diff --git a/previews/271/.buildinfo b/previews/271/.buildinfo new file mode 100644 index 000000000..78e0ec411 --- /dev/null +++ b/previews/271/.buildinfo @@ -0,0 +1,4 @@ +# Sphinx build info version 1 +# This file records the configuration used when building these files. When it is not found, a full rebuild will be done. +config: fdc44998c329910305b7635681c02437 +tags: 645f666f9bcd5a90fca523b33c5a78b7 diff --git a/previews/271/.doctrees/bsp/imx8/imx8.doctree b/previews/271/.doctrees/bsp/imx8/imx8.doctree new file mode 100644 index 000000000..b78bc6aab Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mm/head.doctree b/previews/271/.doctrees/bsp/imx8/imx8mm/head.doctree new file mode 100644 index 000000000..425a83f30 Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mm/head.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mm/imx8mm.doctree b/previews/271/.doctrees/bsp/imx8/imx8mm/imx8mm.doctree new file mode 100644 index 000000000..2d91948c4 Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mm/imx8mm.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mm/pd22.1.1.doctree b/previews/271/.doctrees/bsp/imx8/imx8mm/pd22.1.1.doctree new file mode 100644 index 000000000..0295d37e8 Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mm/pd22.1.1.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mm/pd23.1.0.doctree b/previews/271/.doctrees/bsp/imx8/imx8mm/pd23.1.0.doctree new file mode 100644 index 000000000..d0bbacf3c Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mm/pd23.1.0.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mn/head.doctree b/previews/271/.doctrees/bsp/imx8/imx8mn/head.doctree new file mode 100644 index 000000000..8f69cd399 Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mn/head.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mn/imx8mn.doctree b/previews/271/.doctrees/bsp/imx8/imx8mn/imx8mn.doctree new file mode 100644 index 000000000..2f18bab44 Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mn/imx8mn.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mn/pd22.1.1.doctree b/previews/271/.doctrees/bsp/imx8/imx8mn/pd22.1.1.doctree new file mode 100644 index 000000000..9083647cc Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mn/pd22.1.1.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mn/pd23.1.0.doctree b/previews/271/.doctrees/bsp/imx8/imx8mn/pd23.1.0.doctree new file mode 100644 index 000000000..3d9629136 Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mn/pd23.1.0.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mp-libra-fpsc/head.doctree b/previews/271/.doctrees/bsp/imx8/imx8mp-libra-fpsc/head.doctree new file mode 100644 index 000000000..e43b9bcf6 Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mp-libra-fpsc/head.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.doctree b/previews/271/.doctrees/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.doctree new file mode 100644 index 000000000..668dd0296 Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mp/head.doctree b/previews/271/.doctrees/bsp/imx8/imx8mp/head.doctree new file mode 100644 index 000000000..7651d37b6 Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mp/head.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mp/imx8mp.doctree b/previews/271/.doctrees/bsp/imx8/imx8mp/imx8mp.doctree new file mode 100644 index 000000000..338048044 Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mp/imx8mp.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mp/mainline-head.doctree b/previews/271/.doctrees/bsp/imx8/imx8mp/mainline-head.doctree new file mode 100644 index 000000000..1ded2af7c Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mp/mainline-head.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mp/pd22.1.1.doctree b/previews/271/.doctrees/bsp/imx8/imx8mp/pd22.1.1.doctree new file mode 100644 index 000000000..406e93603 Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mp/pd22.1.1.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mp/pd22.1.2.doctree b/previews/271/.doctrees/bsp/imx8/imx8mp/pd22.1.2.doctree new file mode 100644 index 000000000..45645a665 Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mp/pd22.1.2.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mp/pd23.1.0.doctree b/previews/271/.doctrees/bsp/imx8/imx8mp/pd23.1.0.doctree new file mode 100644 index 000000000..b325f7ace Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mp/pd23.1.0.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mp/pd24.1.0_nxp.doctree b/previews/271/.doctrees/bsp/imx8/imx8mp/pd24.1.0_nxp.doctree new file mode 100644 index 000000000..7b5ef1671 Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mp/pd24.1.0_nxp.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mp/pd24.1.1.doctree b/previews/271/.doctrees/bsp/imx8/imx8mp/pd24.1.1.doctree new file mode 100644 index 000000000..2cd44fb0b Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mp/pd24.1.1.doctree differ diff --git a/previews/271/.doctrees/bsp/imx8/imx8mp/pd24.1.2.doctree b/previews/271/.doctrees/bsp/imx8/imx8mp/pd24.1.2.doctree new file mode 100644 index 000000000..c99efe0c4 Binary files /dev/null and b/previews/271/.doctrees/bsp/imx8/imx8mp/pd24.1.2.doctree differ diff --git a/previews/271/.doctrees/bsp/imx9/imx9.doctree b/previews/271/.doctrees/bsp/imx9/imx9.doctree new file mode 100644 index 000000000..60658f2fd Binary files /dev/null and b/previews/271/.doctrees/bsp/imx9/imx9.doctree differ diff --git a/previews/271/.doctrees/bsp/imx9/imx93/imx93.doctree b/previews/271/.doctrees/bsp/imx9/imx93/imx93.doctree new file mode 100644 index 000000000..c42993a6a Binary files /dev/null and b/previews/271/.doctrees/bsp/imx9/imx93/imx93.doctree differ diff --git a/previews/271/.doctrees/bsp/imx9/imx93/pd24.1.0.doctree b/previews/271/.doctrees/bsp/imx9/imx93/pd24.1.0.doctree new file mode 100644 index 000000000..eef3a8bfc Binary files /dev/null and b/previews/271/.doctrees/bsp/imx9/imx93/pd24.1.0.doctree differ diff --git a/previews/271/.doctrees/bsp/imx9/imx93/pd24.1.1.doctree b/previews/271/.doctrees/bsp/imx9/imx93/pd24.1.1.doctree new file mode 100644 index 000000000..080bc256e Binary files /dev/null and b/previews/271/.doctrees/bsp/imx9/imx93/pd24.1.1.doctree differ diff --git a/previews/271/.doctrees/bsp/imx9/imx93/pd24.2.0.doctree b/previews/271/.doctrees/bsp/imx9/imx93/pd24.2.0.doctree new file mode 100644 index 000000000..45e0f3974 Binary files /dev/null and b/previews/271/.doctrees/bsp/imx9/imx93/pd24.2.0.doctree differ diff --git a/previews/271/.doctrees/contributing_links.doctree b/previews/271/.doctrees/contributing_links.doctree new file mode 100644 index 000000000..50e9ea8ad Binary files /dev/null and b/previews/271/.doctrees/contributing_links.doctree differ diff --git a/previews/271/.doctrees/environment.pickle b/previews/271/.doctrees/environment.pickle new file mode 100644 index 000000000..c478b3f65 Binary files /dev/null and b/previews/271/.doctrees/environment.pickle differ diff --git a/previews/271/.doctrees/index.doctree b/previews/271/.doctrees/index.doctree new file mode 100644 index 000000000..40024ddf4 Binary files /dev/null and b/previews/271/.doctrees/index.doctree differ diff --git a/previews/271/.doctrees/rauc/kirkstone.doctree b/previews/271/.doctrees/rauc/kirkstone.doctree new file mode 100644 index 000000000..b0811562a Binary files /dev/null and b/previews/271/.doctrees/rauc/kirkstone.doctree differ diff --git a/previews/271/.doctrees/rauc/manual-index.doctree b/previews/271/.doctrees/rauc/manual-index.doctree new file mode 100644 index 000000000..07a07ddbc Binary files /dev/null and b/previews/271/.doctrees/rauc/manual-index.doctree differ diff --git a/previews/271/.doctrees/rauc/mickledore.doctree b/previews/271/.doctrees/rauc/mickledore.doctree new file mode 100644 index 000000000..87acd3b5e Binary files /dev/null and b/previews/271/.doctrees/rauc/mickledore.doctree differ diff --git a/previews/271/.doctrees/rauc/scarthgap.doctree b/previews/271/.doctrees/rauc/scarthgap.doctree new file mode 100644 index 000000000..5b55f406d Binary files /dev/null and b/previews/271/.doctrees/rauc/scarthgap.doctree differ diff --git a/previews/271/.doctrees/yocto/kirkstone.doctree b/previews/271/.doctrees/yocto/kirkstone.doctree new file mode 100644 index 000000000..dc8d768ec Binary files /dev/null and b/previews/271/.doctrees/yocto/kirkstone.doctree differ diff --git a/previews/271/.doctrees/yocto/manual-index.doctree b/previews/271/.doctrees/yocto/manual-index.doctree new file mode 100644 index 000000000..a989b1242 Binary files /dev/null and b/previews/271/.doctrees/yocto/manual-index.doctree differ diff --git a/previews/271/.doctrees/yocto/mickledore.doctree b/previews/271/.doctrees/yocto/mickledore.doctree new file mode 100644 index 000000000..911234ba8 Binary files /dev/null and b/previews/271/.doctrees/yocto/mickledore.doctree differ diff --git a/previews/271/.doctrees/yocto/scarthgap.doctree b/previews/271/.doctrees/yocto/scarthgap.doctree new file mode 100644 index 000000000..8a72e9576 Binary files /dev/null and b/previews/271/.doctrees/yocto/scarthgap.doctree differ diff --git a/previews/271/_images/Internal_Fuses.png b/previews/271/_images/Internal_Fuses.png new file mode 100644 index 000000000..0a280afbb Binary files /dev/null and b/previews/271/_images/Internal_Fuses.png differ diff --git a/previews/271/_images/Internal_Fuses1.png b/previews/271/_images/Internal_Fuses1.png new file mode 100644 index 000000000..32ca2d2fa Binary files /dev/null and b/previews/271/_images/Internal_Fuses1.png differ diff --git a/previews/271/_images/Internal_Fuses2.png b/previews/271/_images/Internal_Fuses2.png new file mode 100644 index 000000000..32ca2d2fa Binary files /dev/null and b/previews/271/_images/Internal_Fuses2.png differ diff --git a/previews/271/_images/JTAG_Mode.png b/previews/271/_images/JTAG_Mode.png new file mode 100644 index 000000000..287da4792 Binary files /dev/null and b/previews/271/_images/JTAG_Mode.png differ diff --git a/previews/271/_images/Libra-back-components.jpg b/previews/271/_images/Libra-back-components.jpg new file mode 100644 index 000000000..534205954 Binary files /dev/null and b/previews/271/_images/Libra-back-components.jpg differ diff --git a/previews/271/_images/Libra-front-components.jpg b/previews/271/_images/Libra-front-components.jpg new file mode 100644 index 000000000..6365565db Binary files /dev/null and b/previews/271/_images/Libra-front-components.jpg differ diff --git a/previews/271/_images/Nano_Fuse_BOOT.png b/previews/271/_images/Nano_Fuse_BOOT.png new file mode 100644 index 000000000..ce4d135f2 Binary files /dev/null and b/previews/271/_images/Nano_Fuse_BOOT.png differ diff --git a/previews/271/_images/Nano_QSPI_BOOT.png b/previews/271/_images/Nano_QSPI_BOOT.png new file mode 100644 index 000000000..b6560ec84 Binary files /dev/null and b/previews/271/_images/Nano_QSPI_BOOT.png differ diff --git a/previews/271/_images/Nano_SD_BOOT.jpg b/previews/271/_images/Nano_SD_BOOT.jpg new file mode 100644 index 000000000..8d9b9042c Binary files /dev/null and b/previews/271/_images/Nano_SD_BOOT.jpg differ diff --git a/previews/271/_images/Nano_Serial_downloader_BOOT.png b/previews/271/_images/Nano_Serial_downloader_BOOT.png new file mode 100644 index 000000000..9814af8a5 Binary files /dev/null and b/previews/271/_images/Nano_Serial_downloader_BOOT.png differ diff --git a/previews/271/_images/Nano_eMMC_BOOT.png b/previews/271/_images/Nano_eMMC_BOOT.png new file mode 100644 index 000000000..b80e6d659 Binary files /dev/null and b/previews/271/_images/Nano_eMMC_BOOT.png differ diff --git a/previews/271/_images/RS485_fullduplex_connection.png b/previews/271/_images/RS485_fullduplex_connection.png new file mode 100644 index 000000000..050e123f9 Binary files /dev/null and b/previews/271/_images/RS485_fullduplex_connection.png differ diff --git a/previews/271/_images/RS485_halfduplex_connection.png b/previews/271/_images/RS485_halfduplex_connection.png new file mode 100644 index 000000000..4db999ecd Binary files /dev/null and b/previews/271/_images/RS485_halfduplex_connection.png differ diff --git a/previews/271/_images/RS485_halfduplex_connection1.png b/previews/271/_images/RS485_halfduplex_connection1.png new file mode 100644 index 000000000..4db999ecd Binary files /dev/null and b/previews/271/_images/RS485_halfduplex_connection1.png differ diff --git a/previews/271/_images/RS485_halfduplex_connection2.png b/previews/271/_images/RS485_halfduplex_connection2.png new file mode 100644 index 000000000..9b599a9ab Binary files /dev/null and b/previews/271/_images/RS485_halfduplex_connection2.png differ diff --git a/previews/271/_images/RS485_halfduplex_connection3.png b/previews/271/_images/RS485_halfduplex_connection3.png new file mode 100644 index 000000000..9b599a9ab Binary files /dev/null and b/previews/271/_images/RS485_halfduplex_connection3.png differ diff --git a/previews/271/_images/SD_Card_Boot.jpg b/previews/271/_images/SD_Card_Boot.jpg new file mode 100644 index 000000000..ec7224420 Binary files /dev/null and b/previews/271/_images/SD_Card_Boot.jpg differ diff --git a/previews/271/_images/SD_Card_Boot.png b/previews/271/_images/SD_Card_Boot.png new file mode 100644 index 000000000..0fee073cd Binary files /dev/null and b/previews/271/_images/SD_Card_Boot.png differ diff --git a/previews/271/_images/SD_Card_Boot1.png b/previews/271/_images/SD_Card_Boot1.png new file mode 100644 index 000000000..875841b6d Binary files /dev/null and b/previews/271/_images/SD_Card_Boot1.png differ diff --git a/previews/271/_images/SD_Card_Boot2.png b/previews/271/_images/SD_Card_Boot2.png new file mode 100644 index 000000000..875841b6d Binary files /dev/null and b/previews/271/_images/SD_Card_Boot2.png differ diff --git a/previews/271/_images/SPI_NOR.png b/previews/271/_images/SPI_NOR.png new file mode 100644 index 000000000..4dbc34b4c Binary files /dev/null and b/previews/271/_images/SPI_NOR.png differ diff --git a/previews/271/_images/SPI_NOR1.png b/previews/271/_images/SPI_NOR1.png new file mode 100644 index 000000000..497f23e66 Binary files /dev/null and b/previews/271/_images/SPI_NOR1.png differ diff --git a/previews/271/_images/SPI_NOR2.png b/previews/271/_images/SPI_NOR2.png new file mode 100644 index 000000000..497f23e66 Binary files /dev/null and b/previews/271/_images/SPI_NOR2.png differ diff --git a/previews/271/_images/Test_Mode.png b/previews/271/_images/Test_Mode.png new file mode 100644 index 000000000..287da4792 Binary files /dev/null and b/previews/271/_images/Test_Mode.png differ diff --git a/previews/271/_images/UART1_RS232.jpg b/previews/271/_images/UART1_RS232.jpg new file mode 100644 index 000000000..b953cf79b Binary files /dev/null and b/previews/271/_images/UART1_RS232.jpg differ diff --git a/previews/271/_images/UART1_RS2321.jpg b/previews/271/_images/UART1_RS2321.jpg new file mode 100644 index 000000000..b80e6d659 Binary files /dev/null and b/previews/271/_images/UART1_RS2321.jpg differ diff --git a/previews/271/_images/UART1_RS485.png b/previews/271/_images/UART1_RS485.png new file mode 100644 index 000000000..96a081be0 Binary files /dev/null and b/previews/271/_images/UART1_RS485.png differ diff --git a/previews/271/_images/UART1_RS4851.png b/previews/271/_images/UART1_RS4851.png new file mode 100644 index 000000000..ed819f644 Binary files /dev/null and b/previews/271/_images/UART1_RS4851.png differ diff --git a/previews/271/_images/USB_HOST.jpg b/previews/271/_images/USB_HOST.jpg new file mode 100644 index 000000000..b80e6d659 Binary files /dev/null and b/previews/271/_images/USB_HOST.jpg differ diff --git a/previews/271/_images/USB_OTG.png b/previews/271/_images/USB_OTG.png new file mode 100644 index 000000000..fe72b24f3 Binary files /dev/null and b/previews/271/_images/USB_OTG.png differ diff --git a/previews/271/_images/USB_Serial_Download.png b/previews/271/_images/USB_Serial_Download.png new file mode 100644 index 000000000..875841b6d Binary files /dev/null and b/previews/271/_images/USB_Serial_Download.png differ diff --git a/previews/271/_images/USB_Serial_Download1.png b/previews/271/_images/USB_Serial_Download1.png new file mode 100644 index 000000000..6453fe0ab Binary files /dev/null and b/previews/271/_images/USB_Serial_Download1.png differ diff --git a/previews/271/_images/USB_Serial_Download2.png b/previews/271/_images/USB_Serial_Download2.png new file mode 100644 index 000000000..0fee073cd Binary files /dev/null and b/previews/271/_images/USB_Serial_Download2.png differ diff --git a/previews/271/_images/USB_Serial_Download3.png b/previews/271/_images/USB_Serial_Download3.png new file mode 100644 index 000000000..0fee073cd Binary files /dev/null and b/previews/271/_images/USB_Serial_Download3.png differ diff --git a/previews/271/_images/eMMC.jpg b/previews/271/_images/eMMC.jpg new file mode 100644 index 000000000..d41dc9ac3 Binary files /dev/null and b/previews/271/_images/eMMC.jpg differ diff --git a/previews/271/_images/eMMC.png b/previews/271/_images/eMMC.png new file mode 100644 index 000000000..32ca2d2fa Binary files /dev/null and b/previews/271/_images/eMMC.png differ diff --git a/previews/271/_images/eMMC1.png b/previews/271/_images/eMMC1.png new file mode 100644 index 000000000..0a280afbb Binary files /dev/null and b/previews/271/_images/eMMC1.png differ diff --git a/previews/271/_images/eMMC2.png b/previews/271/_images/eMMC2.png new file mode 100644 index 000000000..0a280afbb Binary files /dev/null and b/previews/271/_images/eMMC2.png differ diff --git a/previews/271/_images/gparted1.png b/previews/271/_images/gparted1.png new file mode 100644 index 000000000..5f6f842b6 Binary files /dev/null and b/previews/271/_images/gparted1.png differ diff --git a/previews/271/_images/gparted2.png b/previews/271/_images/gparted2.png new file mode 100644 index 000000000..149853c35 Binary files /dev/null and b/previews/271/_images/gparted2.png differ diff --git a/previews/271/_images/gparted3.png b/previews/271/_images/gparted3.png new file mode 100644 index 000000000..7caee2797 Binary files /dev/null and b/previews/271/_images/gparted3.png differ diff --git a/previews/271/_images/gparted4.png b/previews/271/_images/gparted4.png new file mode 100644 index 000000000..857f75b38 Binary files /dev/null and b/previews/271/_images/gparted4.png differ diff --git a/previews/271/_images/gparted5.png b/previews/271/_images/gparted5.png new file mode 100644 index 000000000..134a259b6 Binary files /dev/null and b/previews/271/_images/gparted5.png differ diff --git a/previews/271/_images/gparted6.png b/previews/271/_images/gparted6.png new file mode 100644 index 000000000..5593f49e7 Binary files /dev/null and b/previews/271/_images/gparted6.png differ diff --git a/previews/271/_images/gparted7.png b/previews/271/_images/gparted7.png new file mode 100644 index 000000000..45d967808 Binary files /dev/null and b/previews/271/_images/gparted7.png differ diff --git a/previews/271/_images/gparted8.png b/previews/271/_images/gparted8.png new file mode 100644 index 000000000..644191954 Binary files /dev/null and b/previews/271/_images/gparted8.png differ diff --git a/previews/271/_images/phyBOARD-Nash-iMX93-bottom-components.jpg b/previews/271/_images/phyBOARD-Nash-iMX93-bottom-components.jpg new file mode 100644 index 000000000..888a1ceb3 Binary files /dev/null and b/previews/271/_images/phyBOARD-Nash-iMX93-bottom-components.jpg differ diff --git a/previews/271/_images/phyBOARD-Nash-iMX93-top-components.jpg b/previews/271/_images/phyBOARD-Nash-iMX93-top-components.jpg new file mode 100644 index 000000000..74c3a4ed4 Binary files /dev/null and b/previews/271/_images/phyBOARD-Nash-iMX93-top-components.jpg differ diff --git a/previews/271/_images/phyBOARD-Pollux-back-components.jpg b/previews/271/_images/phyBOARD-Pollux-back-components.jpg new file mode 100644 index 000000000..534205954 Binary files /dev/null and b/previews/271/_images/phyBOARD-Pollux-back-components.jpg differ diff --git a/previews/271/_images/phyBOARD-Pollux-front-components.jpg b/previews/271/_images/phyBOARD-Pollux-front-components.jpg new file mode 100644 index 000000000..6365565db Binary files /dev/null and b/previews/271/_images/phyBOARD-Pollux-front-components.jpg differ diff --git a/previews/271/_images/phyBOARD-Segin-iMX93-bottom-components.jpg b/previews/271/_images/phyBOARD-Segin-iMX93-bottom-components.jpg new file mode 100644 index 000000000..7c484f384 Binary files /dev/null and b/previews/271/_images/phyBOARD-Segin-iMX93-bottom-components.jpg differ diff --git a/previews/271/_images/phyBOARD-Segin-iMX93-top-components.jpg b/previews/271/_images/phyBOARD-Segin-iMX93-top-components.jpg new file mode 100644 index 000000000..d849aedca Binary files /dev/null and b/previews/271/_images/phyBOARD-Segin-iMX93-top-components.jpg differ diff --git a/previews/271/_images/polis-back.jpg b/previews/271/_images/polis-back.jpg new file mode 100644 index 000000000..57cefde84 Binary files /dev/null and b/previews/271/_images/polis-back.jpg differ diff --git a/previews/271/_images/polis-front.jpg b/previews/271/_images/polis-front.jpg new file mode 100644 index 000000000..8a36aec26 Binary files /dev/null and b/previews/271/_images/polis-front.jpg differ diff --git a/previews/271/_images/rauc-ab-system.png b/previews/271/_images/rauc-ab-system.png new file mode 100644 index 000000000..8ba234506 Binary files /dev/null and b/previews/271/_images/rauc-ab-system.png differ diff --git a/previews/271/_images/rauc-switching-keyrings.png b/previews/271/_images/rauc-switching-keyrings.png new file mode 100644 index 000000000..db8aba14c Binary files /dev/null and b/previews/271/_images/rauc-switching-keyrings.png differ diff --git a/previews/271/_sources/bsp/imx8/imx8.rst.txt b/previews/271/_sources/bsp/imx8/imx8.rst.txt new file mode 100644 index 000000000..dd4ea56b7 --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8.rst.txt @@ -0,0 +1,12 @@ +============== +i.MX 8 Manuals +============== + +.. toctree:: + :caption: i.MX 8 Manuals + :maxdepth: 2 + + i.MX 8M Plus Manuals + Libra i.MX 8M Plus FPSC Manuals + i.MX 8M Mini Manuals + i.MX 8M Nano Manuals diff --git a/previews/271/_sources/bsp/imx8/imx8mm/head.rst.txt b/previews/271/_sources/bsp/imx8/imx8mm/head.rst.txt new file mode 100644 index 000000000..9e1a8ac42 --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mm/head.rst.txt @@ -0,0 +1,571 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt6demo-image-phyboard-polis-imx8mm-5.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/imx-boot-tools/ +.. |link-bsp-images| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mm +.. _`static-pdf-dl`: ../../../_static/imx8mm-head.pdf + +.. IMX8(MM) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mm/phycore-imx8mm.c?h=v2022.04_2.2.2-phy5#n120 + + +.. General Replacements +.. |doc-id| replace:: L-1002e.Ax +.. |kit| replace:: **phyCORE-i.MX8M Mini Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Polis +.. |soc| replace:: i.MX 8M Mini +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MM +.. |debug-uart| replace:: ttymxc2 +.. |serial-uart| replace:: ttymxc0 +.. |bluetooth-uart| replace:: UART2 +.. |expansion-connector| replace:: X8 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx8_phytec_defconfig +.. |kernel-recipe-path| replace:: meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb +.. |kernel-repo-name| replace:: linux-phytec-imx +.. |kernel-repo-url| replace:: https://github.com/phytec/linux-phytec-imx +.. |kernel-socname| replace:: imx8mm +.. |kernel-tag| replace:: v5.15.71_2.2.2-phy3 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-offset| replace:: 33 +.. |u-boot-offset-boot-part| replace:: 33 +.. |u-boot-mmc-flash-offset| replace:: 0x42 +.. |u-boot-defconfig| replace:: phycore-imx8mm_defconfig +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx +.. |emmcdev-uboot| replace:: mmc 2 +.. |sdcarddev-uboot| replace:: mmc 1 + + +.. IMX8(MM) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MM +.. |u-boot-tag| replace:: v2022.04_2.2.2-phy5 + + +.. RAUC +.. |rauc-manual| replace:: L-1006e.A6 RAUC Update & Device Management Manual +.. _rauc-manual: https://www.phytec.de/cdocuments/?doc=F4DiM + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mm-phyboard-polis-rdk +.. |dt-som| replace:: imx8mm-phycore-som +.. |dtbo-rpmsg| replace:: imx8mm-phycore-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mm-phyboard-polis-peb-av-10.dtbo + +.. IMX8(MM) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n59` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`scarthgap` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MM +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: scarthgap +.. |yocto-distro| replace:: ampliphy-vendor +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: rootfs.wic.xz +.. |yocto-machinename| replace:: phyboard-polis-imx8mm-5 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MM-PD24.1.0 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MM-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MM-PD24.1.y +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (scarthgap) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 5.0.x +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Refs +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S1) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X30) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X2 ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MM) specific replacements +.. |sbc-network| replace:: \ +.. |pollux-fan-note| replace:: Only GPIO fan supported. +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M4 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mm_phyboard_polis/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8MM6_M4 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++----------------------+----------------------+ +| |doc-id| |soc| BSP | +| Manual Head | ++----------------------+----------------------+ +| Document Title | |doc-id| |soc| BSP | +| | Manual Head | ++----------------------+----------------------+ +| Document Type | BSP Manual | ++----------------------+----------------------+ +| Article Number | |doc-id| | ++----------------------+----------------------+ +| Yocto Manual | | ++----------------------+----------------------+ +| Release Date | XXXX/XX/XX | ++----------------------+----------------------+ +| Is Branch of | |doc-id| |soc| BSP | +| | Manual Head | ++----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +================ ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +================ ================ ================= ========== +.. +================ ================ ================= ========== + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +The |sbc| populated with either the i.MX 8M Mini SoC or i.MX 8M Nano SoC, is +supported. + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mm-head-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mm-head-getting-started: +.. include:: /bsp/getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, |ref-bootswitch| needs to be set to the following + position: + +.. list-table:: Bootmode Selection + + * - .. figure:: images/SD_Card_Boot.jpg + + Mini + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP | +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mm-head-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mm.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **fitImage**: Linux kernel FIT image +* **fitImage-its\*.its**: FIT image configuration file +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mm-phyboard-polis-rdk*.dtb**: Kernel device tree file +* **imx8mm-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.rootfs.wic.xz**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S1) +-------------------- + +The |sbc| features a boot switch with six individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mm-head-bootswitch: +.. include:: bootmode-switch.rsti + +.. include:: ../installing-os.rsti + +.. include:: ../efi.rsti +.. include:: /bsp/installing-distro-efi.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mm-head-development: + +Development +=========== + +Starting with this release, the boot behaviour in U-Boot changes. Before, kernel +and device tree came as separate blobs. Now, both will be included in a single +FIT image blob. Further, the logic for booting the PHYTEC ampliphy distributions +is moved to a boot script which itself is part of a separate FIT image blob. +To revert to the old style of booting, you may do + +.. code-block:: console + + u-boot=> run legacyboot + +.. note:: + + This way of booting is deprecated and will be removed in the next release. + By default, booting via this command will return an error as kernel and + device tree are missing in the boot partition. + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti +.. _imx8mm-head-development-build-uboot: +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti +.. include:: /bsp/imx8/development/kernel-standalone.rsti +.. include:: /bsp/imx-common/development/uuu.rsti + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx8/development/netboot.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mm-head-format-sd: + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. include:: /bsp/imx8/development/legacy_boot_deprecated.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mm-head-device-tree: +.. include:: /bsp/device-tree.rsti + +:: + + imx8mm-phyboard-polis-peb-eval-01.dtbo + |dtbo-peb-av-10| + imx8mm-phycore-rpmsg.dtbo + imx8mm-phycore-no-eth.dtbo + imx8mm-phycore-no-spiflash.dtbo + imx8mm-vm016.dtbo + imx8mm-vm016-fpdlink.dtbo + imx8mm-vm017.dtbo + imx8mm-vm017-fpdlink.dtbo + imx8mm-dual-vm017-fpdlink.dtbo + +.. _imx8mm-head-ubootexternalenv: +.. include:: ../../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX 0x00 + MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX 0x00 + MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B 0x00 + MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B 0x00 + >; + }; + +The first part of the string MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad (in this example +SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the desired muxing option for this pad. +The pad setting value (hex value on the right) defines different modes of the pad, for example, if +internal pull resistors are activated or not. In this case, the internal resistors are disabled. + +RS232/RS485 +----------- + +The |soc| SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +|ref-bootswitch| needs to be set correctly: + +.. list-table:: Switch between UART1 RS485/RS232 + + * - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS485.png + + **UART1 RS485** + + - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS232.jpg + + **UART1 RS232** + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n291` + +.. _imx8mm-head-network: + +Network +------- + +|sbc|-|soc| provides one Gigabit Ethernet interface. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +.. include:: ../../peripherals/wireless-network.rsti + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n383` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n335` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n87` + +.. include:: ../peripherals/gpios.rsti + +Pinmuxing of some GPIO pins in the device tree |dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_leds: leds1grp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1 0x16 + MX8MM_IOMUXC_GPIO1_IO14_GPIO1_IO14 0x16 + MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x16 + >; + }; + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n36` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n119` + +General I²C4 bus configuration (e.g. |dt-carrierboard|.dts): +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n244` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues. + +.. note:: + + If you deleted reserved EEPROM spaces, please contact our support! + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file |dt-som|.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n311` + +.. include:: /bsp/peripherals/rtc.rsti + +DT representation for I²C RTCs: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n319` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +'HS'). The USB subsystem has two independent USB controller cores. Both cores +are On-The-Go (OTG) controller cores and are capable of acting as a USB +peripheral device or a USB host. Each is connected to a USB 2.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +User USB2 (host) configuration is in the kernel device tree +|dt-carrierboard|.dts: + +.. code-block:: + + &usbotg2 { + dr_mode = "host"; + picophy,pre-emp-curr-control = <3>; + picophy,dc-vol-level-adjust = <7>; + status = "okay"; + }; + +DT representation for USB Host: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n347` + +.. include:: /bsp/peripherals/usb-otg.rsti + +Both USB interfaces are configured as host in the kernel device tree +|dt-carrierboard|.dts. See: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n335` + +CAN FD +------ + +The |sbc| has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. Hint:: + + phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. + There are different interfaces involved, which limits the datarate + capabilities of CANFD. + +.. Hint:: + + On phyBOARD-Polis-i.MX8MM a terminating resistor can be enabled by setting + S5 to ON if required. + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n175` + +.. include:: /bsp/peripherals/pcie.rsti + +Device Tree PCIe configuration of |dt-carrierboard|.dts: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n257` + +Audio +----- + +The PEB-AV-10-Connector exists in two versions and the 1531.1 version is +populated with a TI TLV320AIC3007 audio codec. Audio support is done via the I2S +interface and controlled via I2C. + +There is a 3.5mm headset jack with OMTP standard and an 8-pin header to connect +audio devices with the AV-Connector. The 8-pin header contains a mono speaker, +headphones, and line-in signals. + +.. include:: /bsp/peripherals/audio.rsti + +Device Tree Audio configuration: +:imx-dt:`overlays/imx8mm-phyboard-polis-peb-av-010.dtsi?h=v5.15.71_2.2.2-phy3#n54` + +.. include:: /bsp/peripherals/video.rsti + +Display +------- + +The 10" Display is always active. If the PEB-AV-Connector is not connected, an +error message may occur at boot. + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +The device tree of PEB-AV-10 can be found here: +:imx-dt:`overlays/imx8mm-phyboard-polis-peb-av-010.dtsi?h=v5.15.71_2.2.2-phy3` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Mini M4 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti + +.. +---------------------------------------------------------------------------+ +.. BSP EXTENSIONS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/bsp-extensions.rsti diff --git a/previews/271/_sources/bsp/imx8/imx8mm/imx8mm.rst.txt b/previews/271/_sources/bsp/imx8/imx8mm/imx8mm.rst.txt new file mode 100644 index 000000000..466d3e555 --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mm/imx8mm.rst.txt @@ -0,0 +1,33 @@ +==================== +i.MX 8M Mini Manuals +==================== + +HEAD +==== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + head + +BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +============================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd23.1.0 + +BSP-Yocto-NXP-i.MX8MM-PD22.1.1 +============================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd22.1.1 diff --git a/previews/271/_sources/bsp/imx8/imx8mm/pd22.1.1.rst.txt b/previews/271/_sources/bsp/imx8/imx8mm/pd22.1.1.rst.txt new file mode 100644 index 000000000..b95972496 --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mm/pd22.1.1.rst.txt @@ -0,0 +1,2435 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MM-PD22.1.1 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/imx-boot-tools/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mm +.. _`static-pdf-dl`: ../../../_static/imx8mm-pd22.1.1.pdf + +.. IMX8(MM) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mm/phycore-imx8mm.c?h=v2021.04_2.2.0-phy13#n188 + + +.. General Replacements +.. |atfloadaddr| replace:: 0x920000 +.. |kit| replace:: **phyCORE-i.MX8M Mini Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Polis +.. |soc| replace:: i.MX 8M Mini +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MM +.. |debug-uart| replace:: ttymxc2 +.. |serial-uart| replace:: ttymxc0 +.. |expansion-connector| replace:: X8 +.. |bluetooth-uart| replace:: UART2 + + +.. Linux Kernel +.. |kernel-socname| replace:: imx8mm +.. |kernel-tag| replace:: v5.10.72_2.2.0-phy17 +.. |emmcdev| replace:: mmcblk2 +.. |kernel-defconfig| replace:: imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx + +.. Bootloader +.. |u-boot-offset| replace:: 33 +.. |u-boot-offset-boot-part| replace:: 33 +.. |u-boot-mmc-flash-offset| replace:: 0x42 +.. |u-boot-defconfig| replace:: phycore-imx8mm_defconfig +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX8(MM) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MM +.. |u-boot-tag| replace:: v2021.04_2.2.0-phy13 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mm-phyboard-polis-rdk +.. |dt-som| replace:: imx8mm-phycore-som +.. |dtbo-rpmsg| replace:: imx8mm-phycore-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mm-phyboard-polis-peb-av-010.dtbo + +.. IMX8(MM) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n53` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`hardknott` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MM +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: hardknott +.. |yocto-distro| replace:: ampliphy-vendor-xwayland +.. |yocto-imagename| replace:: phytec-qt5demo-image +.. |yocto-machinename| replace:: phyboard-polis-imx8mm-5 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MM-PD22.1.1 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MM-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MM-PD22.1.y +.. |yocto-ref-manual| replace:: L-813e.A13 Yocto Reference Manual (hardknott) +.. _yocto-ref-manual: https://www.phytec.de/cdocuments/?doc=UIHsG +.. _yocto-ref-manual-kernel-and-bootloader-config: https://www.phytec.de/cdocuments/?doc=UIHsG#YoctoReferenceManualHardknottL813e-A12-KernelandBootloaderConfiguration +.. |yocto-sdk-rev| replace:: BSP-Yocto-NXP-i.MX8MM-PD22.1.1 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Refs +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S1) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X30) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X2 ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` + + +.. IMX8(MM) specific replacements +.. |sbc-network| replace:: \ +.. |pollux-fan-note| replace:: Only GPIO fan supported. +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M4 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mm_phyboard_polis/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8MM6_M4 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++----------------------+----------------------+ +| |soc| BSP Manual | ++----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++----------------------+----------------------+ +| Document Type | BSP Manual | ++----------------------+----------------------+ +| Yocto Manual | | ++----------------------+----------------------+ +| Release Date | 2023/05/25 | ++----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================= ========== +|yocto-manifestname| Minor 2023/05/23 Released +==================== ================ ================= ========== + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +The |sbc| populated with either the i.MX 8M Mini SoC or i.MX 8M Nano SoC, is +supported. + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mm-pd22.1.1-components: +.. include:: components.rsti + +Getting Started +=============== + +The |kit| is shipped with a pre-flashed SD card. It contains the +|yocto-imagename| and can be used directly as a boot source. The eMMC is +programmed with only a U-boot by default. You can get all sources from the +`PHYTEC download server `_. This chapter explains how to flash a BSP +image to SD card and how to start the board. + +Get the Image +------------- + +The WIC image contains all BSP files in several, correctly pre-formatted +partitions and can be copied to an SD card easily using the single Linux +command ``dd``. It can be built by Yocto or downloaded from the PHYTEC download +server. + +Get the WIC file from the download server: + +.. code-block:: console + :substitutions: + + host:~$ wget |link-image| + +Write the Image to SD Card +-------------------------- + +.. warning:: + To create your bootable SD card with the ``dd`` command, you must have root + privileges. Be very careful when specifying the destination device with + ``dd``! All files on the selected destination device will be erased + immediately without any further query! + + Selecting the wrong device may result in **data loss** and e.g. could erase + your currently running system! + +To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. Unmount any mounted partitions before +you start copying the image to the SD card. + +#. In order to get the correct device name, remove your SD card and + execute:: + + host$ lsblk + +#. Now insert your SD card and execute the command again:: + + host$ lsblk + +#. Compare the two outputs to find the new device names listed in the second + output. These are the device names of the SD card (device and partitions if + the SD card was formatted). +#. In order to verify the device names being found, execute the command + ``sudo dmesg``. Within the last lines of its output, you should also find the + device names, e.g. ``/dev/sde`` or ``/dev/mmcblk0`` (depending on your + system). + +Alternatively, you may use a graphical program of your choice, like `GNOME Disks +`_ or `KDE Partition Manager +`_, to find the correct device. + +Now that you have the correct device name, e.g. ``/dev/sde``, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. ``/dev/sde1``) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption. + +* Unmount all partitions, e.g.:: + + host$ sudo umount /dev/sde1 + +* After having unmounted all partitions, you can create your bootable SD card:: + + host$ sudo dd if=-.wic of=/dev/sdX bs=1M conv=fsync status=progress + + Again, make sure to replace ``/dev/sdX`` with your actual device name found + previously. + + The parameter ``conv=fsync`` forces a sync operation on the device before + ``dd`` returns. This ensures that all blocks are written to the SD card and + none are left in memory. The parameter ``status=progress`` will print out + information on how much data is and still has to be copied until it is + finished. + +An alternative and much faster way to prepare an SD card can be done by using +`bmap-tools `_ from Intel. Yocto +automatically creates a block map file (``-.wic.bmap``) for +the WIC image that describes the image content and includes checksums for data +integrity. *bmaptool* is packaged by various Linux distributions. For +Debian-based systems install it by issuing:: + + host$ sudo apt install bmap-tools + +Flash a WIC image to SD card by calling:: + + host$ bmaptool copy -.wic /dev/ + +.. warning:: + *bmaptool* only overwrites the areas of an SD card where image data is + located. This means that a previously written U-Boot environment may still be + available after writing the image. + +First Start-up +-------------- + +* To boot from an SD card, |ref-bootswitch| needs to be set to the following + position: + +.. list-table:: Bootmode Selection + + * - .. figure:: images/SD_Card_Boot.jpg + + Mini + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP | +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mm-pd22.1.1-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mm.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mm-phyboard-polis-rdk*.dtb**: Kernel device tree file +* **imx8mm-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt5demo-image\*.tar.gz**: Root file system +* **phytec-qt5demo-image\*.wic**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S1) +-------------------- + +The |sbc| features a boot switch with six individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mm-pd22.1.1-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **Default SOM boot**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. However, they only +work if the size of the image file is less than 1GB. If the image file is +larger, go to the section Format SD Card. Configure the |ref-bootswitch| to boot +from SD Card and put in an SD card. Power on the board and stop in U-Boot +prompt. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +* Load your image via network to RAM: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* Write the image to the eMMC: + + .. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + A working network is necessary! Setup Network Host. + +Take a compressed or uncompressed image on the host and send it with ssh through +the network (then uncompress it, if necessary) to the eMMC of the target with a +one-line command: + +.. code-block:: console + :substitutions: + + target:~$ ssh @192.168.3.10 "dd if=/|yocto-imagename|-|yocto-machinename|.wic" | dd of=/dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +Send the image with the command dd command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2" + +Flash eMMC u-boot image via Network from running u-boot +....................................................... + +Update the standalone u-boot image imx-boot is also possible from u-boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB +................... + +Flash eMMC from USB in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in Bootloader after enabling the OPTEE. + +These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch to |ref-bootswitch| and put in an SD card. Power on the board +and stop in u-boot prompt. Insert a USB device with the copied WIC image +to the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} *.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the bootmode switch to +|ref-bootswitch|. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ cd /mnt + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2boot0; mmcblk2boot1) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + +.. warning:: + + Before this will work, you need to configure the multi-port switch + to **Default SOM Boot** to |ref-bootswitch|. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see |ref-format-sd|. + +Flash eMMC from SD card in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in Bootloader after enabling the OPTEE. If the + image file is too large use the `Updating eMMC from SD card in + Linux on Target` subsection. + +* Flash an SD card with a working image and create a third FAT partition. Copy + the WIC image (for example |yocto-imagename|.wic) to this + partition. +* Configure the bootmode switch to boot from the SD Card and insert the SD + card. +* Power on the board and stop in u-boot. +* Flash your WIC image (for example |yocto-imagename|.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> fatload mmc 1:3 ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc0(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the multi-port switch to Default SOM Boot to + boot from eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a complete image saved on +the SD card (e.g. |yocto-imagename|-|yocto-machinename|.wic). + +* Show your saved image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2\ **boot0**; mmcblk2\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + +.. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to Default + SOM Boot to boot from eMMC. + +Flash SPI NOR Flash +------------------- + +The |som| modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set |ref-bootswitch| to **QSPI boot** to boot from QSPI. The SPI Flash is +usually quite small. The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash +populated. Only the bootloader and the environment can be stored. The kernel, +device tree, and file system are taken from eMMC by default. + +The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with: + +.. code-block:: + + u-boot=> printenv mtdparts + mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none) + +Flash SPI NOR Flash from Network +................................ + +The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-|soc|. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Flash SPI NOR from Network in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI-NOR flash needs to be probed: + +.. code-block:: + + u-boot=> sf probe + SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB + +* A specially formatted u-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image over tftp, erase and write the + bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + device 0 offset 0x0, size 0x1c0b20 + 1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +.. warning:: + + Erasing the complete SPI NOR flash when it is fully written will take quite + some time. This can trigger the watchdog to reset. Due to this, erase the + full flash in Linux. + +Flash SPI NOR from Network in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the image from the host to the target: + + .. code-block:: console + :substitutions: + + host:~$ scp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root + +* Find the number of erase blocks of the U-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +Flash SPI NOR Flash from SD Card +................................ + +The bootloader on SPI NOR flash can be also flashed with SD Card. + +Flash SPI NOR from SD Card in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the FAT partition + on the SD Card. Before reading and writing are possible, the SPI-NOR flash + needs to be probed: + + .. code-block:: + + u-boot=> sf probe + SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB + +* A specially formatted U-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image from the SD Card, erase and write + the bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +.. warning:: + + Erasing the complete SPI NOR flash when it is fully written will take quite + some time. This can trigger the watchdog to reset. Due to this, erase the + full flash in Linux. + +Flash SPI NOR from SD Card in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Mount the SD Card: + + .. code-block:: console + :substitutions: + + host:~$ mount /dev/mmcblkp1 /mnt + +* Find the number of erase blocks of the u-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp /mnt/imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A3 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mm-pd22.1.1-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + +.. _imx8mm-pd22.1.1-development-build-uboot: + +U-Boot standalone build +----------------------- + +Get the source code +................... + +* Get the U-Boot sources: + + .. code-block:: console + + host:~$ git clone git://git.phytec.de/u-boot-imx + +* To get the correct *U-Boot* **tag** you need to take a look at our release + notes, which can be found here: `release notes `_ +* The **tag** needed at this release is called |u-boot-tag| +* Check out the needed *U-Boot* **tag**: + +.. code-block:: console + :substitutions: + + host:~$ cd ~/u-boot-imx/ + host:~$ git fetch --all --tags + host:~$ git checkout tags/|u-boot-tag| + +* Technically, you can now build the U-Boot, but practically there are some + further steps necessary: + + * Create your own development branch: + + .. code-block:: console + + host:~$ git switch --create + + .. note:: + + You can name your development branch as you like, this is just an example. + +* Set up a build environment: + + .. code-block:: console + :substitutions: + + host:~$ source /opt/|yocto-distro|/|yocto-manifestname|/environment-setup-cortexa53-crypto-phytec-linux + +* Set this environment variable before building the Image: + + .. code-block:: console + :substitutions: + + host:~$ export ATF_LOAD_ADDR=|atfloadaddr| + +Get the needed binaries +....................... + +To build the bootloader, you need to **copy** these **files** to your |u-boot-repo-name| +**build directory** and rename them to fit with *mkimage* script: + +* **ARM Trusted firmware binary** (*mkimage tool* compatible format + **bl31.bin**): bl31-|kernel-socname|.bin +* **OPTEE image** (optional): tee.bin +* **DDR firmware files** (*mkimage tool* compatible format + **lpddr4_[i,d]mem_\*d_\*.bin**): + lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, + lpddr4_imem_2d_*.bin + +If you already built our BSP with Yocto, you can get the +bl31-|kernel-socname|.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: |ref-bsp-images| + +Or you can download the files here: |link-boot-tools| + +.. warning:: + + Make sure you rename the files you need so that they are compatible with the + *mkimage tool*. + +Build the bootloader +.................... + +* build flash.bin (imx-boot): + + .. code-block:: console + :substitutions: + + host:~$ make phycore-|kernel-socname|_defconfig + host:~$ make flash.bin + +Flash the bootloader to a block device +...................................... + +The flash.bin can be found at u-boot-imx/ directory and now can be flashed. A +chip-specific offset is needed: + +.. _offset-table: + +===== =================== ============================= ============ +SoC Offset User Area Offset Boot Partition eMMC Device +===== =================== ============================= ============ +|soc| |u-boot-offset| kiB |u-boot-offset-boot-part| kiB /dev/mmcblk2 +===== =================== ============================= ============ + +E.g. flash SD card: + +.. code-block:: console + :substitutions: + + host:~$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=|u-boot-offset| conv=sync + +.. hint:: + The specific offset values are also declared in the Yocto variables "BOOTLOADER_SEEK" and "BOOTLOADER_SEEK_EMMC" + +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + :start-after: .. build-uboot-fixed-ram-size-marker + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mm-pd22.1.1-device-tree: + +Device Tree (DT) +================ + +Introduction +------------ + +The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html) + +*"The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn't need to hard code details of the machine."* + +The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at `devicetree.org `_. + +PHYTEC |soc| BSP Device Tree Concept +------------------------------------ + +The following sections explain some rules PHYTEC has defined on how to set up +device trees for our |soc| SoC-based boards. + +Device Tree Structure +..................... + +* *Module.dtsi* - Module includes all devices mounted on the SoM, such as PMIC + and RAM. +* *Carrierboard.dtsi* - Devices that come from the |soc| SoC but are just routed + down to the carrier board and used there are included in this dtsi. +* *Board.dts* - include the carrier board and module dtsi files. There may also + be some hardware configuration nodes enabled on the carrier board or the + module (i.e. the Board .dts shows the special characteristics of the board + configuration). For example, there are phyCORE-|soc| SOMs which may or may not + have a MIPI DSI to LVDS converter mounted. The converter is enabled (if + available) in the Board .dts and not in the Module .dtsi + +From the root directory of the Linux Kernel our devicetree files for |socfamily| +platforms can be found in ``arch/arm64/boot/dts/freescale/``. + +Device Tree Overlay +................... + +Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder ``arch/arm64/boot/dts/freescale/overlays``. + +Available overlays for |yocto-machinename|.conf are: + +.. code-block:: + + imx8mm-phyboard-polis-peb-eval-01.dtbo + imx8mm-phyboard-polis-peb-av-010.dtbo + imx8mm-phycore-rpmsg.dtbo + imx8mm-phycore-no-eth.dtbo + imx8mm-phycore-no-spiflash.dtbo + imx8mm-vm016.dtbo + imx8mm-vm016-fpdlink.dtbo + imx8mm-vm017.dtbo + imx8mm-vm017-fpdlink.dtbo + imx8mm-dual-vm017-fpdlink.dtbo + +.. _imx8mm-pd22.1.1-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +imx8mm-phyboard-polis.dtsi: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX 0x00 + MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX 0x00 + MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B 0x00 + MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B 0x00 + >; + }; + +The first part of the string MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad (in this example +SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the desired muxing option for this pad. +The pad setting value (hex value on the right) defines different modes of the pad, for example, if +internal pull resistors are activated or not. In this case, the internal resistors are disabled. + +RS232/RS485 +----------- + +The |soc| SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +|ref-bootswitch| needs to be set correctly: + +.. list-table:: Switch between UART1 RS485/RS232 + + * - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS485.png + + **UART1 RS485** + + - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS232.jpg + + **UART1 RS232** + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n188` + +.. _imx8mm-pd22.1.1-network: + +Network +------- + +|sbc|-|soc| provides one Gigabit Ethernet interface. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First set the correct regulatory domain for your country: + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see: + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +Set up the wireless interface: + +.. code-block:: console + + target:~$ ip link + target:~$ ip link set up dev wlan0 + +Now you can scan for available networks: + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection. + +To do so, add the network-credentials to the file ``/etc/wpa_supplicant.conf``: + +.. code-block:: + + country=DE + network={ + ssid="" + proto=WPA2 + psk="" + } + +Now a connection can be established: + +.. code-block:: console + + target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B + +This should result in the following output: + +.. code-block:: + + ... + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section `Changing the Network Configuration` in the |yocto-ref-manual|_. + +First, create the directory: + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +Then add the following configuration snippet in ``/etc/systemd/network/10-wlan0.network``: + +.. code-block:: + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +Now, restart the network daemon so that the configuration takes effect: + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Bluetooth +......... + +Bluetooth is connected to |bluetooth-uart| interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually: + +.. code-block:: console + + target:~$ hciconfig hci0 up + + target:~$ hciconfig -a + + hci0: Type: Primary Bus: UART + BD Address: 00:25:CA:2F:39:96 ACL MTU: 1021:8 SCO MTU: 64:1 + UP RUNNING PSCAN + RX bytes:1392 acl:0 sco:0 events:76 errors:0 + TX bytes:1198 acl:0 sco:0 commands:76 errors:0 + ... + +Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup. + +.. code-block:: console + + target:~$ hcitool scan + Scanning ... + XX:XX:XX:XX:XX:XX + +Visibility +~~~~~~~~~~ + +To activate visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 piscan + +To disable visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 noscan + +Connect +~~~~~~~ + +.. code-block:: console + + target:~$ bluetoothctl + [bluetooth]# discoverable on + Changing discoverable on succeeded + [bluetooth]# pairable on + Changing pairable on succeeded + [bluetooth]# agent on + Agent registered + [bluetooth]# default-agent + Default agent request successful + [bluetooth]# scan on + [NEW] Device XX:XX:XX:XX:XX:XX + [bluetooth]# connect XX:XX:XX:XX:XX:XX + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n266` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n315` + +eMMC Devices +------------ + +PHYTEC modules like phyCORE-|soc| is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw MLC memory cells combined with a memory +controller that handles ECC and wear leveling. They are connected via an SD/MMC +interface to the |soc| and are represented as block devices in the Linux kernel +like SD cards, flash drives, or hard disks. + +The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer's datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard. + +PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1 + +Extended CSD Register +..................... + +eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard. + +In the Linux user space, you can query the registers: + +.. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| + +You will see: + +.. code-block:: + + ============================================= + Extended CSD rev 1.7 (MMC 5.0) + ============================================= + + Card Supported Command sets [S_CMD_SET: 0x01] + [...] + +Enabling Background Operations (BKOPS) +...................................... + +In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +cells. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called **Background +Operations (BKOPS)**. + +By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency. + +The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details. + +Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0): + +* Value 0: The host does not support the manual trigger of BKOPS. Device write + performance suffers. +* Value 1: The host does support the manual trigger of BKOPS. It will issue + BKOPS from time to time when it does not need the device. + +The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details). + +The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)). + +The userspace tool mmc does not currently support enabling automatic BKOPS +features. + +* To check whether *BKOPS_EN* is set, execute: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep BKOPS_EN + + The output will be, for example: + + .. code-block:: + + Enable background operations handshake [BKOPS_EN]: 0x01 + #OR + Enable background operations handshake [BKOPS_EN]: 0x00 + + Where value 0x00 means BKOPS_EN is disabled and device write performance + suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue + background operations from time to time. + +* To set the BKOPS_EN bit, execute: + + .. code-block:: console + :substitutions: + + target:~$ mmc bkops enable /dev/|emmcdev| + +* To ensure that the new setting is taken over and the kernel triggers BKOPS by + itself, shut down the system: + + .. code-block:: console + + target:~$ poweroff + +.. tip:: + + The BKOPS_EN bit is one-time programmable only. It cannot be reversed. + +Reliable Write +.............. + +There are two different Reliable Write options: + +1. Reliable Write option for a whole eMMC device/partition. +2. Reliable Write for single write transactions. + +.. tip:: + + Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT + partition table (see the previous section). + +The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-|soc| SoMs. To check this on the running target: + +.. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep -A 5 WR_REL_SET + Write reliability setting register [WR_REL_SET]: 0x1f + user area: the device protects existing data if a power failure occurs during a write o + peration + partition 1: the device protects existing data if a power failure occurs during a write + operation + partition 2: the device protects existing data if a power failure occurs during a write + operation + partition 3: the device protects existing data if a power failure occurs during a write + operation + partition 4: the device protects existing data if a power failure occurs during a write + operation + -- + Device supports writing EXT_CSD_WR_REL_SET + Device supports the enhanced def. of reliable write + +Otherwise, it can be enabled with the mmc tool: + +.. code-block:: console + + target:~$ mmc --help + + [...] + mmc write_reliability set <-y|-n> + +The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META. + +**Conclusion**: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application. + +Resizing ext4 Root Filesystem +............................. + +When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk. + +* Get the current device size: + + .. code-block:: console + :substitutions: + + target:~$ parted /dev/|emmcdev| print + +* The output looks like this: + + .. code-block:: + :substitutions: + + Model: MMC Q2J55L (sd/mmc) + Disk /dev/|emmcdev|: 7617MB + Sect[ 1799.850385] |emmcdev|: p1 p2 + or size (logical/physical): 512B/512B + Partition Table: msdos + Disk Flags: + + Number Start End Size Type File system Flags + 1 4194kB 72.4MB 68.2MB primary fat16 boot, lba + 2 72.4MB 537MB 465MB primary ext4 + +* Use parted to resize the root partition to the max size of the device: + + .. code-block:: console + :substitutions: + + target:~$ parted /dev/|emmcdev| resizepart 2 100% + Information: You may need to update /etc/fstab. + + target:~$ parted /dev/|emmcdev| print + Model: MMC Q2J55L (sd/mmc) + Disk /dev/|emmcdev|: 7617MB + Sector size (logical/physical): 512[ 1974.191657] |emmcdev|: p1 p2 + B/512B + Partition Table: msdos + Disk Flags: + + Number Start End Size Type File system Flags + 1 4194kB 72.4MB 68.2MB primary fat16 boot, lba + 2 72.4MB 7617MB 7545MB primary ext4 + +Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted. + +* Resize the filesystem to a new partition size: + + .. code-block:: console + :substitutions: + + target:~$ resize2fs /dev/|emmcdev|p2 + resize2fs 1.46.1 (9-Feb-2021) + Filesystem at /dev/|emmcdev|p2 is mounted on /; on-line resizing required + [ 131.609512] EXT4-fs (|emmcdev|p2): resizing filesystem + from 454136 to 7367680 blocks + old_desc_blocks = 4, new_desc_blocks = 57 + [ 131.970278] EXT4-fs (|emmcdev|p2): resized filesystem to 7367680 + The filesystem on /dev/|emmcdev|p2 is now 7367680 (1k) blocks long + +Enable pseudo-SLC Mode +...................... + +eMMC devices use MLC memory cells +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC memory cells used in NAND Flash, MLC memory cells have lower +reliability and a higher error rate at lower costs. + +If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity. + +.. warning:: + + When enabling the enhanced attribute on the device, all data will be lost. + +The following sequence shows how to enable the enhanced attribute. + +* First obtain the current size of the eMMC device with: + + .. code-block:: console + :substitutions: + + target:~$ parted -m /dev/|emmcdev| unit B print + + You will receive: + + .. code-block:: + :substitutions: + + BYT; + /dev/|emmcdev|:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:; + + As you can see this device has 63652757504 Byte = 60704 MiB. + +* To get the maximum size of the device after pseudo-SLC is enabled use: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep ENH_SIZE_MULT -A 1 + + which shows, for example: + + .. code-block:: + + Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + -- + Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000 + i.e. 0 KiB + + Here the maximum size is 3719168 KiB = 3632 MiB. + +* Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by + typing: + + .. code-block:: console + :substitutions: + + target:~$ mmc enh_area set -y 0 3719168 /dev/|emmcdev| + + You will get: + + .. code-block:: + :substitutions: + + Done setting ENH_USR area on /dev/|emmcdev| + setting OTP PARTITION_SETTING_COMPLETED! + Setting OTP PARTITION_SETTING_COMPLETED on /dev/|emmcdev| SUCCESS + Device power cycle needed for settings to take effect. + Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle + +* To ensure that the new setting has taken over, shut down the system: + + .. code-block:: console + + target:~$ poweroff + + and perform a power cycle. It is recommended that you verify the settings now. + +* First, check the value of ENH_SIZE_MULT which must be 3719168 KiB: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep ENH_SIZE_MULT -A 1 + + You should receive:: + + Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + -- + Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + +* Finally, check the size of the device: + + .. code-block:: console + :substitutions: + + target:~$ parted -m /dev/|emmcdev| unit B print + BYT; + /dev/|emmcdev|:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:; + +Erasing the Device +.................. + +It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC memory +cells or mark these blocks as discard. The data on the device is lost and will +be read back as zeros. + +* After booting from SD Card execute: + + .. code-block:: console + :substitutions: + + target:~$ blkdiscard -f --secure /dev/|emmcdev| + + The option --secure ensures that the command waits until the eMMC device has + erased all blocks. The -f (force) option disables all checking before erasing + and it is needed when the eMMC device contains existing partitions with data. + +.. tip:: + .. code-block:: console + :substitutions: + + target:~$ dd if=/dev/zero of=/dev/|emmcdev| conv=fsync + + also destroys all information on the device, but this command is bad for wear + leveling and takes much longer! + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy9#n71` + +GPIOs +----- + +The |sbc| has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to |soc| pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal |soc| GPIO banks GPIO1 – GPIO5. + +The GPIOs are identified as GPIO_ (e.g. GPIO5_07). identifies the GPIO +bank and counts from 1 to 5, while stands for the GPIO within the bank. +is being counted from 0 to 31 (32 GPIOs on each bank). + +By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is: + +.. code-block:: + + Linux GPIO number: = ( - 1) * 32 + + +Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools: + +* Detecting the gpiochips on the chip: + + .. code-block:: console + + target:~$ gpiodetect + gpiochip0 [30200000.gpio] (32 lines) + gpiochip1 [30210000.gpio] (32 lines) + gpiochip2 [30220000.gpio] (32 lines) + gpiochip3 [30230000.gpio] (32 lines) + gpiochip4 [30240000.gpio] (32 lines) + +* Show detailed information about the gpiochips. Like their names, consumers, + direction, active state, and additional flags: + + .. code-block:: console + + target:~$ gpioinfo gpiochip0 + +* Read the value of a GPIO (e.g GPIO 20 from chip0): + + .. code-block:: console + + target:~$ gpioget gpiochip0 20 + +* Set the value of GPIO 20 on chip0 to 0 and exit tool: + + .. code-block:: console + + target:~$ gpioset --mode=exit gpiochip0 20=0 + +* Help text of gpioset shows possible options: + + .. code-block:: console + + target:~$ gpioset --help + Usage: gpioset [OPTIONS] = = ... + Set GPIO line values of a GPIO chip + + Options: + -h, --help: display this message and exit + -v, --version: display the version and exit + -l, --active-low: set the line active state to low + -m, --mode=[exit|wait|time|signal] (defaults to 'exit'): + tell the program what to do after setting values + -s, --sec=SEC: specify the number of seconds to wait (only valid for --mode=time) + -u, --usec=USEC: specify the number of microseconds to wait (only valid for --mode=time) + -b, --background: after setting values: detach from the controlling terminal + + Modes: + exit: set values and exit immediately + wait: set values and wait for user to press ENTER + time: set values and sleep for a specified amount of time + signal: set values and wait for SIGINT or SIGTERM + + Note: the state of a GPIO line controlled over the character device reverts to default + when the last process referencing the file descriptor representing the device file exits. + This means that it's wrong to run gpioset, have it exit and expect the line to continue + being driven high or low. It may happen if given pin is floating but it must be interpreted + as undefined behavior. + + +.. warning:: + + Some of the user IOs are used for special functions. Before using a user IO, + refer to the schematic or the hardware manual of your board to ensure that it + is not already in use. + +GPIOs via sysfs +............... + +.. warning:: + + Accessing gpios via sysfs is deprecated and we encourage to use libgpiod + instead. + +Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling ``CONFIG_GPIO_SYSFS`` in the kernel +configuration. To make ``CONFIG_GPIO_SYSFS`` visible in menuconfig the option +``CONFIG_EXPERT`` has to be enabled first. + +You can also add this option for example to the defconfig you use in +``arch/arm64/configs/`` in the linux kernel sources. For our NXP based releases, +this could be for example ``imx8_phytec_distro.config``:: + + .. + CONFIG_EXPERT=y + CONFIG_GPIO_SYSFS=y + .. + +Otherwise you can create a new config fragment. This is described in our +`Yocto Reference Manual `_. + +Pinmuxing of some GPIO pins in the device tree |dt-carrierboard|.dtsi:: + + pinctrl_leds: leds1grp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1 0x16 + MX8MM_IOMUXC_GPIO1_IO14_GPIO1_IO14 0x16 + MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x16 + >; + }; + +LEDs +---- + +If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using ``/sys/class/leds/`` instead +of ``/sys/class/gpio/``. The maximum brightness of the LEDs can be read from +the ``max_brightness`` file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings. + +Below is a simple example. + +To get all available LEDs, type: + +.. code-block:: console + + target:~$ ls /sys/class/leds + mmc1::@ mmc2::@ user-led1@ user-led2@ user-led3@ + +Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the |sbc|. + +* To toggle the LEDs ON: + + .. code-block:: console + + target:~$ echo 255 > /sys/class/leds/user-led1/brightness + +* To toggle OFF: + + .. code-block:: console + + target:~$ echo 0 > /sys/class/leds/user-led1/brightness + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n37` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy#n102` + +General I²C4 bus configuration (e.g. |dt-carrierboard|.dtsi): +:imx-dt:`imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n149` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues. + +.. include:: ../peripherals/eeprom.rsti + +Rescue EEPROM Data +.................. + +The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area. + +.. code-block:: console + + target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 + +.. note:: + + If you deleted both EEPROM spaces, please contact our support! + +DT representation, e.g. in phyCORE-|soc| file |dt-som|.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n271` + +.. include:: /bsp/peripherals/rtc.rsti + :end-before: .. rtc_parameter_start_label + +DT representation for I²C RTCs: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy9#n277` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +'HS'). The USB subsystem has two independent USB controller cores. Both cores +are On-The-Go (OTG) controller cores and are capable of acting as a USB +peripheral device or a USB host. Each is connected to a USB 2.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +User USB2 (host) configuration is in the kernel device tree +|kernel-socname|.dtsi:: + + &usbotg2 { + dr_mode = "host"; + picophy,pre-emp-curr-control = <3>; + picophy,dc-vol-level-adjust = <7>; + status = "okay"; + }; + +DT representation for USB Host: +:imx-dt:`imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy9#n240` + +.. include:: /bsp/peripherals/usb-otg.rsti + +Both USB interfaces are configured as host in the kernel device tree +imx8mm-phyboard-polis.dtsi. See: +:imx-dt:`imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n228` + +CAN FD +------ + +The |sbc| has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. Hint:: + + phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. + There are different interfaces involved, which limits the datarate + capabilities of CANFD. + +.. Hint:: + + On phyBOARD-Polis-i.MX8MM a terminating resistor can be enabled by setting + S5 to ON if required. + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of imx8mm-phyboard-polis.dtsi: +:imx-dt:`imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n106` + +PCIe +---- + +The phyCORE-|soc| has one Mini-PCIe slot. In general, PCIe autodetects new +devices on the bus. After connecting the device and booting up the system, you +can use the command lspci to see all PCIe devices recognized. + +* Type: + + .. code-block:: console + + target:~$ lspci -v + +* You will receive: + + .. code-block:: + + 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode]) + Flags: bus master, fast devsel, latency 0, IRQ 218 + Memory at 18000000 (64-bit, non-prefetchable) [size=1M] + Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0 + I/O behind bridge: None + Memory behind bridge: 18100000-181fffff [size=1M] + Prefetchable memory behind bridge: None + [virtual] Expansion ROM at 18200000 [disabled] [size=64K] + Capabilities: [40] Power Management version 3 + Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+ + Capabilities: [70] Express Root Port (Slot-), MSI 00 + Capabilities: [100] Advanced Error Reporting + Capabilities: [148] L1 PM Substates + Kernel driver in use: dwc3-haps + + 01:00.0 Network controller: Intel Corporation WiFi Link 5100 + Subsystem: Intel Corporation WiFi Link 5100 AGN + Flags: fast devsel + Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K] + Capabilities: [c8] Power Management version 3 + Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+ + Capabilities: [e0] Express Endpoint, MSI 00 + Capabilities: [100] Advanced Error Reporting + Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e + Kernel modules: iwlwifi + +In this example, the PCIe device is the *Intel Corporation WiFi Link 5100*. + +For PCIe devices, you have to enable the correct driver in the kernel +configuration. This WLAN card, for example, is manufactured by Intel. The +option for the driver, which must be enabled, is named ``CONFIG_IWLWIFI`` and can be +found under *Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimat* in +the kernel configuration. + +* In order to activate the driver, follow the instructions from our + `Yocto Reference Manual `_. + + - The linux-imx is represented by: **virtual/kernel** + +For some devices like the WLAN card, additional binary firmware blobs are +needed. These firmware blobs have to be placed in ``/lib/firmware/`` before the +device can be used. + +* Type: + + .. code-block:: console + + host:~$ scp -r root@192.168.3.11:/lib/firmware + +* For example, if you try to bring up the network interface: + + .. code-block:: console + + target:~$ ip link set up wlp1s0 + +* You will get the following output on the serial console: + + .. code-block:: console + + [ 58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0 + [ 58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0 + [ 58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready + +.. tip:: + + Some PCIe devices, e.g. the Ethernet card, may function properly even if no + firmware blob is loaded from ``/lib/firmware/`` and you received an error message + as shown in the first line of the output above. This is because some + manufacturers provide the firmware as a fallback on the card itself. In this + case, the behavior and output depend strongly on the manufacturer's firmware. + +Audio +----- + +The PEB-AV-10-Connector exists in two versions and the 1531.1 version is +populated with a TI TLV320AIC3007 audio codec. Audio support is done via the I2S +interface and controlled via I2C. + +There is a 3.5mm headset jack with OMTP standard and an 8-pin header to connect +audio devices with the AV-Connector. The 8-pin header contains a mono speaker, +headphones, and line-in signals. + +To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices: + +.. code-block:: console + + target:~$ aplay -L + +Or type for recording devices: + +.. code-block:: console + + target:~$ arecord -L + +Alsamixer +......... + +To inspect the capabilities of your soundcard, call: + +.. code-block:: console + + target:~$ alsamixer + +You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. "MM" means the feature is muted +(both output, left & right), which can be toggled by hitting **m**. You can also +toggle by hitting '**<**' for left and '**>**' for right output. With the **tab** +key, you can switch between controls for playback and recording. + +ALSA configuration +.................. + +Our BSP comes with a ALSA configuration file ``/etc/asound.conf``. + +The ALSA configuration file can be edited as desired or deleted since it is not +required for ALSA to work properly. + +.. code-block:: console + + target:~$ vi /etc/asound.conf + +To set PEB-AV-10 as output, set playback.pcm from "dummy" to "pebav10": + +.. code-block:: + + [...] + + pcm.asymed { + type asym + playback.pcm "pebav10" + capture.pcm "dsnoop" + } + + [...] + +If the sound is not audible change playback devices to the software volume control +playback devices, set *playback.pcm* to the respective softvol playback device e.g. +"softvol_pebav10". Use alsamixer controls to vary the volume levels. + +.. code-block:: + + [...] + + pcm.asymed { + type asym + playback.pcm "softvol_pebav10" + capture.pcm "dsnoop" + } + + [...] + +Pulseaudio Configuration +........................ + +For applications using Pulseaudio, check for available sinks: + +.. code-block:: console + + target:~$ pactl list short sinks + 0 alsa_output.platform-snd_dummy.0.stereo-fallback module-alsa-card.c s16le 2ch 44100Hz SUSPENDED + 1 alsa_output.platform-sound-peb-av-10.stereo-fallback module-alsa-card.c s16le 2ch 44100Hz SUSPENDED + +To select PEB-AV-10, type: + +.. code-block:: console + + target:~$ pactl set-default-sink 1 + +Playback +........ + +Run speaker-test to check playback availability: + +.. code-block:: console + + target:~$ speaker-test -c 2 -t wav + +To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds: + +.. code-block:: console + + target:~$ aplay /usr/share/sounds/alsa/* + +To playback other formats like mp3 for example, you can use Gstreamer: + +.. code-block:: console + + target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3 + +Capture +....... + +``arecord`` is a command-line tool for capturing audio streams which use Line In as +the default input source. To select a different audio source you can +use ``alsamixer``. For example, switch on *Right PGA Mixer Mic3R* and *Left PGA Mixer +Mic3R* in order to capture the audio from the microphone input of the +TLV320-Codec using the 3.5mm jack. + +.. code-block:: console + + target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on + target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on + +.. code-block:: console + + target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav + +.. hint:: + + Since playback and capture share hardware interfaces, it is not possible to + use different sampling rates and formats for simultaneous playback and + capture operations. + +Device Tree Audio configuration: +:imx-dt:`overlays/imx8mm-phyboard-polis-peb-av-010.dtso?h=v5.10.72_2.2.0-phy17#n56` + +Video +----- + +Videos with Gstreamer +..................... + +The video is installed by default in the BSP: + +.. code-block:: console + + target:~$ gst-launch-1.0 playbin uri=file:///usr/share/phytec-qtdemo/videos/caminandes.webm + +* Or: + +.. code-block:: console + + target:~$ gst-launch-1.0 -v filesrc location= \ + \! qtdemux \! h264parse \! queue \! vpudec \! waylandsink async=false enable-last-sample=false \ + qos=false sync=false + +* Or: + +.. code-block:: console + + target:~$ gplay-1.0 /usr/share/phytec-qtdemo/videos/caminandes.webm + +kmssink Plugin ID Evaluation +............................ + +The kmssink plugin needs a connector ID. To get the connector ID, you can use +the tool modetest. + +.. code-block:: console + + target:~$ modetest -c imx-drm + +The output will show something like: + +.. code-block:: + + Connectors: + id encoder status name size (mm) modes encoders + 35 34 connected LVDS-1 216x135 1 34 + modes: + index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot + #0 1280x800 59.07 1280 1380 1399 1440 800 804 808 823 70000 flags: phsync, pvsync; type: preferred, driver + props: + 1 EDID: + flags: immutable blob + blobs: + + value: + 2 DPMS: + flags: enum + enums: On=0 Standby=1 Suspend=2 Off=3 + value: 0 + 5 link-status: + flags: enum + enums: Good=0 Bad=1 + value: 0 + 6 non-desktop: + flags: immutable range + values: 0 1 + value: 0 + 4 TILE: + flags: immutable blob + blobs: + + value: + +Display +------- + +The 10" Display is always active. If the PEB-AV-Connector is not connected, an +error message may occur at boot. + +.. include:: /bsp/qt5.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +The device tree of PEB-AV-10 can be found here: +:imx-dt:`overlays/imx8mm-phyboard-polis-peb-av-010.dtso?h=v5.10.72_2.2.0-phy17` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Mini M4 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti + +.. +---------------------------------------------------------------------------+ +.. BSP EXTENSIONS +.. +---------------------------------------------------------------------------+ + +BSP Extensions +============== + +Chromium +-------- + +Our BSP for the |sbc|-|soc| supports Chromium. You can include it in the +|yocto-imagename| with only a few steps. + +Adding Chromium to Your local.conf +.................................. + +To include Chromium you have to add the following line into your local.conf. You +can find it in /build/conf/local.conf. This adds Chromium to your +next image build. :: + + IMAGE_INSTALL_append = " chromium-ozone-wayland" + +.. note:: + + Compiling Chromium takes a long time. + +Get Chromium Running on the Target +.................................. + +To run Chromium, it needs a few arguments to use the hardware graphics +acceleration:: + + target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox + +If you want to start Chromium via SSH, you must first define the display on +which Chromium will run. For example:: + + target$ DISPLAY=:0 + +After you have defined this, you can start it via virtual terminal on Weston as +shown above. diff --git a/previews/271/_sources/bsp/imx8/imx8mm/pd23.1.0.rst.txt b/previews/271/_sources/bsp/imx8/imx8mm/pd23.1.0.rst.txt new file mode 100644 index 000000000..18fa0f96d --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mm/pd23.1.0.rst.txt @@ -0,0 +1,1749 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt6demo-image-phyboard-polis-imx8mm-5.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/imx-boot-tools/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mm +.. _`static-pdf-dl`: ../../../_static/imx8mm-pd23.1.0.pdf + +.. IMX8(MM) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mm/phycore-imx8mm.c?h=v2022.04_2.2.2-phy5#n120 + + +.. General Replacements +.. |kit| replace:: **phyCORE-i.MX8M Mini Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Polis +.. |soc| replace:: i.MX 8M Mini +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MM +.. |debug-uart| replace:: ttymxc2 +.. |serial-uart| replace:: ttymxc0 +.. |bluetooth-uart| replace:: UART2 +.. |expansion-connector| replace:: X8 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx8mm +.. |kernel-tag| replace:: v5.15.71_2.2.2-phy3 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-offset| replace:: 33 +.. |u-boot-offset-boot-part| replace:: 33 +.. |u-boot-mmc-flash-offset| replace:: 0x42 +.. |u-boot-defconfig| replace:: phycore-imx8mm_defconfig +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX8(MM) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MM +.. |u-boot-tag| replace:: v2022.04_2.2.2-phy5 + + +.. RAUC +.. |rauc-manual| replace:: L-1006e.A5 RAUC Update & Device Management Manual +.. _rauc-manual: https://www.phytec.de/cdocuments/?doc=fgByJg + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mm-phyboard-polis-rdk +.. |dt-som| replace:: imx8mm-phycore-som +.. |dtbo-rpmsg| replace:: imx8mm-phycore-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mm-phyboard-polis-peb-av-010.dtbo + +.. IMX8(MM) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n59` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`kirkstone` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MM +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: kirkstone +.. |yocto-distro| replace:: ampliphy-vendor-xwayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: wic +.. |yocto-machinename| replace:: phyboard-polis-imx8mm-5 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MM-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MM-PD23.1.y +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (kirkstone) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 4.0.13 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + + +.. Refs +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S1) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X30) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X2 ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MM) specific replacements +.. |sbc-network| replace:: \ +.. |pollux-fan-note| replace:: Only GPIO fan supported. +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M4 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mm_phyboard_polis/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8MM6_M4 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++----------------------+----------------------+ +| |soc| BSP Manual | ++----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++----------------------+----------------------+ +| Document Type | BSP Manual | ++----------------------+----------------------+ +| Yocto Manual | Kirkstone | ++----------------------+----------------------+ +| Release Date | 2024/01/10 | ++----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================ ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================ ========== +|yocto-manifestname| Major 2023/12/12 Released +==================== ================ ================ ========== + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +The |sbc| populated with either the i.MX 8M Mini SoC or i.MX 8M Nano SoC, is +supported. + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mm-pd23.1.0-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mm-pd23.1.0-getting-started: + +Getting Started +=============== + +The |kit| is shipped with a pre-flashed SD card. It contains the +|yocto-imagename| and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +`PHYTEC download server `_. This chapter explains how to flash a BSP +image to SD card and how to start the board. + +There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool ``dd``. An +alternative way is to use PHYTEC's system initialization program called +`partup `_, which makes it especially easy to +format more complex systems. You can get `prebuilt Linux binaries of partup +`__ from its release page. Also read +`partup's README `__ for installation +instructions. + +Get the Image +------------- + +The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using ``dd``, can be downloaded from the `PHYTEC download server +`_. + +Get either the partup package or the WIC image from the download server: + +.. code-block:: console + :substitutions: + + host:~$ wget |link-partup-package| + host:~$ wget |link-image| + +.. note:: + For eMMC, more complex partitioning schemes or even just large images, we + recommend using the partup package, as it is faster in writing than ``dd`` + and allows for a more flexible configuration of the target flash device. + +Write the Image to SD Card +-------------------------- + +.. warning:: + To create your bootable SD card, you must have root privileges on your Linux + host PC. Be very careful when specifying the destination device! All files + on the selected device will be erased immediately without any further query! + + Selecting the wrong device may result in **data loss** and e.g. could erase + your currently running system on your host PC! + +Finding the Correct Device +.......................... + +To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card. + +#. In order to get the correct device name, remove your SD card and + execute: + + .. code-block:: console + + host:~$ lsblk + +#. Now insert your SD card and execute the command again: + + .. code-block:: console + + host:~$ lsblk + +#. Compare the two outputs to find the new device names listed in the second + output. These are the device names of the SD card (device and partitions if + the SD card was formatted). +#. In order to verify the device names being found, execute the command + ``sudo dmesg``. Within the last lines of its output, you should also find the + device names, e.g. ``/dev/sde`` or ``/dev/mmcblk0`` (depending on your + system). + +Alternatively, you may use a graphical program of your choice, like `GNOME Disks +`_ or `KDE Partition Manager +`_, to find the correct device. + +Now that you have the correct device name, e.g. ``/dev/sde``, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. ``/dev/sde1``) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption. + +Unmount all those partitions, e.g.: + +.. code-block:: console + + host:~$ sudo umount /dev/sde1 + host:~$ sudo umount /dev/sde2 + +Now, the SD card is ready to be flashed with an image, using either ``partup``, +``dd`` or ``bmap-tools``. + +Using partup +............ + +Writing to an SD card with partup is done in a single command: + +.. code-block:: console + :substitutions: + + host:~$ sudo partup install |yocto-imagename|-|yocto-machinename|.partup /dev/ + +Make sure to replace with your actual device name found previously. + +Further usage of partup is explained at its `official documentation website +`__. + +.. note:: + *partup* has the advantage of allowing to clear specific raw areas in the + MMC user area, which is used in our provided partup packages to erase any + existing U-Boot environments. This is a known issue *bmaptool* does not + solve, as mentioned below. + + Another key advantage of partup over other flashing tools is that it allows + configuring MMC specific parts, like writing to eMMC boot partitions, without + the need to call multiple other commands when writing. + +Using bmap-tools +................ + +An alternative and also fast way to prepare an SD card is using +`bmap-tools `_. Yocto +automatically creates a block map file (``-.wic.bmap``) for +the WIC image that describes the image content and includes checksums for data +integrity. *bmaptool* is packaged by various Linux distributions. For +Debian-based systems install it by issuing: + +.. code-block:: console + + host:~$ sudo apt install bmap-tools + +Flash a WIC image to SD card by calling: + +.. code-block:: console + :substitutions: + + host:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/ + +Replace with your actual SD card's device name found previously, +and make sure to place the file ``-.wic.bmap`` alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip. + +.. warning:: + *bmaptool* only overwrites the areas of an SD card where image data is + located. This means that a previously written U-Boot environment may still be + available after writing the image. + +Using ``dd`` +............ + +After having unmounted all SD card's partitions, you can create your bootable SD card. + +Some PHYTEC BSPs produce uncompressed images (with filename-extension \*.wic), +and some others produce compressed images (with filename-extension \*.wic.xz). + +To flash an uncompressed images (\*.wic) use command below: + +.. code-block:: console + :substitutions: + + host:~$ sudo dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/ bs=1M conv=fsync status=progress + +Or to flash a compressed images (\*.wic.xz) use that command: + +.. code-block:: console + :substitutions: + + host:~$ xzcat |yocto-imagename|-|yocto-machinename|.wic.xz | sudo dd of=/dev/ bs=1M conv=fsync status=progress + +Again, make sure to replace with your actual device name found +previously. + +The parameter ``conv=fsync`` forces a sync operation on the device before +``dd`` returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter ``status=progress`` will print out +information on how much data is and still has to be copied until it is +finished. + +First Start-up +-------------- + +* To boot from an SD card, |ref-bootswitch| needs to be set to the following + position: + +.. list-table:: Bootmode Selection + + * - .. figure:: images/SD_Card_Boot.jpg + + Mini + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP | +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mm-pd23.1.0-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mm.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mm-phyboard-polis-rdk*.dtb**: Kernel device tree file +* **imx8mm-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.wic**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S1) +-------------------- + +The |sbc| features a boot switch with six individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mm-pd23.1.0-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see |ref-setup-network-host|. + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **eMMC**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load your image via network to RAM: + +* when using dhcp + + .. code-block:: + :substitutions: + + u-boot=> dhcp |yocto-imagename|-|yocto-machinename|.wic + BOOTP broadcast 1 + DHCP client bound to address 192.168.3.1 (1 ms) + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.1 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* when using a static ip address (serverip and ipaddr must be set + additionally). + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Take a compressed or uncompressed image with accompanying block map on the host +and send it with ssh through the network to the eMMC of the target with a +one-line command: + +.. code-block:: console + :substitutions: + + target:~$ scp @192.168.3.10:/srv/tftp/|yocto-imagename|-|yocto-machinename|.wic.* /tmp && bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls /srv/tftp + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +Send the image with the ``bmaptool`` command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ scp /srv/tftp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2" + +Flash eMMC U-Boot image via Network from running U-Boot +....................................................... + +Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB stick +......................... + +Flash eMMC from USB stick in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. + +These steps will show how to update the eMMC via a USB device. Configure the +|ref-bootswitch| to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied WIC image to the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} *.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the |ref-bootswitch| to SD Card. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ ls /mnt + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy /mnt/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + + .. tip:: + + Before this will work, you need to configure the |ref-bootswitch| to + **eMMC**. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see |ref-format-sd|. + +Alternatively, flash a partup package to the SD card, as described in +|ref-getting-started|. This will ensure the full space of the SD card is used. + +Flash eMMC from SD card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. If the + image file is too large use the `Updating eMMC from SD card in + Linux on Target` subsection. + +* Flash an SD card with a working image and create a third ext4 partition. Copy + the WIC image (for example |yocto-imagename|.wic) to this + partition. +* Configure the |ref-bootswitch| to SD Card and insert the SD Card. +* Power on the board and stop in U-Boot. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> ext4load mmc 1:3 ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev to eMMC: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + +* Flash your WIC image (for example |yocto-imagename|.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. + + .. code-block:: + + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the |ref-bootswitch| to eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card. + +* Show your saved partup package or WIC image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.partup + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition) using `partup`_: + + .. code-block:: console + :substitutions: + + target:~$ partup install |yocto-imagename|-|yocto-machinename|.partup /dev/mmcblk2 + + Flashing the partup package has the advantage of using the full capacity of + the eMMC device, adjusting partitions accordingly. + + .. note:: + + Alternatively, ``bmaptool`` may be used instead: + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + + Keep in mind that the root partition does not make use of the full space when + flashing with ``bmaptool``. + +* After a complete write, your board can boot from eMMC. + + .. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to eMMC. + +Flash SPI NOR Flash +------------------- + +The |som| modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set |ref-bootswitch| to **SPI NOR**. The SPI Flash is usually quite small. +The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash populated. Only the +bootloader and the environment can be stored. The kernel, device tree, and file +system are taken from eMMC by default. + +The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with: + +.. code-block:: + + u-boot=> printenv mtdparts + mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none) + +Flash SPI NOR Flash from Network +................................ + +The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-|soc|. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Flash SPI NOR from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI NOR flash needs to be probed: + +.. code-block:: + + u-boot=> sf probe + SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB + +* A specially formatted U-Boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image over tftp, erase and write the + bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + device 0 offset 0x0, size 0x1c0b20 + 1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +Flash SPI NOR from Network in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the image from the host to the target: + + .. code-block:: console + :substitutions: + + host:~$ scp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root + +* Find the number of blocks to erase of the U-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the U-Boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +Flash SPI NOR Flash from SD Card +................................ + +The bootloader on SPI NOR flash can be also flashed with SD Card. + +Flash SPI NOR from SD Card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the first partition + on the SD Card. + +* Before reading and writing are possible, the SPI-NOR flash + needs to be probed: + + .. code-block:: + + u-boot=> sf probe + SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB + +* A specially formatted U-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image from the SD Card, erase and write + the bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +Flash SPI NOR from SD Card in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the first partition + on the SD Card. + +* Mount the SD Card: + + .. code-block:: console + :substitutions: + + target:~$ mount /dev/mmcblk1p1 /mnt + +* Find the number of blocks to erase of the U-Boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp /mnt/imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: |rauc-manual|_. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mm-pd23.1.0-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti +.. _imx8mm-pd23.1.0-development-build-uboot: +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + :end-before: .. build-uboot-marker + +.. note:: + The regulator for the SD card reset pin has been disabled to ensure + compatibility with 1532.1 revision baseboards. If you have a revision + 1532.2(a) or higher baseboard, you may enable the device tree nodes for + highest performance. In the imx8mm-phyboard-polis-rdk-u-boot.dtsi file, + remove the following lines:: + + /delete-node/ ®_usdhc2_vmmc; + /delete-property/ vmmc-supply; + +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + :start-after: .. build-uboot-marker + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mm-pd23.1.0-format-sd: + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mm-pd23.1.0-device-tree: + +Device Tree (DT) +================ + +Introduction +------------ + +The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html) + +*"The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn't need to hard code details of the machine."* + +The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at `devicetree.org `_. + +PHYTEC |soc| BSP Device Tree Concept +------------------------------------ + +The following sections explain some rules PHYTEC has defined on how to set up +device trees for our |soc| SoC-based boards. + +Device Tree Structure +..................... + +* *Module.dtsi* - Module includes all devices mounted on the SoM, such as PMIC + and RAM. +* *Board.dts* - include the module dtsi file. Devices that come from the |soc| + SoC but are just routed down to the carrier board and used there are included + in this dts. +* *Overlay.dtso* - enable/disable features depending on optional hardware that + may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10) + +From the root directory of the Linux Kernel our devicetree files for |socfamily| +platforms can be found in ``arch/arm64/boot/dts/freescale/``. + +Device Tree Overlay +................... + +Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder ``arch/arm64/boot/dts/freescale/overlays``. + +Available overlays for |yocto-machinename|.conf are: + +.. Add overlay files in leaf file + +:: + + imx8mm-phyboard-polis-peb-eval-01.dtbo + imx8mm-phyboard-polis-peb-av-010.dtbo + imx8mm-phycore-rpmsg.dtbo + imx8mm-phycore-no-eth.dtbo + imx8mm-phycore-no-spiflash.dtbo + imx8mm-vm016.dtbo + imx8mm-vm016-fpdlink.dtbo + imx8mm-vm017.dtbo + imx8mm-vm017-fpdlink.dtbo + imx8mm-dual-vm017-fpdlink.dtbo + +.. _imx8mm-pd23.1.0-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX 0x00 + MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX 0x00 + MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B 0x00 + MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B 0x00 + >; + }; + +The first part of the string MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad (in this example +SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the desired muxing option for this pad. +The pad setting value (hex value on the right) defines different modes of the pad, for example, if +internal pull resistors are activated or not. In this case, the internal resistors are disabled. + +RS232/RS485 +----------- + +The |soc| SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +|ref-bootswitch| needs to be set correctly: + +.. list-table:: Switch between UART1 RS485/RS232 + + * - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS485.png + + **UART1 RS485** + + - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS232.jpg + + **UART1 RS232** + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n291` + +.. _imx8mm-pd23.1.0-network: + +Network +------- + +|sbc|-|soc| provides one Gigabit Ethernet interface. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First set the correct regulatory domain for your country: + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see: + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +Set up the wireless interface: + +.. code-block:: console + + target:~$ ip link + target:~$ ip link set up dev wlan0 + +Now you can scan for available networks: + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection. + +To do so, add the network-credentials to the file ``/etc/wpa_supplicant.conf``: + +.. code-block:: + + country=DE + network={ + ssid="" + proto=WPA2 + psk="" + } + +Now a connection can be established: + +.. code-block:: console + + target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B + +This should result in the following output: + +.. code-block:: + + ... + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section `Changing the Network Configuration` in the |yocto-ref-manual|. + +First, create the directory: + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +Then add the following configuration snippet in ``/etc/systemd/network/10-wlan0.network``: + +.. code-block:: + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +Now, restart the network daemon so that the configuration takes effect: + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Bluetooth +......... + +Bluetooth is connected to |bluetooth-uart| interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually: + +.. code-block:: console + + target:~$ hciconfig hci0 up + + target:~$ hciconfig -a + + hci0: Type: Primary Bus: UART + BD Address: 00:25:CA:2F:39:96 ACL MTU: 1021:8 SCO MTU: 64:1 + UP RUNNING PSCAN + RX bytes:1392 acl:0 sco:0 events:76 errors:0 + TX bytes:1198 acl:0 sco:0 commands:76 errors:0 + ... + +Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup. + +.. code-block:: console + + target:~$ hcitool scan + Scanning ... + XX:XX:XX:XX:XX:XX + +Visibility +~~~~~~~~~~ + +To activate visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 piscan + +To disable visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 noscan + +Connect +~~~~~~~ + +.. code-block:: console + + target:~$ bluetoothctl + [bluetooth]# discoverable on + Changing discoverable on succeeded + [bluetooth]# pairable on + Changing pairable on succeeded + [bluetooth]# agent on + Agent registered + [bluetooth]# default-agent + Default agent request successful + [bluetooth]# scan on + [NEW] Device XX:XX:XX:XX:XX:XX + [bluetooth]# connect XX:XX:XX:XX:XX:XX +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n383` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n335` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n87` + +GPIOs +----- + +The |sbc| has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to |soc| pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal |soc| GPIO banks GPIO1 – GPIO5. + +The GPIOs are identified as GPIO_ (e.g. GPIO5_07). identifies the GPIO +bank and counts from 1 to 5, while stands for the GPIO within the bank. +is being counted from 0 to 31 (32 GPIOs on each bank). + +By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is: + +.. code-block:: + + Linux GPIO number: = ( - 1) * 32 + + +Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools: + +* Detecting the gpiochips on the chip: + + .. code-block:: console + + target:~$ gpiodetect + gpiochip0 [30200000.gpio] (32 lines) + gpiochip1 [30210000.gpio] (32 lines) + gpiochip2 [30220000.gpio] (32 lines) + gpiochip3 [30230000.gpio] (32 lines) + gpiochip4 [30240000.gpio] (32 lines) + +* Show detailed information about the gpiochips. Like their names, consumers, + direction, active state, and additional flags: + + .. code-block:: console + + target:~$ gpioinfo gpiochip0 + +* Read the value of a GPIO (e.g GPIO 20 from chip0): + + .. code-block:: console + + target:~$ gpioget gpiochip0 20 + +* Set the value of GPIO 20 on chip0 to 0 and exit tool: + + .. code-block:: console + + target:~$ gpioset --mode=exit gpiochip0 20=0 + +* Help text of gpioset shows possible options: + + .. code-block:: console + + target:~$ gpioset --help + Usage: gpioset [OPTIONS] = = ... + Set GPIO line values of a GPIO chip + + Options: + -h, --help: display this message and exit + -v, --version: display the version and exit + -l, --active-low: set the line active state to low + -m, --mode=[exit|wait|time|signal] (defaults to 'exit'): + tell the program what to do after setting values + -s, --sec=SEC: specify the number of seconds to wait (only valid for --mode=time) + -u, --usec=USEC: specify the number of microseconds to wait (only valid for --mode=time) + -b, --background: after setting values: detach from the controlling terminal + + Modes: + exit: set values and exit immediately + wait: set values and wait for user to press ENTER + time: set values and sleep for a specified amount of time + signal: set values and wait for SIGINT or SIGTERM + + Note: the state of a GPIO line controlled over the character device reverts to default + when the last process referencing the file descriptor representing the device file exits. + This means that it's wrong to run gpioset, have it exit and expect the line to continue + being driven high or low. It may happen if given pin is floating but it must be interpreted + as undefined behavior. + + +.. warning:: + + Some of the user IOs are used for special functions. Before using a user IO, + refer to the schematic or the hardware manual of your board to ensure that it + is not already in use. + +.. include:: ../peripherals/gpios.rsti + :start-after: .. gpios-via-sysfs-marker + +Pinmuxing of some GPIO pins in the device tree |dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_leds: leds1grp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1 0x16 + MX8MM_IOMUXC_GPIO1_IO14_GPIO1_IO14 0x16 + MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x16 + >; + }; + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n36` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n119` + +General I²C4 bus configuration (e.g. |dt-carrierboard|.dts): +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n244` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues. + +.. include:: ../peripherals/eeprom.rsti + +Rescue EEPROM Data +.................. + +The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area. + +.. code-block:: console + + target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 + +.. note:: + + If you deleted both EEPROM spaces, please contact our support! + +DT representation, e.g. in phyCORE-|soc| file |dt-som|.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n311` + +.. include:: /bsp/peripherals/rtc.rsti + :end-before: .. rtc_parameter_start_label + +RTC Parameters +.............. + +RTCs have a few abilities which can be read/set with the help of ``hwclock`` +tool. + +* We can check RTC supported features with: + + .. code-block:: console + + target:~$ hwclock --param-get features + The RTC parameter 0x0 is set to 0x11. + + What this value means is encoded in kernel, each set bit translates to: + + .. code-block:: + + #define RTC_FEATURE_ALARM 0 + #define RTC_FEATURE_ALARM_RES_MINUTE 1 + #define RTC_FEATURE_NEED_WEEK_DAY 2 + #define RTC_FEATURE_ALARM_RES_2S 3 + #define RTC_FEATURE_UPDATE_INTERRUPT 4 + #define RTC_FEATURE_CORRECTION 5 + #define RTC_FEATURE_BACKUP_SWITCH_MODE 6 + #define RTC_FEATURE_CNT 7 + +* We can check RTC BSM (Backup Switchover Mode) with: + + .. code-block:: console + + target:~$ hwclock --param-get bsm + The RTC parameter 0x2 is set to 0x1. + +* We can set RTC BSM with: + + .. code-block:: console + + target:~$ hwclock --param-set bsm=0x2 + The RTC parameter 0x2 will be set to 0x2. + + What BSM values mean translates to these values: + + .. code-block:: + + #define RTC_BSM_DISABLED 0 + #define RTC_BSM_DIRECT 1 + #define RTC_BSM_LEVEL 2 + #define RTC_BSM_STANDBY 3 + + .. tip:: + You should set BSM mode to DSM or LSM for RTC to switch to backup power + source when the initial power source is not available. Check **RV-3028** RTC + datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching + Mode) actually mean. + +DT representation for I²C RTCs: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n319` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +'HS'). The USB subsystem has two independent USB controller cores. Both cores +are On-The-Go (OTG) controller cores and are capable of acting as a USB +peripheral device or a USB host. Each is connected to a USB 2.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +User USB2 (host) configuration is in the kernel device tree +|dt-carrierboard|.dts: + +.. code-block:: + + &usbotg2 { + dr_mode = "host"; + picophy,pre-emp-curr-control = <3>; + picophy,dc-vol-level-adjust = <7>; + status = "okay"; + }; + +DT representation for USB Host: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n347` + +.. include:: /bsp/peripherals/usb-otg.rsti + +Both USB interfaces are configured as host in the kernel device tree +|dt-carrierboard|.dts. See: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n335` + +CAN FD +------ + +The |sbc| has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. Hint:: + + phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. + There are different interfaces involved, which limits the datarate + capabilities of CANFD. + +.. Hint:: + + On phyBOARD-Polis-i.MX8MM a terminating resistor can be enabled by setting + S5 to ON if required. + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n175` + +.. include:: /bsp/peripherals/pcie.rsti + +Audio +----- + +The PEB-AV-10-Connector exists in two versions and the 1531.1 version is +populated with a TI TLV320AIC3007 audio codec. Audio support is done via the I2S +interface and controlled via I2C. + +There is a 3.5mm headset jack with OMTP standard and an 8-pin header to connect +audio devices with the AV-Connector. The 8-pin header contains a mono speaker, +headphones, and line-in signals. + +.. include:: /bsp/peripherals/audio.rsti + +Device Tree Audio configuration: +:imx-dt:`overlays/imx8mm-phyboard-polis-peb-av-010.dtsi?h=v5.15.71_2.2.2-phy3#n54` + +.. include:: /bsp/peripherals/video.rsti + +Display +------- + +The 10" Display is always active. If the PEB-AV-Connector is not connected, an +error message may occur at boot. + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +The device tree of PEB-AV-10 can be found here: +:imx-dt:`overlays/imx8mm-phyboard-polis-peb-av-010.dtsi?h=v5.15.71_2.2.2-phy3` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Mini M4 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti + +.. +---------------------------------------------------------------------------+ +.. BSP EXTENSIONS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/bsp-extensions.rsti diff --git a/previews/271/_sources/bsp/imx8/imx8mn/head.rst.txt b/previews/271/_sources/bsp/imx8/imx8mn/head.rst.txt new file mode 100644 index 000000000..de505064f --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mn/head.rst.txt @@ -0,0 +1,477 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.wic +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/imx-boot-tools/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mm +.. _`static-pdf-dl`: ../../../_static/imx8mn-head.pdf + +.. IMX8(MN) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mn/phycore-imx8mn.c?h=v2022.04_2.2.2-phy5#n66 + + +.. General Replacements +.. |doc-id| replace:: L-1002e.Ax +.. |kit| replace:: **phyCORE-i.MX8M Nano Kit** +.. |kit-ram-size| replace:: 1GiB +.. |mcore| replace:: M4 Core +.. |sbc| replace:: phyBOARD-Polis +.. |soc| replace:: i.MX 8M Nano +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MN +.. |debug-uart| replace:: ttymxc2 +.. |serial-uart| replace:: ttymxc0 +.. |bluetooth-uart| replace:: UART2 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx8mn +.. |kernel-tag| replace:: v5.15.71_2.2.2-phy3 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-defconfig| replace:: phycore-imx8mn_defconfig +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX8(MN) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MN +.. |u-boot-tag| replace:: v2022.04_2.2.2-phy5 + + +.. RAUC +.. |rauc-manual| replace:: L-1006e.A6 RAUC Update & Device Management Manual +.. _rauc-manual: https://www.phytec.de/cdocuments/?doc=F4DiM + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mn-phyboard-polis +.. |dt-som| replace:: imx8mn-phycore-som +.. |dtbo-peb-av-10| replace:: imx8mn-phyboard-polis-peb-av-010.dtbo + +.. IMX8(MN) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n50` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`kirkstone` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MM +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: kirkstone +.. |yocto-distro| replace:: ampliphy-vendor +.. |yocto-imagename| replace:: phytec-headless-image +.. |yocto-imageext| replace:: rootfs.wic.xz +.. |yocto-machinename| replace:: phyboard-polis-imx8mn-2 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MM-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MM-PD23.1.y +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (kirkstone) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 4.0.13 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Refs +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S1) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X30) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X2 ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MN) specific replacements +.. |sbc-network| replace:: \ +.. |pollux-fan-note| replace:: Only GPIO fan supported. +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + +.. only:: html + + Documentation in pdf format: `Download `_ + ++----------------------+----------------------+ +| |doc-id| |soc| BSP | +| Manual Head | ++----------------------+----------------------+ +| Document Title | |doc-id| |soc| BSP | +| | Manual Head | ++----------------------+----------------------+ +| Document Type | BSP Manual | ++----------------------+----------------------+ +| Article Number | |doc-id| | ++----------------------+----------------------+ +| Yocto Manual | | ++----------------------+----------------------+ +| Release Date | XXXX/XX/XX | ++----------------------+----------------------+ +| Is Branch of | |doc-id| |soc| BSP | +| | Manual Head | ++----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +================ ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +================ ================ ================= ========== +.. +================ ================ ================= ========== + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +The |sbc| populated with the |soc| SoC is supported. + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mn-head-components: +.. include:: ../imx8mm/components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mn-head-getting-started: +.. include:: /bsp/getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, |ref-bootswitch| needs to be set to the following + position: + +.. list-table:: Bootmode Selection + :align: center + + * - .. figure:: images/Nano_SD_BOOT.jpg + :width: 250px + + SD Card Boot + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP | +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mn-head-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mn.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mn-phyboard-polis*.dtb**: Kernel device tree file +* **imx8mn-phy*.dtbo**: Kernel device tree overlay files +* **phytec-headless-image\*.tar.gz**: Root file system +* **phytec-headless-image\*.rootfs.wic.xz**: compressed SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S1) +-------------------- + +The |sbc| features a boot switch with six individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mn-head-bootswitch: +.. include:: bootmode-switch.rsti + +.. include:: ../installing-os.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mn-head-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx-common/development/netboot.rsti + +.. include:: /bsp/imx-common/development/uuu.rsti + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + :end-before: .. build-uboot-fixed-ram-size-marker + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mn-head-format-sd: + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mn-head-device-tree: +.. include:: /bsp/device-tree.rsti + +.. code-block:: + + imx8mn-phyboard-polis-peb-eval-01.dtbo + imx8mn-phyboard-polis-peb-av-010.dtbo + imx8mn-phycore-rpmsg.dtbo + imx8mn-phycore-no-eth.dtbo + imx8mn-phycore-no-spiflash.dtbo + imx8mn-vm016.dtbo + imx8mn-vm016-fpdlink.dtbo + imx8mn-vm017.dtbo + imx8mn-vm017-fpdlink.dtbo + imx8mn-dual-vm017-fpdlink.dtbo + +.. _imx8mn-head-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX 0x00 + MX8MN_IOMUXC_SAI2_RXC_UART1_DCE_RX 0x00 + MX8MN_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B 0x00 + MX8MN_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B 0x00 + >; + }; + +The first part of the string MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad +(in this example SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the right) +defines different modes of the pad, for example, if internal pull resistors are +activated or not. In this case, the internal resistors are disabled. + +RS232/RS485 +----------- + +The |soc| SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +|ref-bootswitch| needs to be set correctly: + +.. list-table:: Switch between UART1 RS485/RS232 + + * - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS485.png + + **UART1 RS485** + + - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS232.jpg + + **UART1 RS232** + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n220` + +.. _imx8mn-head-network: + +Network +------- + +|sbc|-|soc| provides one Gigabit Ethernet interface. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +.. include:: ../../peripherals/wireless-network.rsti + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n301` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n309` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n78` + +.. include:: ../peripherals/gpios.rsti + +Pinmuxing of some GPIO pins in the device tree |dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_leds: leds1grp { + fsl,pins = < + MX8MN_IOMUXC_GPIO1_IO01_GPIO1_IO1 0x16 + MX8MN_IOMUXC_GPIO1_IO14_GPIO1_IO14 0x16 + MX8MN_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x16 + >; + }; + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n45` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n106` + +General I²C3 bus configuration (e.g. |dt-carrierboard|.dts): +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n196` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues. + +.. note:: + + If you deleted reserved EEPROM spaces, please contact our support! + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file |dt-som|.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n259` + +.. include:: /bsp/peripherals/rtc.rsti + +DT representation for I²C RTCs: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n267` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +'HS'). + +The |soc| SoC has a single USB controller core that is set to OTG mode. +To use the micro USB / OTG port dip switch S1 Pos5 has to be set to on. + +.. include:: /bsp/peripherals/usb-host.rsti + +.. include:: /bsp/peripherals/usb-otg.rsti + +The USB interface is configured as host in the kernel device tree +|dt-carrierboard|.dts. See: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n264` + +CAN FD +------ + +The |sbc| has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. Hint:: + + phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. + There are different interfaces involved, which limits the datarate + capabilities of CANFD. + +.. Hint:: + + On phyBOARD-Polis-i.MX8MN a terminating resistor can be enabled by setting + S5 to ON if required. + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n125` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti diff --git a/previews/271/_sources/bsp/imx8/imx8mn/imx8mn.rst.txt b/previews/271/_sources/bsp/imx8/imx8mn/imx8mn.rst.txt new file mode 100644 index 000000000..b318fc141 --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mn/imx8mn.rst.txt @@ -0,0 +1,33 @@ +==================== +i.MX 8M Nano Manuals +==================== + +HEAD +==== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + head + +BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +============================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd23.1.0 + +BSP-Yocto-NXP-i.MX8MM-PD22.1.1 +============================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd22.1.1 diff --git a/previews/271/_sources/bsp/imx8/imx8mn/pd22.1.1.rst.txt b/previews/271/_sources/bsp/imx8/imx8mn/pd22.1.1.rst.txt new file mode 100644 index 000000000..19e3ba813 --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mn/pd22.1.1.rst.txt @@ -0,0 +1,2082 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MM-PD22.1.1 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.wic +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/images/ampliphy-vendor/phyboard-polis-imx8mn-2/imx-boot-tools/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mm +.. _`static-pdf-dl`: ../../../_static/imx8mn-pd22.1.1.pdf + +.. IMX8(MN) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mn/phycore-imx8mn.c?h=v2021.04_2.2.0-phy13 + + +.. General Replacements +.. |atfloadaddr| replace:: 0x960000 +.. |kit| replace:: **phyCORE-i.MX8M Nano Kit** +.. |kit-ram-size| replace:: 1GiB +.. |mcore| replace:: M4 Core +.. |sbc| replace:: phyBOARD-Polis +.. |soc| replace:: i.MX 8M Nano +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MN +.. |debug-uart| replace:: ttymxc2 +.. |serial-uart| replace:: ttymxc0 +.. |bluetooth-uart| replace:: UART2 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx8mn +.. |kernel-tag| replace:: v5.10.72_2.2.0-phy17 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-defconfig| replace:: phycore-imx8mm_defconfig +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX8(MN) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MN +.. |u-boot-tag| replace:: v2021.04_2.2.0-phy13 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mn-phyboard-polis +.. |dt-som| replace:: imx8mn-phycore-som +.. |dtbo-peb-av-10| replace:: imx8mn-phyboard-polis-peb-av-010.dtbo + +.. IMX8(MN) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n47` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`hardknott` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MM +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: hardknott +.. |yocto-distro| replace:: ampliphy-vendor +.. |yocto-imagename| replace:: phytec-headless-image +.. |yocto-machinename| replace:: phyboard-polis-imx8mn-2 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MM-PD22.1.1 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MM-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MM-PD22.1.y +.. |yocto-ref-manual| replace:: L-813e.A12 Yocto Reference Manual (Hardknott) +.. _yocto-ref-manual: https://www.phytec.de/cdocuments/?doc=UIHsG +.. _yocto-ref-manual-kernel-and-bootloader-config: https://www.phytec.de/cdocuments/?doc=UIHsG#YoctoReferenceManualHardknottL813e-A12-KernelandBootloaderConfiguration +.. |yocto-sdk-rev| replace:: BSP-Yocto-NXP-i.MX8MP-PD22.1.1 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + + +.. Refs +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S1) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X30) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X2 ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MN) specific replacements +.. |sbc-network| replace:: \ +.. |pollux-fan-note| replace:: Only GPIO fan supported. +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + +.. only:: html + + Documentation in pdf format: `Download `_ + ++----------------------+----------------------+ +| |soc| BSP Manual | ++----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++----------------------+----------------------+ +| Document Type | BSP Manual | ++----------------------+----------------------+ +| Yocto Manual | | ++----------------------+----------------------+ +| Release Date | 2023/05/25 | ++----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================= ========== +|yocto-manifestname| Minor 2023/05/23 Released +==================== ================ ================= ========== + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +The |sbc| populated with the |soc| SoC is supported. + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mn-pd22.1.1-components: +.. include:: ../imx8mm/components.rsti + +Getting Started +=============== + +The |kit| is shipped with a pre-flashed SD card. It contains the +|yocto-imagename| and can be used directly as a boot source. The eMMC is +programmed with only a U-boot by default. You can get all sources from the +`PHYTEC download server `_. This chapter explains how to flash a BSP +image to SD card and how to start the board. + +Get the Image +------------- + +The WIC image contains all BSP files in several, correctly pre-formatted +partitions and can be copied to an SD card easily using the single Linux +command ``dd``. It can be built by Yocto or downloaded from the PHYTEC download +server. + +Get the WIC file from the download server: + +.. code-block:: console + :substitutions: + + host:~$ wget |link-image| + +Write the Image to SD Card +-------------------------- + +.. warning:: + To create your bootable SD card with the ``dd`` command, you must have root + privileges. Be very careful when specifying the destination device with + ``dd``! All files on the selected destination device will be erased + immediately without any further query! + + Selecting the wrong device may result in **data loss** and e.g. could erase + your currently running system! + +To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. Unmount any mounted partitions before +you start copying the image to the SD card. + +#. In order to get the correct device name, remove your SD card and + execute:: + + host$ lsblk + +#. Now insert your SD card and execute the command again:: + + host$ lsblk + +#. Compare the two outputs to find the new device names listed in the second + output. These are the device names of the SD card (device and partitions if + the SD card was formatted). +#. In order to verify the device names being found, execute the command + ``sudo dmesg``. Within the last lines of its output, you should also find the + device names, e.g. ``/dev/sde`` or ``/dev/mmcblk0`` (depending on your + system). + +Alternatively, you may use a graphical program of your choice, like `GNOME Disks +`_ or `KDE Partition Manager +`_, to find the correct device. + +Now that you have the correct device name, e.g. ``/dev/sde``, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. ``/dev/sde1``) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption. + +* Unmount all partitions, e.g.:: + + host$ sudo umount /dev/sde1 + +* After having unmounted all partitions, you can create your bootable SD card:: + + host$ sudo dd if=-.wic of=/dev/sdX bs=1M conv=fsync status=progress + + Again, make sure to replace ``/dev/sdX`` with your actual device name found + previously. + + The parameter ``conv=fsync`` forces a sync operation on the device before + ``dd`` returns. This ensures that all blocks are written to the SD card and + none are left in memory. The parameter ``status=progress`` will print out + information on how much data is and still has to be copied until it is + finished. + +An alternative and much faster way to prepare an SD card can be done by using +`bmap-tools `_ from Intel. Yocto +automatically creates a block map file (``-.wic.bmap``) for +the WIC image that describes the image content and includes checksums for data +integrity. *bmaptool* is packaged by various Linux distributions. For +Debian-based systems install it by issuing:: + + host$ sudo apt install bmap-tools + +Flash a WIC image to SD card by calling:: + + host$ bmaptool copy -.wic /dev/ + +.. warning:: + *bmaptool* only overwrites the areas of an SD card where image data is + located. This means that a previously written U-Boot environment may still be + available after writing the image. + +First Start-up +-------------- + +* To boot from an SD card, |ref-bootswitch| needs to be set to the following + position: + +.. list-table:: Bootmode Selection + :align: center + + * - .. figure:: images/Nano_SD_BOOT.jpg + :width: 250px + + SD Card Boot + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP | +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mn-pd22.1.1-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mm.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mn-phyboard-polis-dsi*.dtb**: Kernel device tree file +* **imx8mn-phy*.dtbo**: Kernel device tree overlay files +* **phytec-headless-image\*.tar.gz**: Root file system +* **phytec-headless-image\*.wic**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S1) +-------------------- + +The |sbc| features a boot switch with six individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mn-pd22.1.1-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **Default SOM boot**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. However, they only +work if the size of the image file is less than 1GB. If the image file is +larger, go to the section Format SD Card. Configure the |ref-bootswitch| to boot +from SD Card and put in an SD card. Power on the board and stop in U-Boot +prompt. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +* Load your image via network to RAM: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* Write the image to the eMMC: + + .. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + A working network is necessary! Setup Network Host. + +Take a compressed or uncompressed image on the host and send it with ssh through +the network (then uncompress it, if necessary) to the eMMC of the target with a +one-line command: + +.. code-block:: console + :substitutions: + + target:~$ ssh @192.168.3.10 "dd if=/|yocto-imagename|-|yocto-machinename|.wic" | dd of=/dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +Send the image with the command dd command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2" + +Flash eMMC u-boot image via Network from running u-boot +....................................................... + +Update the standalone u-boot image imx-boot is also possible from u-boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB +................... + +Flash eMMC from USB in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in Bootloader after enabling the OPTEE. + +These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch to |ref-bootswitch| and put in an SD card. Power on the board +and stop in u-boot prompt. Insert a USB device with the copied WIC image +to the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} *.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the bootmode switch to +|ref-bootswitch|. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ cd /mnt + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2boot0; mmcblk2boot1) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + +.. warning:: + + Before this will work, you need to configure the multi-port switch + to **Default SOM Boot** to |ref-bootswitch|. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see |ref-format-sd|. + +Flash eMMC from SD card in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in Bootloader after enabling the OPTEE. If the + image file is too large use the `Updating eMMC from SD card in + Linux on Target` subsection. + +* Flash an SD card with a working image and create a third FAT partition. Copy + the WIC image (for example |yocto-imagename|.wic) to this + partition. +* Configure the bootmode switch to boot from the SD Card and insert the SD + card. +* Power on the board and stop in u-boot. +* Flash your WIC image (for example |yocto-imagename|.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> fatload mmc 1:3 ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc0(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the multi-port switch to Default SOM Boot to + boot from eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a complete image saved on +the SD card (e.g. |yocto-imagename|-|yocto-machinename|.wic). + +* Show your saved image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2\ **boot0**; mmcblk2\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + +.. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to Default + SOM Boot to boot from eMMC. + +Flash SPI NOR Flash +------------------- + +The |som| modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set |ref-bootswitch| to **QSPI boot** to boot from QSPI. The SPI Flash is +usually quite small. The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash +populated. Only the bootloader and the environment can be stored. The kernel, +device tree, and file system are taken from eMMC by default. + +The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with: + +.. code-block:: + + u-boot=> printenv mtdparts + mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none) + +Flash SPI NOR Flash from Network +................................ + +The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-|soc|. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Flash SPI NOR from Network in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI-NOR flash needs to be probed: + +.. code-block:: + + u-boot=> sf probe + SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB + +* A specially formatted u-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image over tftp, erase and write the + bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + device 0 offset 0x0, size 0x1c0b20 + 1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +.. warning:: + + Erasing the complete SPI NOR flash when it is fully written will take quite + some time. This can trigger the watchdog to reset. Due to this, erase the + full flash in Linux. + +Flash SPI NOR from Network in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the image from the host to the target: + + .. code-block:: console + :substitutions: + + host:~$ scp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root + +* Find the number of erase blocks of the U-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +Flash SPI NOR Flash from SD Card +................................ + +The bootloader on SPI NOR flash can be also flashed with SD Card. + +Flash SPI NOR from SD Card in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the FAT partition + on the SD Card. Before reading and writing are possible, the SPI-NOR flash + needs to be probed: + + .. code-block:: + + u-boot=> sf probe + SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB + +* A specially formatted U-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image from the SD Card, erase and write + the bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +.. warning:: + + Erasing the complete SPI NOR flash when it is fully written will take quite + some time. This can trigger the watchdog to reset. Due to this, erase the + full flash in Linux. + +Flash SPI NOR from SD Card in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Mount the SD Card: + + .. code-block:: console + :substitutions: + + host:~$ mount /dev/mmcblkp1 /mnt + +* Find the number of erase blocks of the u-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp /mnt/imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A3 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mn-pd22.1.1-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + +U-Boot standalone build +----------------------- + +Get the source code +................... + +* Get the U-Boot sources: + + .. code-block:: console + + host:~$ git clone git://git.phytec.de/u-boot-imx + +* To get the correct *U-Boot* **tag** you need to take a look at our release + notes, which can be found here: `release notes `_ +* The **tag** needed at this release is called |u-boot-tag| +* Check out the needed *U-Boot* **tag**: + +.. code-block:: console + :substitutions: + + host:~$ cd ~/u-boot-imx/ + host:~$ git fetch --all --tags + host:~$ git checkout tags/|u-boot-tag| + +* Technically, you can now build the U-Boot, but practically there are some + further steps necessary: + + * Create your own development branch: + + .. code-block:: console + + host:~$ git switch --create + + .. note:: + + You can name your development branch as you like, this is just an example. + +* Set up a build environment: + + .. code-block:: console + :substitutions: + + host:~$ source /opt/|yocto-distro|/|yocto-manifestname|/environment-setup-cortexa53-crypto-phytec-linux + +* Set this environment variable before building the Image: + + .. code-block:: console + :substitutions: + + host:~$ export ATF_LOAD_ADDR=|atfloadaddr| + +Get the needed binaries +....................... + +To build the bootloader, you need to **copy** these **files** to your |u-boot-repo-name| +**build directory** and rename them to fit with *mkimage* script: + +* **ARM Trusted firmware binary** (*mkimage tool* compatible format + **bl31.bin**): bl31-|kernel-socname|.bin +* **OPTEE image** (optional): tee.bin +* **DDR firmware files** (*mkimage tool* compatible format + **lpddr4_[i,d]mem_\*d_\*.bin**): + lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, + lpddr4_imem_2d_*.bin + +If you already built our BSP with Yocto, you can get the +bl31-|kernel-socname|.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: |ref-bsp-images| + +Or you can download the files here: |link-boot-tools| + +.. warning:: + + Make sure you rename the files you need so that they are compatible with the + *mkimage tool*. + +Build the bootloader +.................... + +* build flash.bin (imx-boot): + + .. code-block:: console + :substitutions: + + host:~$ make phycore-|kernel-socname|_defconfig + host:~$ make flash.bin + +Flash the bootloader to a block device +...................................... + +The flash.bin can be found at u-boot-imx/ directory and now can be flashed. A +chip-specific offset is needed: + +.. _offset-table: + +===== =================== ============================= ============ +SoC Offset User Area Offset Boot Partition eMMC Device +===== =================== ============================= ============ +|soc| |u-boot-offset| kiB |u-boot-offset-boot-part| kiB /dev/mmcblk2 +===== =================== ============================= ============ + +E.g. flash SD card: + +.. code-block:: console + :substitutions: + + host:~$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=|u-boot-offset| conv=sync + +.. hint:: + The specific offset values are also declared in the Yocto variables "BOOTLOADER_SEEK" and "BOOTLOADER_SEEK_EMMC" + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mn-pd22.1.1-device-tree: + +Device Tree (DT) +================ + +Introduction +------------ + +The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html) + +*"The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn't need to hard code details of the machine."* + +The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at `devicetree.org `_. + +PHYTEC |soc| BSP Device Tree Concept +------------------------------------ + +The following sections explain some rules PHYTEC has defined on how to set up +device trees for our |soc| SoC-based boards. + +Device Tree Structure +..................... + +* *Module.dtsi* - Module includes all devices mounted on the SoM, such as PMIC + and RAM. +* *Carrierboard.dtsi* - Devices that come from the |soc| SoC but are just routed + down to the carrier board and used there are included in this dtsi. +* *Board.dts* - include the carrier board and module dtsi files. There may also + be some hardware configuration nodes enabled on the carrier board or the + module (i.e. the Board .dts shows the special characteristics of the board + configuration). For example, there are phyCORE-|soc| SOMs which may or may not + have a MIPI DSI to LVDS converter mounted. The converter is enabled (if + available) in the Board .dts and not in the Module .dtsi + +From the root directory of the Linux Kernel our devicetree files for |socfamily| +platforms can be found in ``arch/arm64/boot/dts/freescale/``. + +Device Tree Overlay +................... + +Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder ``arch/arm64/boot/dts/freescale/overlays``. + +Available overlays for |yocto-machinename|.conf are: + +.. code-block:: + + imx8mn-phyboard-polis-peb-eval-01.dtbo + imx8mn-phyboard-polis-peb-av-010.dtbo + imx8mn-phycore-rpmsg.dtbo + imx8mn-phycore-no-eth.dtbo + imx8mn-phycore-no-spiflash.dtbo + imx8mn-vm016.dtbo + imx8mn-vm016-fpdlink.dtbo + imx8mn-vm017.dtbo + imx8mn-vm017-fpdlink.dtbo + imx8mn-dual-vm017-fpdlink.dtbo + +.. _imx8mn-pd22.1.1-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +imx8mn-phyboard-polis.dtsi: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX 0x00 + MX8MN_IOMUXC_SAI2_RXC_UART1_DCE_RX 0x00 + MX8MN_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B 0x00 + MX8MN_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B 0x00 + >; + }; + +The first part of the string MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad +(in this example SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the right) +defines different modes of the pad, for example, if internal pull resistors are +activated or not. In this case, the internal resistors are disabled. + +RS232/RS485 +----------- + +The |soc| SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +|ref-bootswitch| needs to be set correctly: + +.. list-table:: Switch between UART1 RS485/RS232 + + * - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS485.png + + **UART1 RS485** + + - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS232.jpg + + **UART1 RS232** + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n166` + +.. _imx8mn-pd22.1.1-network: + +Network +------- + +|sbc|-|soc| provides one Gigabit Ethernet interface. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First set the correct regulatory domain for your country: + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see: + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +Set up the wireless interface: + +.. code-block:: console + + target:~$ ip link + target:~$ ip link set up dev wlan0 + +Now you can scan for available networks: + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection. + +To do so, add the network-credentials to the file ``/etc/wpa_supplicant.conf``: + +.. code-block:: + + country=DE + network={ + ssid="" + proto=WPA2 + psk="" + } + +Now a connection can be established: + +.. code-block:: console + + target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B + +This should result in the following output: + +.. code-block:: + + ... + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section `Changing the Network Configuration` in the |yocto-ref-manual|_. + +First, create the directory: + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +Then add the following configuration snippet in ``/etc/systemd/network/10-wlan0.network``: + +.. code-block:: + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +Now, restart the network daemon so that the configuration takes effect: + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Bluetooth +......... + +Bluetooth is connected to |bluetooth-uart| interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually: + +.. code-block:: console + + target:~$ hciconfig hci0 up + + target:~$ hciconfig -a + + hci0: Type: Primary Bus: UART + BD Address: 00:25:CA:2F:39:96 ACL MTU: 1021:8 SCO MTU: 64:1 + UP RUNNING PSCAN + RX bytes:1392 acl:0 sco:0 events:76 errors:0 + TX bytes:1198 acl:0 sco:0 commands:76 errors:0 + ... + +Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup. + +.. code-block:: console + + target:~$ hcitool scan + Scanning ... + XX:XX:XX:XX:XX:XX + +Visibility +~~~~~~~~~~ + +To activate visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 piscan + +To disable visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 noscan + +Connect +~~~~~~~ + +.. code-block:: console + + target:~$ bluetoothctl + [bluetooth]# discoverable on + Changing discoverable on succeeded + [bluetooth]# pairable on + Changing pairable on succeeded + [bluetooth]# agent on + Agent registered + [bluetooth]# default-agent + Default agent request successful + [bluetooth]# scan on + [NEW] Device XX:XX:XX:XX:XX:XX + [bluetooth]# connect XX:XX:XX:XX:XX:XX + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n238` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n293` + +eMMC Devices +------------ + +PHYTEC modules like phyCORE-|soc| is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw MLC memory cells combined with a memory +controller that handles ECC and wear leveling. They are connected via an SD/MMC +interface to the |soc| and are represented as block devices in the Linux kernel +like SD cards, flash drives, or hard disks. + +The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer's datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard. + +PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1 + +Extended CSD Register +..................... + +eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard. + +In the Linux user space, you can query the registers: + +.. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| + +You will see: + +.. code-block:: + + ============================================= + Extended CSD rev 1.7 (MMC 5.0) + ============================================= + + Card Supported Command sets [S_CMD_SET: 0x01] + [...] + +Enabling Background Operations (BKOPS) +...................................... + +In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +cells. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called **Background +Operations (BKOPS)**. + +By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency. + +The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details. + +Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0): + +* Value 0: The host does not support the manual trigger of BKOPS. Device write + performance suffers. +* Value 1: The host does support the manual trigger of BKOPS. It will issue + BKOPS from time to time when it does not need the device. + +The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details). + +The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)). + +The userspace tool mmc does not currently support enabling automatic BKOPS +features. + +* To check whether *BKOPS_EN* is set, execute: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep BKOPS_EN + + The output will be, for example: + + .. code-block:: + + Enable background operations handshake [BKOPS_EN]: 0x01 + #OR + Enable background operations handshake [BKOPS_EN]: 0x00 + + Where value 0x00 means BKOPS_EN is disabled and device write performance + suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue + background operations from time to time. + +* To set the BKOPS_EN bit, execute: + + .. code-block:: console + :substitutions: + + target:~$ mmc bkops enable /dev/|emmcdev| + +* To ensure that the new setting is taken over and the kernel triggers BKOPS by + itself, shut down the system: + + .. code-block:: console + + target:~$ poweroff + +.. tip:: + + The BKOPS_EN bit is one-time programmable only. It cannot be reversed. + +Reliable Write +.............. + +There are two different Reliable Write options: + +1. Reliable Write option for a whole eMMC device/partition. +2. Reliable Write for single write transactions. + +.. tip:: + + Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT + partition table (see the previous section). + +The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-|soc| SoMs. To check this on the running target: + +.. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep -A 5 WR_REL_SET + Write reliability setting register [WR_REL_SET]: 0x1f + user area: the device protects existing data if a power failure occurs during a write o + peration + partition 1: the device protects existing data if a power failure occurs during a write + operation + partition 2: the device protects existing data if a power failure occurs during a write + operation + partition 3: the device protects existing data if a power failure occurs during a write + operation + partition 4: the device protects existing data if a power failure occurs during a write + operation + -- + Device supports writing EXT_CSD_WR_REL_SET + Device supports the enhanced def. of reliable write + +Otherwise, it can be enabled with the mmc tool: + +.. code-block:: console + + target:~$ mmc --help + + [...] + mmc write_reliability set <-y|-n> + +The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META. + +**Conclusion**: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application. + +Resizing ext4 Root Filesystem +............................. + +When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk. + +* Get the current device size: + + .. code-block:: console + :substitutions: + + target:~$ parted /dev/|emmcdev| print + +* The output looks like this: + + .. code-block:: + :substitutions: + + Model: MMC Q2J55L (sd/mmc) + Disk /dev/|emmcdev|: 7617MB + Sect[ 1799.850385] |emmcdev|: p1 p2 + or size (logical/physical): 512B/512B + Partition Table: msdos + Disk Flags: + + Number Start End Size Type File system Flags + 1 4194kB 72.4MB 68.2MB primary fat16 boot, lba + 2 72.4MB 537MB 465MB primary ext4 + +* Use parted to resize the root partition to the max size of the device: + + .. code-block:: console + :substitutions: + + target:~$ parted /dev/|emmcdev| resizepart 2 100% + Information: You may need to update /etc/fstab. + + target:~$ parted /dev/|emmcdev| print + Model: MMC Q2J55L (sd/mmc) + Disk /dev/|emmcdev|: 7617MB + Sector size (logical/physical): 512[ 1974.191657] |emmcdev|: p1 p2 + B/512B + Partition Table: msdos + Disk Flags: + + Number Start End Size Type File system Flags + 1 4194kB 72.4MB 68.2MB primary fat16 boot, lba + 2 72.4MB 7617MB 7545MB primary ext4 + +Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted. + +* Resize the filesystem to a new partition size: + + .. code-block:: console + :substitutions: + + target:~$ resize2fs /dev/|emmcdev|p2 + resize2fs 1.46.1 (9-Feb-2021) + Filesystem at /dev/|emmcdev|p2 is mounted on /; on-line resizing required + [ 131.609512] EXT4-fs (|emmcdev|p2): resizing filesystem + from 454136 to 7367680 blocks + old_desc_blocks = 4, new_desc_blocks = 57 + [ 131.970278] EXT4-fs (|emmcdev|p2): resized filesystem to 7367680 + The filesystem on /dev/|emmcdev|p2 is now 7367680 (1k) blocks long + +Enable pseudo-SLC Mode +...................... + +eMMC devices use MLC memory cells +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC memory cells used in NAND Flash, MLC memory cells have lower +reliability and a higher error rate at lower costs. + +If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity. + +.. warning:: + + When enabling the enhanced attribute on the device, all data will be lost. + +The following sequence shows how to enable the enhanced attribute. + +* First obtain the current size of the eMMC device with: + + .. code-block:: console + :substitutions: + + target:~$ parted -m /dev/|emmcdev| unit B print + + You will receive: + + .. code-block:: + :substitutions: + + BYT; + /dev/|emmcdev|:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:; + + As you can see this device has 63652757504 Byte = 60704 MiB. + +* To get the maximum size of the device after pseudo-SLC is enabled use: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep ENH_SIZE_MULT -A 1 + + which shows, for example: + + .. code-block:: + + Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + -- + Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000 + i.e. 0 KiB + + Here the maximum size is 3719168 KiB = 3632 MiB. + +* Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by + typing: + + .. code-block:: console + :substitutions: + + target:~$ mmc enh_area set -y 0 3719168 /dev/|emmcdev| + + You will get: + + .. code-block:: + :substitutions: + + Done setting ENH_USR area on /dev/|emmcdev| + setting OTP PARTITION_SETTING_COMPLETED! + Setting OTP PARTITION_SETTING_COMPLETED on /dev/|emmcdev| SUCCESS + Device power cycle needed for settings to take effect. + Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle + +* To ensure that the new setting has taken over, shut down the system: + + .. code-block:: console + + target:~$ poweroff + + and perform a power cycle. It is recommended that you verify the settings now. + +* First, check the value of ENH_SIZE_MULT which must be 3719168 KiB: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep ENH_SIZE_MULT -A 1 + + You should receive:: + + Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + -- + Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + +* Finally, check the size of the device: + + .. code-block:: console + :substitutions: + + target:~$ parted -m /dev/|emmcdev| unit B print + BYT; + /dev/|emmcdev|:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:; + +Erasing the Device +.................. + +It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC memory +cells or mark these blocks as discard. The data on the device is lost and will +be read back as zeros. + +* After booting from SD Card execute: + + .. code-block:: console + :substitutions: + + target:~$ blkdiscard -f --secure /dev/|emmcdev| + + The option --secure ensures that the command waits until the eMMC device has + erased all blocks. The -f (force) option disables all checking before erasing + and it is needed when the eMMC device contains existing partitions with data. + +.. tip:: + .. code-block:: console + :substitutions: + + target:~$ dd if=/dev/zero of=/dev/|emmcdev| conv=fsync + + also destroys all information on the device, but this command is bad for wear + leveling and takes much longer! + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n75` + +GPIOs +----- + +The |sbc| has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to |soc| pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal |soc| GPIO banks GPIO1 – GPIO5. + +The GPIOs are identified as GPIO_ (e.g. GPIO5_07). identifies the GPIO +bank and counts from 1 to 5, while stands for the GPIO within the bank. +is being counted from 0 to 31 (32 GPIOs on each bank). + +By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is: + +.. code-block:: + + Linux GPIO number: = ( - 1) * 32 + + +Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools: + +* Detecting the gpiochips on the chip: + + .. code-block:: console + + target:~$ gpiodetect + gpiochip0 [30200000.gpio] (32 lines) + gpiochip1 [30210000.gpio] (32 lines) + gpiochip2 [30220000.gpio] (32 lines) + gpiochip3 [30230000.gpio] (32 lines) + gpiochip4 [30240000.gpio] (32 lines) + +* Show detailed information about the gpiochips. Like their names, consumers, + direction, active state, and additional flags: + + .. code-block:: console + + target:~$ gpioinfo gpiochip0 + +* Read the value of a GPIO (e.g GPIO 20 from chip0): + + .. code-block:: console + + target:~$ gpioget gpiochip0 20 + +* Set the value of GPIO 20 on chip0 to 0 and exit tool: + + .. code-block:: console + + target:~$ gpioset --mode=exit gpiochip0 20=0 + +* Help text of gpioset shows possible options: + + .. code-block:: console + + target:~$ gpioset --help + Usage: gpioset [OPTIONS] = = ... + Set GPIO line values of a GPIO chip + + Options: + -h, --help: display this message and exit + -v, --version: display the version and exit + -l, --active-low: set the line active state to low + -m, --mode=[exit|wait|time|signal] (defaults to 'exit'): + tell the program what to do after setting values + -s, --sec=SEC: specify the number of seconds to wait (only valid for --mode=time) + -u, --usec=USEC: specify the number of microseconds to wait (only valid for --mode=time) + -b, --background: after setting values: detach from the controlling terminal + + Modes: + exit: set values and exit immediately + wait: set values and wait for user to press ENTER + time: set values and sleep for a specified amount of time + signal: set values and wait for SIGINT or SIGTERM + + Note: the state of a GPIO line controlled over the character device reverts to default + when the last process referencing the file descriptor representing the device file exits. + This means that it's wrong to run gpioset, have it exit and expect the line to continue + being driven high or low. It may happen if given pin is floating but it must be interpreted + as undefined behavior. + + +.. warning:: + + Some of the user IOs are used for special functions. Before using a user IO, + refer to the schematic or the hardware manual of your board to ensure that it + is not already in use. + +GPIOs via sysfs +............... + +.. warning:: + + Accessing gpios via sysfs is deprecated and we encourage to use libgpiod + instead. + +Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling ``CONFIG_GPIO_SYSFS`` in the kernel +configuration. To make ``CONFIG_GPIO_SYSFS`` visible in menuconfig the option +``CONFIG_EXPERT`` has to be enabled first. + +You can also add this option for example to the defconfig you use in +``arch/arm64/configs/`` in the linux kernel sources. For our NXP based releases, +this could be for example ``imx8_phytec_distro.config``:: + + .. + CONFIG_EXPERT=y + CONFIG_GPIO_SYSFS=y + .. + +Otherwise you can create a new config fragment. This is described in our +`Yocto Reference Manual `_. + +Pinmuxing of some GPIO pins in the device tree |dt-carrierboard|.dtsi:: + + pinctrl_leds: leds1grp { + fsl,pins = < + MX8MN_IOMUXC_GPIO1_IO01_GPIO1_IO1 0x16 + MX8MN_IOMUXC_GPIO1_IO14_GPIO1_IO14 0x16 + MX8MN_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x16 + >; + }; + +LEDs +---- + +If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using ``/sys/class/leds/`` instead +of ``/sys/class/gpio/``. The maximum brightness of the LEDs can be read from +the ``max_brightness`` file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings. + +Below is a simple example. + +To get all available LEDs, type: + +.. code-block:: console + + target:~$ ls /sys/class/leds + mmc1::@ mmc2::@ user-led1@ user-led2@ user-led3@ + +Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the |sbc|. + +* To toggle the LEDs ON: + + .. code-block:: console + + target:~$ echo 255 > /sys/class/leds/user-led1/brightness + +* To toggle OFF: + + .. code-block:: console + + target:~$ echo 0 > /sys/class/leds/user-led1/brightness + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n35` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n98` + +General I²C3 bus configuration (e.g. |dt-carrierboard|.dtsi): +:imx-dt:`imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n147` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues. + +.. include:: ../peripherals/eeprom.rsti + +Rescue EEPROM Data +.................. + +The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area. + +.. code-block:: console + + target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 + +.. note:: + + If you deleted both EEPROM spaces, please contact our support! + +DT representation, e.g. in phyCORE-|soc| file |dt-som|.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n248` + +.. include:: /bsp/peripherals/rtc.rsti + :end-before: .. rtc_parameter_start_label + +DT representation for I²C RTCs: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy9#n254` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +'HS'). + +The |soc| SoC has a single USB controller core that is set to OTG mode. +To use the micro USB / OTG port dip switch S1 Pos5 has to be set to on. + +.. include:: /bsp/peripherals/usb-host.rsti + +.. include:: /bsp/peripherals/usb-otg.rsti + +Both USB interfaces are configured as host in the kernel device tree +|dt-carrierboard|.dtsi. See: +:imx-dt:`imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n206` + +CAN FD +------ + +The |sbc| has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. Hint:: + + phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. + There are different interfaces involved, which limits the datarate + capabilities of CANFD. + +.. Hint:: + + On phyBOARD-Polis-i.MX8MN a terminating resistor can be enabled by setting + S5 to ON if required. + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dtsi: +:imx-dt:`imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n104` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. BSP EXTENSIONS +.. +---------------------------------------------------------------------------+ + +BSP Extensions +============== + +Chromium +-------- + +Our BSP for the |sbc|-|soc| supports Chromium. You can include it in the +|yocto-imagename| with only a few steps. + +Adding Chromium to Your local.conf +.................................. + +To include Chromium you have to add the following line into your local.conf. You +can find it in /build/conf/local.conf. This adds Chromium to your +next image build. :: + + IMAGE_INSTALL_append = " chromium-ozone-wayland" + +.. note:: + + Compiling Chromium takes a long time. + +Get Chromium Running on the Target +.................................. + +To run Chromium, it needs a few arguments to use the hardware graphics +acceleration:: + + target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox + +If you want to start Chromium via SSH, you must first define the display on +which Chromium will run. For example:: + + target$ DISPLAY=:0 + +After you have defined this, you can start it via virtual terminal on Weston as +shown above. diff --git a/previews/271/_sources/bsp/imx8/imx8mn/pd23.1.0.rst.txt b/previews/271/_sources/bsp/imx8/imx8mn/pd23.1.0.rst.txt new file mode 100644 index 000000000..229d493ea --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mn/pd23.1.0.rst.txt @@ -0,0 +1,1670 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.wic +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/imx-boot-tools/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mm +.. _`static-pdf-dl`: ../../../_static/imx8mn-pd23.1.0.pdf + +.. IMX8(MN) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mn/phycore-imx8mn.c?h=v2022.04_2.2.2-phy5#n66 + + +.. General Replacements +.. |kit| replace:: **phyCORE-i.MX8M Nano Kit** +.. |kit-ram-size| replace:: 1GiB +.. |mcore| replace:: M4 Core +.. |sbc| replace:: phyBOARD-Polis +.. |soc| replace:: i.MX 8M Nano +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MN +.. |debug-uart| replace:: ttymxc2 +.. |serial-uart| replace:: ttymxc0 +.. |bluetooth-uart| replace:: UART2 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx8mn +.. |kernel-tag| replace:: v5.15.71_2.2.2-phy3 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-defconfig| replace:: phycore-imx8mn_defconfig +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX8(MN) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MN +.. |u-boot-tag| replace:: v2022.04_2.2.2-phy5 + + +.. RAUC +.. |rauc-manual| replace:: L-1006e.A5 RAUC Update & Device Management Manual +.. _rauc-manual: https://www.phytec.de/cdocuments/?doc=fgByJg + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mn-phyboard-polis +.. |dt-som| replace:: imx8mn-phycore-som +.. |dtbo-peb-av-10| replace:: imx8mn-phyboard-polis-peb-av-010.dtbo + +.. IMX8(MN) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n50` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`kirkstone` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MM +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: kirkstone +.. |yocto-distro| replace:: ampliphy-vendor +.. |yocto-imagename| replace:: phytec-headless-image +.. |yocto-imageext| replace:: wic +.. |yocto-machinename| replace:: phyboard-polis-imx8mn-2 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MM-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MM-PD23.1.y +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (kirkstone) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 4.0.13 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Refs +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S1) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X30) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X2 ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MN) specific replacements +.. |sbc-network| replace:: \ +.. |pollux-fan-note| replace:: Only GPIO fan supported. +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + +.. only:: html + + Documentation in pdf format: `Download `_ + ++----------------------+----------------------+ +| |soc| BSP Manual | ++----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++----------------------+----------------------+ +| Document Type | BSP Manual | ++----------------------+----------------------+ +| Yocto Manual | Kirkstone | ++----------------------+----------------------+ +| Release Date | 2024/01/10 | ++----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================ ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================ ========== +|yocto-manifestname| Major 2023/12/12 Released +==================== ================ ================ ========== + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +The |sbc| populated with the |soc| SoC is supported. + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mn-pd23.1.0-components: +.. include:: ../imx8mm/components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mn-pd23.1.0-getting-started: + +Getting Started +=============== + +The |kit| is shipped with a pre-flashed SD card. It contains the +|yocto-imagename| and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +`PHYTEC download server `_. This chapter explains how to flash a BSP +image to SD card and how to start the board. + +There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool ``dd``. An +alternative way is to use PHYTEC's system initialization program called +`partup `_, which makes it especially easy to +format more complex systems. You can get `prebuilt Linux binaries of partup +`__ from its release page. Also read +`partup's README `__ for installation +instructions. + +Get the Image +------------- + +The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using ``dd``, can be downloaded from the `PHYTEC download server +`_. + +Get either the partup package or the WIC image from the download server: + +.. code-block:: console + :substitutions: + + host:~$ wget |link-partup-package| + host:~$ wget |link-image| + +.. note:: + For eMMC, more complex partitioning schemes or even just large images, we + recommend using the partup package, as it is faster in writing than ``dd`` + and allows for a more flexible configuration of the target flash device. + +Write the Image to SD Card +-------------------------- + +.. warning:: + To create your bootable SD card, you must have root privileges on your Linux + host PC. Be very careful when specifying the destination device! All files + on the selected device will be erased immediately without any further query! + + Selecting the wrong device may result in **data loss** and e.g. could erase + your currently running system on your host PC! + +Finding the Correct Device +.......................... + +To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card. + +#. In order to get the correct device name, remove your SD card and + execute: + + .. code-block:: console + + host:~$ lsblk + +#. Now insert your SD card and execute the command again: + + .. code-block:: console + + host:~$ lsblk + +#. Compare the two outputs to find the new device names listed in the second + output. These are the device names of the SD card (device and partitions if + the SD card was formatted). +#. In order to verify the device names being found, execute the command + ``sudo dmesg``. Within the last lines of its output, you should also find the + device names, e.g. ``/dev/sde`` or ``/dev/mmcblk0`` (depending on your + system). + +Alternatively, you may use a graphical program of your choice, like `GNOME Disks +`_ or `KDE Partition Manager +`_, to find the correct device. + +Now that you have the correct device name, e.g. ``/dev/sde``, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. ``/dev/sde1``) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption. + +Unmount all those partitions, e.g.: + +.. code-block:: console + + host:~$ sudo umount /dev/sde1 + host:~$ sudo umount /dev/sde2 + +Now, the SD card is ready to be flashed with an image, using either ``partup``, +``dd`` or ``bmap-tools``. + +Using partup +............ + +Writing to an SD card with partup is done in a single command: + +.. code-block:: console + :substitutions: + + host:~$ sudo partup install |yocto-imagename|-|yocto-machinename|.partup /dev/ + +Make sure to replace with your actual device name found previously. + +Further usage of partup is explained at its `official documentation website +`__. + +.. note:: + *partup* has the advantage of allowing to clear specific raw areas in the + MMC user area, which is used in our provided partup packages to erase any + existing U-Boot environments. This is a known issue *bmaptool* does not + solve, as mentioned below. + + Another key advantage of partup over other flashing tools is that it allows + configuring MMC specific parts, like writing to eMMC boot partitions, without + the need to call multiple other commands when writing. + +Using bmap-tools +................ + +An alternative and also fast way to prepare an SD card is using +`bmap-tools `_. Yocto +automatically creates a block map file (``-.wic.bmap``) for +the WIC image that describes the image content and includes checksums for data +integrity. *bmaptool* is packaged by various Linux distributions. For +Debian-based systems install it by issuing: + +.. code-block:: console + + host:~$ sudo apt install bmap-tools + +Flash a WIC image to SD card by calling: + +.. code-block:: console + :substitutions: + + host:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/ + +Replace with your actual SD card's device name found previously, +and make sure to place the file ``-.wic.bmap`` alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip. + +.. warning:: + *bmaptool* only overwrites the areas of an SD card where image data is + located. This means that a previously written U-Boot environment may still be + available after writing the image. + +Using ``dd`` +............ + +After having unmounted all SD card's partitions, you can create your bootable SD card. + +Some PHYTEC BSPs produce uncompressed images (with filename-extension \*.wic), +and some others produce compressed images (with filename-extension \*.wic.xz). + +To flash an uncompressed images (\*.wic) use command below: + +.. code-block:: console + :substitutions: + + host:~$ sudo dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/ bs=1M conv=fsync status=progress + +Or to flash a compressed images (\*.wic.xz) use that command: + +.. code-block:: console + :substitutions: + + host:~$ xzcat |yocto-imagename|-|yocto-machinename|.wic.xz | sudo dd of=/dev/ bs=1M conv=fsync status=progress + +Again, make sure to replace with your actual device name found +previously. + +The parameter ``conv=fsync`` forces a sync operation on the device before +``dd`` returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter ``status=progress`` will print out +information on how much data is and still has to be copied until it is +finished. + +First Start-up +-------------- + +* To boot from an SD card, |ref-bootswitch| needs to be set to the following + position: + +.. list-table:: Bootmode Selection + :align: center + + * - .. figure:: images/Nano_SD_BOOT.jpg + :width: 250px + + SD Card Boot + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP | +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mn-pd23.1.0-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mn.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mn-phyboard-polis*.dtb**: Kernel device tree file +* **imx8mn-phy*.dtbo**: Kernel device tree overlay files +* **phytec-headless-image\*.tar.gz**: Root file system +* **phytec-headless-image\*.wic**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S1) +-------------------- + +The |sbc| features a boot switch with six individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mn-pd23.1.0-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see |ref-setup-network-host|. + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **eMMC**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load your image via network to RAM: + +* when using dhcp + + .. code-block:: + :substitutions: + + u-boot=> dhcp |yocto-imagename|-|yocto-machinename|.wic + BOOTP broadcast 1 + DHCP client bound to address 192.168.3.1 (1 ms) + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.1 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* when using a static ip address (serverip and ipaddr must be set + additionally). + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Take a compressed or uncompressed image with accompanying block map on the host +and send it with ssh through the network to the eMMC of the target with a +one-line command: + +.. code-block:: console + :substitutions: + + target:~$ scp @192.168.3.10:/srv/tftp/|yocto-imagename|-|yocto-machinename|.wic /tmp && bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls /srv/tftp + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +Send the image with the ``bmaptool`` command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ scp /srv/tftp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2" + +Flash eMMC U-Boot image via Network from running U-Boot +....................................................... + +Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB stick +......................... + +Flash eMMC from USB stick in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. + +These steps will show how to update the eMMC via a USB device. Configure the +|ref-bootswitch| to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied WIC image to the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} *.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the |ref-bootswitch| to SD Card. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ ls /mnt + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy /mnt/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + + .. tip:: + + Before this will work, you need to configure the |ref-bootswitch| to + **eMMC**. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see |ref-format-sd|. + +Alternatively, flash a partup package to the SD card, as described in +|ref-getting-started|. This will ensure the full space of the SD card is used. + +Flash eMMC from SD card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. If the + image file is too large use the `Updating eMMC from SD card in + Linux on Target` subsection. + +* Flash an SD card with a working image and create a third ext4 partition. Copy + the WIC image (for example |yocto-imagename|.wic) to this + partition. +* Configure the |ref-bootswitch| to SD Card and insert the SD Card. +* Power on the board and stop in U-Boot. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> ext4load mmc 1:3 ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev to eMMC: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + +* Flash your WIC image (for example |yocto-imagename|.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. + + .. code-block:: + + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the |ref-bootswitch| to eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card. + +* Show your saved partup package or WIC image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.partup + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition) using `partup`_: + + .. code-block:: console + :substitutions: + + target:~$ partup install |yocto-imagename|-|yocto-machinename|.partup /dev/mmcblk2 + + Flashing the partup package has the advantage of using the full capacity of + the eMMC device, adjusting partitions accordingly. + + .. note:: + + Alternatively, ``bmaptool`` may be used instead: + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + + Keep in mind that the root partition does not make use of the full space when + flashing with ``bmaptool``. + +* After a complete write, your board can boot from eMMC. + + .. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to eMMC. + +Flash SPI NOR Flash +------------------- + +The |som| modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set |ref-bootswitch| to **SPI NOR**. The SPI Flash is usually quite small. +The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash populated. Only the +bootloader and the environment can be stored. The kernel, device tree, and file +system are taken from eMMC by default. + +The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with: + +.. code-block:: + + u-boot=> printenv mtdparts + mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none) + +Flash SPI NOR Flash from Network +................................ + +The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-|soc|. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Flash SPI NOR from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI NOR flash needs to be probed: + +.. code-block:: + + u-boot=> sf probe + SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB + +* A specially formatted U-Boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image over tftp, erase and write the + bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + device 0 offset 0x0, size 0x1c0b20 + 1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +Flash SPI NOR from Network in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the image from the host to the target: + + .. code-block:: console + :substitutions: + + host:~$ scp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root + +* Find the number of blocks to erase of the U-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the U-Boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +Flash SPI NOR Flash from SD Card +................................ + +The bootloader on SPI NOR flash can be also flashed with SD Card. + +Flash SPI NOR from SD Card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the first partition + on the SD Card. + +* Before reading and writing are possible, the SPI-NOR flash + needs to be probed: + + .. code-block:: + + u-boot=> sf probe + SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB + +* A specially formatted U-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image from the SD Card, erase and write + the bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +Flash SPI NOR from SD Card in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the first partition + on the SD Card. + +* Mount the SD Card: + + .. code-block:: console + :substitutions: + + target:~$ mount /dev/mmcblk1p1 /mnt + +* Find the number of blocks to erase of the U-Boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp /mnt/imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: |rauc-manual|_. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mn-pd23.1.0-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + :end-before: .. build-uboot-fixed-ram-size-marker + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mn-pd23.1.0-format-sd: + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mn-pd23.1.0-device-tree: + +Device Tree (DT) +================ + +Introduction +------------ + +The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html) + +*"The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn't need to hard code details of the machine."* + +The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at `devicetree.org `_. + +PHYTEC |soc| BSP Device Tree Concept +------------------------------------ + +The following sections explain some rules PHYTEC has defined on how to set up +device trees for our |soc| SoC-based boards. + +Device Tree Structure +..................... + +* *Module.dtsi* - Module includes all devices mounted on the SoM, such as PMIC + and RAM. +* *Board.dts* - include the module dtsi file. Devices that come from the |soc| + SoC but are just routed down to the carrier board and used there are included + in this dts. +* *Overlay.dtso* - enable/disable features depending on optional hardware that + may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10) + +From the root directory of the Linux Kernel our devicetree files for |socfamily| +platforms can be found in ``arch/arm64/boot/dts/freescale/``. + +Device Tree Overlay +................... + +Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder ``arch/arm64/boot/dts/freescale/overlays``. + +Available overlays for |yocto-machinename|.conf are: + +.. Add overlay files in leaf file + +.. code-block:: + + imx8mn-phyboard-polis-peb-eval-01.dtbo + imx8mn-phyboard-polis-peb-av-010.dtbo + imx8mn-phycore-rpmsg.dtbo + imx8mn-phycore-no-eth.dtbo + imx8mn-phycore-no-spiflash.dtbo + imx8mn-vm016.dtbo + imx8mn-vm016-fpdlink.dtbo + imx8mn-vm017.dtbo + imx8mn-vm017-fpdlink.dtbo + imx8mn-dual-vm017-fpdlink.dtbo + +.. _imx8mn-pd23.1.0-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX 0x00 + MX8MN_IOMUXC_SAI2_RXC_UART1_DCE_RX 0x00 + MX8MN_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B 0x00 + MX8MN_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B 0x00 + >; + }; + +The first part of the string MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad +(in this example SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the right) +defines different modes of the pad, for example, if internal pull resistors are +activated or not. In this case, the internal resistors are disabled. + +RS232/RS485 +----------- + +The |soc| SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +|ref-bootswitch| needs to be set correctly: + +.. list-table:: Switch between UART1 RS485/RS232 + + * - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS485.png + + **UART1 RS485** + + - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS232.jpg + + **UART1 RS232** + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n220` + +.. _imx8mn-pd23.1.0-network: + +Network +------- + +|sbc|-|soc| provides one Gigabit Ethernet interface. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First set the correct regulatory domain for your country: + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see: + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +Set up the wireless interface: + +.. code-block:: console + + target:~$ ip link + target:~$ ip link set up dev wlan0 + +Now you can scan for available networks: + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection. + +To do so, add the network-credentials to the file ``/etc/wpa_supplicant.conf``: + +.. code-block:: + + country=DE + network={ + ssid="" + proto=WPA2 + psk="" + } + +Now a connection can be established: + +.. code-block:: console + + target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B + +This should result in the following output: + +.. code-block:: + + ... + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section `Changing the Network Configuration` in the |yocto-ref-manual|. + +First, create the directory: + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +Then add the following configuration snippet in ``/etc/systemd/network/10-wlan0.network``: + +.. code-block:: + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +Now, restart the network daemon so that the configuration takes effect: + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Bluetooth +......... + +Bluetooth is connected to |bluetooth-uart| interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually: + +.. code-block:: console + + target:~$ hciconfig hci0 up + + target:~$ hciconfig -a + + hci0: Type: Primary Bus: UART + BD Address: 00:25:CA:2F:39:96 ACL MTU: 1021:8 SCO MTU: 64:1 + UP RUNNING PSCAN + RX bytes:1392 acl:0 sco:0 events:76 errors:0 + TX bytes:1198 acl:0 sco:0 commands:76 errors:0 + ... + +Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup. + +.. code-block:: console + + target:~$ hcitool scan + Scanning ... + XX:XX:XX:XX:XX:XX + +Visibility +~~~~~~~~~~ + +To activate visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 piscan + +To disable visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 noscan + +Connect +~~~~~~~ + +.. code-block:: console + + target:~$ bluetoothctl + [bluetooth]# discoverable on + Changing discoverable on succeeded + [bluetooth]# pairable on + Changing pairable on succeeded + [bluetooth]# agent on + Agent registered + [bluetooth]# default-agent + Default agent request successful + [bluetooth]# scan on + [NEW] Device XX:XX:XX:XX:XX:XX + [bluetooth]# connect XX:XX:XX:XX:XX:XX + + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n301` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n309` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n78` + +GPIOs +----- + +The |sbc| has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to |soc| pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal |soc| GPIO banks GPIO1 – GPIO5. + +The GPIOs are identified as GPIO_ (e.g. GPIO5_07). identifies the GPIO +bank and counts from 1 to 5, while stands for the GPIO within the bank. +is being counted from 0 to 31 (32 GPIOs on each bank). + +By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is: + +.. code-block:: + + Linux GPIO number: = ( - 1) * 32 + + +Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools: + +* Detecting the gpiochips on the chip: + + .. code-block:: console + + target:~$ gpiodetect + gpiochip0 [30200000.gpio] (32 lines) + gpiochip1 [30210000.gpio] (32 lines) + gpiochip2 [30220000.gpio] (32 lines) + gpiochip3 [30230000.gpio] (32 lines) + gpiochip4 [30240000.gpio] (32 lines) + +* Show detailed information about the gpiochips. Like their names, consumers, + direction, active state, and additional flags: + + .. code-block:: console + + target:~$ gpioinfo gpiochip0 + +* Read the value of a GPIO (e.g GPIO 20 from chip0): + + .. code-block:: console + + target:~$ gpioget gpiochip0 20 + +* Set the value of GPIO 20 on chip0 to 0 and exit tool: + + .. code-block:: console + + target:~$ gpioset --mode=exit gpiochip0 20=0 + +* Help text of gpioset shows possible options: + + .. code-block:: console + + target:~$ gpioset --help + Usage: gpioset [OPTIONS] = = ... + Set GPIO line values of a GPIO chip + + Options: + -h, --help: display this message and exit + -v, --version: display the version and exit + -l, --active-low: set the line active state to low + -m, --mode=[exit|wait|time|signal] (defaults to 'exit'): + tell the program what to do after setting values + -s, --sec=SEC: specify the number of seconds to wait (only valid for --mode=time) + -u, --usec=USEC: specify the number of microseconds to wait (only valid for --mode=time) + -b, --background: after setting values: detach from the controlling terminal + + Modes: + exit: set values and exit immediately + wait: set values and wait for user to press ENTER + time: set values and sleep for a specified amount of time + signal: set values and wait for SIGINT or SIGTERM + + Note: the state of a GPIO line controlled over the character device reverts to default + when the last process referencing the file descriptor representing the device file exits. + This means that it's wrong to run gpioset, have it exit and expect the line to continue + being driven high or low. It may happen if given pin is floating but it must be interpreted + as undefined behavior. + + +.. warning:: + + Some of the user IOs are used for special functions. Before using a user IO, + refer to the schematic or the hardware manual of your board to ensure that it + is not already in use. + +.. include:: ../peripherals/gpios.rsti + :start-after: .. gpios-via-sysfs-marker + +Pinmuxing of some GPIO pins in the device tree |dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_leds: leds1grp { + fsl,pins = < + MX8MN_IOMUXC_GPIO1_IO01_GPIO1_IO1 0x16 + MX8MN_IOMUXC_GPIO1_IO14_GPIO1_IO14 0x16 + MX8MN_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x16 + >; + }; + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n45` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n106` + +General I²C3 bus configuration (e.g. |dt-carrierboard|.dts): +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n196` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues. + +.. include:: ../peripherals/eeprom.rsti + +Rescue EEPROM Data +.................. + +The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area. + +.. code-block:: console + + target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 + +.. note:: + + If you deleted both EEPROM spaces, please contact our support! + +DT representation, e.g. in phyCORE-|soc| file |dt-som|.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n259` + +.. include:: /bsp/peripherals/rtc.rsti + :end-before: .. rtc_parameter_start_label + +RTC Parameters +.............. + +RTCs have a few abilities which can be read/set with the help of ``hwclock`` +tool. + +* We can check RTC supported features with: + + .. code-block:: console + + target:~$ hwclock --param-get features + The RTC parameter 0x0 is set to 0x11. + + What this value means is encoded in kernel, each set bit translates to: + + .. code-block:: + + #define RTC_FEATURE_ALARM 0 + #define RTC_FEATURE_ALARM_RES_MINUTE 1 + #define RTC_FEATURE_NEED_WEEK_DAY 2 + #define RTC_FEATURE_ALARM_RES_2S 3 + #define RTC_FEATURE_UPDATE_INTERRUPT 4 + #define RTC_FEATURE_CORRECTION 5 + #define RTC_FEATURE_BACKUP_SWITCH_MODE 6 + #define RTC_FEATURE_CNT 7 + +* We can check RTC BSM (Backup Switchover Mode) with: + + .. code-block:: console + + target:~$ hwclock --param-get bsm + The RTC parameter 0x2 is set to 0x1. + +* We can set RTC BSM with: + + .. code-block:: console + + target:~$ hwclock --param-set bsm=0x2 + The RTC parameter 0x2 will be set to 0x2. + + What BSM values mean translates to these values: + + .. code-block:: + + #define RTC_BSM_DISABLED 0 + #define RTC_BSM_DIRECT 1 + #define RTC_BSM_LEVEL 2 + #define RTC_BSM_STANDBY 3 + + .. tip:: + You should set BSM mode to DSM or LSM for RTC to switch to backup power + source when the initial power source is not available. Check **RV-3028** RTC + datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching + Mode) actually mean. + +DT representation for I²C RTCs: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n267` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +'HS'). + +The |soc| SoC has a single USB controller core that is set to OTG mode. +To use the micro USB / OTG port dip switch S1 Pos5 has to be set to on. + +.. include:: /bsp/peripherals/usb-host.rsti + +.. include:: /bsp/peripherals/usb-otg.rsti + +The USB interface is configured as host in the kernel device tree +|dt-carrierboard|.dts. See: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n264` + +CAN FD +------ + +The |sbc| has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. Hint:: + + phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. + There are different interfaces involved, which limits the datarate + capabilities of CANFD. + +.. Hint:: + + On phyBOARD-Polis-i.MX8MN a terminating resistor can be enabled by setting + S5 to ON if required. + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n125` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti diff --git a/previews/271/_sources/bsp/imx8/imx8mp-libra-fpsc/head.rst.txt b/previews/271/_sources/bsp/imx8/imx8mp-libra-fpsc/head.rst.txt new file mode 100644 index 000000000..f02ef3f6a --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mp-libra-fpsc/head.rst.txt @@ -0,0 +1,588 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MP-PD24.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/ +.. |link-bsp-images| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp +.. _`static-pdf-dl`: ../../../_static/imx8mp-libra-fpsc-head.pdf + +.. IMX8(MP) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mp/phycore-imx8mp.c?h=v2024.04-2.0.0-phy7#n177 + + +.. General Substitutions +.. |doc-id| replace:: L-XXXXX.Xx +.. |kit| replace:: **Libra i.MX 8M Plus FPSC Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: Libra +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP-FPSC +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |bluetooth-uart| replace:: UART3 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx8_phytec_defconfig +.. |kernel-recipe-path| replace:: meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb +.. |kernel-repo-name| replace:: linux-phytec-imx +.. |kernel-repo-url| replace:: https://github.com/phytec/linux-phytec-imx +.. |kernel-socname| replace:: imx8mp-fpsc +.. |kernel-tag| replace:: v6.6.23-2.0.0-phy10 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-defconfig| replace:: imx8mp-libra_defconfig +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx +.. |emmcdev-uboot| replace:: mmc 2 +.. |sdcarddev-uboot| replace:: mmc 1 + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: IMX8MP_LIBRA +.. |u-boot-tag| replace:: v2024.04_2.0.0-phy7 + + +.. RAUC +.. |rauc-manual| replace:: L-1006e.A6 RAUC Update & Device Management Manual +.. _rauc-manual: https://www.phytec.de/cdocuments/?doc=F4DiM + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-libra-rdk-fpsc +.. |dt-som| replace:: imx8mp-phycore-fpsc +.. |dtbo-rpmsg| replace:: conf-imx8mp-phycore-fpsc-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mp-libra-peb-av-10.dtbo + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: :linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L50` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`scarthgap` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP-FPSC +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: scarthgap +.. |yocto-distro| replace:: ampliphy-vendor-xwayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: rootfs.wic.xz +.. |yocto-machinename| replace:: libra-imx8mp-1 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MP-PD24.1.0 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MP-FPSC-PD25.1.y +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (scarthgap) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 5.0.x +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L179`. +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` +.. |lvds-display-adapters| replace:: PEB-AV-10 +.. |weston-hdmi-mode| replace:: preferred + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |doc-id| |soc| FPSC | | +| BSP ManualHead | | ++-----------------------+----------------------+ +| Document Title | |doc-id| |soc| FPSC | +| | BSP Manual Head | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Article Number | |doc-id| | ++-----------------------+----------------------+ +| Yocto Manual | | ++-----------------------+----------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+----------------------+ +| Is Branch of | |doc-id| |soc| FPSC | +| | BSP Manual Head | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +================ ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +================ ================ ================= ========== +.. +================ ================ ================= ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mp-libra-fpsc-head-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-libra-fpsc-head-getting-started: +.. include:: /bsp/getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-libra-fpsc-head-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **fitImage**: Linux kernel FIT image +* **fitImage-its\*.its** +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-libra-rdk-fpsc*.dtb**: Kernel device tree file +* **imx8mp-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.rootfs.wic.xz**: compressed SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-libra-fpsc-head-bootswitch: +.. include:: bootmode-switch.rsti + +.. include:: ../installing-os.rsti + +.. include:: ../efi.rsti +.. include:: /bsp/installing-distro-efi.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-libra-fpsc-head-development: + +Development +=========== + +Starting with this release, the boot behaviour in U-Boot changes. Before, kernel +and device tree came as separate blobs. Now, both will be included in a single +FIT image blob. Further, the logic for booting the PHYTEC ampliphy distributions +is moved to a boot script which itself is part of a separate FIT image blob. +To revert to the old style of booting, you may do + +.. code-block:: console + + run legacyboot + +.. note:: + + This way of booting is deprecated and will be removed in the next release. + By default, booting via this command will return an error as kernel and + device tree are missing in the boot partition. + +.. include:: ../../imx-common/development/standalone_build_preface.rsti +.. _imx8mp-libra-fpsc-head-development-build-uboot: +.. include:: ../../imx-common/development/standalone_build_u-boot_binman.rsti +.. include:: ../development/kernel-standalone.rsti +.. include:: ../../imx-common/development/uuu.rsti + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx8/development/netboot.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mp-libra-fpsc-head-format-sd: + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. include:: /bsp/imx8/development/legacy_boot_deprecated.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-libra-fpsc-head-device-tree: +.. include:: /bsp/device-tree.rsti + +.. code-block:: + :substitutions: + + imx8mp-isi-csi1.dtbo + imx8mp-isi-csi2.dtbo + imx8mp-isp-csi1.dtbo + imx8mp-isp-csi2.dtbo + |dtbo-peb-av-10| + imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + imx8mp-phycore-no-eth.dtbo + imx8mp-phycore-no-rtc.dtbo + imx8mp-phycore-no-spiflash.dtbo + imx8mp-phycore-rpmsg.dtbo + imx8mp-vm016-csi1.dtbo + imx8mp-vm016-csi1-fpdlink.dtbo + imx8mp-vm016-csi2.dtbo + imx8mp-vm016-csi2-fpdlink.dtbo + imx8mp-vm017-csi1.dtbo + imx8mp-vm017-csi1-fpdlink.dtbo + imx8mp-vm017-csi2.dtbo + imx8mp-vm017-csi2-fpdlink.dtbo + +.. _imx8mp-libra-fpsc-head-ubootexternalenv: +.. include:: ../../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x140 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x140 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +The device tree representation for UART1 pinmuxing: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L373` + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti +.. include:: /bsp/peripherals/rs485-fullduplex.rsti + +The device tree representation for RS232 and RS485: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L412` + +.. _imx8mp-libra-fpsc-head-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + +.. include:: wireless-network.rsti + +.. include:: ../../peripherals/wireless-network.rsti + :end-before: .. bluetooth_chapter_start_label + +Bluetooth is supported on |sbc| with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section. + +.. include:: ../../peripherals/wireless-network.rsti + :start-after: .. bluetooth_chapter_start_label + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L422` + +DT configuration for the eMMC interface can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L214` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L76` + +.. include:: ../peripherals/gpios.rsti + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L255` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L113` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L239` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues. + +.. note:: + + If you deleted reserved EEPROM spaces, please contact our support! + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L201` + +.. include:: ../../peripherals/rtc.rsti + +DT representation for I²C RTCs: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L208` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L380` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L203` + +.. include:: /bsp/peripherals/pcie.rsti + +Device Tree PCIe configuration of |dt-carrierboard|.dts: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L345` + +Audio +----- + +Playback devices supported for |sbc| are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals. + +.. note:: + + Using the PEB-AV-10 connector for display output along HDMI as audio output + is not supported. The audio output device must match the video output device. + +.. include:: /bsp/peripherals/audio.rsti + +Device Tree Audio configuration: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L58` + +.. include:: /bsp/peripherals/video.rsti + +.. include:: display.rsti + :end-before: .. supported-display-interfaces-marker-start + +The |sbc| supports up to 3 different display outputs. Two can be used +simultaneously. The following table shows the required extensions and devicetree +overlays for the different interfaces. + +========= ======================== ====================================== +Interface Expansion devicetree overlay +========= ======================== ====================================== +HDMI |sbc| no overlay needed (enabled by default) +LVDS0 PEB-AV-10 |dtbo-peb-av-10| + (loaded by default) +LVDS1 |sbc| disabled if PEB-AV-10 overlay is used +========= ======================== ====================================== + +.. include:: display.rsti + :start-after: .. supported-display-interfaces-marker-end + :end-before: .. no-peb-av-12-marker + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +Device tree description of LVDS-1 and HDMI can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L294` +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L218` + +The device tree of LVDS-0 on PEB-AV-10 can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L133` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +The device tree description of GPIO Fan can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L35` + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/snvs-power-key.rsti + +.. include:: ../peripherals/npu.rsti + +.. include:: ../peripherals/isp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti diff --git a/previews/271/_sources/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.rst.txt b/previews/271/_sources/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.rst.txt new file mode 100644 index 000000000..75e3e2260 --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.rst.txt @@ -0,0 +1,13 @@ +=============================== +Libra i.MX 8M Plus FPSC Manuals +=============================== + +HEAD +==== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + head diff --git a/previews/271/_sources/bsp/imx8/imx8mp/head.rst.txt b/previews/271/_sources/bsp/imx8/imx8mp/head.rst.txt new file mode 100644 index 000000000..1f9f59507 --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mp/head.rst.txt @@ -0,0 +1,589 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MP-PD24.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/ +.. |link-bsp-images| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp +.. _`static-pdf-dl`: ../../../_static/imx8mp-head.pdf + +.. IMX8(MP) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mp/phycore-imx8mp.c?h=v2024.04-2.0.0-phy7#n177 + + +.. General Substitutions +.. |doc-id| replace:: L-1017e.Ax +.. |kit| replace:: **phyCORE-i.MX8M Plus Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Pollux +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |bluetooth-uart| replace:: UART3 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx8_phytec_defconfig +.. |kernel-recipe-path| replace:: meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb +.. |kernel-repo-name| replace:: linux-phytec-imx +.. |kernel-repo-url| replace:: https://github.com/phytec/linux-phytec-imx +.. |kernel-socname| replace:: imx8mp +.. |kernel-tag| replace:: v6.6.23-2.0.0-phy10 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-defconfig| replace:: phycore-imx8mp_defconfig +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx +.. |emmcdev-uboot| replace:: mmc 2 +.. |sdcarddev-uboot| replace:: mmc 1 + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MP +.. |u-boot-tag| replace:: v2024.04_2.0.0-phy7 + + +.. RAUC +.. |rauc-manual| replace:: L-1006e.A6 RAUC Update & Device Management Manual +.. _rauc-manual: https://www.phytec.de/cdocuments/?doc=F4DiM + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-phyboard-pollux-rdk +.. |dt-som| replace:: imx8mp-phycore-som +.. |dtbo-rpmsg| replace:: conf-imx8mp-phycore-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mp-phyboard-pollux-peb-av-10.dtbo + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: :linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L50` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`scarthgap` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: scarthgap +.. |yocto-distro| replace:: ampliphy-vendor-xwayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: rootfs.wic.xz +.. |yocto-machinename| replace:: phyboard-pollux-imx8mp-3 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MP-PD24.1.0 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MP-PD24.1.y +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (scarthgap) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 5.0.x +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L179`. +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` +.. |lvds-display-adapters| replace:: PEB-AV-10 +.. |weston-hdmi-mode| replace:: preferred + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |doc-id| |soc| BSP | | +| ManualHead | | ++-----------------------+----------------------+ +| Document Title | |doc-id| |soc| BSP | +| | Manual Head | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Article Number | |doc-id| | ++-----------------------+----------------------+ +| Yocto Manual | | ++-----------------------+----------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+----------------------+ +| Is Branch of | |doc-id| |soc| BSP | +| | Manual Head | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +================ ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +================ ================ ================= ========== +.. +================ ================ ================= ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mp-head-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-head-getting-started: +.. include:: /bsp/getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-head-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **fitImage**: Linux kernel FIT image +* **fitImage-its\*.its** +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-phyboard-pollux-rdk*.dtb**: Kernel device tree file +* **imx8mp-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.rootfs.wic.xz**: compressed SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-head-bootswitch: +.. include:: bootmode-switch.rsti + +.. include:: ../installing-os.rsti + +.. include:: ../efi.rsti +.. include:: /bsp/installing-distro-efi.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-head-development: + +Development +=========== + +Starting with this release, the boot behaviour in U-Boot changes. Before, kernel +and device tree came as separate blobs. Now, both will be included in a single +FIT image blob. Further, the logic for booting the PHYTEC ampliphy distributions +is moved to a boot script which itself is part of a separate FIT image blob. +To revert to the old style of booting, you may do + +.. code-block:: console + + run legacyboot + +.. note:: + + This way of booting is deprecated and will be removed in the next release. + By default, booting via this command will return an error as kernel and + device tree are missing in the boot partition. + +.. include:: ../../imx-common/development/standalone_build_preface.rsti +.. _imx8mp-head-development-build-uboot: +.. include:: ../../imx-common/development/standalone_build_u-boot_binman.rsti +.. include:: development/uboot-standalone-fixed-ram-config.rsti +.. include:: ../development/kernel-standalone.rsti +.. include:: ../../imx-common/development/uuu.rsti + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx8/development/netboot.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mp-head-format-sd: + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. include:: /bsp/imx8/development/legacy_boot_deprecated.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-head-device-tree: +.. include:: /bsp/device-tree.rsti + +.. code-block:: + :substitutions: + + imx8mp-isi-csi1.dtbo + imx8mp-isi-csi2.dtbo + imx8mp-isp-csi1.dtbo + imx8mp-isp-csi2.dtbo + |dtbo-peb-av-10| + imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + imx8mp-phycore-no-eth.dtbo + imx8mp-phycore-no-rtc.dtbo + imx8mp-phycore-no-spiflash.dtbo + imx8mp-phycore-rpmsg.dtbo + imx8mp-vm016-csi1.dtbo + imx8mp-vm016-csi1-fpdlink.dtbo + imx8mp-vm016-csi2.dtbo + imx8mp-vm016-csi2-fpdlink.dtbo + imx8mp-vm017-csi1.dtbo + imx8mp-vm017-csi1-fpdlink.dtbo + imx8mp-vm017-csi2.dtbo + imx8mp-vm017-csi2-fpdlink.dtbo + +.. _imx8mp-head-ubootexternalenv: +.. include:: ../../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x140 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x140 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +The device tree representation for UART1 pinmuxing: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L373` + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti +.. include:: /bsp/peripherals/rs485-fullduplex.rsti + +The device tree representation for RS232 and RS485: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L412` + +.. _imx8mp-head-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + +.. include:: wireless-network.rsti + +.. include:: ../../peripherals/wireless-network.rsti + :end-before: .. bluetooth_chapter_start_label + +Bluetooth is supported on |sbc| with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section. + +.. include:: ../../peripherals/wireless-network.rsti + :start-after: .. bluetooth_chapter_start_label + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L422` + +DT configuration for the eMMC interface can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L214` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L76` + +.. include:: ../peripherals/gpios.rsti + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L255` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L113` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L239` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues. + +.. note:: + + If you deleted reserved EEPROM spaces, please contact our support! + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L201` + +.. include:: ../../peripherals/rtc.rsti + +DT representation for I²C RTCs: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L208` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L380` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L203` + +.. include:: /bsp/peripherals/pcie.rsti + +Device Tree PCIe configuration of |dt-carrierboard|.dts: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L345` + +Audio +----- + +Playback devices supported for |sbc| are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals. + +.. note:: + + Using the PEB-AV-10 connector for display output along HDMI as audio output + is not supported. The audio output device must match the video output device. + +.. include:: /bsp/peripherals/audio.rsti + +Device Tree Audio configuration: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L58` + +.. include:: /bsp/peripherals/video.rsti + +.. include:: display.rsti + :end-before: .. supported-display-interfaces-marker-start + +The |sbc| supports up to 3 different display outputs. Two can be used +simultaneously. The following table shows the required extensions and devicetree +overlays for the different interfaces. + +========= ======================== ====================================== +Interface Expansion devicetree overlay +========= ======================== ====================================== +HDMI |sbc| no overlay needed (enabled by default) +LVDS0 PEB-AV-10 |dtbo-peb-av-10| + (loaded by default) +LVDS1 |sbc| disabled if PEB-AV-10 overlay is used +========= ======================== ====================================== + +.. include:: display.rsti + :start-after: .. supported-display-interfaces-marker-end + :end-before: .. no-peb-av-12-marker + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +Device tree description of LVDS-1 and HDMI can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L294` +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L218` + +The device tree of LVDS-0 on PEB-AV-10 can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L133` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +The device tree description of GPIO Fan can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L35` + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/snvs-power-key.rsti + +.. include:: ../peripherals/npu.rsti + +.. include:: ../peripherals/isp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti diff --git a/previews/271/_sources/bsp/imx8/imx8mp/imx8mp.rst.txt b/previews/271/_sources/bsp/imx8/imx8mp/imx8mp.rst.txt new file mode 100644 index 000000000..8c852c8b2 --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mp/imx8mp.rst.txt @@ -0,0 +1,84 @@ +==================== +i.MX 8M Plus Manuals +==================== + +HEAD +==== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + head + +Mainline HEAD +============= + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + mainline-head + +BSP-Yocto-NXP-i.MX8MP-PD24.1.0 +============================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd24.1.0_nxp + +BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 +=================================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd24.1.2 + +BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 +=================================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd24.1.1 + + +BSP-Yocto-NXP-i.MX8MP-PD23.1.0 +============================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd23.1.0 + +BSP-Yocto-NXP-i.MX8MP-PD22.1.2 +============================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd22.1.2 + +BSP-Yocto-NXP-i.MX8MP-PD22.1.1 +============================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd22.1.1 diff --git a/previews/271/_sources/bsp/imx8/imx8mp/mainline-head.rst.txt b/previews/271/_sources/bsp/imx8/imx8mp/mainline-head.rst.txt new file mode 100644 index 000000000..9cfb4bde8 --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mp/mainline-head.rst.txt @@ -0,0 +1,1343 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp +.. _`static-pdf-dl`: ../../../_static/imx8mp-mainline-head.pdf + + +.. General Substitutions +.. |doc-id| replace:: L-XXXXX.Xx +.. |kit| replace:: **phyCORE-i.MX8M Plus Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Pollux +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: defconfig +.. |kernel-recipe-path| replace:: recipes-kernel/linux/linux-phytec_*.bb +.. |kernel-repo-name| replace:: linux-phytec +.. |kernel-repo-url| replace:: https://github.com/phytec/linux-phytec.git +.. |kernel-socname| replace:: imx8mp +.. |kernel-tag| replace:: v6.6.21-phy1 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-defconfig| replace:: phycore-imx8mp_defconfig +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-phytec_*.bb +.. |u-boot-repo-name| replace:: u-boot-phytec +.. |u-boot-repo-url| replace:: https://github.com/phytec/u-boot-phytec.git + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MP +.. |u-boot-tag| replace:: v2024.01-phy4 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-phyboard-pollux-rdk +.. |dt-som| replace:: imx8mp-phycore-som + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L41 + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`scarthgap` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: scarthgap +.. |yocto-distro| replace:: ampliphy-xwayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: rootfs.wic.xz +.. |yocto-machinename| replace:: phyboard-pollux-imx8mp-3 +.. |yocto-manifestname| replace:: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (scarthgap) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-a-core| replace:: cortexa53-crypto +.. |yocto-sdk-rev| replace:: 5.0.1 + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L106 +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |doc-id| |soc| BSP | | +| ManualHead | | ++-----------------------+----------------------+ +| Document Title | |doc-id| |soc| BSP | +| | Mainline Manual Head | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Article Number | |doc-id| | ++-----------------------+----------------------+ +| Yocto Manual | | ++-----------------------+----------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+----------------------+ +| Is Branch of | |doc-id| |soc| BSP | +| | Mainline Manual Head | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +================ ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +================ ================ ================= ========== +.. +================ ================ ================= ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mp-mainline-head-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-mainline-head-getting-started: + +.. include:: ../../getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-mainline-head-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_1d_dmem_202006.bin, + lpddr4_pmu_train_1d_imem_202006.bin, + lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-phyboard-pollux-rdk*.dtb**: Kernel device tree file +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.wic.xz**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see |ref-setup-network-host|. + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-mainline-head-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **eMMC**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +.. tip:: + + This step only works if the size of the image file is less than 1,28GB due to + limited RAM space available in the Bootloader. + +* Uncompress your image: + +.. code-block:: console + :substitutions: + + host:~$ unxz /srv/tftp/phytec-headless-image-|yocto-machinename|.rootfs.wic.xz + +* Load your image via network to RAM: + + .. code-block:: + :substitutions: + + u-boot=> dhcp ${loadaddr} phytec-headless-image-|yocto-machinename|.rootfs.wic + BOOTP broadcast 1 + DHCP client bound to address 192.168.3.11 (101 ms) + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename 'phytec-headless-image-|yocto-machinename|.rootfs.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* Write the image to the eMMC: + + .. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Take a compressed or decompressed image with the accompanying block map file +`*.bmap` on the host and send it with `ssh` through the network to the eMMC of +the target with a one-line command: + +.. code-block:: console + :substitutions: + + target:~$ scp @192.168.3.10:/srv/tftp/|yocto-imagename|-|yocto-machinename|.rootfs.wic.* /tmp && bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls /srv/tftp + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + |yocto-imagename|-|yocto-machinename|.rootfs.wic.bmap + +Send the image with the ``bmaptool`` command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ scp /srv/tftp/|yocto-imagename|-|yocto-machinename|.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2" + +Flash eMMC U-Boot image via Network from running U-Boot +....................................................... + +Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> dhcp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB stick +......................... + +Flash eMMC from USB stick in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. note:: + + Only the lower USB-A port is configured for storage devices and only + this port will work when trying to access a storage device in U-Boot. + +.. tip:: + + This step only works if the size of the image file is less than 1,28GB due to + limited RAM space available in the Bootloader. + +These steps will show how to update the eMMC via a USB device. Configure the +|ref-bootswitch| to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied uncompressed WIC image to +the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + :substitutions: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} phytec-headless-image-|yocto-machinename|.rootfs.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.\ |yocto-imageext|). Set the |ref-bootswitch| to SD Card. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ ls /mnt + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + |yocto-imagename|-|yocto-machinename|.rootfs.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy /mnt/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + + .. tip:: + + Before this will work, you need to configure the |ref-bootswitch| to + **eMMC**. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see |ref-format-sd|. + +Alternatively, flash a partup package to the SD card, as described in +|ref-getting-started|. This will ensure the full space of the SD card is used. + +Flash eMMC from SD card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1,28GB due to + limited RAM space available in the Bootloader. + + +* Flash an SD card with a working image and create a third ext4 partition. Copy + the WIC image (for example |yocto-imagename|.rootfs.wic) to this partition. +* Configure the |ref-bootswitch| to SD Card and insert the SD Card. +* Power on the board and stop in U-Boot. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-|yocto-machinename|.rootfs.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev to eMMC: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + +* Flash your WIC image (for example |yocto-imagename|.roots.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. + + .. code-block:: + + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the |ref-bootswitch| to eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card. + +* Show your saved partup package or WIC image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.rootfs.partup + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + |yocto-imagename|-|yocto-machinename|.rootfs.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition) using `partup`_: + + .. code-block:: console + :substitutions: + + target:~$ partup install |yocto-imagename|-|yocto-machinename|.rootfs.partup /dev/mmcblk2 + + Flashing the partup package has the advantage of using the full capacity of + the eMMC device, adjusting partitions accordingly. + + .. note:: + + Alternatively, ``bmaptool`` may be used instead: + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + + Keep in mind that the root partition does not make use of the full space when + flashing with ``bmaptool``. + +* After a complete write, your board can boot from eMMC. + + .. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to eMMC. + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A6 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-mainline-head-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti + +Booting the Kernel from a Network +--------------------------------- + +Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device. + +Place Images on Host for Netboot +................................ + +* Copy the kernel image to your tftp directory: + + .. code-block:: console + + host:~$ cp Image /srv/tftp + +* Copy the devicetree to your tftp directory: + + .. code-block:: console + + host:~$ cp oftree /srv/tftp + +* Make sure other users have read access to all the files in the tftp directory, + otherwise they are not accessible from the target: + + .. code-block:: console + + host:~$ sudo chmod -R o+r /srv/tftp + +* Extract the rootfs to your nfs directory: + + .. code-block:: console + :substitutions: + + host:~$ sudo tar -xvzf |yocto-imagename|-|yocto-machinename|.rootfs.tar.gz -C /srv/nfs + +.. note:: + Make sure you extract with sudo to preserve the correct ownership. + +Booting from an Embedded Board +.............................. + +Boot the board into the U-boot prompt and press any key to hold. + +* To boot from a network, call: + + .. code-block:: console + + u-boot=> run netboot + + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy-|yocto-distro|/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.rootfs.wic + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.rootfs.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + +.. _imx8mp-mainline-head-development-build-uboot: +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + +.. include:: development/uboot-standalone-fixed-ram-config.rsti + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mp-mainline-head-format-sd: + +Format SD-Card +-------------- + +Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted. + +Gparted +....... + +* Get GParted: + + .. code-block:: console + + host:~$ sudo apt install gparted + +* Insert the SD Card into your host and get the device name: + + .. code-block:: console + + host:~$ dmesg | tail + ... + [30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB) + [30436.179846] sdb: sdb1 sdb2 + ... + +* Unmount all SD Card partitions. +* Launch GParted: + + .. code-block:: console + + host:~$ sudo gparted + +.. image:: /bsp/imx-common/images/gparted1.png + +Expand rootfs +~~~~~~~~~~~~~ + +.. warning:: + Running gparted on host systems which are using resize2fs version 1.46.6 and older + (e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto + Mickledore and newer. + This is due to a new default option in resize2fs which causes a incompatibility. + See `release notes `_. + +* Choose your SD Card device at the drop-down menu on the top right +* Choose the ext4 root partition and click on resize: + +.. image:: /bsp/imx-common/images/gparted5.png +.. image:: /bsp/imx-common/images/gparted2.png + +* Drag the slider as far as you like or enter the size manually. + +.. image:: /bsp/imx-common/images/gparted3.png + +* Confirm your entry by clicking on the "Change size" button. + +.. image:: /bsp/imx-common/images/gparted4.png + +* To apply your changes, press the green tick. +* Now you can mount the root partition and copy e.g. the + |yocto-imagename|-|yocto-machinename|.\ |yocto-imageext| image to it. Then unmount it again: + + .. code-block:: console + :substitutions: + + host:~$ sudo cp |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /mnt/ ; sync + host:~$ umount /mnt + +Create the Third Partition +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Choose your SD Card device at the drop-down menu on the top right + +.. image:: /bsp/imx-common/images/gparted1.png + +* Choose the bigger unallocated area and press "New": + +.. image:: /bsp/imx-common/images/gparted6.png + +* Click "Add" + +.. image:: /bsp/imx-common/images/gparted7.png + +* Confirm your changes by pressing the green tick. + +.. image:: /bsp/imx-common/images/gparted8.png + +* Now you can mount the new partition and copy e.g. + |yocto-imagename|-|yocto-machinename|.\ |yocto-imageext| image to it. Then unmount it again: + + .. code-block:: console + :substitutions: + + host:~$ sudo mount /dev/sde3 /mnt + host:~$ sudo cp |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /mnt/ ; sync + host:~$ umount /mnt + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-mainline-head-device-tree: +.. include:: /bsp/device-tree.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x140 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x140 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +The device tree representation for UART1 pinmuxing: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L387` + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti +.. include:: /bsp/peripherals/rs485-fullduplex.rsti + +The device tree representation for RS232 and RS485: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L251` + +.. _imx8mp-mainline-head-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + :end-before: .. u-boot-network-environment-marker + +U-boot network-environment +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* We currently use dynamic IP addresses in U-Boot. This is enabled by this variable: + + .. code-block:: + + u-boot=> printenv ip_dyn + ip_dyn=yes + +* Set up path for NFS. A modification could look like this: + + .. code-block:: + + u-boot=> setenv nfsroot /home/user/nfssrc + +Please note that these modifications will only affect the bootloader settings. + +.. include:: /bsp/imx-common/peripherals/network.rsti + :start-after: .. kernel-network-environment-marker + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:linux-phytec:`/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L261` + +DT configuration for the eMMC interface can be found here: +:linux-phytec:`/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L181` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + :end-before: .. peripherals-spi-nor-flash-marker + +The definition of the SPI master node in the device tree can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L67` + +.. include:: ../peripherals/gpios.rsti + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L160` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L81` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L145` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues. + +.. note:: + + If you deleted reserved EEPROM spaces, please contact our support! + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L169` + +RTC +--- + +RTCs can be accessed via ``/dev/rtc*``. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file. + +* To find the name of the RTC device, you can read its sysfs entry with: + + .. code-block:: console + + target:~$ cat /sys/class/rtc/rtc*/name + +* You will get, for example: + + .. code-block:: + + rtc-rv3028 0-0052 + snvs_rtc 30370000.snvs:snvs-rtc-lp + +.. tip:: + + This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device + IDs based on the device tree/aliases entries if present. + +Date and time can be manipulated with the ``hwclock`` tool and the date command. +To show the current date and time set on the target: + +.. code-block:: console + + target:~$ date + Thu Jan 1 00:01:26 UTC 1970 + +Change the date and time with the date command. The date command sets the time +with the following syntax "YYYY-MM-DD hh:mm:ss (+|-)hh:mm": + +.. code-block:: console + + target:~$ date -s "2022-03-02 11:15:00 +0100" + Wed Mar 2 10:15:00 UTC 2022 + +.. note:: + + Your timezone (in this example +0100) may vary. + +Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the ``hwclock`` command. Write the current date and time (set +with the date command) to the RTC using the ``hwclock`` tool and reboot the +target to check if the changes were applied to the RTC: + +.. code-block:: console + + target:~$ hwclock -w + target:~$ reboot + . + . + . + target:~$ date + Wed Mar 2 10:34:06 UTC 2022 + +To set the time and date from the RTC use: + +.. code-block:: console + + target:~$ date + Thu Jan 1 01:00:02 UTC 1970 + target:~$ hwclock -s + target:~$ date + Wed Mar 2 10:45:01 UTC 2022 + +.. include:: ../../peripherals/rtc.rsti + :start-after: .. rtc_parameter_start_label + +DT representation for I²C RTCs: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L175` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L220` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L130` + +Video +----- + +Videos with Gstreamer +..................... + +One example video is installed by default in the BSP at `/usr/share/qtphy/videos/`. +Start the video playback with one of these commands: + +.. code-block:: console + + target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink fullscreen=true + +* Or: + +.. code-block:: console + + target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink + +.. note:: + The mainline BSP currently only supports software rendering. + +Display +------- + +The |sbc| supports LVDS output via the LVDS1 connector on the carrier board. The +LVDS interface is enabled by default. + +Weston Configuration +.................... + +Weston will work without any additional configuration. Configuration options are +done at /etc/xdg/weston/weston.ini. + +Device tree description of LVDS can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L182` + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +.. note:: + We noticed some visible backlight flickering on brightness level 1 (probably + due to frequency problems with the hardware). + +Power Management +---------------- + +CPU Core Frequency Scaling +.......................... + +The CPU in the |soc| SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as 'Dynamic Voltage and +Frequency Scaling' (DVFS). The |soc| BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the |socfamily| +variant used, several different frequencies are supported. + +.. tip:: + + Although the DVFS framework provides frequency settings for each CPU core, a + change in the frequency settings of one CPU core always affects all other CPU + cores too. So all CPU cores always share the same DVFS setting. An individual + DVFS setting for each core is not possible. + + +* To get a complete list type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies + + In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately + 1,6 GHz, the result will be: + + .. code-block:: + + 1200000 1600000 + +* To ask for the current frequency type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq + +So-called governors are automatically selecting one of these frequencies in +accordance with their goals. + +* List all governors available with the following command: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors + + The result will be: + + .. code-block:: + + ondemand userspace performance schedutil + +* **ondemand** (default) switches between possible CPU core frequencies in + reference to the current system load. When the system load increases above a + specific limit, it increases the CPU core frequency immediately. +* **performance** always selects the highest possible CPU core frequency. +* **userspace** allows the user or userspace program running as root to set a + specific frequency (e.g. to 1600000). Type: + +* In order to ask for the current governor, type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor + + You will normally get: + + .. code-block:: + + schedutil + +* Switching over to another governor (e.g. userspace) is done with: + + .. code-block:: console + + target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor + +* Now you can set the speed: + + .. code-block:: console + + target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed + +For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +``Documentation/admin-guide/pm/cpufreq.rst``. + +CPU Core Management +................... + +The |soc| SoC can have multiple processor cores on the die. The |soc|, for +example, has 4 ARM Cores which can be turned on and off individually at runtime. + +* To see all available cores in the system, execute: + + .. code-block:: console + + target:~$ ls /sys/devices/system/cpu -1 + +* This will show, for example: + + .. code-block:: + + cpu0 cpu1 cpu2 cpu3 cpufreq + [...] + + Here the system has four processor cores. By default, all available cores in the + system are enabled to get maximum performance. + +* To switch off a single-core, execute: + + .. code-block:: console + + target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online + + As confirmation, you will see: + + .. code-block:: + + [ 110.505012] psci: CPU3 killed + + Now the core is powered down and no more processes are scheduled on this core. + +* You can use top to see a graphical overview of the cores and processes: + + .. code-block:: console + + target:~$ htop + +* To power up the core again, execute: + + .. code-block:: console + + target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online + +.. include:: ../peripherals/tm.rsti + :end-before: .. tm-gpio-fan-marker + +.. include:: /bsp/peripherals/watchdog.rsti + +snvs Power Key +-------------- + +The X_ONOFF pin connected to the ON/OFF button can be pressed long to trigger +Power OFF without SW intervention. With the *snvs_pwrkey* driver, the KEY_POWER +event is also reported to userspace when the button is pressed. On default, systemd +is configured to ignore such events. The function of Power OFF without SW +intervention are not configured. Triggering a power off with systemd when pushing +the ON/OFF button can be configured under ``/etc/systemd/logind.conf`` and set using: + +.. code-block:: + + HandlePowerKey=poweroff + +.. include:: ../peripherals/ocotp-ctrl.rsti diff --git a/previews/271/_sources/bsp/imx8/imx8mp/pd22.1.1.rst.txt b/previews/271/_sources/bsp/imx8/imx8mp/pd22.1.1.rst.txt new file mode 100644 index 000000000..4549e03f8 --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mp/pd22.1.1.rst.txt @@ -0,0 +1,2577 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MP-PD22.1.1 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp +.. _`static-pdf-dl`: ../../../_static/imx8mp-pd22.1.1.pdf + +.. IMX8(MP) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mp/phycore-imx8mp.c?h=v2021.04_2.2.0-phy13#n239 + + +.. General Substitutions +.. |atfloadaddr| replace:: 0x970000 +.. |kit| replace:: **phyCORE-i.MX8M Plus Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Pollux +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |bluetooth-uart| replace:: UART3 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx8mp +.. |kernel-tag| replace:: v5.10.72_2.2.0-phy17 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-defconfig| replace:: phycore-imx8mp_defconfig +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MP +.. |u-boot-tag| replace:: v2021.04_2.2.0-phy13 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-phyboard-pollux-rdk +.. |dt-som| replace:: imx8mp-phycore-som +.. |dtbo-rpmsg| replace:: imx8mp-phycore-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mp-phyboard-pollux-peb-av-010.dtbo + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n41` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`hardknott` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: hardknott +.. |yocto-distro| replace:: ampliphy-vendor-xwayland +.. |yocto-imagename| replace:: phytec-qt5demo-image +.. |yocto-machinename| replace:: phyboard-pollux-imx8mp-3 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MP-PD22.1.1 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MP-PD22.1.y +.. |yocto-ref-manual| replace:: L-813e.A12 Yocto Reference Manual (Hardknott) +.. _yocto-ref-manual: https://www.phytec.de/cdocuments/?doc=UIHsG +.. _yocto-ref-manual-kernel-and-bootloader-config: https://www.phytec.de/cdocuments/?doc=UIHsG#YoctoReferenceManualHardknottL813e-A12-KernelandBootloaderConfiguration +.. |yocto-sdk-rev| replace:: BSP-Yocto-NXP-i.MX8MP-PD22.1.1 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n141`. +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Yocto Manual | | ++-----------------------+----------------------+ +| Release Date | 2023/05/25 | ++-----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================= ========== +|yocto-manifestname| Minor 2023/05/23 Released +==================== ================ ================= ========== + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mp-pd22.1.1-components: +.. include:: components.rsti + +Getting Started +=============== + +The |kit| is shipped with a pre-flashed SD card. It contains the +|yocto-imagename| and can be used directly as a boot source. The eMMC is +programmed with only a U-boot by default. You can get all sources from the +`PHYTEC download server `_. This chapter explains how to flash a BSP +image to SD card and how to start the board. + +Get the Image +------------- + +The WIC image contains all BSP files in several, correctly pre-formatted +partitions and can be copied to an SD card easily using the single Linux +command ``dd``. It can be built by Yocto or downloaded from the PHYTEC download +server. + +Get the WIC file from the download server: + +.. code-block:: console + :substitutions: + + host:~$ wget |link-image| + +Write the Image to SD Card +-------------------------- + +.. warning:: + To create your bootable SD card with the ``dd`` command, you must have root + privileges. Be very careful when specifying the destination device with + ``dd``! All files on the selected destination device will be erased + immediately without any further query! + + Selecting the wrong device may result in **data loss** and e.g. could erase + your currently running system! + +To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. Unmount any mounted partitions before +you start copying the image to the SD card. + +#. In order to get the correct device name, remove your SD card and + execute:: + + host$ lsblk + +#. Now insert your SD card and execute the command again:: + + host$ lsblk + +#. Compare the two outputs to find the new device names listed in the second + output. These are the device names of the SD card (device and partitions if + the SD card was formatted). +#. In order to verify the device names being found, execute the command + ``sudo dmesg``. Within the last lines of its output, you should also find the + device names, e.g. ``/dev/sde`` or ``/dev/mmcblk0`` (depending on your + system). + +Alternatively, you may use a graphical program of your choice, like `GNOME Disks +`_ or `KDE Partition Manager +`_, to find the correct device. + +Now that you have the correct device name, e.g. ``/dev/sde``, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. ``/dev/sde1``) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption. + +* Unmount all partitions, e.g.:: + + host$ sudo umount /dev/sde1 + +* After having unmounted all partitions, you can create your bootable SD card:: + + host$ sudo dd if=-.wic of=/dev/sdX bs=1M conv=fsync status=progress + + Again, make sure to replace ``/dev/sdX`` with your actual device name found + previously. + + The parameter ``conv=fsync`` forces a sync operation on the device before + ``dd`` returns. This ensures that all blocks are written to the SD card and + none are left in memory. The parameter ``status=progress`` will print out + information on how much data is and still has to be copied until it is + finished. + +An alternative and much faster way to prepare an SD card can be done by using +`bmap-tools `_ from Intel. Yocto +automatically creates a block map file (``-.wic.bmap``) for +the WIC image that describes the image content and includes checksums for data +integrity. *bmaptool* is packaged by various Linux distributions. For +Debian-based systems install it by issuing:: + + host$ sudo apt install bmap-tools + +Flash a WIC image to SD card by calling:: + + host$ bmaptool copy -.wic /dev/ + +.. warning:: + *bmaptool* only overwrites the areas of an SD card where image data is + located. This means that a previously written U-Boot environment may still be + available after writing the image. + +First Start-up +-------------- + +* To boot from an SD card, |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-pd22.1.1-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-phyboard-pollux-rdk*.dtb**: Kernel device tree file +* **imx8mp-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt5demo-image\*.tar.gz**: Root file system +* **phytec-qt5demo-image\*.wic**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-pd22.1.1-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **Default SOM boot**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. However, they only +work if the size of the image file is less than 1GB. If the image file is +larger, go to the section Format SD Card. Configure the |ref-bootswitch| to boot +from SD Card and put in an SD card. Power on the board and stop in U-Boot +prompt. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +* Load your image via network to RAM: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* Write the image to the eMMC: + + .. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + A working network is necessary! Setup Network Host. + +Take a compressed or uncompressed image on the host and send it with ssh through +the network (then uncompress it, if necessary) to the eMMC of the target with a +one-line command: + +.. code-block:: console + :substitutions: + + target:~$ ssh @192.168.3.10 "dd if=/|yocto-imagename|-|yocto-machinename|.wic" | dd of=/dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +Send the image with the command dd command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2" + +Flash eMMC u-boot image via Network from running u-boot +....................................................... + +Update the standalone u-boot image imx-boot is also possible from u-boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB +................... + +Flash eMMC from USB in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in Bootloader after enabling the OPTEE. + +These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch to |ref-bootswitch| and put in an SD card. Power on the board +and stop in u-boot prompt. Insert a USB device with the copied WIC image +to the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} *.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the bootmode switch to +|ref-bootswitch|. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ cd /mnt + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2boot0; mmcblk2boot1) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + +.. warning:: + + Before this will work, you need to configure the multi-port switch + to **Default SOM Boot** to |ref-bootswitch|. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to enlarge your SD card to use +its full space (if it was not enlarged before). To enlarge your SD card, see +Resizing ext4 Root Filesystem. + +Flash eMMC from SD card in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in Bootloader after enabling the OPTEE. If the + image file is too large use the `Updating eMMC from SD card in + Linux on Target` subsection. + +* Flash an SD card with a working image and create a third FAT partition. Copy + the WIC image (for example |yocto-imagename|.wic) to this + partition. +* Configure the bootmode switch to boot from the SD Card and insert the SD + card. +* Power on the board and stop in u-boot. +* Flash your WIC image (for example |yocto-imagename|.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> fatload mmc 1:3 ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc0(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the multi-port switch to Default SOM Boot to + boot from eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a complete image saved on +the SD card (e.g. |yocto-imagename|-|yocto-machinename|.wic). + +* Show your saved image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2\ **boot0**; mmcblk2\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + +.. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to Default + SOM Boot to boot from eMMC. + +Flash SPI NOR Flash +------------------- + +The |som| modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set |ref-bootswitch| to **QSPI boot** to boot from QSPI. The SPI Flash is +usually quite small. The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash +populated. Only the bootloader and the environment can be stored. The kernel, +device tree, and file system are taken from eMMC by default. + +The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with: + +.. code-block:: + + u-boot=> printenv mtdparts + mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none) + +Flash SPI NOR Flash from Network +................................ + +The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-|soc|. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Flash SPI NOR from Network in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI-NOR flash needs to be probed: + +.. code-block:: + + u-boot=> sf probe + SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB + +* A specially formatted u-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image over tftp, erase and write the + bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + device 0 offset 0x0, size 0x1c0b20 + 1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +.. warning:: + + Erasing the complete SPI NOR flash when it is fully written will take quite + some time. This can trigger the watchdog to reset. Due to this, erase the + full flash in Linux. + +Flash SPI NOR from Network in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the image from the host to the target: + + .. code-block:: console + :substitutions: + + host:~$ scp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root + +* Find the number of erase blocks of the U-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +Flash SPI NOR Flash from SD Card +................................ + +The bootloader on SPI NOR flash can be also flashed with SD Card. + +Flash SPI NOR from SD Card in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the FAT partition + on the SD Card. Before reading and writing are possible, the SPI-NOR flash + needs to be probed: + + .. code-block:: + + u-boot=> sf probe + SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB + +* A specially formatted U-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image from the SD Card, erase and write + the bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +.. warning:: + + Erasing the complete SPI NOR flash when it is fully written will take quite + some time. This can trigger the watchdog to reset. Due to this, erase the + full flash in Linux. + +Flash SPI NOR from SD Card in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Mount the SD Card: + + .. code-block:: console + :substitutions: + + host:~$ mount /dev/mmcblkp1 /mnt + +* Find the number of erase blocks of the u-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp /mnt/imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A3 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd22.1.1-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + +.. _imx8mp-pd22.1.1-development-build-uboot: + +U-Boot standalone build +----------------------- + +Get the source code +................... + +* Get the U-Boot sources: + + .. code-block:: console + + host:~$ git clone git://git.phytec.de/u-boot-imx + +* To get the correct *U-Boot* **tag** you need to take a look at our release + notes, which can be found here: `release notes `_ +* The **tag** needed at this release is called |u-boot-tag| +* Check out the needed *U-Boot* **tag**: + +.. code-block:: console + :substitutions: + + host:~$ cd ~/u-boot-imx/ + host:~$ git fetch --all --tags + host:~$ git checkout tags/|u-boot-tag| + +* Technically, you can now build the U-Boot, but practically there are some + further steps necessary: + + * Create your own development branch: + + .. code-block:: console + + host:~$ git switch --create + + .. note:: + + You can name your development branch as you like, this is just an example. + +* Set up a build environment: + + .. code-block:: console + :substitutions: + + host:~$ source /opt/|yocto-distro|/|yocto-manifestname|/environment-setup-cortexa53-crypto-phytec-linux + +* Set this environment variable before building the Image: + + .. code-block:: console + :substitutions: + + host:~$ export ATF_LOAD_ADDR=|atfloadaddr| + +Get the needed binaries +....................... + +To build the bootloader, you need to **copy** these **files** to your |u-boot-repo-name| +**build directory** and rename them to fit with *mkimage* script: + +* **ARM Trusted firmware binary** (*mkimage tool* compatible format + **bl31.bin**): bl31-|kernel-socname|.bin +* **OPTEE image** (optional): tee.bin +* **DDR firmware files** (*mkimage tool* compatible format + **lpddr4_[i,d]mem_\*d_\*.bin**): + lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, + lpddr4_imem_2d_*.bin + +If you already built our BSP with Yocto, you can get the +bl31-|kernel-socname|.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: |ref-bsp-images| + +Or you can download the files here: |link-boot-tools| + +.. warning:: + + Make sure you rename the files you need so that they are compatible with the + *mkimage tool*. + +Build the bootloader +.................... + +* build flash.bin (imx-boot): + + .. code-block:: console + :substitutions: + + host:~$ make phycore-|kernel-socname|_defconfig + host:~$ make flash.bin + +Flash the bootloader to a block device +...................................... + +The flash.bin can be found at u-boot-imx/ directory and now can be flashed. A +chip-specific offset is needed: + +.. _offset-table: + +===== =================== ============================= ============ +SoC Offset User Area Offset Boot Partition eMMC Device +===== =================== ============================= ============ +|soc| |u-boot-offset| kiB |u-boot-offset-boot-part| kiB /dev/mmcblk2 +===== =================== ============================= ============ + +E.g. flash SD card: + +.. code-block:: console + :substitutions: + + host:~$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=|u-boot-offset| conv=sync + +.. hint:: + The specific offset values are also declared in the Yocto variables "BOOTLOADER_SEEK" and "BOOTLOADER_SEEK_EMMC" + +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + :start-after: .. build-uboot-fixed-ram-size-marker + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd22.1.1-device-tree: + +Device Tree (DT) +================ + +Introduction +------------ + +The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html) + +*"The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn't need to hard code details of the machine."* + +The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at `devicetree.org `_. + +PHYTEC |soc| BSP Device Tree Concept +------------------------------------ + +The following sections explain some rules PHYTEC has defined on how to set up +device trees for our |soc| SoC-based boards. + +Device Tree Structure +..................... + +* *Module.dtsi* - Module includes all devices mounted on the SoM, such as PMIC + and RAM. +* *Carrierboard.dtsi* - Devices that come from the |soc| SoC but are just routed + down to the carrier board and used there are included in this dtsi. +* *Board.dts* - include the carrier board and module dtsi files. There may also + be some hardware configuration nodes enabled on the carrier board or the + module (i.e. the Board .dts shows the special characteristics of the board + configuration). For example, there are phyCORE-|soc| SOMs which may or may not + have a MIPI DSI to LVDS converter mounted. The converter is enabled (if + available) in the Board .dts and not in the Module .dtsi + +From the root directory of the Linux Kernel our devicetree files for |socfamily| +platforms can be found in ``arch/arm64/boot/dts/freescale/``. + +Device Tree Overlay +................... + +Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder ``arch/arm64/boot/dts/freescale/overlays``. + +Available overlays for |yocto-machinename|.conf are: + +.. code-block:: + + imx8mp-isi-csi1.dtbo + imx8mp-isi-csi2.dtbo + imx8mp-isp-csi1.dtbo + imx8mp-isp-csi2.dtbo + imx8mp-phyboard-pollux-peb-av-010.dtbo + imx8mp-phyboard-pollux-peb-av-012.dtbo + imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + imx8mp-phycore-no-eth.dtbo + imx8mp-phycore-no-rtc.dtbo + imx8mp-phycore-no-spiflash.dtbo + imx8mp-phycore-rpmsg.dtbo + imx8mp-vm016-csi1.dtbo + imx8mp-vm016-csi1-fpdlink.dtbo + imx8mp-vm016-csi2.dtbo + imx8mp-vm016-csi2-fpdlink.dtbo + imx8mp-vm017-csi1.dtbo + imx8mp-vm017-csi1-fpdlink.dtbo + imx8mp-vm017-csi2.dtbo + imx8mp-vm017-csi2-fpdlink.dtbo + +.. hint:: + There is one more overlay available for phyboard-pollux-imx8mp-2.conf: + imx8mp-phyboard-pollux-1552.1.dtbo + +.. _imx8mp-pd22.1.1-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +imx8mp-phyboard-pollux.dtsi: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x49 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x49 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n331` + +.. _imx8mp-pd22.1.1-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +WLAN and Bluetooth on the |sbc| are provided by the PEB-WLBT-05 expansion card. +The PEB-WLBT-05 for |sbc| Quickstart Guide shows you how to install the +PEB-WLBT-05. + +.. tip:: + + With the BSP Version PD22.1 and newer, the PEB-WLBT-05 overlay needs to be activated first, + otherwise the PEB-WLBT-05 won't be recognized. + + .. code-block:: console + + target:~$ vi /boot/bootenv.txt + + Afterwards the bootenv.txt file should look like this (it can also contain other devicetree + overlays!): + + .. code-block:: + + overlays=imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + + The changes will be applied after a reboot: + + .. code-block:: console + + target:~$ reboot + + For further information about devicetree overlays, read the |ref-dt| chapter. + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First set the correct regulatory domain for your country: + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see: + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +Set up the wireless interface: + +.. code-block:: console + + target:~$ ip link + target:~$ ip link set up dev wlan0 + +Now you can scan for available networks: + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection. + +To do so, add the network-credentials to the file ``/etc/wpa_supplicant.conf``: + +.. code-block:: + + country=DE + network={ + ssid="" + proto=WPA2 + psk="" + } + +Now a connection can be established: + +.. code-block:: console + + target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B + +This should result in the following output: + +.. code-block:: + + ... + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section `Changing the Network Configuration` in the |yocto-ref-manual|_. + +First, create the directory: + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +Then add the following configuration snippet in ``/etc/systemd/network/10-wlan0.network``: + +.. code-block:: + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +Now, restart the network daemon so that the configuration takes effect: + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Bluetooth +......... + +Bluetooth is supported on |sbc| with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section. + +Bluetooth is connected to |bluetooth-uart| interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually: + +.. code-block:: console + + target:~$ hciconfig hci0 up + + target:~$ hciconfig -a + + hci0: Type: Primary Bus: UART + BD Address: 00:25:CA:2F:39:96 ACL MTU: 1021:8 SCO MTU: 64:1 + UP RUNNING PSCAN + RX bytes:1392 acl:0 sco:0 events:76 errors:0 + TX bytes:1198 acl:0 sco:0 commands:76 errors:0 + ... + +Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup. + +.. code-block:: console + + target:~$ hcitool scan + Scanning ... + XX:XX:XX:XX:XX:XX + +Visibility +~~~~~~~~~~ + +To activate visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 piscan + +To disable visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 noscan + +Connect +~~~~~~~ + +.. code-block:: console + + target:~$ bluetoothctl + [bluetooth]# discoverable on + Changing discoverable on succeeded + [bluetooth]# pairable on + Changing pairable on succeeded + [bluetooth]# agent on + Agent registered + [bluetooth]# default-agent + Default agent request successful + [bluetooth]# scan on + [NEW] Device XX:XX:XX:XX:XX:XX + [bluetooth]# connect XX:XX:XX:XX:XX:XX + +.. include:: ../../peripherals/wireless-network.rsti + :start-after: .. bluetooth_chapter_start_label + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n367` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n220` + +eMMC Devices +------------ + +PHYTEC modules like phyCORE-|soc| is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw MLC memory cells combined with a memory +controller that handles ECC and wear leveling. They are connected via an SD/MMC +interface to the |soc| and are represented as block devices in the Linux kernel +like SD cards, flash drives, or hard disks. + +The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer's datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard. + +PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1 + +Extended CSD Register +..................... + +eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard. + +In the Linux user space, you can query the registers: + +.. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| + +You will see: + +.. code-block:: + + ============================================= + Extended CSD rev 1.7 (MMC 5.0) + ============================================= + + Card Supported Command sets [S_CMD_SET: 0x01] + [...] + +Enabling Background Operations (BKOPS) +...................................... + +In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +cells. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called **Background +Operations (BKOPS)**. + +By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency. + +The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details. + +Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0): + +* Value 0: The host does not support the manual trigger of BKOPS. Device write + performance suffers. +* Value 1: The host does support the manual trigger of BKOPS. It will issue + BKOPS from time to time when it does not need the device. + +The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details). + +The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)). + +The userspace tool mmc does not currently support enabling automatic BKOPS +features. + +* To check whether *BKOPS_EN* is set, execute: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep BKOPS_EN + + The output will be, for example: + + .. code-block:: + + Enable background operations handshake [BKOPS_EN]: 0x01 + #OR + Enable background operations handshake [BKOPS_EN]: 0x00 + + Where value 0x00 means BKOPS_EN is disabled and device write performance + suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue + background operations from time to time. + +* To set the BKOPS_EN bit, execute: + + .. code-block:: console + :substitutions: + + target:~$ mmc bkops enable /dev/|emmcdev| + +* To ensure that the new setting is taken over and the kernel triggers BKOPS by + itself, shut down the system: + + .. code-block:: console + + target:~$ poweroff + +.. tip:: + + The BKOPS_EN bit is one-time programmable only. It cannot be reversed. + +Reliable Write +.............. + +There are two different Reliable Write options: + +1. Reliable Write option for a whole eMMC device/partition. +2. Reliable Write for single write transactions. + +.. tip:: + + Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT + partition table (see the previous section). + +The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-|soc| SoMs. To check this on the running target: + +.. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep -A 5 WR_REL_SET + Write reliability setting register [WR_REL_SET]: 0x1f + user area: the device protects existing data if a power failure occurs during a write o + peration + partition 1: the device protects existing data if a power failure occurs during a write + operation + partition 2: the device protects existing data if a power failure occurs during a write + operation + partition 3: the device protects existing data if a power failure occurs during a write + operation + partition 4: the device protects existing data if a power failure occurs during a write + operation + -- + Device supports writing EXT_CSD_WR_REL_SET + Device supports the enhanced def. of reliable write + +Otherwise, it can be enabled with the mmc tool: + +.. code-block:: console + + target:~$ mmc --help + + [...] + mmc write_reliability set <-y|-n> + +The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META. + +**Conclusion**: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application. + +Resizing ext4 Root Filesystem +............................. + +When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk. + +* Get the current device size: + + .. code-block:: console + :substitutions: + + target:~$ parted /dev/|emmcdev| print + +* The output looks like this: + + .. code-block:: + :substitutions: + + Model: MMC Q2J55L (sd/mmc) + Disk /dev/|emmcdev|: 7617MB + Sect[ 1799.850385] |emmcdev|: p1 p2 + or size (logical/physical): 512B/512B + Partition Table: msdos + Disk Flags: + + Number Start End Size Type File system Flags + 1 4194kB 72.4MB 68.2MB primary fat16 boot, lba + 2 72.4MB 537MB 465MB primary ext4 + +* Use parted to resize the root partition to the max size of the device: + + .. code-block:: console + :substitutions: + + target:~$ parted /dev/|emmcdev| resizepart 2 100% + Information: You may need to update /etc/fstab. + + target:~$ parted /dev/|emmcdev| print + Model: MMC Q2J55L (sd/mmc) + Disk /dev/|emmcdev|: 7617MB + Sector size (logical/physical): 512[ 1974.191657] |emmcdev|: p1 p2 + B/512B + Partition Table: msdos + Disk Flags: + + Number Start End Size Type File system Flags + 1 4194kB 72.4MB 68.2MB primary fat16 boot, lba + 2 72.4MB 7617MB 7545MB primary ext4 + +Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted. + +* Resize the filesystem to a new partition size: + + .. code-block:: console + :substitutions: + + target:~$ resize2fs /dev/|emmcdev|p2 + resize2fs 1.46.1 (9-Feb-2021) + Filesystem at /dev/|emmcdev|p2 is mounted on /; on-line resizing required + [ 131.609512] EXT4-fs (|emmcdev|p2): resizing filesystem + from 454136 to 7367680 blocks + old_desc_blocks = 4, new_desc_blocks = 57 + [ 131.970278] EXT4-fs (|emmcdev|p2): resized filesystem to 7367680 + The filesystem on /dev/|emmcdev|p2 is now 7367680 (1k) blocks long + +Enable pseudo-SLC Mode +...................... + +eMMC devices use MLC memory cells +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC memory cells used in NAND Flash, MLC memory cells have lower +reliability and a higher error rate at lower costs. + +If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity. + +.. warning:: + + When enabling the enhanced attribute on the device, all data will be lost. + +The following sequence shows how to enable the enhanced attribute. + +* First obtain the current size of the eMMC device with: + + .. code-block:: console + :substitutions: + + target:~$ parted -m /dev/|emmcdev| unit B print + + You will receive: + + .. code-block:: + :substitutions: + + BYT; + /dev/|emmcdev|:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:; + + As you can see this device has 63652757504 Byte = 60704 MiB. + +* To get the maximum size of the device after pseudo-SLC is enabled use: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep ENH_SIZE_MULT -A 1 + + which shows, for example: + + .. code-block:: + + Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + -- + Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000 + i.e. 0 KiB + + Here the maximum size is 3719168 KiB = 3632 MiB. + +* Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by + typing: + + .. code-block:: console + :substitutions: + + target:~$ mmc enh_area set -y 0 3719168 /dev/|emmcdev| + + You will get: + + .. code-block:: + :substitutions: + + Done setting ENH_USR area on /dev/|emmcdev| + setting OTP PARTITION_SETTING_COMPLETED! + Setting OTP PARTITION_SETTING_COMPLETED on /dev/|emmcdev| SUCCESS + Device power cycle needed for settings to take effect. + Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle + +* To ensure that the new setting has taken over, shut down the system: + + .. code-block:: console + + target:~$ poweroff + + and perform a power cycle. It is recommended that you verify the settings now. + +* First, check the value of ENH_SIZE_MULT which must be 3719168 KiB: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep ENH_SIZE_MULT -A 1 + + You should receive:: + + Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + -- + Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + +* Finally, check the size of the device: + + .. code-block:: console + :substitutions: + + target:~$ parted -m /dev/|emmcdev| unit B print + BYT; + /dev/|emmcdev|:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:; + +Erasing the Device +.................. + +It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC memory +cells or mark these blocks as discard. The data on the device is lost and will +be read back as zeros. + +* After booting from SD Card execute: + + .. code-block:: console + :substitutions: + + target:~$ blkdiscard -f --secure /dev/|emmcdev| + + The option --secure ensures that the command waits until the eMMC device has + erased all blocks. The -f (force) option disables all checking before erasing + and it is needed when the eMMC device contains existing partitions with data. + +.. tip:: + .. code-block:: console + :substitutions: + + target:~$ dd if=/dev/zero of=/dev/|emmcdev| conv=fsync + + also destroys all information on the device, but this command is bad for wear + leveling and takes much longer! + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n72` + +GPIOs +----- + +The |sbc| has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to |soc| pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal |soc| GPIO banks GPIO1 – GPIO5. + +The GPIOs are identified as GPIO_ (e.g. GPIO5_07). identifies the GPIO +bank and counts from 1 to 5, while stands for the GPIO within the bank. +is being counted from 0 to 31 (32 GPIOs on each bank). + +By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is: + +.. code-block:: + + Linux GPIO number: = ( - 1) * 32 + + +Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools: + +* Detecting the gpiochips on the chip: + + .. code-block:: console + + target:~$ gpiodetect + gpiochip0 [30200000.gpio] (32 lines) + gpiochip1 [30210000.gpio] (32 lines) + gpiochip2 [30220000.gpio] (32 lines) + gpiochip3 [30230000.gpio] (32 lines) + gpiochip4 [30240000.gpio] (32 lines) + +* Show detailed information about the gpiochips. Like their names, consumers, + direction, active state, and additional flags: + + .. code-block:: console + + target:~$ gpioinfo gpiochip0 + +* Read the value of a GPIO (e.g GPIO 20 from chip0): + + .. code-block:: console + + target:~$ gpioget gpiochip0 20 + +* Set the value of GPIO 20 on chip0 to 0 and exit tool: + + .. code-block:: console + + target:~$ gpioset --mode=exit gpiochip0 20=0 + +* Help text of gpioset shows possible options: + + .. code-block:: console + + target:~$ gpioset --help + Usage: gpioset [OPTIONS] = = ... + Set GPIO line values of a GPIO chip + + Options: + -h, --help: display this message and exit + -v, --version: display the version and exit + -l, --active-low: set the line active state to low + -m, --mode=[exit|wait|time|signal] (defaults to 'exit'): + tell the program what to do after setting values + -s, --sec=SEC: specify the number of seconds to wait (only valid for --mode=time) + -u, --usec=USEC: specify the number of microseconds to wait (only valid for --mode=time) + -b, --background: after setting values: detach from the controlling terminal + + Modes: + exit: set values and exit immediately + wait: set values and wait for user to press ENTER + time: set values and sleep for a specified amount of time + signal: set values and wait for SIGINT or SIGTERM + + Note: the state of a GPIO line controlled over the character device reverts to default + when the last process referencing the file descriptor representing the device file exits. + This means that it's wrong to run gpioset, have it exit and expect the line to continue + being driven high or low. It may happen if given pin is floating but it must be interpreted + as undefined behavior. + + +.. warning:: + + Some of the user IOs are used for special functions. Before using a user IO, + refer to the schematic or the hardware manual of your board to ensure that it + is not already in use. + +GPIOs via sysfs +............... + +.. warning:: + + Accessing gpios via sysfs is deprecated and we encourage to use libgpiod + instead. + +Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling ``CONFIG_GPIO_SYSFS`` in the kernel +configuration. To make ``CONFIG_GPIO_SYSFS`` visible in menuconfig the option +``CONFIG_EXPERT`` has to be enabled first. + +You can also add this option for example to the defconfig you use in +``arch/arm64/configs/`` in the linux kernel sources. For our NXP based releases, +this could be for example ``imx8_phytec_distro.config``:: + + .. + CONFIG_EXPERT=y + CONFIG_GPIO_SYSFS=y + .. + +Otherwise you can create a new config fragment. This is described in our +`Yocto Reference Manual `_. + +LEDs +---- + +If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using ``/sys/class/leds/`` instead +of ``/sys/class/gpio/``. The maximum brightness of the LEDs can be read from +the ``max_brightness`` file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings. + +Below is a simple example. + +To get all available LEDs, type: + +.. code-block:: console + + target:~$ ls /sys/class/leds + mmc1::@ mmc2::@ user-led1@ user-led2@ user-led3@ + +Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the |sbc|. + +* To toggle the LEDs ON: + + .. code-block:: console + + target:~$ echo 255 > /sys/class/leds/user-led1/brightness + +* To toggle OFF: + + .. code-block:: console + + target:~$ echo 0 > /sys/class/leds/user-led1/brightness + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n216` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n105` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n201` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues. + +.. include:: ../peripherals/eeprom.rsti + +Rescue EEPROM Data +.................. + +The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area. + +.. code-block:: console + + target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 + +.. note:: + + If you deleted both EEPROM spaces, please contact our support! + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n201` + +.. include:: ../../peripherals/rtc.rsti + :end-before: .. rtc_parameter_start_label + +DT representation for I²C RTCs: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n207` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n341` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of imx8mp-phyboard-pollux.dtsi: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n165` + +PCIe +---- + +The phyCORE-|soc| has one Mini-PCIe slot. In general, PCIe autodetects new +devices on the bus. After connecting the device and booting up the system, you +can use the command lspci to see all PCIe devices recognized. + +* Type: + + .. code-block:: console + + target:~$ lspci -v + +* You will receive: + + .. code-block:: + + 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode]) + Flags: bus master, fast devsel, latency 0, IRQ 218 + Memory at 18000000 (64-bit, non-prefetchable) [size=1M] + Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0 + I/O behind bridge: None + Memory behind bridge: 18100000-181fffff [size=1M] + Prefetchable memory behind bridge: None + [virtual] Expansion ROM at 18200000 [disabled] [size=64K] + Capabilities: [40] Power Management version 3 + Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+ + Capabilities: [70] Express Root Port (Slot-), MSI 00 + Capabilities: [100] Advanced Error Reporting + Capabilities: [148] L1 PM Substates + Kernel driver in use: dwc3-haps + + 01:00.0 Network controller: Intel Corporation WiFi Link 5100 + Subsystem: Intel Corporation WiFi Link 5100 AGN + Flags: fast devsel + Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K] + Capabilities: [c8] Power Management version 3 + Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+ + Capabilities: [e0] Express Endpoint, MSI 00 + Capabilities: [100] Advanced Error Reporting + Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e + Kernel modules: iwlwifi + +In this example, the PCIe device is the *Intel Corporation WiFi Link 5100*. + +For PCIe devices, you have to enable the correct driver in the kernel +configuration. This WLAN card, for example, is manufactured by Intel. The +option for the driver, which must be enabled, is named ``CONFIG_IWLWIFI`` and can be +found under *Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimat* in +the kernel configuration. + +* In order to activate the driver, follow the instructions from our + `Yocto Reference Manual `_. + + - The linux-imx is represented by: **virtual/kernel** + +For some devices like the WLAN card, additional binary firmware blobs are +needed. These firmware blobs have to be placed in ``/lib/firmware/`` before the +device can be used. + +* Type: + + .. code-block:: console + + host:~$ scp -r root@192.168.3.11:/lib/firmware + +* For example, if you try to bring up the network interface: + + .. code-block:: console + + target:~$ ip link set up wlp1s0 + +* You will get the following output on the serial console: + + .. code-block:: console + + [ 58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0 + [ 58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0 + [ 58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready + +.. tip:: + + Some PCIe devices, e.g. the Ethernet card, may function properly even if no + firmware blob is loaded from ``/lib/firmware/`` and you received an error message + as shown in the first line of the output above. This is because some + manufacturers provide the firmware as a fallback on the card itself. In this + case, the behavior and output depend strongly on the manufacturer's firmware. + +Device Tree PCIe configuration of imx8mm-phyboard-polis.dtsi: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n277` + +Audio +----- + +Playback devices supported for |sbc| are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals. + +.. note:: + + Using the PEB-AV-10 connector for display output along HDMI as audio output + is not supported. The audio output device must match the video output device. + +To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices: + +.. code-block:: console + + target:~$ aplay -L + +Or type for recording devices: + +.. code-block:: console + + target:~$ arecord -L + +Alsamixer +......... + +To inspect the capabilities of your soundcard, call: + +.. code-block:: console + + target:~$ alsamixer + +You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. "MM" means the feature is muted +(both output, left & right), which can be toggled by hitting **m**. You can also +toggle by hitting '**<**' for left and '**>**' for right output. With the **tab** +key, you can switch between controls for playback and recording. + +ALSA configuration +.................. + +Our BSP comes with a ALSA configuration file ``/etc/asound.conf``. + +The ALSA configuration file can be edited as desired or deleted since it is not +required for ALSA to work properly. + +.. code-block:: console + + target:~$ vi /etc/asound.conf + +To set PEB-AV-10 as output, set *playback.pcm* from "dummy" to "pebav10": + +.. code-block:: + + [...] + + pcm.asymed { + type asym + playback.pcm "pebav10" + capture.pcm "dsnoop" + } + + [...] + +If the sound is not audible change playback devices to the software volume control +playback devices, set *playback.pcm* to the respective softvol playback device either +"softvol_hdmi" or "softvol_pebav10". Use alsamixer controls to vary the volume levels. + +.. code-block:: + + [...] + + pcm.asymed { + type asym + playback.pcm "softvol_hdmi" + capture.pcm "dsnoop" + } + + [...] + +Pulseaudio Configuration +........................ + +For applications using Pulseaudio, check for available sinks: + +.. code-block:: console + + target:~$ pactl list short sinks + 0 alsa_output.platform-snd_dummy.0.stereo-fallback module-alsa-card.c s16le 2ch 44100Hz SUSPENDED + 1 alsa_output.platform-sound-peb-av-10.stereo-fallback module-alsa-card.c s16le 2ch 44100Hz SUSPENDED + +To select PEB-AV-10, type: + +.. code-block:: console + + target:~$ pactl set-default-sink 1 + +Playback +........ + +Run speaker-test to check playback availability: + +.. code-block:: console + + target:~$ speaker-test -c 2 -t wav + +To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds: + +.. code-block:: console + + target:~$ aplay /usr/share/sounds/alsa/* + +To playback other formats like mp3 for example, you can use Gstreamer: + +.. code-block:: console + + target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3 + +Capture +....... + +``arecord`` is a command-line tool for capturing audio streams which use Line In as +the default input source. To select a different audio source you can +use ``alsamixer``. For example, switch on *Right PGA Mixer Mic3R* and *Left PGA Mixer +Mic3R* in order to capture the audio from the microphone input of the +TLV320-Codec using the 3.5mm jack. + +.. code-block:: console + + target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on + target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on + +.. code-block:: console + + target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav + +.. hint:: + + Since playback and capture share hardware interfaces, it is not possible to + use different sampling rates and formats for simultaneous playback and + capture operations. + +Device Tree Audio configuration: +:imx-dt:`overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.10.72_2.2.0-phy17#n57` + +Video +----- + +Videos with Gstreamer +..................... + +The video is installed by default in the BSP: + +.. code-block:: console + + target:~$ gst-launch-1.0 playbin uri=file:///usr/share/phytec-qtdemo/videos/caminandes.webm + +* Or: + +.. code-block:: console + + target:~$ gst-launch-1.0 -v filesrc location= \ + \! qtdemux \! h264parse \! queue \! vpudec \! waylandsink async=false enable-last-sample=false \ + qos=false sync=false + +* Or: + +.. code-block:: console + + target:~$ gplay-1.0 /usr/share/phytec-qtdemo/videos/caminandes.webm + +kmssink Plugin ID Evaluation +............................ + +The kmssink plugin needs a connector ID. To get the connector ID, you can use +the tool modetest. + +.. code-block:: console + + target:~$ modetest -c imx-drm + +The output will show something like: + +.. code-block:: + + Connectors: + id encoder status name size (mm) modes encoders + 35 34 connected LVDS-1 216x135 1 34 + modes: + index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot + #0 1280x800 59.07 1280 1380 1399 1440 800 804 808 823 70000 flags: phsync, pvsync; type: preferred, driver + props: + 1 EDID: + flags: immutable blob + blobs: + + value: + 2 DPMS: + flags: enum + enums: On=0 Standby=1 Suspend=2 Off=3 + value: 0 + 5 link-status: + flags: enum + enums: Good=0 Bad=1 + value: 0 + 6 non-desktop: + flags: immutable range + values: 0 1 + value: 0 + 4 TILE: + flags: immutable blob + blobs: + + value: + +Display +------- + +The |sbc| supports up to 4 different display outputs. Three can be used +simultaneously. The following table shows the required extensions and devicetree +overlays for the different interfaces. + +========= ======================== ====================================== +Interface Expansion devicetree overlay +========= ======================== ====================================== +HDMI |sbc| no overlay needed (enabled by default) +LVDS0 PEB-AV-10 imx8mp-phyboard-pollux-peb-av-010.dtbo + (loaded by default) +LVDS1 |sbc| disabled if PEB-AV-10 overlay is used +MIPI PEB-AV-12 (MIPI to LVDS) imx8mp-phyboard-pollux-peb-av-012.dtbo +========= ======================== ====================================== + +.. note:: + + * HDMI will not work if LVDS1 (onboard) is enabled. + * When changing Weston output, make sure to match the audio output as well. + * LVDS0 (PEB-AV-10) and LVDS1 (onboard)can not be used at the same time. + +HDMI is always enabled in the devicetree. The other interfaces can be enabled +with Device Tree Overlay. + +The default-enabled Interfaces are HDMI and LVDS0 (PEB-AV-010). We support a +10'' edt,etml1010g0dka display for the PEB-AV-10 and PEB-AV-12. + +.. note:: + + The current display driver limits the pixel clock for a display connected to + LVDS to 74.25Mhz (or a divider of it). If this does not fit your display + requirements, please contact Support for further help. + +Weston Configuration +.................... + +In order to get an output from Weston on the correct display, it still needs to +be configured correctly. This will be done at /etc/xdg/weston/weston.ini. + +Single Display +~~~~~~~~~~~~~~ + +In our BSP, the default Weston output is set to HDMI. :: + + [output] + name=HDMI-A-1 + mode=current + +.. include:: /bsp/qt5.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +Device tree description of LVDS-1 and HDMI can be found here: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n255` +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n180` + +The device tree of LVDS-0 on PEB-AV-10 can be found here: +:imx-dt:`overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.10.72_2.2.0-phy17#n132` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +The device tree description of GPIO Fan can be found here: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n26` + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/snvs-power-key.rsti + +NPU +--- + +The |soc| SoC contains a Neural Processing Unit up to 2.3 TOPS as an accelerator +for artificial intelligence operations. Refer to our latest phyCORE-|soc| AI Kit +Guide on the phyCORE-|soc| download section to get information about the +NPU: `L-1015e.A0 phyCORE-i.MX 8M Plus AI Kit Guide +`_ + +NXP Examples for eIQ +.................... + +NXP provides a set of machine learning examples for eIQ using Python3. To add a +pre-configured machine learning package group, add to your local.conf and build +your BSP:: + + IMAGE_INSTALL_append = " packagegroup-imx-ml python3-pip python3-requests opencv" + +This will require about 1GB of additional space on the SD Card. Instructions +on how to install and use the NXP examples can be found at +https://community.nxp.com/t5/Blogs/PyeIQ-3-x-Release-User-Guide/ba-p/1305998. + +.. hint:: + + The installation of the eiq examples with pip3 requires an internet + connection. + +.. note:: + + On some Ubuntu 20.04 hosts, cmake uses the host's Python 3 instead of Python + 3.7 from Yocto when building python3-pybind11. (see + https://community.nxp.com/t5/i-MX-Processors/Yocto-L5-4-70-2-3-0-build-image-failed/m-p/1219619) + + As a workaround edit, the python3-pybind11 recipe by:: + + $ devtool edit-recipe python3-pybind11 + + and add to the file:: + + EXTRA_OECMAKE += "-DPYTHON_EXECUTABLE=${RECIPE_SYSROOT_NATIVE}/usr/bin/python3-native/python3.7" + +.. include:: ../peripherals/isp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +Reading the registers using ``/dev/mem`` will cause the system to hang unless the +*ocotp_root_clk* is enabled. To enable this clock permanent, add to the device +tree: + +.. code-block:: + + &clk { + init-on-array = ; + }; + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti + +.. +---------------------------------------------------------------------------+ +.. BSP EXTENSIONS +.. +---------------------------------------------------------------------------+ + +BSP Extensions +============== + +Chromium +-------- + +Our BSP for the |sbc|-|soc| supports Chromium. You can include it in the +|yocto-imagename| with only a few steps. + +Adding Chromium to Your local.conf +.................................. + +To include Chromium you have to add the following line into your local.conf. You +can find it in /build/conf/local.conf. This adds Chromium to your +next image build. :: + + IMAGE_INSTALL_append = " chromium-ozone-wayland" + +.. note:: + + Compiling Chromium takes a long time. + +Get Chromium Running on the Target +.................................. + +To run Chromium, it needs a few arguments to use the hardware graphics +acceleration:: + + target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox + +If you want to start Chromium via SSH, you must first define the display on +which Chromium will run. For example:: + + target$ DISPLAY=:0 + +After you have defined this, you can start it via virtual terminal on Weston as +shown above. diff --git a/previews/271/_sources/bsp/imx8/imx8mp/pd22.1.2.rst.txt b/previews/271/_sources/bsp/imx8/imx8mp/pd22.1.2.rst.txt new file mode 100644 index 000000000..96163ec69 --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mp/pd22.1.2.rst.txt @@ -0,0 +1,2598 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MP-PD22.1.2 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.2/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.2/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.2/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp + +.. IMX8(MP) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mp/phycore-imx8mp.c?h=v2021.04_2.2.0-phy13#n239 + + +.. General Substitutions +.. |atfloadaddr| replace:: 0x970000 +.. |kit| replace:: **phyCORE-i.MX8M Plus Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Pollux +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |bluetooth-uart| replace:: UART3 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx8mp +.. |kernel-tag| replace:: v5.10.72_2.2.0-phy18 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MP +.. |u-boot-tag| replace:: v2021.04_2.2.0-phy17 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-phyboard-pollux-rdk +.. |dt-som| replace:: imx8mp-phycore-som +.. |dtbo-rpmsg| replace:: imx8mp-phycore-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mp-phyboard-pollux-peb-av-010.dtbo + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n41` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`hardknott` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: hardknott +.. |yocto-distro| replace:: ampliphy-vendor-xwayland +.. |yocto-imagename| replace:: phytec-qt5demo-image +.. |yocto-machinename| replace:: phyboard-pollux-imx8mp-3 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MP-PD22.1.2 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MP-PD22.1.y +.. |yocto-ref-manual| replace:: L-813e.A12 Yocto Reference Manual (Hardknott) +.. _yocto-ref-manual: https://www.phytec.de/cdocuments/?doc=UIHsG +.. _yocto-ref-manual-kernel-and-bootloader-config: https://www.phytec.de/cdocuments/?doc=UIHsG#YoctoReferenceManualHardknottL813e-A12-KernelandBootloaderConfiguration +.. |yocto-sdk-rev| replace:: BSP-Yocto-NXP-i.MX8MP-PD22.1.2 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n141`. +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + ++-----------------------+----------------------+ +| |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Yocto Manual | | ++-----------------------+----------------------+ +| Release Date | 2024/08/05 | ++-----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================= ========== +|yocto-manifestname| Minor 2024/08/05 Released +==================== ================ ================= ========== + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. note:: + When the PCM-070 does not have the X1 extension connector populated, some + Software features described here do not work. These are Wirless LAN, PCIe, + CSI (cameras), PEB-AV-12, CAN, USB-OTG. + +.. _imx8mp-pd22.1.2-components: +.. include:: components.rsti + +Getting Started +=============== + +The |kit| is shipped with a pre-flashed SD card. It contains the +|yocto-imagename| and can be used directly as a boot source. The eMMC is +programmed with only a U-boot by default. You can get all sources from the +`PHYTEC download server `_. This chapter explains how to flash a BSP +image to SD card and how to start the board. + +Get the Image +------------- + +The WIC image contains all BSP files in several, correctly pre-formatted +partitions and can be copied to an SD card easily using the single Linux +command ``dd``. It can be built by Yocto or downloaded from the PHYTEC download +server. + +Get the WIC file from the download server: + +.. code-block:: console + :substitutions: + + host:~$ wget |link-image| + +Write the Image to SD Card +-------------------------- + +.. warning:: + To create your bootable SD card with the ``dd`` command, you must have root + privileges. Be very careful when specifying the destination device with + ``dd``! All files on the selected destination device will be erased + immediately without any further query! + + Selecting the wrong device may result in **data loss** and e.g. could erase + your currently running system! + +To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. Unmount any mounted partitions before +you start copying the image to the SD card. + +#. In order to get the correct device name, remove your SD card and + execute:: + + host$ lsblk + +#. Now insert your SD card and execute the command again:: + + host$ lsblk + +#. Compare the two outputs to find the new device names listed in the second + output. These are the device names of the SD card (device and partitions if + the SD card was formatted). +#. In order to verify the device names being found, execute the command + ``sudo dmesg``. Within the last lines of its output, you should also find the + device names, e.g. ``/dev/sde`` or ``/dev/mmcblk0`` (depending on your + system). + +Alternatively, you may use a graphical program of your choice, like `GNOME Disks +`_ or `KDE Partition Manager +`_, to find the correct device. + +Now that you have the correct device name, e.g. ``/dev/sde``, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. ``/dev/sde1``) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption. + +* Unmount all partitions, e.g.:: + + host$ sudo umount /dev/sde1 + +* After having unmounted all partitions, you can create your bootable SD card:: + + host$ sudo dd if=-.wic of=/dev/sdX bs=1M conv=fsync status=progress + + Again, make sure to replace ``/dev/sdX`` with your actual device name found + previously. + + The parameter ``conv=fsync`` forces a sync operation on the device before + ``dd`` returns. This ensures that all blocks are written to the SD card and + none are left in memory. The parameter ``status=progress`` will print out + information on how much data is and still has to be copied until it is + finished. + +An alternative and much faster way to prepare an SD card can be done by using +`bmap-tools `_ from Intel. Yocto +automatically creates a block map file (``-.wic.bmap``) for +the WIC image that describes the image content and includes checksums for data +integrity. *bmaptool* is packaged by various Linux distributions. For +Debian-based systems install it by issuing:: + + host$ sudo apt install bmap-tools + +Flash a WIC image to SD card by calling:: + + host$ bmaptool copy -.wic /dev/ + +.. warning:: + *bmaptool* only overwrites the areas of an SD card where image data is + located. This means that a previously written U-Boot environment may still be + available after writing the image. + +First Start-up +-------------- + +* To boot from an SD card, |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-pd22.1.2-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-phyboard-pollux-rdk*.dtb**: Kernel device tree file +* **imx8mp-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt5demo-image\*.tar.gz**: Root file system +* **phytec-qt5demo-image\*.wic**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-pd22.1.2-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **Default SOM boot**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. However, they only +work if the size of the image file is less than 1GB. If the image file is +larger, go to the section Format SD Card. Configure the |ref-bootswitch| to boot +from SD Card and put in an SD card. Power on the board and stop in U-Boot +prompt. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +* Load your image via network to RAM: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* Write the image to the eMMC: + + .. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + A working network is necessary! Setup Network Host. + +Take a compressed or uncompressed image on the host and send it with ssh through +the network (then uncompress it, if necessary) to the eMMC of the target with a +one-line command: + +.. code-block:: console + :substitutions: + + target:~$ ssh @192.168.3.10 "dd if=/|yocto-imagename|-|yocto-machinename|.wic" | dd of=/dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +Send the image with the command dd command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2" + +Flash eMMC u-boot image via Network from running u-boot +....................................................... + +Update the standalone u-boot image imx-boot is also possible from u-boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB +................... + +Flash eMMC from USB in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in Bootloader after enabling the OPTEE. + +These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch to |ref-bootswitch| and put in an SD card. Power on the board +and stop in u-boot prompt. Insert a USB device with the copied WIC image +to the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} *.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the bootmode switch to +|ref-bootswitch|. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ cd /mnt + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2boot0; mmcblk2boot1) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + +.. warning:: + + Before this will work, you need to configure the multi-port switch + to **Default SOM Boot** to |ref-bootswitch|. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to enlarge your SD card to use +its full space (if it was not enlarged before). To enlarge your SD card, see +Resizing ext4 Root Filesystem. + +Flash eMMC from SD card in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in Bootloader after enabling the OPTEE. If the + image file is too large use the `Updating eMMC from SD card in + Linux on Target` subsection. + +* Flash an SD card with a working image and create a third FAT partition. Copy + the WIC image (for example |yocto-imagename|.wic) to this + partition. +* Configure the bootmode switch to boot from the SD Card and insert the SD + card. +* Power on the board and stop in u-boot. +* Flash your WIC image (for example |yocto-imagename|.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> fatload mmc 1:3 ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc0(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the multi-port switch to Default SOM Boot to + boot from eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a complete image saved on +the SD card (e.g. |yocto-imagename|-|yocto-machinename|.wic). + +* Show your saved image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2\ **boot0**; mmcblk2\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + +.. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to Default + SOM Boot to boot from eMMC. + +Flash SPI NOR Flash +------------------- + +The |som| modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set |ref-bootswitch| to **QSPI boot** to boot from QSPI. The SPI Flash is +usually quite small. The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash +populated. Only the bootloader and the environment can be stored. The kernel, +device tree, and file system are taken from eMMC by default. + +The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with: + +.. code-block:: + + u-boot=> printenv mtdparts + mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none) + +Flash SPI NOR Flash from Network +................................ + +The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-|soc|. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Flash SPI NOR from Network in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI-NOR flash needs to be probed: + +.. code-block:: + + u-boot=> sf probe + SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB + +* A specially formatted u-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image over tftp, erase and write the + bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + device 0 offset 0x0, size 0x1c0b20 + 1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +.. warning:: + + Erasing the complete SPI NOR flash when it is fully written will take quite + some time. This can trigger the watchdog to reset. Due to this, erase the + full flash in Linux. + +Flash SPI NOR from Network in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the image from the host to the target: + + .. code-block:: console + :substitutions: + + host:~$ scp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root + +* Find the number of erase blocks of the U-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +Flash SPI NOR Flash from SD Card +................................ + +The bootloader on SPI NOR flash can be also flashed with SD Card. + +Flash SPI NOR from SD Card in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the FAT partition + on the SD Card. Before reading and writing are possible, the SPI-NOR flash + needs to be probed: + + .. code-block:: + + u-boot=> sf probe + SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB + +* A specially formatted U-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image from the SD Card, erase and write + the bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +.. warning:: + + Erasing the complete SPI NOR flash when it is fully written will take quite + some time. This can trigger the watchdog to reset. Due to this, erase the + full flash in Linux. + +Flash SPI NOR from SD Card in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Mount the SD Card: + + .. code-block:: console + :substitutions: + + host:~$ mount /dev/mmcblkp1 /mnt + +* Find the number of erase blocks of the u-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp /mnt/imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A3 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd22.1.2-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + +.. _imx8mp-pd22.1.2-development-build-uboot: + +U-Boot standalone build +----------------------- + +Get the source code +................... + +* Get the U-Boot sources: + + .. code-block:: console + + host:~$ git clone git://git.phytec.de/u-boot-imx + +* To get the correct *U-Boot* **tag** you need to take a look at our release + notes, which can be found here: `release notes `_ +* The **tag** needed at this release is called |u-boot-tag| +* Check out the needed *U-Boot* **tag**: + +.. code-block:: console + :substitutions: + + host:~$ cd ~/u-boot-imx/ + host:~$ git fetch --all --tags + host:~$ git checkout tags/|u-boot-tag| + +* Technically, you can now build the U-Boot, but practically there are some + further steps necessary: + + * Create your own development branch: + + .. code-block:: console + + host:~$ git switch --create + + .. note:: + + You can name your development branch as you like, this is just an example. + +* Set up a build environment: + + .. code-block:: console + :substitutions: + + host:~$ source /opt/|yocto-distro|/|yocto-manifestname|/environment-setup-cortexa53-crypto-phytec-linux + +* Set this environment variable before building the Image: + + .. code-block:: console + :substitutions: + + host:~$ export ATF_LOAD_ADDR=|atfloadaddr| + +Get the needed binaries +....................... + +To build the bootloader, you need to **copy** these **files** to your |u-boot-repo-name| +**build directory** and rename them to fit with *mkimage* script: + +* **ARM Trusted firmware binary** (*mkimage tool* compatible format + **bl31.bin**): bl31-|kernel-socname|.bin +* **OPTEE image** (optional): tee.bin +* **DDR firmware files** (*mkimage tool* compatible format + **lpddr4_[i,d]mem_\*d_\*.bin**): + lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, + lpddr4_imem_2d_*.bin + +If you already built our BSP with Yocto, you can get the +bl31-|kernel-socname|.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: |ref-bsp-images| + +Or you can download the files here: |link-boot-tools| + +.. warning:: + + Make sure you rename the files you need so that they are compatible with the + *mkimage tool*. + +Build the bootloader +.................... + +* build flash.bin (imx-boot): + + .. code-block:: console + :substitutions: + + host:~$ make phycore-|kernel-socname|_defconfig + host:~$ make flash.bin + +Flash the bootloader to a block device +...................................... + +The flash.bin can be found at u-boot-imx/ directory and now can be flashed. A +chip-specific offset is needed: + +.. _offset-table: + +===== =================== ============================= ============ +SoC Offset User Area Offset Boot Partition eMMC Device +===== =================== ============================= ============ +|soc| |u-boot-offset| kiB |u-boot-offset-boot-part| kiB /dev/mmcblk2 +===== =================== ============================= ============ + +E.g. flash SD card: + +.. code-block:: console + :substitutions: + + host:~$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=|u-boot-offset| conv=sync + +.. hint:: + The specific offset values are also declared in the Yocto variables "BOOTLOADER_SEEK" and "BOOTLOADER_SEEK_EMMC" + +Build U-Boot With a Fixed RAM Size +.................................. + +If you cannot boot your system anymore because the hardware introspection in the +EEPROM is damaged or deleted, you can create a flash.bin with a fixed ram size. +You should still contact support and flash the correct EEPROM data, as this +could lead to unexpected behavior. + +Follow the steps to get the U-boot sources and check the correct branch in the +**Build U-Boot** section. + +Edit the file configs/phycore-|kernel-socname|\_defconfig: + +.. code-block:: kconfig + :substitutions: + + CONFIG_TARGET_|u-boot-socname-config|=y + CONFIG_|u-boot-socname-config|_RAM_SIZE_FIX=y + # CONFIG_|u-boot-socname-config|_RAM_SIZE_1GB=y + # CONFIG_|u-boot-socname-config|_RAM_SIZE_2GB=y + # CONFIG_|u-boot-socname-config|_RAM_SIZE_4GB=y + # CONFIG_|u-boot-socname-config|_RAM_SIZE_4GB_2GHZ=y + +Choose the correct RAM size as populated on the board and uncomment the line for +this ram size. For Article number 0F\ **8**\ 443I, use [...]_4GB_2GHZ, for +0F\ **5**\ 443I, use [...]_4GB. +After saving the changes, follow the remaining steps from |ref-build-uboot|. + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd22.1.2-device-tree: + +Device Tree (DT) +================ + +Introduction +------------ + +The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html) + +*"The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn't need to hard code details of the machine."* + +The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at `devicetree.org `_. + +PHYTEC |soc| BSP Device Tree Concept +------------------------------------ + +The following sections explain some rules PHYTEC has defined on how to set up +device trees for our |soc| SoC-based boards. + +Device Tree Structure +..................... + +* *Module.dtsi* - Module includes all devices mounted on the SoM, such as PMIC + and RAM. +* *Carrierboard.dtsi* - Devices that come from the |soc| SoC but are just routed + down to the carrier board and used there are included in this dtsi. +* *Board.dts* - include the carrier board and module dtsi files. There may also + be some hardware configuration nodes enabled on the carrier board or the + module (i.e. the Board .dts shows the special characteristics of the board + configuration). For example, there are phyCORE-|soc| SOMs which may or may not + have a MIPI DSI to LVDS converter mounted. The converter is enabled (if + available) in the Board .dts and not in the Module .dtsi + +From the root directory of the Linux Kernel our devicetree files for |socfamily| +platforms can be found in ``arch/arm64/boot/dts/freescale/``. + +Device Tree Overlay +................... + +Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder ``arch/arm64/boot/dts/freescale/overlays``. + +Available overlays for |yocto-machinename|.conf are: + +.. code-block:: + + imx8mp-isi-csi1.dtbo + imx8mp-isi-csi2.dtbo + imx8mp-isp-csi1.dtbo + imx8mp-isp-csi2.dtbo + imx8mp-phyboard-pollux-peb-av-010.dtbo + imx8mp-phyboard-pollux-peb-av-012.dtbo + imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + imx8mp-phycore-no-eth.dtbo + imx8mp-phycore-no-rtc.dtbo + imx8mp-phycore-no-spiflash.dtbo + imx8mp-phycore-rpmsg.dtbo + imx8mp-vm016-csi1.dtbo + imx8mp-vm016-csi1-fpdlink.dtbo + imx8mp-vm016-csi2.dtbo + imx8mp-vm016-csi2-fpdlink.dtbo + imx8mp-vm017-csi1.dtbo + imx8mp-vm017-csi1-fpdlink.dtbo + imx8mp-vm017-csi2.dtbo + imx8mp-vm017-csi2-fpdlink.dtbo + +.. hint:: + There is one more overlay available for phyboard-pollux-imx8mp-2.conf: + imx8mp-phyboard-pollux-1552.1.dtbo + +.. _imx8mp-pd22.1.2-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +imx8mp-phyboard-pollux.dtsi: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x49 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x49 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n331` + +.. _imx8mp-pd22.1.2-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +WLAN and Bluetooth on the |sbc| are provided by the PEB-WLBT-05 expansion card. +The PEB-WLBT-05 for |sbc| Quickstart Guide shows you how to install the +PEB-WLBT-05. + +.. tip:: + + With the BSP Version PD22.1 and newer, the PEB-WLBT-05 overlay needs to be activated first, + otherwise the PEB-WLBT-05 won't be recognized. + + .. code-block:: console + + target:~$ vi /boot/bootenv.txt + + Afterwards the bootenv.txt file should look like this (it can also contain other devicetree + overlays!): + + .. code-block:: + + overlays=imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + + The changes will be applied after a reboot: + + .. code-block:: console + + target:~$ reboot + + For further information about devicetree overlays, read the |ref-dt| chapter. + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First set the correct regulatory domain for your country: + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see: + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +Set up the wireless interface: + +.. code-block:: console + + target:~$ ip link + target:~$ ip link set up dev wlan0 + +Now you can scan for available networks: + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection. + +To do so, add the network-credentials to the file ``/etc/wpa_supplicant.conf``: + +.. code-block:: + + country=DE + network={ + ssid="" + proto=WPA2 + psk="" + } + +Now a connection can be established: + +.. code-block:: console + + target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B + +This should result in the following output: + +.. code-block:: + + ... + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section `Changing the Network Configuration` in the |yocto-ref-manual|_. + +First, create the directory: + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +Then add the following configuration snippet in ``/etc/systemd/network/10-wlan0.network``: + +.. code-block:: + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +Now, restart the network daemon so that the configuration takes effect: + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Bluetooth +......... + +Bluetooth is supported on |sbc| with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section. + +Bluetooth is connected to |bluetooth-uart| interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually: + +.. code-block:: console + + target:~$ hciconfig hci0 up + + target:~$ hciconfig -a + + hci0: Type: Primary Bus: UART + BD Address: 00:25:CA:2F:39:96 ACL MTU: 1021:8 SCO MTU: 64:1 + UP RUNNING PSCAN + RX bytes:1392 acl:0 sco:0 events:76 errors:0 + TX bytes:1198 acl:0 sco:0 commands:76 errors:0 + ... + +Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup. + +.. code-block:: console + + target:~$ hcitool scan + Scanning ... + XX:XX:XX:XX:XX:XX + +Visibility +~~~~~~~~~~ + +To activate visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 piscan + +To disable visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 noscan + +Connect +~~~~~~~ + +.. code-block:: console + + target:~$ bluetoothctl + [bluetooth]# discoverable on + Changing discoverable on succeeded + [bluetooth]# pairable on + Changing pairable on succeeded + [bluetooth]# agent on + Agent registered + [bluetooth]# default-agent + Default agent request successful + [bluetooth]# scan on + [NEW] Device XX:XX:XX:XX:XX:XX + [bluetooth]# connect XX:XX:XX:XX:XX:XX + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n367` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n220` + +eMMC Devices +------------ + +PHYTEC modules like phyCORE-|soc| is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw MLC memory cells combined with a memory +controller that handles ECC and wear leveling. They are connected via an SD/MMC +interface to the |soc| and are represented as block devices in the Linux kernel +like SD cards, flash drives, or hard disks. + +The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer's datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard. + +PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1 + +Extended CSD Register +..................... + +eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard. + +In the Linux user space, you can query the registers: + +.. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| + +You will see: + +.. code-block:: + + ============================================= + Extended CSD rev 1.7 (MMC 5.0) + ============================================= + + Card Supported Command sets [S_CMD_SET: 0x01] + [...] + +Enabling Background Operations (BKOPS) +...................................... + +In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +cells. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called **Background +Operations (BKOPS)**. + +By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency. + +The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details. + +Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0): + +* Value 0: The host does not support the manual trigger of BKOPS. Device write + performance suffers. +* Value 1: The host does support the manual trigger of BKOPS. It will issue + BKOPS from time to time when it does not need the device. + +The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details). + +The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)). + +The userspace tool mmc does not currently support enabling automatic BKOPS +features. + +* To check whether *BKOPS_EN* is set, execute: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep BKOPS_EN + + The output will be, for example: + + .. code-block:: + + Enable background operations handshake [BKOPS_EN]: 0x01 + #OR + Enable background operations handshake [BKOPS_EN]: 0x00 + + Where value 0x00 means BKOPS_EN is disabled and device write performance + suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue + background operations from time to time. + +* To set the BKOPS_EN bit, execute: + + .. code-block:: console + :substitutions: + + target:~$ mmc bkops enable /dev/|emmcdev| + +* To ensure that the new setting is taken over and the kernel triggers BKOPS by + itself, shut down the system: + + .. code-block:: console + + target:~$ poweroff + +.. tip:: + + The BKOPS_EN bit is one-time programmable only. It cannot be reversed. + +Reliable Write +.............. + +There are two different Reliable Write options: + +1. Reliable Write option for a whole eMMC device/partition. +2. Reliable Write for single write transactions. + +.. tip:: + + Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT + partition table (see the previous section). + +The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-|soc| SoMs. To check this on the running target: + +.. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep -A 5 WR_REL_SET + Write reliability setting register [WR_REL_SET]: 0x1f + user area: the device protects existing data if a power failure occurs during a write o + peration + partition 1: the device protects existing data if a power failure occurs during a write + operation + partition 2: the device protects existing data if a power failure occurs during a write + operation + partition 3: the device protects existing data if a power failure occurs during a write + operation + partition 4: the device protects existing data if a power failure occurs during a write + operation + -- + Device supports writing EXT_CSD_WR_REL_SET + Device supports the enhanced def. of reliable write + +Otherwise, it can be enabled with the mmc tool: + +.. code-block:: console + + target:~$ mmc --help + + [...] + mmc write_reliability set <-y|-n> + +The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META. + +**Conclusion**: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application. + +Resizing ext4 Root Filesystem +............................. + +When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk. + +* Get the current device size: + + .. code-block:: console + :substitutions: + + target:~$ parted /dev/|emmcdev| print + +* The output looks like this: + + .. code-block:: + :substitutions: + + Model: MMC Q2J55L (sd/mmc) + Disk /dev/|emmcdev|: 7617MB + Sect[ 1799.850385] |emmcdev|: p1 p2 + or size (logical/physical): 512B/512B + Partition Table: msdos + Disk Flags: + + Number Start End Size Type File system Flags + 1 4194kB 72.4MB 68.2MB primary fat16 boot, lba + 2 72.4MB 537MB 465MB primary ext4 + +* Use parted to resize the root partition to the max size of the device: + + .. code-block:: console + :substitutions: + + target:~$ parted /dev/|emmcdev| resizepart 2 100% + Information: You may need to update /etc/fstab. + + target:~$ parted /dev/|emmcdev| print + Model: MMC Q2J55L (sd/mmc) + Disk /dev/|emmcdev|: 7617MB + Sector size (logical/physical): 512[ 1974.191657] |emmcdev|: p1 p2 + B/512B + Partition Table: msdos + Disk Flags: + + Number Start End Size Type File system Flags + 1 4194kB 72.4MB 68.2MB primary fat16 boot, lba + 2 72.4MB 7617MB 7545MB primary ext4 + +Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted. + +* Resize the filesystem to a new partition size: + + .. code-block:: console + :substitutions: + + target:~$ resize2fs /dev/|emmcdev|p2 + resize2fs 1.46.1 (9-Feb-2021) + Filesystem at /dev/|emmcdev|p2 is mounted on /; on-line resizing required + [ 131.609512] EXT4-fs (|emmcdev|p2): resizing filesystem + from 454136 to 7367680 blocks + old_desc_blocks = 4, new_desc_blocks = 57 + [ 131.970278] EXT4-fs (|emmcdev|p2): resized filesystem to 7367680 + The filesystem on /dev/|emmcdev|p2 is now 7367680 (1k) blocks long + +Enable pseudo-SLC Mode +...................... + +eMMC devices use MLC memory cells +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC memory cells used in NAND Flash, MLC memory cells have lower +reliability and a higher error rate at lower costs. + +If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity. + +.. warning:: + + When enabling the enhanced attribute on the device, all data will be lost. + +The following sequence shows how to enable the enhanced attribute. + +* First obtain the current size of the eMMC device with: + + .. code-block:: console + :substitutions: + + target:~$ parted -m /dev/|emmcdev| unit B print + + You will receive: + + .. code-block:: + :substitutions: + + BYT; + /dev/|emmcdev|:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:; + + As you can see this device has 63652757504 Byte = 60704 MiB. + +* To get the maximum size of the device after pseudo-SLC is enabled use: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep ENH_SIZE_MULT -A 1 + + which shows, for example: + + .. code-block:: + + Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + -- + Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000 + i.e. 0 KiB + + Here the maximum size is 3719168 KiB = 3632 MiB. + +* Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by + typing: + + .. code-block:: console + :substitutions: + + target:~$ mmc enh_area set -y 0 3719168 /dev/|emmcdev| + + You will get: + + .. code-block:: + :substitutions: + + Done setting ENH_USR area on /dev/|emmcdev| + setting OTP PARTITION_SETTING_COMPLETED! + Setting OTP PARTITION_SETTING_COMPLETED on /dev/|emmcdev| SUCCESS + Device power cycle needed for settings to take effect. + Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle + +* To ensure that the new setting has taken over, shut down the system: + + .. code-block:: console + + target:~$ poweroff + + and perform a power cycle. It is recommended that you verify the settings now. + +* First, check the value of ENH_SIZE_MULT which must be 3719168 KiB: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep ENH_SIZE_MULT -A 1 + + You should receive:: + + Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + -- + Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + +* Finally, check the size of the device: + + .. code-block:: console + :substitutions: + + target:~$ parted -m /dev/|emmcdev| unit B print + BYT; + /dev/|emmcdev|:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:; + +Erasing the Device +.................. + +It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC memory +cells or mark these blocks as discard. The data on the device is lost and will +be read back as zeros. + +* After booting from SD Card execute: + + .. code-block:: console + :substitutions: + + target:~$ blkdiscard -f --secure /dev/|emmcdev| + + The option --secure ensures that the command waits until the eMMC device has + erased all blocks. The -f (force) option disables all checking before erasing + and it is needed when the eMMC device contains existing partitions with data. + +.. tip:: + .. code-block:: console + :substitutions: + + target:~$ dd if=/dev/zero of=/dev/|emmcdev| conv=fsync + + also destroys all information on the device, but this command is bad for wear + leveling and takes much longer! + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n72` + +GPIOs +----- + +The |sbc| has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to |soc| pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal |soc| GPIO banks GPIO1 – GPIO5. + +The GPIOs are identified as GPIO_ (e.g. GPIO5_07). identifies the GPIO +bank and counts from 1 to 5, while stands for the GPIO within the bank. +is being counted from 0 to 31 (32 GPIOs on each bank). + +By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is: + +.. code-block:: + + Linux GPIO number: = ( - 1) * 32 + + +Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools: + +* Detecting the gpiochips on the chip: + + .. code-block:: console + + target:~$ gpiodetect + gpiochip0 [30200000.gpio] (32 lines) + gpiochip1 [30210000.gpio] (32 lines) + gpiochip2 [30220000.gpio] (32 lines) + gpiochip3 [30230000.gpio] (32 lines) + gpiochip4 [30240000.gpio] (32 lines) + +* Show detailed information about the gpiochips. Like their names, consumers, + direction, active state, and additional flags: + + .. code-block:: console + + target:~$ gpioinfo gpiochip0 + +* Read the value of a GPIO (e.g GPIO 20 from chip0): + + .. code-block:: console + + target:~$ gpioget gpiochip0 20 + +* Set the value of GPIO 20 on chip0 to 0 and exit tool: + + .. code-block:: console + + target:~$ gpioset --mode=exit gpiochip0 20=0 + +* Help text of gpioset shows possible options: + + .. code-block:: console + + target:~$ gpioset --help + Usage: gpioset [OPTIONS] = = ... + Set GPIO line values of a GPIO chip + + Options: + -h, --help: display this message and exit + -v, --version: display the version and exit + -l, --active-low: set the line active state to low + -m, --mode=[exit|wait|time|signal] (defaults to 'exit'): + tell the program what to do after setting values + -s, --sec=SEC: specify the number of seconds to wait (only valid for --mode=time) + -u, --usec=USEC: specify the number of microseconds to wait (only valid for --mode=time) + -b, --background: after setting values: detach from the controlling terminal + + Modes: + exit: set values and exit immediately + wait: set values and wait for user to press ENTER + time: set values and sleep for a specified amount of time + signal: set values and wait for SIGINT or SIGTERM + + Note: the state of a GPIO line controlled over the character device reverts to default + when the last process referencing the file descriptor representing the device file exits. + This means that it's wrong to run gpioset, have it exit and expect the line to continue + being driven high or low. It may happen if given pin is floating but it must be interpreted + as undefined behavior. + + +.. warning:: + + Some of the user IOs are used for special functions. Before using a user IO, + refer to the schematic or the hardware manual of your board to ensure that it + is not already in use. + +GPIOs via sysfs +............... + +.. warning:: + + Accessing gpios via sysfs is deprecated and we encourage to use libgpiod + instead. + +Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling ``CONFIG_GPIO_SYSFS`` in the kernel +configuration. To make ``CONFIG_GPIO_SYSFS`` visible in menuconfig the option +``CONFIG_EXPERT`` has to be enabled first. + +You can also add this option for example to the defconfig you use in +``arch/arm64/configs/`` in the linux kernel sources. For our NXP based releases, +this could be for example ``imx8_phytec_distro.config``:: + + .. + CONFIG_EXPERT=y + CONFIG_GPIO_SYSFS=y + .. + +Otherwise you can create a new config fragment. This is described in our +`Yocto Reference Manual `_. + +LEDs +---- + +If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using ``/sys/class/leds/`` instead +of ``/sys/class/gpio/``. The maximum brightness of the LEDs can be read from +the ``max_brightness`` file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings. + +Below is a simple example. + +To get all available LEDs, type: + +.. code-block:: console + + target:~$ ls /sys/class/leds + mmc1::@ mmc2::@ user-led1@ user-led2@ user-led3@ + +Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the |sbc|. + +* To toggle the LEDs ON: + + .. code-block:: console + + target:~$ echo 255 > /sys/class/leds/user-led1/brightness + +* To toggle OFF: + + .. code-block:: console + + target:~$ echo 0 > /sys/class/leds/user-led1/brightness + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n216` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n105` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n201` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues. + +.. include:: ../peripherals/eeprom.rsti + +Rescue EEPROM Data +.................. + +The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area. + +.. code-block:: console + + target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 + +.. note:: + + If you deleted both EEPROM spaces, please contact our support! + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n201` + +.. include:: ../../peripherals/rtc.rsti + :end-before: .. rtc_parameter_start_label + +DT representation for I²C RTCs: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n207` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n341` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of imx8mp-phyboard-pollux.dtsi: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n165` + +PCIe +---- + +The phyCORE-|soc| has one Mini-PCIe slot. In general, PCIe autodetects new +devices on the bus. After connecting the device and booting up the system, you +can use the command lspci to see all PCIe devices recognized. + +* Type: + + .. code-block:: console + + target:~$ lspci -v + +* You will receive: + + .. code-block:: + + 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode]) + Flags: bus master, fast devsel, latency 0, IRQ 218 + Memory at 18000000 (64-bit, non-prefetchable) [size=1M] + Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0 + I/O behind bridge: None + Memory behind bridge: 18100000-181fffff [size=1M] + Prefetchable memory behind bridge: None + [virtual] Expansion ROM at 18200000 [disabled] [size=64K] + Capabilities: [40] Power Management version 3 + Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+ + Capabilities: [70] Express Root Port (Slot-), MSI 00 + Capabilities: [100] Advanced Error Reporting + Capabilities: [148] L1 PM Substates + Kernel driver in use: dwc3-haps + + 01:00.0 Network controller: Intel Corporation WiFi Link 5100 + Subsystem: Intel Corporation WiFi Link 5100 AGN + Flags: fast devsel + Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K] + Capabilities: [c8] Power Management version 3 + Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+ + Capabilities: [e0] Express Endpoint, MSI 00 + Capabilities: [100] Advanced Error Reporting + Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e + Kernel modules: iwlwifi + +In this example, the PCIe device is the *Intel Corporation WiFi Link 5100*. + +For PCIe devices, you have to enable the correct driver in the kernel +configuration. This WLAN card, for example, is manufactured by Intel. The +option for the driver, which must be enabled, is named ``CONFIG_IWLWIFI`` and can be +found under *Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimat* in +the kernel configuration. + +* In order to activate the driver, follow the instructions from our + `Yocto Reference Manual `_. + + - The linux-imx is represented by: **virtual/kernel** + +For some devices like the WLAN card, additional binary firmware blobs are +needed. These firmware blobs have to be placed in ``/lib/firmware/`` before the +device can be used. + +* Type: + + .. code-block:: console + + host:~$ scp -r root@192.168.3.11:/lib/firmware + +* For example, if you try to bring up the network interface: + + .. code-block:: console + + target:~$ ip link set up wlp1s0 + +* You will get the following output on the serial console: + + .. code-block:: console + + [ 58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0 + [ 58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0 + [ 58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready + +.. tip:: + + Some PCIe devices, e.g. the Ethernet card, may function properly even if no + firmware blob is loaded from ``/lib/firmware/`` and you received an error message + as shown in the first line of the output above. This is because some + manufacturers provide the firmware as a fallback on the card itself. In this + case, the behavior and output depend strongly on the manufacturer's firmware. + +Device Tree PCIe configuration of imx8mm-phyboard-polis.dtsi: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n277` + +Audio +----- + +Playback devices supported for |sbc| are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals. + +.. note:: + + Using the PEB-AV-10 connector for display output along HDMI as audio output + is not supported. The audio output device must match the video output device. + +To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices: + +.. code-block:: console + + target:~$ aplay -L + +Or type for recording devices: + +.. code-block:: console + + target:~$ arecord -L + +Alsamixer +......... + +To inspect the capabilities of your soundcard, call: + +.. code-block:: console + + target:~$ alsamixer + +You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. "MM" means the feature is muted +(both output, left & right), which can be toggled by hitting **m**. You can also +toggle by hitting '**<**' for left and '**>**' for right output. With the **tab** +key, you can switch between controls for playback and recording. + +ALSA configuration +.................. + +Our BSP comes with a ALSA configuration file ``/etc/asound.conf``. + +The ALSA configuration file can be edited as desired or deleted since it is not +required for ALSA to work properly. + +.. code-block:: console + + target:~$ vi /etc/asound.conf + +To set PEB-AV-10 as output, set *playback.pcm* from "dummy" to "pebav10": + +.. code-block:: + + [...] + + pcm.asymed { + type asym + playback.pcm "pebav10" + capture.pcm "dsnoop" + } + + [...] + +If the sound is not audible change playback devices to the software volume control +playback devices, set *playback.pcm* to the respective softvol playback device either +"softvol_hdmi" or "softvol_pebav10". Use alsamixer controls to vary the volume levels. + +.. code-block:: + + [...] + + pcm.asymed { + type asym + playback.pcm "softvol_hdmi" + capture.pcm "dsnoop" + } + + [...] + +Pulseaudio Configuration +........................ + +For applications using Pulseaudio, check for available sinks: + +.. code-block:: console + + target:~$ pactl list short sinks + 0 alsa_output.platform-snd_dummy.0.stereo-fallback module-alsa-card.c s16le 2ch 44100Hz SUSPENDED + 1 alsa_output.platform-sound-peb-av-10.stereo-fallback module-alsa-card.c s16le 2ch 44100Hz SUSPENDED + +To select PEB-AV-10, type: + +.. code-block:: console + + target:~$ pactl set-default-sink 1 + +Playback +........ + +Run speaker-test to check playback availability: + +.. code-block:: console + + target:~$ speaker-test -c 2 -t wav + +To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds: + +.. code-block:: console + + target:~$ aplay /usr/share/sounds/alsa/* + +To playback other formats like mp3 for example, you can use Gstreamer: + +.. code-block:: console + + target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3 + +Capture +....... + +``arecord`` is a command-line tool for capturing audio streams which use Line In as +the default input source. To select a different audio source you can +use ``alsamixer``. For example, switch on *Right PGA Mixer Mic3R* and *Left PGA Mixer +Mic3R* in order to capture the audio from the microphone input of the +TLV320-Codec using the 3.5mm jack. + +.. code-block:: console + + target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on + target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on + +.. code-block:: console + + target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav + +.. hint:: + + Since playback and capture share hardware interfaces, it is not possible to + use different sampling rates and formats for simultaneous playback and + capture operations. + +Device Tree Audio configuration: +:imx-dt:`overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.10.72_2.2.0-phy18#n57` + +Video +----- + +Videos with Gstreamer +..................... + +The video is installed by default in the BSP: + +.. code-block:: console + + target:~$ gst-launch-1.0 playbin uri=file:///usr/share/phytec-qtdemo/videos/caminandes.webm + +* Or: + +.. code-block:: console + + target:~$ gst-launch-1.0 -v filesrc location= \ + \! qtdemux \! h264parse \! queue \! vpudec \! waylandsink async=false enable-last-sample=false \ + qos=false sync=false + +* Or: + +.. code-block:: console + + target:~$ gplay-1.0 /usr/share/phytec-qtdemo/videos/caminandes.webm + +kmssink Plugin ID Evaluation +............................ + +The kmssink plugin needs a connector ID. To get the connector ID, you can use +the tool modetest. + +.. code-block:: console + + target:~$ modetest -c imx-drm + +The output will show something like: + +.. code-block:: + + Connectors: + id encoder status name size (mm) modes encoders + 35 34 connected LVDS-1 216x135 1 34 + modes: + index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot + #0 1280x800 59.07 1280 1380 1399 1440 800 804 808 823 70000 flags: phsync, pvsync; type: preferred, driver + props: + 1 EDID: + flags: immutable blob + blobs: + + value: + 2 DPMS: + flags: enum + enums: On=0 Standby=1 Suspend=2 Off=3 + value: 0 + 5 link-status: + flags: enum + enums: Good=0 Bad=1 + value: 0 + 6 non-desktop: + flags: immutable range + values: 0 1 + value: 0 + 4 TILE: + flags: immutable blob + blobs: + + value: + +Display +------- + +The |sbc| supports up to 4 different display outputs. Three can be used +simultaneously. The following table shows the required extensions and devicetree +overlays for the different interfaces. + +========= ======================== ====================================== +Interface Expansion devicetree overlay +========= ======================== ====================================== +HDMI |sbc| no overlay needed (enabled by default) +LVDS0 PEB-AV-10 imx8mp-phyboard-pollux-peb-av-010.dtbo + (loaded by default) +LVDS1 |sbc| disabled if PEB-AV-10 overlay is used +MIPI PEB-AV-12 (MIPI to LVDS) imx8mp-phyboard-pollux-peb-av-012.dtbo +========= ======================== ====================================== + +.. note:: + + * HDMI will not work if LVDS1 (onboard) is enabled. + * When changing Weston output, make sure to match the audio output as well. + * LVDS0 (PEB-AV-10) and LVDS1 (onboard)can not be used at the same time. + +HDMI is always enabled in the devicetree. The other interfaces can be enabled +with Device Tree Overlay. + +The default-enabled Interfaces are HDMI and LVDS0 (PEB-AV-010). We support a +10'' edt,etml1010g0dka display for the PEB-AV-10 and PEB-AV-12. + +.. note:: + + The current display driver limits the pixel clock for a display connected to + LVDS to 74.25Mhz (or a divider of it). If this does not fit your display + requirements, please contact Support for further help. + +Weston Configuration +.................... + +In order to get an output from Weston on the correct display, it still needs to +be configured correctly. This will be done at /etc/xdg/weston/weston.ini. + +Single Display +~~~~~~~~~~~~~~ + +In our BSP, the default Weston output is set to HDMI. :: + + [output] + name=HDMI-A-1 + mode=current + +.. include:: /bsp/qt5.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +Device tree description of LVDS-1 and HDMI can be found here: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n255` +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n180` + +The device tree of LVDS-0 on PEB-AV-10 can be found here: +:imx-dt:`overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.10.72_2.2.0-phy18#n132` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +The device tree description of GPIO Fan can be found here: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n26` + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/snvs-power-key.rsti + +NPU +--- + +The |soc| SoC contains a Neural Processing Unit up to 2.3 TOPS as an accelerator +for artificial intelligence operations. Refer to our latest phyCORE-|soc| AI Kit +Guide on the phyCORE-|soc| download section to get information about the +NPU: `L-1015e.A0 phyCORE-i.MX 8M Plus AI Kit Guide +`_ + +NXP Examples for eIQ +.................... + +NXP provides a set of machine learning examples for eIQ using Python3. To add a +pre-configured machine learning package group, add to your local.conf and build +your BSP:: + + IMAGE_INSTALL_append = " packagegroup-imx-ml python3-pip python3-requests opencv" + +This will require about 1GB of additional space on the SD Card. Instructions +on how to install and use the NXP examples can be found at +https://community.nxp.com/t5/Blogs/PyeIQ-3-x-Release-User-Guide/ba-p/1305998. + +.. hint:: + + The installation of the eiq examples with pip3 requires an internet + connection. + +.. note:: + + On some Ubuntu 20.04 hosts, cmake uses the host's Python 3 instead of Python + 3.7 from Yocto when building python3-pybind11. (see + https://community.nxp.com/t5/i-MX-Processors/Yocto-L5-4-70-2-3-0-build-image-failed/m-p/1219619) + + As a workaround edit, the python3-pybind11 recipe by:: + + $ devtool edit-recipe python3-pybind11 + + and add to the file:: + + EXTRA_OECMAKE += "-DPYTHON_EXECUTABLE=${RECIPE_SYSROOT_NATIVE}/usr/bin/python3-native/python3.7" + +.. include:: ../peripherals/isp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +Reading the registers using ``/dev/mem`` will cause the system to hang unless the +*ocotp_root_clk* is enabled. To enable this clock permanent, add to the device +tree: + +.. code-block:: + + &clk { + init-on-array = ; + }; + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti + +.. +---------------------------------------------------------------------------+ +.. BSP EXTENSIONS +.. +---------------------------------------------------------------------------+ + +BSP Extensions +============== + +Chromium +-------- + +Our BSP for the |sbc|-|soc| supports Chromium. You can include it in the +|yocto-imagename| with only a few steps. + +Adding Chromium to Your local.conf +.................................. + +To include Chromium you have to add the following line into your local.conf. You +can find it in /build/conf/local.conf. This adds Chromium to your +next image build. :: + + IMAGE_INSTALL_append = " chromium-ozone-wayland" + +.. note:: + + Compiling Chromium takes a long time. + +Get Chromium Running on the Target +.................................. + +To run Chromium, it needs a few arguments to use the hardware graphics +acceleration:: + + target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox + +If you want to start Chromium via SSH, you must first define the display on +which Chromium will run. For example:: + + target$ DISPLAY=:0 + +After you have defined this, you can start it via virtual terminal on Weston as +shown above. diff --git a/previews/271/_sources/bsp/imx8/imx8mp/pd23.1.0.rst.txt b/previews/271/_sources/bsp/imx8/imx8mp/pd23.1.0.rst.txt new file mode 100644 index 000000000..78a61b416 --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mp/pd23.1.0.rst.txt @@ -0,0 +1,1798 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MP-PD23.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD23.1.0/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp +.. _`static-pdf-dl`: ../../../_static/imx8mp-pd23.1.0.pdf + +.. IMX8(MP) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mp/phycore-imx8mp.c?h=v2022.04_2.2.2-phy5#n149 + + +.. General Substitutions +.. |kit| replace:: **phyCORE-i.MX8M Plus Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Pollux +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |bluetooth-uart| replace:: UART3 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx8mp +.. |kernel-tag| replace:: v5.15.71_2.2.2-phy3 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-defconfig| replace:: phycore-imx8mp_defconfig +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MP +.. |u-boot-tag| replace:: v2022.04_2.2.2-phy5 + + +.. RAUC +.. |rauc-manual| replace:: L-1006e.A5 RAUC Update & Device Management Manual +.. _rauc-manual: https://www.phytec.de/cdocuments/?doc=fgByJg + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-phyboard-pollux-rdk +.. |dt-som| replace:: imx8mp-phycore-som +.. |dtbo-rpmsg| replace:: imx8mp-phycore-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mp-phyboard-pollux-peb-av-010.dtbo + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n50` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`kirkstone` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: kirkstone +.. |yocto-distro| replace:: ampliphy-vendor-xwayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: wic +.. |yocto-machinename| replace:: phyboard-pollux-imx8mp-3 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MP-PD23.1.0 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MP-PD23.1.y +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (kirkstone) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 4.0.13 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n150`. +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. +.. |lvds-display-adapters| replace:: PEB-AV-10 and PEB-AV-012 +.. |weston-hdmi-mode| replace:: current + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Yocto Manual | Kirkstone | ++-----------------------+----------------------+ +| Release Date | 2024/01/10 | ++-----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================ ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================ ========== +|yocto-manifestname| Major 2023/12/12 Released +==================== ================ ================ ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mp-pd23.1.0-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd23.1.0-getting-started: + +Getting Started +=============== + +The |kit| is shipped with a pre-flashed SD card. It contains the +|yocto-imagename| and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +`PHYTEC download server `_. This chapter explains how to flash a BSP +image to SD card and how to start the board. + +There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool ``dd``. An +alternative way is to use PHYTEC's system initialization program called +`partup `_, which makes it especially easy to +format more complex systems. You can get `prebuilt Linux binaries of partup +`__ from its release page. Also read +`partup's README `__ for installation +instructions. + +Get the Image +------------- + +The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using ``dd``, can be downloaded from the `PHYTEC download server +`_. + +Get either the partup package or the WIC image from the download server: + +.. code-block:: console + :substitutions: + + host:~$ wget |link-partup-package| + host:~$ wget |link-image| + +.. note:: + For eMMC, more complex partitioning schemes or even just large images, we + recommend using the partup package, as it is faster in writing than ``dd`` + and allows for a more flexible configuration of the target flash device. + +Write the Image to SD Card +-------------------------- + +.. warning:: + To create your bootable SD card, you must have root privileges on your Linux + host PC. Be very careful when specifying the destination device! All files + on the selected device will be erased immediately without any further query! + + Selecting the wrong device may result in **data loss** and e.g. could erase + your currently running system on your host PC! + +Finding the Correct Device +.......................... + +To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card. + +#. In order to get the correct device name, remove your SD card and + execute: + + .. code-block:: console + + host:~$ lsblk + +#. Now insert your SD card and execute the command again: + + .. code-block:: console + + host:~$ lsblk + +#. Compare the two outputs to find the new device names listed in the second + output. These are the device names of the SD card (device and partitions if + the SD card was formatted). +#. In order to verify the device names being found, execute the command + ``sudo dmesg``. Within the last lines of its output, you should also find the + device names, e.g. ``/dev/sde`` or ``/dev/mmcblk0`` (depending on your + system). + +Alternatively, you may use a graphical program of your choice, like `GNOME Disks +`_ or `KDE Partition Manager +`_, to find the correct device. + +Now that you have the correct device name, e.g. ``/dev/sde``, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. ``/dev/sde1``) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption. + +Unmount all those partitions, e.g.: + +.. code-block:: console + + host:~$ sudo umount /dev/sde1 + host:~$ sudo umount /dev/sde2 + +Now, the SD card is ready to be flashed with an image, using either ``partup``, +``dd`` or ``bmap-tools``. + +Using partup +............ + +Writing to an SD card with partup is done in a single command: + +.. code-block:: console + :substitutions: + + host:~$ sudo partup install |yocto-imagename|-|yocto-machinename|.partup /dev/ + +Make sure to replace with your actual device name found previously. + +Further usage of partup is explained at its `official documentation website +`__. + +.. note:: + *partup* has the advantage of allowing to clear specific raw areas in the + MMC user area, which is used in our provided partup packages to erase any + existing U-Boot environments. This is a known issue *bmaptool* does not + solve, as mentioned below. + + Another key advantage of partup over other flashing tools is that it allows + configuring MMC specific parts, like writing to eMMC boot partitions, without + the need to call multiple other commands when writing. + +Using bmap-tools +................ + +An alternative and also fast way to prepare an SD card is using +`bmap-tools `_. Yocto +automatically creates a block map file (``-.wic.bmap``) for +the WIC image that describes the image content and includes checksums for data +integrity. *bmaptool* is packaged by various Linux distributions. For +Debian-based systems install it by issuing: + +.. code-block:: console + + host:~$ sudo apt install bmap-tools + +Flash a WIC image to SD card by calling: + +.. code-block:: console + :substitutions: + + host:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/ + +Replace with your actual SD card's device name found previously, +and make sure to place the file ``-.wic.bmap`` alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip. + +.. warning:: + *bmaptool* only overwrites the areas of an SD card where image data is + located. This means that a previously written U-Boot environment may still be + available after writing the image. + +Using ``dd`` +............ + +After having unmounted all SD card's partitions, you can create your bootable SD card. + +Some PHYTEC BSPs produce uncompressed images (with filename-extension \*.wic), +and some others produce compressed images (with filename-extension \*.wic.xz). + +To flash an uncompressed images (\*.wic) use command below: + +.. code-block:: console + :substitutions: + + host:~$ sudo dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/ bs=1M conv=fsync status=progress + +Or to flash a compressed images (\*.wic.xz) use that command: + +.. code-block:: console + :substitutions: + + host:~$ xzcat |yocto-imagename|-|yocto-machinename|.wic.xz | sudo dd of=/dev/ bs=1M conv=fsync status=progress + +Again, make sure to replace with your actual device name found +previously. + +The parameter ``conv=fsync`` forces a sync operation on the device before +``dd`` returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter ``status=progress`` will print out +information on how much data is and still has to be copied until it is +finished. + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-pd23.1.0-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-phyboard-pollux-rdk*.dtb**: Kernel device tree file +* **imx8mp-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.wic**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-pd23.1.0-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see |ref-setup-network-host|. + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **eMMC**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load your image via network to RAM: + +* when using dhcp + + .. code-block:: + :substitutions: + + u-boot=> dhcp |yocto-imagename|-|yocto-machinename|.wic + BOOTP broadcast 1 + DHCP client bound to address 192.168.3.1 (1 ms) + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.1 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* when using a static ip address (serverip and ipaddr must be set + additionally). + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Take a compressed or uncompressed image with accompanying block map on the host +and send it with ssh through the network to the eMMC of the target with a +one-line command: + +.. code-block:: console + :substitutions: + + target:~$ scp @192.168.3.10:/srv/tftp/|yocto-imagename|-|yocto-machinename|.wic.* /tmp && bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls /srv/tftp + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +Send the image with the ``bmaptool`` command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ scp /srv/tftp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2" + +Flash eMMC U-Boot image via Network from running U-Boot +....................................................... + +Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB stick +......................... + +Flash eMMC from USB stick in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. + +These steps will show how to update the eMMC via a USB device. Configure the +|ref-bootswitch| to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied WIC image to the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} *.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the |ref-bootswitch| to SD Card. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ ls /mnt + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy /mnt/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + + .. tip:: + + Before this will work, you need to configure the |ref-bootswitch| to + **eMMC**. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see |ref-format-sd|. + +Alternatively, flash a partup package to the SD card, as described in +|ref-getting-started|. This will ensure the full space of the SD card is used. + +Flash eMMC from SD card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. If the + image file is too large use the `Updating eMMC from SD card in + Linux on Target` subsection. + +* Flash an SD card with a working image and create a third ext4 partition. Copy + the WIC image (for example |yocto-imagename|.wic) to this + partition. +* Configure the |ref-bootswitch| to SD Card and insert the SD Card. +* Power on the board and stop in U-Boot. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> ext4load mmc 1:3 ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev to eMMC: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + +* Flash your WIC image (for example |yocto-imagename|.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. + + .. code-block:: + + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the |ref-bootswitch| to eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card. + +* Show your saved partup package or WIC image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.partup + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition) using `partup`_: + + .. code-block:: console + :substitutions: + + target:~$ partup install |yocto-imagename|-|yocto-machinename|.partup /dev/mmcblk2 + + Flashing the partup package has the advantage of using the full capacity of + the eMMC device, adjusting partitions accordingly. + + .. note:: + + Alternatively, ``bmaptool`` may be used instead: + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + + Keep in mind that the root partition does not make use of the full space when + flashing with ``bmaptool``. + +* After a complete write, your board can boot from eMMC. + + .. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to eMMC. + +Flash SPI NOR Flash +------------------- + +The |som| modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set |ref-bootswitch| to **SPI NOR**. The SPI Flash is usually quite small. +The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash populated. Only the +bootloader and the environment can be stored. The kernel, device tree, and file +system are taken from eMMC by default. + +The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with: + +.. code-block:: + + u-boot=> printenv mtdparts + mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none) + +Flash SPI NOR Flash from Network +................................ + +The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-|soc|. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Flash SPI NOR from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI NOR flash needs to be probed: + +.. code-block:: + + u-boot=> sf probe + SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB + +* A specially formatted U-Boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image over tftp, erase and write the + bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + device 0 offset 0x0, size 0x1c0b20 + 1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +Flash SPI NOR from Network in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the image from the host to the target: + + .. code-block:: console + :substitutions: + + host:~$ scp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root + +* Find the number of blocks to erase of the U-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the U-Boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +Flash SPI NOR Flash from SD Card +................................ + +The bootloader on SPI NOR flash can be also flashed with SD Card. + +Flash SPI NOR from SD Card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the first partition + on the SD Card. + +* Before reading and writing are possible, the SPI-NOR flash + needs to be probed: + + .. code-block:: + + u-boot=> sf probe + SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB + +* A specially formatted U-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image from the SD Card, erase and write + the bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +Flash SPI NOR from SD Card in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the first partition + on the SD Card. + +* Mount the SD Card: + + .. code-block:: console + :substitutions: + + target:~$ mount /dev/mmcblk1p1 /mnt + +* Find the number of blocks to erase of the U-Boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp /mnt/imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: |rauc-manual|_. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd23.1.0-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + +.. _imx8mp-pd23.1.0-development-build-uboot: +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + +Starting with PD23.1.0 release, the phyCORE-|soc| SoMs with revision 1549.3 and +newer also support 2GHz RAM timings. These will be enabled for supported boards +automatically, but they can also be enabled or disabled manually. + +Edit the file configs/phycore-|kernel-socname|\_defconfig. +The fixed RAM size with 2GHz timings will be used: + +.. code-block:: kconfig + + CONFIG_TARGET_PHYCORE_IMX8MP=y + CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y + # CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y + # CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y + # CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y + CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y + +Choose the correct RAM size as populated on the board and uncomment the line +for this ram size. When not specifying the +``CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS`` option, the 1.5GHz timings will +be chosen by default. After saving the changes, follow the remaining steps from +|ref-build-uboot|. + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mp-pd23.1.0-format-sd: + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd23.1.0-device-tree: + +Device Tree (DT) +================ + +Introduction +------------ + +The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html) + +*"The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn't need to hard code details of the machine."* + +The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at `devicetree.org `_. + +PHYTEC |soc| BSP Device Tree Concept +------------------------------------ + +The following sections explain some rules PHYTEC has defined on how to set up +device trees for our |soc| SoC-based boards. + +Device Tree Structure +..................... + +* *Module.dtsi* - Module includes all devices mounted on the SoM, such as PMIC + and RAM. +* *Board.dts* - include the module dtsi file. Devices that come from the |soc| + SoC but are just routed down to the carrier board and used there are included + in this dts. +* *Overlay.dtso* - enable/disable features depending on optional hardware that + may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10) + +From the root directory of the Linux Kernel our devicetree files for |socfamily| +platforms can be found in ``arch/arm64/boot/dts/freescale/``. + +Device Tree Overlay +................... + +Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder ``arch/arm64/boot/dts/freescale/overlays``. + +Available overlays for |yocto-machinename|.conf are: + +.. Add overlay files in leaf file + +:: + + imx8mp-isi-csi1.dtbo + imx8mp-isi-csi2.dtbo + imx8mp-isp-csi1.dtbo + imx8mp-isp-csi2.dtbo + imx8mp-phyboard-pollux-peb-av-010.dtbo + imx8mp-phyboard-pollux-peb-av-012.dtbo + imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + imx8mp-phycore-no-eth.dtbo + imx8mp-phycore-no-rtc.dtbo + imx8mp-phycore-no-spiflash.dtbo + imx8mp-phycore-rpmsg.dtbo + imx8mp-vm016-csi1.dtbo + imx8mp-vm016-csi1-fpdlink.dtbo + imx8mp-vm016-csi2.dtbo + imx8mp-vm016-csi2-fpdlink.dtbo + imx8mp-vm017-csi1.dtbo + imx8mp-vm017-csi1-fpdlink.dtbo + imx8mp-vm017-csi2.dtbo + imx8mp-vm017-csi2-fpdlink.dtbo + +.. _imx8mp-pd23.1.0-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x140 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x140 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +The device tree representation for UART1 pinmuxing: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n536` + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti +.. include:: /bsp/peripherals/rs485-fullduplex.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n341` + +.. _imx8mp-pd23.1.0-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +WLAN and Bluetooth on the |sbc| are provided by the PEB-WLBT-05 expansion card. +The PEB-WLBT-05 for |sbc| Quickstart Guide shows you how to install the +PEB-WLBT-05. + +.. tip:: + + With the BSP Version PD22.1 and newer, the PEB-WLBT-05 overlay needs to be activated first, + otherwise the PEB-WLBT-05 won't be recognized. + + .. code-block:: console + + target:~$ vi /boot/bootenv.txt + + Afterwards the bootenv.txt file should look like this (it can also contain other devicetree + overlays!): + + .. code-block:: + + overlays=imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + + The changes will be applied after a reboot: + + .. code-block:: console + + target:~$ reboot + + For further information about devicetree overlays, read the |ref-dt| chapter. + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First set the correct regulatory domain for your country: + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see: + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +Set up the wireless interface: + +.. code-block:: console + + target:~$ ip link + target:~$ ip link set up dev wlan0 + +Now you can scan for available networks: + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection. + +To do so, add the network-credentials to the file ``/etc/wpa_supplicant.conf``: + +.. code-block:: + + country=DE + network={ + ssid="" + proto=WPA2 + psk="" + } + +Now a connection can be established: + +.. code-block:: console + + target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B + +This should result in the following output: + +.. code-block:: + + ... + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section `Changing the Network Configuration` in the |yocto-ref-manual|. + +First, create the directory: + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +Then add the following configuration snippet in ``/etc/systemd/network/10-wlan0.network``: + +.. code-block:: + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +Now, restart the network daemon so that the configuration takes effect: + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Bluetooth +......... + +Bluetooth is supported on |sbc| with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section. + +Bluetooth is connected to |bluetooth-uart| interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually: + +.. code-block:: console + + target:~$ hciconfig hci0 up + + target:~$ hciconfig -a + + hci0: Type: Primary Bus: UART + BD Address: 00:25:CA:2F:39:96 ACL MTU: 1021:8 SCO MTU: 64:1 + UP RUNNING PSCAN + RX bytes:1392 acl:0 sco:0 events:76 errors:0 + TX bytes:1198 acl:0 sco:0 commands:76 errors:0 + ... + +Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup. + +.. code-block:: console + + target:~$ hcitool scan + Scanning ... + XX:XX:XX:XX:XX:XX + +Visibility +~~~~~~~~~~ + +To activate visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 piscan + +To disable visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 noscan + +Connect +~~~~~~~ + +.. code-block:: console + + target:~$ bluetoothctl + [bluetooth]# discoverable on + Changing discoverable on succeeded + [bluetooth]# pairable on + Changing pairable on succeeded + [bluetooth]# agent on + Agent registered + [bluetooth]# default-agent + Default agent request successful + [bluetooth]# scan on + [NEW] Device XX:XX:XX:XX:XX:XX + [bluetooth]# connect XX:XX:XX:XX:XX:XX + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n380` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n223` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n76` + +GPIOs +----- + +The |sbc| has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to |soc| pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal |soc| GPIO banks GPIO1 – GPIO5. + +The GPIOs are identified as GPIO_ (e.g. GPIO5_07). identifies the GPIO +bank and counts from 1 to 5, while stands for the GPIO within the bank. +is being counted from 0 to 31 (32 GPIOs on each bank). + +By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is: + +.. code-block:: + + Linux GPIO number: = ( - 1) * 32 + + +Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools: + +* Detecting the gpiochips on the chip: + + .. code-block:: console + + target:~$ gpiodetect + gpiochip0 [30200000.gpio] (32 lines) + gpiochip1 [30210000.gpio] (32 lines) + gpiochip2 [30220000.gpio] (32 lines) + gpiochip3 [30230000.gpio] (32 lines) + gpiochip4 [30240000.gpio] (32 lines) + +* Show detailed information about the gpiochips. Like their names, consumers, + direction, active state, and additional flags: + + .. code-block:: console + + target:~$ gpioinfo gpiochip0 + +* Read the value of a GPIO (e.g GPIO 20 from chip0): + + .. code-block:: console + + target:~$ gpioget gpiochip0 20 + +* Set the value of GPIO 20 on chip0 to 0 and exit tool: + + .. code-block:: console + + target:~$ gpioset --mode=exit gpiochip0 20=0 + +* Help text of gpioset shows possible options: + + .. code-block:: console + + target:~$ gpioset --help + Usage: gpioset [OPTIONS] = = ... + Set GPIO line values of a GPIO chip + + Options: + -h, --help: display this message and exit + -v, --version: display the version and exit + -l, --active-low: set the line active state to low + -m, --mode=[exit|wait|time|signal] (defaults to 'exit'): + tell the program what to do after setting values + -s, --sec=SEC: specify the number of seconds to wait (only valid for --mode=time) + -u, --usec=USEC: specify the number of microseconds to wait (only valid for --mode=time) + -b, --background: after setting values: detach from the controlling terminal + + Modes: + exit: set values and exit immediately + wait: set values and wait for user to press ENTER + time: set values and sleep for a specified amount of time + signal: set values and wait for SIGINT or SIGTERM + + Note: the state of a GPIO line controlled over the character device reverts to default + when the last process referencing the file descriptor representing the device file exits. + This means that it's wrong to run gpioset, have it exit and expect the line to continue + being driven high or low. It may happen if given pin is floating but it must be interpreted + as undefined behavior. + + +.. warning:: + + Some of the user IOs are used for special functions. Before using a user IO, + refer to the schematic or the hardware manual of your board to ensure that it + is not already in use. + +.. include:: ../peripherals/gpios.rsti + :start-after: .. gpios-via-sysfs-marker + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n229` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n110` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n212` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issue. + +.. include:: ../peripherals/eeprom.rsti + +Rescue EEPROM Data +.................. + +The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area. + +.. code-block:: console + + target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 + +.. note:: + + If you deleted both EEPROM spaces, please contact our support! + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n199` + +.. include:: /bsp/peripherals/rtc.rsti + :end-before: .. rtc_parameter_start_label + +RTC Parameters +.............. + +RTCs have a few abilities which can be read/set with the help of ``hwclock`` +tool. + +* We can check RTC supported features with: + + .. code-block:: console + + target:~$ hwclock --param-get features + The RTC parameter 0x0 is set to 0x11. + + What this value means is encoded in kernel, each set bit translates to: + + .. code-block:: + + #define RTC_FEATURE_ALARM 0 + #define RTC_FEATURE_ALARM_RES_MINUTE 1 + #define RTC_FEATURE_NEED_WEEK_DAY 2 + #define RTC_FEATURE_ALARM_RES_2S 3 + #define RTC_FEATURE_UPDATE_INTERRUPT 4 + #define RTC_FEATURE_CORRECTION 5 + #define RTC_FEATURE_BACKUP_SWITCH_MODE 6 + #define RTC_FEATURE_CNT 7 + +* We can check RTC BSM (Backup Switchover Mode) with: + + .. code-block:: console + + target:~$ hwclock --param-get bsm + The RTC parameter 0x2 is set to 0x1. + +* We can set RTC BSM with: + + .. code-block:: console + + target:~$ hwclock --param-set bsm=0x2 + The RTC parameter 0x2 will be set to 0x2. + + What BSM values mean translates to these values: + + .. code-block:: + + #define RTC_BSM_DISABLED 0 + #define RTC_BSM_DIRECT 1 + #define RTC_BSM_LEVEL 2 + #define RTC_BSM_STANDBY 3 + + .. tip:: + You should set BSM mode to DSM or LSM for RTC to switch to backup power + source when the initial power source is not available. Check **RV-3028** RTC + datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching + Mode) actually mean. + +DT representation for I²C RTCs: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n207` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n351` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n175` + +.. include:: /bsp/peripherals/pcie.rsti + +Device Tree PCIe configuration of |dt-carrierboard|.dts: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n287` + +Audio +----- + +Playback devices supported for |sbc| are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals. + +.. note:: + + Using the PEB-AV-10 connector for display output along HDMI as audio output + is not supported. The audio output device must match the video output device. + +.. include:: /bsp/peripherals/audio.rsti + +Device Tree Audio configuration: +:imx-dt:`overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.15.71_2.2.2-phy3#n58` + +.. include:: /bsp/peripherals/video.rsti + +.. include:: display.rsti + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +Device tree description of LVDS-1 and HDMI can be found here: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n264` +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n191` + +The device tree of LVDS-0 on PEB-AV-10 can be found here: +:imx-dt:`overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.15.71_2.2.2-phy3#n133` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +The device tree description of GPIO Fan can be found here: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n33` + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/snvs-power-key.rsti + +.. include:: ../peripherals/npu.rsti + +.. include:: ../peripherals/isp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti + +.. +---------------------------------------------------------------------------+ +.. BSP EXTENSIONS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/bsp-extensions.rsti diff --git a/previews/271/_sources/bsp/imx8/imx8mp/pd24.1.0_nxp.rst.txt b/previews/271/_sources/bsp/imx8/imx8mp/pd24.1.0_nxp.rst.txt new file mode 100644 index 000000000..66d5067f9 --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mp/pd24.1.0_nxp.rst.txt @@ -0,0 +1,589 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MP-PD24.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/ +.. |link-bsp-images| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp +.. _`static-pdf-dl`: ../../../_static/imx8mp-pd24.1.0_nxp.pdf + +.. IMX8(MP) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mp/phycore-imx8mp.c?h=v2024.04-2.0.0-phy7#n177 + + +.. General Substitutions +.. |doc-id| replace:: PD24.1.0 NXP +.. |kit| replace:: **phyCORE-i.MX8M Plus Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Pollux +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |bluetooth-uart| replace:: UART3 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx8_phytec_defconfig +.. |kernel-recipe-path| replace:: meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb +.. |kernel-repo-name| replace:: linux-phytec-imx +.. |kernel-repo-url| replace:: https://github.com/phytec/linux-phytec-imx +.. |kernel-socname| replace:: imx8mp +.. |kernel-tag| replace:: v6.6.23-2.0.0-phy10 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-defconfig| replace:: phycore-imx8mp_defconfig +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx +.. |emmcdev-uboot| replace:: mmc 2 +.. |sdcarddev-uboot| replace:: mmc 1 + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MP +.. |u-boot-tag| replace:: v2024.04_2.0.0-phy7 + + +.. RAUC +.. |rauc-manual| replace:: L-1006e.A6 RAUC Update & Device Management Manual +.. _rauc-manual: https://www.phytec.de/cdocuments/?doc=F4DiM + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-phyboard-pollux-rdk +.. |dt-som| replace:: imx8mp-phycore-som +.. |dtbo-rpmsg| replace:: conf-imx8mp-phycore-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mp-phyboard-pollux-peb-av-10.dtbo + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: :linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L50` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`scarthgap` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: scarthgap +.. |yocto-distro| replace:: ampliphy-vendor-xwayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: rootfs.wic.xz +.. |yocto-machinename| replace:: phyboard-pollux-imx8mp-3 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MP-PD24.1.0 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MP-PD24.1.y +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (scarthgap) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 5.0.x +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L179`. +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` +.. |lvds-display-adapters| replace:: PEB-AV-10 +.. |weston-hdmi-mode| replace:: preferred + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |doc-id| |soc| BSP | | +| Manual | | ++-----------------------+----------------------+ +| Document Title | |doc-id| |soc| BSP | +| | Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Article Number | |doc-id| | ++-----------------------+----------------------+ +| Yocto Manual | Scarthgap | ++-----------------------+----------------------+ +| Release Date | 2024/11/08 | ++-----------------------+----------------------+ +| Is Branch of | |doc-id| |soc| BSP | +| | Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +============================== ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +============================== ================ ================= ========== +BSP-Yocto-NXP-i.MX8MP-PD24.1.0 Major 2024/11/06 Released +============================== ================ ================= ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mp-pd24.1.0_nxp-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.0_nxp-getting-started: +.. include:: /bsp/getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-pd24.1.0_nxp-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **fitImage**: Linux kernel FIT image +* **fitImage-its\*.its** +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-phyboard-pollux-rdk*.dtb**: Kernel device tree file +* **imx8mp-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.rootfs.wic.xz**: compressed SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-pd24.1.0_nxp-bootswitch: +.. include:: bootmode-switch.rsti + +.. include:: ../installing-os.rsti + +.. include:: ../efi.rsti +.. include:: /bsp/installing-distro-efi.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.0_nxp-development: + +Development +=========== + +Starting with this release, the boot behaviour in U-Boot changes. Before, kernel +and device tree came as separate blobs. Now, both will be included in a single +FIT image blob. Further, the logic for booting the PHYTEC ampliphy distributions +is moved to a boot script which itself is part of a separate FIT image blob. +To revert to the old style of booting, you may do + +.. code-block:: console + + run legacyboot + +.. note:: + + This way of booting is deprecated and will be removed in the next release. + By default, booting via this command will return an error as kernel and + device tree are missing in the boot partition. + +.. include:: ../../imx-common/development/standalone_build_preface.rsti +.. _imx8mp-pd24.1.0_nxp-development-build-uboot: +.. include:: ../../imx-common/development/standalone_build_u-boot_binman.rsti +.. include:: development/uboot-standalone-fixed-ram-config.rsti +.. include:: ../development/kernel-standalone.rsti +.. include:: ../../imx-common/development/uuu.rsti + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx8/development/netboot.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mp-pd24.1.0_nxp-format-sd: + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. include:: /bsp/imx8/development/legacy_boot_deprecated.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.0_nxp-device-tree: +.. include:: /bsp/device-tree.rsti + +.. code-block:: + :substitutions: + + imx8mp-isi-csi1.dtbo + imx8mp-isi-csi2.dtbo + imx8mp-isp-csi1.dtbo + imx8mp-isp-csi2.dtbo + |dtbo-peb-av-10| + imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + imx8mp-phycore-no-eth.dtbo + imx8mp-phycore-no-rtc.dtbo + imx8mp-phycore-no-spiflash.dtbo + imx8mp-phycore-rpmsg.dtbo + imx8mp-vm016-csi1.dtbo + imx8mp-vm016-csi1-fpdlink.dtbo + imx8mp-vm016-csi2.dtbo + imx8mp-vm016-csi2-fpdlink.dtbo + imx8mp-vm017-csi1.dtbo + imx8mp-vm017-csi1-fpdlink.dtbo + imx8mp-vm017-csi2.dtbo + imx8mp-vm017-csi2-fpdlink.dtbo + +.. _imx8mp-pd24.1.0_nxp-ubootexternalenv: +.. include:: ../../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x140 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x140 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +The device tree representation for UART1 pinmuxing: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L373` + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti +.. include:: /bsp/peripherals/rs485-fullduplex.rsti + +The device tree representation for RS232 and RS485: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L412` + +.. _imx8mp-pd24.1.0_nxp-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + +.. include:: wireless-network.rsti + +.. include:: ../../peripherals/wireless-network.rsti + :end-before: .. bluetooth_chapter_start_label + +Bluetooth is supported on |sbc| with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section. + +.. include:: ../../peripherals/wireless-network.rsti + :start-after: .. bluetooth_chapter_start_label + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L422` + +DT configuration for the eMMC interface can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L214` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L76` + +.. include:: ../peripherals/gpios.rsti + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L255` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L113` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L239` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues. + +.. note:: + + If you deleted reserved EEPROM spaces, please contact our support! + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L201` + +.. include:: ../../peripherals/rtc.rsti + +DT representation for I²C RTCs: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L208` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L380` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L203` + +.. include:: /bsp/peripherals/pcie.rsti + +Device Tree PCIe configuration of |dt-carrierboard|.dts: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L345` + +Audio +----- + +Playback devices supported for |sbc| are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals. + +.. note:: + + Using the PEB-AV-10 connector for display output along HDMI as audio output + is not supported. The audio output device must match the video output device. + +.. include:: /bsp/peripherals/audio.rsti + +Device Tree Audio configuration: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L58` + +.. include:: /bsp/peripherals/video.rsti + +.. include:: display.rsti + :end-before: .. supported-display-interfaces-marker-start + +The |sbc| supports up to 3 different display outputs. Two can be used +simultaneously. The following table shows the required extensions and devicetree +overlays for the different interfaces. + +========= ======================== ====================================== +Interface Expansion devicetree overlay +========= ======================== ====================================== +HDMI |sbc| no overlay needed (enabled by default) +LVDS0 PEB-AV-10 |dtbo-peb-av-10| + (loaded by default) +LVDS1 |sbc| disabled if PEB-AV-10 overlay is used +========= ======================== ====================================== + +.. include:: display.rsti + :start-after: .. supported-display-interfaces-marker-end + :end-before: .. no-peb-av-12-marker + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +Device tree description of LVDS-1 and HDMI can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L294` +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L218` + +The device tree of LVDS-0 on PEB-AV-10 can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L133` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +The device tree description of GPIO Fan can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L35` + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/snvs-power-key.rsti + +.. include:: ../peripherals/npu.rsti + +.. include:: ../peripherals/isp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti diff --git a/previews/271/_sources/bsp/imx8/imx8mp/pd24.1.1.rst.txt b/previews/271/_sources/bsp/imx8/imx8mp/pd24.1.1.rst.txt new file mode 100644 index 000000000..ea542a479 --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mp/pd24.1.1.rst.txt @@ -0,0 +1,1556 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: none +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp +.. _`static-pdf-dl`: ../../../_static/imx8mp-pd24.1.1.pdf + + +.. General Substitutions +.. |doc-id| replace:: PD24.1.1 +.. |kit| replace:: **phyCORE-i.MX8M Plus Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Pollux +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: defconfig +.. |kernel-recipe-path| replace:: recipes-kernel/linux/linux-phytec_*.bb +.. |kernel-repo-name| replace:: linux-phytec +.. |kernel-repo-url| replace:: https://github.com/phytec/linux-phytec.git +.. |kernel-socname| replace:: imx8mp +.. |kernel-tag| replace:: v6.6.21-phy1 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-defconfig| replace:: phycore-imx8mp_defconfig +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-phytec_*.bb +.. |u-boot-repo-name| replace:: u-boot-phytec +.. |u-boot-repo-url| replace:: https://github.com/phytec/u-boot-phytec.git + + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MP +.. |u-boot-tag| replace:: v2024.01-phy3 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-phyboard-pollux-rdk +.. |dt-som| replace:: imx8mp-phycore-som +.. |dtbo-rpmsg| replace:: imx8mp-phycore-rpmsg.dtbo + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L41 + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`scarthgap` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: scarthgap +.. |yocto-distro| replace:: ampliphy-xwayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: rootfs.wic +.. |yocto-machinename| replace:: phyboard-pollux-imx8mp-3 +.. |yocto-manifestname| replace:: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (scarthgap) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 4.3 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L106 +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |doc-id| |soc| BSP | | +| Manual | | ++-----------------------+----------------------+ +| Document Title | |doc-id| |soc| BSP | +| | Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Article Number | |doc-id| | ++-----------------------+----------------------+ +| Yocto Manual | Scarthgap | ++-----------------------+----------------------+ +| Release Date | 2024/04/08 | ++-----------------------+----------------------+ +| Is Branch of | |doc-id| |soc| BSP | +| | Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +================ ================ ================= ============== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +================ ================ ================= ============== +PD24.1.1 Major 2024/04/08 Released +================ ================ ================= ============== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mp-pd24.1.1-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.1-getting-started: + +Getting Started +=============== + +The |kit| is shipped with a pre-flashed SD card. It contains the +|yocto-imagename| and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +`PHYTEC download server `_. This chapter explains how to flash a BSP +image to SD card and how to start the board. + +There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool ``dd``. An +alternative way is to use PHYTEC's system initialization program called +`partup `_, which makes it especially easy to +format more complex systems. You can get `prebuilt Linux binaries of partup +`__ from its release page. Also read +`partup's README `__ for installation +instructions. + +Get the Image +------------- + +The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using ``dd``, can be downloaded from the `PHYTEC download server +`_. + +Get either the partup package or the WIC image from the download server: + +.. code-block:: console + :substitutions: + + host:~$ wget |link-partup-package| + host:~$ wget |link-image| + +.. note:: + For eMMC, more complex partitioning schemes or even just large images, we + recommend using the partup package, as it is faster in writing than ``dd`` + and allows for a more flexible configuration of the target flash device. + +Write the Image to SD Card +-------------------------- + +.. warning:: + To create your bootable SD card, you must have root privileges on your Linux + host PC. Be very careful when specifying the destination device! All files + on the selected device will be erased immediately without any further query! + + Selecting the wrong device may result in **data loss** and e.g. could erase + your currently running system on your host PC! + +Finding the Correct Device +.......................... + +To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card. + +#. In order to get the correct device name, remove your SD card and + execute: + + .. code-block:: console + + host:~$ lsblk + +#. Now insert your SD card and execute the command again: + + .. code-block:: console + + host:~$ lsblk + +#. Compare the two outputs to find the new device names listed in the second + output. These are the device names of the SD card (device and partitions if + the SD card was formatted). +#. In order to verify the device names being found, execute the command + ``sudo dmesg``. Within the last lines of its output, you should also find the + device names, e.g. ``/dev/sde`` or ``/dev/mmcblk0`` (depending on your + system). + +Alternatively, you may use a graphical program of your choice, like `GNOME Disks +`_ or `KDE Partition Manager +`_, to find the correct device. + +Now that you have the correct device name, e.g. ``/dev/sde``, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. ``/dev/sde1``) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption. + +Unmount all those partitions, e.g.: + +.. code-block:: console + + host:~$ sudo umount /dev/sde1 + host:~$ sudo umount /dev/sde2 + +Now, the SD card is ready to be flashed with an image, using either ``partup``, +``dd`` or ``bmap-tools``. + +Using bmap-tools +................ + +One way to prepare an SD card is using +`bmap-tools `_. Yocto +automatically creates a block map file (``-.wic.bmap``) for +the WIC image that describes the image content and includes checksums for data +integrity. *bmaptool* is packaged by various Linux distributions. For +Debian-based systems install it by issuing: + +.. code-block:: console + + host:~$ sudo apt install bmap-tools + +Flash a WIC image to SD card by calling: + +.. code-block:: console + :substitutions: + + host:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/ + +Replace with your actual SD card's device name found previously, +and make sure to place the file ``-.wic.bmap`` alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip. + +.. warning:: + *bmaptool* only overwrites the areas of an SD card where image data is + located. This means that a previously written U-Boot environment may still be + available after writing the image. + +Using partup +............ + +Writing to an SD card with partup is done in a single command: + +.. code-block:: console + :substitutions: + + host:~$ sudo partup install |yocto-imagename|-|yocto-machinename|.rootfs.partup /dev/ + +Make sure to replace with your actual device name found previously. + +Further usage of partup is explained at its `official documentation website +`__. + +.. warning:: + Host systems which are using resize2fs version 1.46.6 and older + (e.g. Ubuntu 22.04) are not able to write partup packages created with Yocto Mickledore + or newer to SD-Card. This is due to a new default option in resize2fs which causes an + incompatibility. See `release notes `_. + +.. note:: + *partup* has the advantage of allowing to clear specific raw areas in the + MMC user area, which is used in our provided partup packages to erase any + existing U-Boot environments. This is a known issue *bmaptool* does not + solve, as mentioned in the previous chapter. + + Another key advantage of partup over other flashing tools is that it allows + configuring MMC specific parts, like writing to eMMC boot partitions, without + the need to call multiple other commands when writing. + +Using ``dd`` +............ + +After having unmounted all SD card's partitions, you can create your bootable SD card. + +Some PHYTEC BSPs produce uncompressed images (with filename-extension \*.wic), +and some others produce compressed images (with filename-extension \*.wic.xz). + +To flash an uncompressed images (\*.wic) use command below: + +.. code-block:: console + :substitutions: + + host:~$ sudo dd if=|yocto-imagename|-|yocto-machinename|.|yocto-imageext| of=/dev/ bs=1M conv=fsync status=progress + +Or to flash a compressed images (\*.wic.xz) use that command: + +.. code-block:: console + :substitutions: + + host:~$ xzcat |yocto-imagename|-|yocto-machinename|.|yocto-imageext|.xz | sudo dd of=/dev/ bs=1M conv=fsync status=progress + +Again, make sure to replace with your actual device name found +previously. + +The parameter ``conv=fsync`` forces a sync operation on the device before +``dd`` returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter ``status=progress`` will print out +information on how much data is and still has to be copied until it is +finished. + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-pd24.1.1-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_1d_dmem_202006.bin, + lpddr4_pmu_train_1d_imem_202006.bin, + lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-phyboard-pollux-rdk*.dtb**: Kernel device tree file +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.wic**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-pd24.1.1-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **eMMC**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +* Load your image via network to RAM: + + .. code-block:: + :substitutions: + + u-boot=> dhcp ${loadaddr} |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + BOOTP broadcast 1 + DHCP client bound to address 192.168.3.11 (101 ms) + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename '|yocto-imagename|-|yocto-machinename|.|yocto-imageext|'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* Write the image to the eMMC: + + .. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Take a compressed or uncompressed image on the host and send it with ssh through +the network (then uncompress it, if necessary) to the eMMC of the target with a +one-line command: + +.. code-block:: console + :substitutions: + + target:~$ ssh @192.168.3.10 "dd if=/|yocto-imagename|-|yocto-machinename|.|yocto-imageext|" | dd of=/dev/mmcblk2 conv=fsync + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + +Send the image with the ``dd`` command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ dd if=|yocto-imagename|-|yocto-machinename|.|yocto-imageext| status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2 conv=fsync" + +Flash eMMC U-Boot image via Network from running U-Boot +....................................................... + +Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> dhcp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB +................... + +Flash eMMC from USB in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. note:: + + Only the lower USB-A port is configured for storage devices and only + this port will work when trying to access a storage device in U-Boot. + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. + +These steps will show how to update the eMMC via a USB device. Configure the +|ref-bootswitch| to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied WIC image to the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} *.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.\ |yocto-imageext|). Set the |ref-bootswitch| to SD Card. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ cd /mnt + target:~$ ls + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2boot0; mmcblk2boot1) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.|yocto-imageext| of=/dev/mmcblk2 conv=fsync + +* After a complete write, your board can boot from eMMC. + + .. tip:: + + Before this will work, you need to configure the |ref-bootswitch| to + **eMMC**. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see |ref-format-sd|. + +Alternatively, flash a partup package to the SD card, as described in +|ref-getting-started|. This will ensure the full space of the SD card is used. + +Flash eMMC from SD card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. If the + image file is too large use the `Updating eMMC from SD card in + Linux on Target` subsection. + +* Flash an SD card with a working image and create a third FAT partition. Copy + the WIC image (for example |yocto-imagename|.\ |yocto-imageext|) to this + partition. +* Configure the |ref-bootswitch| to SD Card and insert the SD Card. +* Power on the board and stop in U-Boot. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> fatload mmc 1:3 ${loadaddr} |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev to eMMC: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + +* Flash your WIC image (for example |yocto-imagename|.\ |yocto-imageext|) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. + + .. code-block:: + + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the |ref-bootswitch| to eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card. + +* Show your saved partup package or WIC image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.rootfs.partup + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2\ **boot0**; mmcblk2\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition) using `partup`_: + + .. code-block:: console + :substitutions: + + target:~$ partup install |yocto-imagename|-|yocto-machinename|.rootfs.partup /dev/mmcblk2 + + Flashing the partup package has the advantage of using the full capacity of + the eMMC device, adjusting partitions accordingly. + + .. note:: + + Alternatively, ``dd`` may be used instead: + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.|yocto-imageext| of=/dev/mmcblk2 conv=fsync + + Keep in mind that the root partition does not make use of the full space when + flashing with ``dd``. + +* After a complete write, your board can boot from eMMC. + + .. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to eMMC. + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A6 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.1-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti + +Booting the Kernel from a Network +--------------------------------- + +Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device. + +Place Images on Host for Netboot +................................ + +* Copy the kernel image to your tftp directory: + + .. code-block:: console + + host:~$ cp Image /srv/tftp + +* Copy the devicetree to your tftp directory: + + .. code-block:: console + + host:~$ cp oftree /srv/tftp + +* Make sure other users have read access to all the files in the tftp directory, + otherwise they are not accessible from the target: + + .. code-block:: console + + host:~$ sudo chmod -R o+r /srv/tftp + +* Extract the rootfs to your nfs directory: + + .. code-block:: console + :substitutions: + + host:~$ sudo tar -xvzf |yocto-imagename|-|yocto-machinename|.rootfs.tar.gz -C /srv/nfs + +.. note:: + Make sure you extract with sudo to preserve the correct ownership. + +Booting from an Embedded Board +.............................. + +Boot the board into the U-boot prompt and press any key to hold. + +* To boot from a network, call: + + .. code-block:: console + + u-boot=> run netboot + + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.\ |yocto-imageext| + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + :end-before: .. get-sdk-marker + +Build the SDK +............. + +You can build the SDK yourself with Yocto: + +* Move to the Yocto build directory: + + .. code-block:: console + :substitutions: + + host:~$ source sources/poky/oe-init-build-env + host:~$ bitbake -c populate_sdk |yocto-imagename| # or another image + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + :start-after: .. install-sdk-marker + +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + :end-before: .. build-uboot-fixed-ram-size-marker +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti +.. include:: /bsp/imx8/development/upstream_manifest.rsti +Format SD-Card +-------------- + +Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted. + +Gparted +....... + +* Get GParted: + + .. code-block:: console + + host:~$ sudo apt install gparted + +* Insert the SD Card into your host and get the device name: + + .. code-block:: console + + host:~$ dmesg | tail + ... + [30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB) + [30436.179846] sdb: sdb1 sdb2 + ... + +* Unmount all SD Card partitions. +* Launch GParted: + + .. code-block:: console + + host:~$ sudo gparted + +.. image:: /bsp/imx-common/images/gparted1.png + +Expand rootfs +~~~~~~~~~~~~~ + +.. warning:: + Running gparted on host systems which are using resize2fs version 1.46.6 and older + (e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto + Mickledore and newer. + This is due to a new default option in resize2fs which causes a incompatibility. + See `release notes `_. + +* Choose your SD Card device at the drop-down menu on the top right +* Choose the ext4 root partition and click on resize: + +.. image:: /bsp/imx-common/images/gparted5.png +.. image:: /bsp/imx-common/images/gparted2.png + +* Drag the slider as far as you like or enter the size manually. + +.. image:: /bsp/imx-common/images/gparted3.png + +* Confirm your entry by clicking on the "Change size" button. + +.. image:: /bsp/imx-common/images/gparted4.png + +* To apply your changes, press the green tick. +* Now you can mount the root partition and copy e.g. the + |yocto-imagename|-|yocto-machinename|.\ |yocto-imageext| image to it. Then unmount it again: + + .. code-block:: console + :substitutions: + + host:~$ sudo cp |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /mnt/ ; sync + host:~$ umount /mnt + +Create the Third Partition +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Choose your SD Card device at the drop-down menu on the top right + +.. image:: /bsp/imx-common/images/gparted1.png + +* Choose the bigger unallocated area and press "New": + +.. image:: /bsp/imx-common/images/gparted6.png + +* Click "Add" + +.. image:: /bsp/imx-common/images/gparted7.png + +* Confirm your changes by pressing the green tick. + +.. image:: /bsp/imx-common/images/gparted8.png + +* Now you can mount the new partition and copy e.g. + |yocto-imagename|-|yocto-machinename|.\ |yocto-imageext| image to it. Then unmount it again: + + .. code-block:: console + :substitutions: + + host:~$ sudo mount /dev/sde3 /mnt + host:~$ sudo cp |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /mnt/ ; sync + host:~$ umount /mnt + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.1-device-tree: +.. include:: /bsp/device-tree.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x140 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x140 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +The device tree representation for UART1 pinmuxing: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L387` + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti + +The device tree representation for RS232 and RS485: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L251` + +.. _imx8mp-pd24.1.1-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + :end-before: .. u-boot-network-environment-marker + +U-boot network-environment +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* We currently use dynamic IP addresses in U-Boot. This is enabled by this variable: + + .. code-block:: + + u-boot=> printenv ip_dyn + ip_dyn=yes + +* Set up path for NFS. A modification could look like this: + + .. code-block:: + + u-boot=> setenv nfsroot /home/user/nfssrc + +Please note that these modifications will only affect the bootloader settings. + +.. include:: /bsp/imx-common/peripherals/network.rsti + :start-after: .. kernel-network-environment-marker + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L261` + +DT configuration for the eMMC interface can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L181` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + :end-before: .. peripherals-spi-nor-flash-marker + +The definition of the SPI master node in the device tree can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L67` + +.. include:: ../peripherals/gpios.rsti + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L160` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L81` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L145` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues. + +.. note:: + + If you deleted reserved EEPROM spaces, please contact our support! + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L169` + +RTC +--- + +RTCs can be accessed via ``/dev/rtc*``. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file. + +* To find the name of the RTC device, you can read its sysfs entry with: + + .. code-block:: console + + target:~$ cat /sys/class/rtc/rtc*/name + +* You will get, for example: + + .. code-block:: + + rtc-rv3028 0-0052 + snvs_rtc 30370000.snvs:snvs-rtc-lp + +.. tip:: + + This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device + IDs based on the device tree/aliases entries if present. + +Date and time can be manipulated with the ``hwclock`` tool and the date command. +To show the current date and time set on the target: + +.. code-block:: console + + target:~$ date + Thu Jan 1 00:01:26 UTC 1970 + +Change the date and time with the date command. The date command sets the time +with the following syntax "YYYY-MM-DD hh:mm:ss (+|-)hh:mm": + +.. code-block:: console + + target:~$ date -s "2022-03-02 11:15:00 +0100" + Wed Mar 2 10:15:00 UTC 2022 + +.. note:: + + Your timezone (in this example +0100) may vary. + +Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the ``hwclock`` command. Write the current date and time (set +with the date command) to the RTC using the ``hwclock`` tool and reboot the +target to check if the changes were applied to the RTC: + +.. code-block:: console + + target:~$ hwclock -w + target:~$ reboot + . + . + . + target:~$ date + Wed Mar 2 10:34:06 UTC 2022 + +To set the time and date from the RTC use: + +.. code-block:: console + + target:~$ date + Thu Jan 1 01:00:02 UTC 1970 + target:~$ hwclock -s + target:~$ date + Wed Mar 2 10:45:01 UTC 2022 + +.. include:: ../../peripherals/rtc.rsti + :start-after: .. rtc_parameter_start_label + +DT representation for I²C RTCs: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L175` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L220` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L130` + +Video +----- + +Videos with Gstreamer +..................... + +One example video is installed by default in the BSP at `/usr/share/qtphy/videos/`. +Start the video playback with one of these commands: + +.. code-block:: console + + target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink fullscreen=true + +* Or: + +.. code-block:: console + + target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink + +.. note:: + The mainline BSP currently only supports software rendering. + +Display +------- + +The |sbc| supports LVDS output via the LVDS1 connector on the carrier board. The +LVDS interface is enabled by default. + +Weston Configuration +.................... + +Weston will work without any additional configuration. Configuration options are +done at /etc/xdg/weston/weston.ini. + +Device tree description of LVDS can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L182` + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +.. note:: + We noticed some visible backlight flickering on brightness level 1 (probably + due to frequency problems with the hardware). + +Power Management +---------------- + +CPU Core Frequency Scaling +.......................... + +The CPU in the |soc| SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as 'Dynamic Voltage and +Frequency Scaling' (DVFS). The |soc| BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the |socfamily| +variant used, several different frequencies are supported. + +.. tip:: + + Although the DVFS framework provides frequency settings for each CPU core, a + change in the frequency settings of one CPU core always affects all other CPU + cores too. So all CPU cores always share the same DVFS setting. An individual + DVFS setting for each core is not possible. + + +* To get a complete list type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies + + In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately + 1,6 GHz, the result will be: + + .. code-block:: + + 1200000 1600000 + +* To ask for the current frequency type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq + +So-called governors are automatically selecting one of these frequencies in +accordance with their goals. + +* List all governors available with the following command: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors + + The result will be: + + .. code-block:: + + ondemand userspace performance schedutil + +* **ondemand** (default) switches between possible CPU core frequencies in + reference to the current system load. When the system load increases above a + specific limit, it increases the CPU core frequency immediately. +* **performance** always selects the highest possible CPU core frequency. +* **userspace** allows the user or userspace program running as root to set a + specific frequency (e.g. to 1600000). Type: + +* In order to ask for the current governor, type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor + + You will normally get: + + .. code-block:: + + schedutil + +* Switching over to another governor (e.g. userspace) is done with: + + .. code-block:: console + + target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor + +* Now you can set the speed: + + .. code-block:: console + + target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed + +For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +``Documentation/admin-guide/pm/cpufreq.rst``. + +CPU Core Management +................... + +The |soc| SoC can have multiple processor cores on the die. The |soc|, for +example, has 4 ARM Cores which can be turned on and off individually at runtime. + +* To see all available cores in the system, execute: + + .. code-block:: console + + target:~$ ls /sys/devices/system/cpu -1 + +* This will show, for example: + + .. code-block:: + + cpu0 cpu1 cpu2 cpu3 cpufreq + [...] + + Here the system has four processor cores. By default, all available cores in the + system are enabled to get maximum performance. + +* To switch off a single-core, execute: + + .. code-block:: console + + target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online + + As confirmation, you will see: + + .. code-block:: + + [ 110.505012] psci: CPU3 killed + + Now the core is powered down and no more processes are scheduled on this core. + +* You can use top to see a graphical overview of the cores and processes: + + .. code-block:: console + + target:~$ htop + +* To power up the core again, execute: + + .. code-block:: console + + target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online + +.. include:: ../peripherals/tm.rsti + :end-before: .. tm-gpio-fan-marker + +.. include:: /bsp/peripherals/watchdog.rsti + +snvs Power Key +-------------- + +The X_ONOFF pin connected to the ON/OFF button can be pressed long to trigger +Power OFF without SW intervention. With the *snvs_pwrkey* driver, the KEY_POWER +event is also reported to userspace when the button is pressed. On default, systemd +is configured to ignore such events. The function of Power OFF without SW +intervention are not configured. Triggering a power off with systemd when pushing +the ON/OFF button can be configured under ``/etc/systemd/logind.conf`` and set using: + +.. code-block:: + + HandlePowerKey=poweroff + +.. include:: ../peripherals/ocotp-ctrl.rsti diff --git a/previews/271/_sources/bsp/imx8/imx8mp/pd24.1.2.rst.txt b/previews/271/_sources/bsp/imx8/imx8mp/pd24.1.2.rst.txt new file mode 100644 index 000000000..1fad85de4 --- /dev/null +++ b/previews/271/_sources/bsp/imx8/imx8mp/pd24.1.2.rst.txt @@ -0,0 +1,1343 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp +.. _`static-pdf-dl`: ../../../_static/imx8mp-pd24.1.2.pdf + + +.. General Substitutions +.. |doc-id| replace:: PD24.1.2 +.. |kit| replace:: **phyCORE-i.MX8M Plus Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Pollux +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: defconfig +.. |kernel-recipe-path| replace:: recipes-kernel/linux/linux-phytec_*.bb +.. |kernel-repo-name| replace:: linux-phytec +.. |kernel-repo-url| replace:: https://github.com/phytec/linux-phytec.git +.. |kernel-socname| replace:: imx8mp +.. |kernel-tag| replace:: v6.6.21-phy1 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-defconfig| replace:: phycore-imx8mp_defconfig +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-phytec_*.bb +.. |u-boot-repo-name| replace:: u-boot-phytec +.. |u-boot-repo-url| replace:: https://github.com/phytec/u-boot-phytec.git + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MP +.. |u-boot-tag| replace:: v2024.01-phy4 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-phyboard-pollux-rdk +.. |dt-som| replace:: imx8mp-phycore-som + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L41 + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`scarthgap` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: scarthgap +.. |yocto-distro| replace:: ampliphy-xwayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: rootfs.wic.xz +.. |yocto-machinename| replace:: phyboard-pollux-imx8mp-3 +.. |yocto-manifestname| replace:: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (scarthgap) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-a-core| replace:: cortexa53-crypto +.. |yocto-sdk-rev| replace:: 5.0.1 + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L106 +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |doc-id| |soc| BSP | | +| Manual | | ++-----------------------+----------------------+ +| Document Title | |doc-id| |soc| BSP | +| | Mainline Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Article Number | |doc-id| | ++-----------------------+----------------------+ +| Yocto Manual | Scarthgap | ++-----------------------+----------------------+ +| Release Date | 2024/06/26 | ++-----------------------+----------------------+ +| Is Branch of | |doc-id| |soc| BSP | +| | Mainline Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +===================== ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +===================== ================ ================= ========== +|yocto-manifestname| Minor 2024/06/26 Released +===================== ================ ================= ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mp-pd24.1.2-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.2-getting-started: + +.. include:: ../../getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-pd24.1.2-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_1d_dmem_202006.bin, + lpddr4_pmu_train_1d_imem_202006.bin, + lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-phyboard-pollux-rdk*.dtb**: Kernel device tree file +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.wic.xz**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see |ref-setup-network-host|. + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-pd24.1.2-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **eMMC**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +.. tip:: + + This step only works if the size of the image file is less than 1,28GB due to + limited RAM space available in the Bootloader. + +* Uncompress your image: + +.. code-block:: console + :substitutions: + + host:~$ unxz /srv/tftp/phytec-headless-image-|yocto-machinename|.rootfs.wic.xz + +* Load your image via network to RAM: + + .. code-block:: + :substitutions: + + u-boot=> dhcp ${loadaddr} phytec-headless-image-|yocto-machinename|.rootfs.wic + BOOTP broadcast 1 + DHCP client bound to address 192.168.3.11 (101 ms) + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename 'phytec-headless-image-|yocto-machinename|.rootfs.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* Write the image to the eMMC: + + .. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Take a compressed or decompressed image with the accompanying block map file +`*.bmap` on the host and send it with `ssh` through the network to the eMMC of +the target with a one-line command: + +.. code-block:: console + :substitutions: + + target:~$ scp @192.168.3.10:/srv/tftp/|yocto-imagename|-|yocto-machinename|.rootfs.wic.* /tmp && bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls /srv/tftp + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + |yocto-imagename|-|yocto-machinename|.rootfs.wic.bmap + +Send the image with the ``bmaptool`` command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ scp /srv/tftp/|yocto-imagename|-|yocto-machinename|.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2" + +Flash eMMC U-Boot image via Network from running U-Boot +....................................................... + +Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> dhcp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB stick +......................... + +Flash eMMC from USB stick in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. note:: + + Only the lower USB-A port is configured for storage devices and only + this port will work when trying to access a storage device in U-Boot. + +.. tip:: + + This step only works if the size of the image file is less than 1,28GB due to + limited RAM space available in the Bootloader. + +These steps will show how to update the eMMC via a USB device. Configure the +|ref-bootswitch| to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied uncompressed WIC image to +the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + :substitutions: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} phytec-headless-image-|yocto-machinename|.rootfs.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.\ |yocto-imageext|). Set the |ref-bootswitch| to SD Card. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ ls /mnt + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + |yocto-imagename|-|yocto-machinename|.rootfs.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy /mnt/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + + .. tip:: + + Before this will work, you need to configure the |ref-bootswitch| to + **eMMC**. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see |ref-format-sd|. + +Alternatively, flash a partup package to the SD card, as described in +|ref-getting-started|. This will ensure the full space of the SD card is used. + +Flash eMMC from SD card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1,28GB due to + limited RAM space available in the Bootloader. + + +* Flash an SD card with a working image and create a third ext4 partition. Copy + the WIC image (for example |yocto-imagename|.rootfs.wic) to this partition. +* Configure the |ref-bootswitch| to SD Card and insert the SD Card. +* Power on the board and stop in U-Boot. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-|yocto-machinename|.rootfs.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev to eMMC: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + +* Flash your WIC image (for example |yocto-imagename|.roots.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. + + .. code-block:: + + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the |ref-bootswitch| to eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card. + +* Show your saved partup package or WIC image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.rootfs.partup + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + |yocto-imagename|-|yocto-machinename|.rootfs.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition) using `partup`_: + + .. code-block:: console + :substitutions: + + target:~$ partup install |yocto-imagename|-|yocto-machinename|.rootfs.partup /dev/mmcblk2 + + Flashing the partup package has the advantage of using the full capacity of + the eMMC device, adjusting partitions accordingly. + + .. note:: + + Alternatively, ``bmaptool`` may be used instead: + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + + Keep in mind that the root partition does not make use of the full space when + flashing with ``bmaptool``. + +* After a complete write, your board can boot from eMMC. + + .. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to eMMC. + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A6 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.2-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti + +Booting the Kernel from a Network +--------------------------------- + +Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device. + +Place Images on Host for Netboot +................................ + +* Copy the kernel image to your tftp directory: + + .. code-block:: console + + host:~$ cp Image /srv/tftp + +* Copy the devicetree to your tftp directory: + + .. code-block:: console + + host:~$ cp oftree /srv/tftp + +* Make sure other users have read access to all the files in the tftp directory, + otherwise they are not accessible from the target: + + .. code-block:: console + + host:~$ sudo chmod -R o+r /srv/tftp + +* Extract the rootfs to your nfs directory: + + .. code-block:: console + :substitutions: + + host:~$ sudo tar -xvzf |yocto-imagename|-|yocto-machinename|.rootfs.tar.gz -C /srv/nfs + +.. note:: + Make sure you extract with sudo to preserve the correct ownership. + +Booting from an Embedded Board +.............................. + +Boot the board into the U-boot prompt and press any key to hold. + +* To boot from a network, call: + + .. code-block:: console + + u-boot=> run netboot + + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.rootfs.wic + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.rootfs.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + +.. _imx8mp-pd24.1.2-development-build-uboot: +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + +.. include:: development/uboot-standalone-fixed-ram-config.rsti + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mp-pd24.1.2-format-sd: + +Format SD-Card +-------------- + +Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted. + +Gparted +....... + +* Get GParted: + + .. code-block:: console + + host:~$ sudo apt install gparted + +* Insert the SD Card into your host and get the device name: + + .. code-block:: console + + host:~$ dmesg | tail + ... + [30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB) + [30436.179846] sdb: sdb1 sdb2 + ... + +* Unmount all SD Card partitions. +* Launch GParted: + + .. code-block:: console + + host:~$ sudo gparted + +.. image:: /bsp/imx-common/images/gparted1.png + +Expand rootfs +~~~~~~~~~~~~~ + +.. warning:: + Running gparted on host systems which are using resize2fs version 1.46.6 and older + (e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto + Mickledore and newer. + This is due to a new default option in resize2fs which causes a incompatibility. + See `release notes `_. + +* Choose your SD Card device at the drop-down menu on the top right +* Choose the ext4 root partition and click on resize: + +.. image:: /bsp/imx-common/images/gparted5.png +.. image:: /bsp/imx-common/images/gparted2.png + +* Drag the slider as far as you like or enter the size manually. + +.. image:: /bsp/imx-common/images/gparted3.png + +* Confirm your entry by clicking on the "Change size" button. + +.. image:: /bsp/imx-common/images/gparted4.png + +* To apply your changes, press the green tick. +* Now you can mount the root partition and copy e.g. the + |yocto-imagename|-|yocto-machinename|.\ |yocto-imageext| image to it. Then unmount it again: + + .. code-block:: console + :substitutions: + + host:~$ sudo cp |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /mnt/ ; sync + host:~$ umount /mnt + +Create the Third Partition +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Choose your SD Card device at the drop-down menu on the top right + +.. image:: /bsp/imx-common/images/gparted1.png + +* Choose the bigger unallocated area and press "New": + +.. image:: /bsp/imx-common/images/gparted6.png + +* Click "Add" + +.. image:: /bsp/imx-common/images/gparted7.png + +* Confirm your changes by pressing the green tick. + +.. image:: /bsp/imx-common/images/gparted8.png + +* Now you can mount the new partition and copy e.g. + |yocto-imagename|-|yocto-machinename|.\ |yocto-imageext| image to it. Then unmount it again: + + .. code-block:: console + :substitutions: + + host:~$ sudo mount /dev/sde3 /mnt + host:~$ sudo cp |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /mnt/ ; sync + host:~$ umount /mnt + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.2-device-tree: +.. include:: /bsp/device-tree.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x140 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x140 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +The device tree representation for UART1 pinmuxing: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L387` + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti +.. include:: /bsp/peripherals/rs485-fullduplex.rsti + +The device tree representation for RS232 and RS485: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L251` + +.. _imx8mp-pd24.1.2-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + :end-before: .. u-boot-network-environment-marker + +U-boot network-environment +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* We currently use dynamic IP addresses in U-Boot. This is enabled by this variable: + + .. code-block:: + + u-boot=> printenv ip_dyn + ip_dyn=yes + +* Set up path for NFS. A modification could look like this: + + .. code-block:: + + u-boot=> setenv nfsroot /home/user/nfssrc + +Please note that these modifications will only affect the bootloader settings. + +.. include:: /bsp/imx-common/peripherals/network.rsti + :start-after: .. kernel-network-environment-marker + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:linux-phytec:`/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L261` + +DT configuration for the eMMC interface can be found here: +:linux-phytec:`/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L181` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + :end-before: .. peripherals-spi-nor-flash-marker + +The definition of the SPI master node in the device tree can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L67` + +.. include:: ../peripherals/gpios.rsti + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L160` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L81` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L145` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues. + +.. note:: + + If you deleted reserved EEPROM spaces, please contact our support! + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L169` + +RTC +--- + +RTCs can be accessed via ``/dev/rtc*``. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file. + +* To find the name of the RTC device, you can read its sysfs entry with: + + .. code-block:: console + + target:~$ cat /sys/class/rtc/rtc*/name + +* You will get, for example: + + .. code-block:: + + rtc-rv3028 0-0052 + snvs_rtc 30370000.snvs:snvs-rtc-lp + +.. tip:: + + This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device + IDs based on the device tree/aliases entries if present. + +Date and time can be manipulated with the ``hwclock`` tool and the date command. +To show the current date and time set on the target: + +.. code-block:: console + + target:~$ date + Thu Jan 1 00:01:26 UTC 1970 + +Change the date and time with the date command. The date command sets the time +with the following syntax "YYYY-MM-DD hh:mm:ss (+|-)hh:mm": + +.. code-block:: console + + target:~$ date -s "2022-03-02 11:15:00 +0100" + Wed Mar 2 10:15:00 UTC 2022 + +.. note:: + + Your timezone (in this example +0100) may vary. + +Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the ``hwclock`` command. Write the current date and time (set +with the date command) to the RTC using the ``hwclock`` tool and reboot the +target to check if the changes were applied to the RTC: + +.. code-block:: console + + target:~$ hwclock -w + target:~$ reboot + . + . + . + target:~$ date + Wed Mar 2 10:34:06 UTC 2022 + +To set the time and date from the RTC use: + +.. code-block:: console + + target:~$ date + Thu Jan 1 01:00:02 UTC 1970 + target:~$ hwclock -s + target:~$ date + Wed Mar 2 10:45:01 UTC 2022 + +.. include:: ../../peripherals/rtc.rsti + :start-after: .. rtc_parameter_start_label + +DT representation for I²C RTCs: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L175` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L220` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L130` + +Video +----- + +Videos with Gstreamer +..................... + +One example video is installed by default in the BSP at `/usr/share/qtphy/videos/`. +Start the video playback with one of these commands: + +.. code-block:: console + + target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink fullscreen=true + +* Or: + +.. code-block:: console + + target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink + +.. note:: + The mainline BSP currently only supports software rendering. + +Display +------- + +The |sbc| supports LVDS output via the LVDS1 connector on the carrier board. The +LVDS interface is enabled by default. + +Weston Configuration +.................... + +Weston will work without any additional configuration. Configuration options are +done at /etc/xdg/weston/weston.ini. + +Device tree description of LVDS can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L182` + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +.. note:: + We noticed some visible backlight flickering on brightness level 1 (probably + due to frequency problems with the hardware). + +Power Management +---------------- + +CPU Core Frequency Scaling +.......................... + +The CPU in the |soc| SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as 'Dynamic Voltage and +Frequency Scaling' (DVFS). The |soc| BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the |socfamily| +variant used, several different frequencies are supported. + +.. tip:: + + Although the DVFS framework provides frequency settings for each CPU core, a + change in the frequency settings of one CPU core always affects all other CPU + cores too. So all CPU cores always share the same DVFS setting. An individual + DVFS setting for each core is not possible. + + +* To get a complete list type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies + + In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately + 1,6 GHz, the result will be: + + .. code-block:: + + 1200000 1600000 + +* To ask for the current frequency type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq + +So-called governors are automatically selecting one of these frequencies in +accordance with their goals. + +* List all governors available with the following command: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors + + The result will be: + + .. code-block:: + + ondemand userspace performance schedutil + +* **ondemand** (default) switches between possible CPU core frequencies in + reference to the current system load. When the system load increases above a + specific limit, it increases the CPU core frequency immediately. +* **performance** always selects the highest possible CPU core frequency. +* **userspace** allows the user or userspace program running as root to set a + specific frequency (e.g. to 1600000). Type: + +* In order to ask for the current governor, type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor + + You will normally get: + + .. code-block:: + + schedutil + +* Switching over to another governor (e.g. userspace) is done with: + + .. code-block:: console + + target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor + +* Now you can set the speed: + + .. code-block:: console + + target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed + +For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +``Documentation/admin-guide/pm/cpufreq.rst``. + +CPU Core Management +................... + +The |soc| SoC can have multiple processor cores on the die. The |soc|, for +example, has 4 ARM Cores which can be turned on and off individually at runtime. + +* To see all available cores in the system, execute: + + .. code-block:: console + + target:~$ ls /sys/devices/system/cpu -1 + +* This will show, for example: + + .. code-block:: + + cpu0 cpu1 cpu2 cpu3 cpufreq + [...] + + Here the system has four processor cores. By default, all available cores in the + system are enabled to get maximum performance. + +* To switch off a single-core, execute: + + .. code-block:: console + + target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online + + As confirmation, you will see: + + .. code-block:: + + [ 110.505012] psci: CPU3 killed + + Now the core is powered down and no more processes are scheduled on this core. + +* You can use top to see a graphical overview of the cores and processes: + + .. code-block:: console + + target:~$ htop + +* To power up the core again, execute: + + .. code-block:: console + + target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online + +.. include:: ../peripherals/tm.rsti + :end-before: .. tm-gpio-fan-marker + +.. include:: /bsp/peripherals/watchdog.rsti + +snvs Power Key +-------------- + +The X_ONOFF pin connected to the ON/OFF button can be pressed long to trigger +Power OFF without SW intervention. With the *snvs_pwrkey* driver, the KEY_POWER +event is also reported to userspace when the button is pressed. On default, systemd +is configured to ignore such events. The function of Power OFF without SW +intervention are not configured. Triggering a power off with systemd when pushing +the ON/OFF button can be configured under ``/etc/systemd/logind.conf`` and set using: + +.. code-block:: + + HandlePowerKey=poweroff + +.. include:: ../peripherals/ocotp-ctrl.rsti diff --git a/previews/271/_sources/bsp/imx9/imx9.rst.txt b/previews/271/_sources/bsp/imx9/imx9.rst.txt new file mode 100644 index 000000000..41577c72d --- /dev/null +++ b/previews/271/_sources/bsp/imx9/imx9.rst.txt @@ -0,0 +1,9 @@ +============== +i.MX 9 Manuals +============== + +.. toctree:: + :caption: i.MX 9 Manuals + :maxdepth: 2 + + i.MX 93 Manuals diff --git a/previews/271/_sources/bsp/imx9/imx93/imx93.rst.txt b/previews/271/_sources/bsp/imx9/imx93/imx93.rst.txt new file mode 100644 index 000000000..4a869bd41 --- /dev/null +++ b/previews/271/_sources/bsp/imx9/imx93/imx93.rst.txt @@ -0,0 +1,34 @@ +==================== +i.MX 93 Manuals +==================== + +BSP-Yocto-NXP-i.MX93-PD24.2.0 +============================= + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd24.2.0 + +BSP-Yocto-NXP-i.MX93-PD24.1.1 +============================= + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd24.1.1 + +BSP-Yocto-NXP-i.MX93-PD24.1.0 +============================= + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd24.1.0 + diff --git a/previews/271/_sources/bsp/imx9/imx93/pd24.1.0.rst.txt b/previews/271/_sources/bsp/imx9/imx93/pd24.1.0.rst.txt new file mode 100644 index 000000000..d0e32f88a --- /dev/null +++ b/previews/271/_sources/bsp/imx9/imx93/pd24.1.0.rst.txt @@ -0,0 +1,841 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX93-PD24.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-91-93/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/sdk/ampliphy-vendor-wayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools/ +.. _`static-pdf-dl`: ../../../_static/imx93-pd24.1.0.pdf + +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx93 + +.. General Substitutions +.. |kit| replace:: **phyBOARD-Segin i.MX 93 Kit** +.. |kit-ram-size| replace:: 1GiB +.. |sbc| replace:: phyBOARD-Segin i.MX 93 +.. |soc| replace:: i.MX 93 +.. |socfamily| replace:: i.MX 9 +.. |som| replace:: phyCORE-i.MX93 +.. |debug-uart| replace:: ttyLP0 +.. |expansion-connector| replace:: X16 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx9_phytec_distro.config imx9_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx93 +.. |kernel-tag| replace:: v6.1.36_2.1.0-phy1 +.. |emmcdev| replace:: mmcblk0 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 0 +.. |u-boot-defconfig| replace:: phycore-imx93_defconfig +.. |u-boot-multiple-defconfig-note| replace:: In command above replace ```` with ``phycore-imx93_defconfig``. +.. |u-boot-multiple-dtb-note| replace:: In command above replace ```` with ``imx93-phyboard-segin.dtb``. +.. |u-boot-imx-mkimage-tag| replace:: lf-6.1.36_2.1.0 +.. |u-boot-soc-name| replace:: iMX9 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + + +.. IMX93 specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX93 +.. |u-boot-tag| replace:: v2023.04_2.1.0-phy1 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx93-phyboard-segin +.. |dt-som| replace:: imx93-phycore-som +.. |dtbo-rpmsg| replace:: imx93-phycore-rpmsg.dtso + +.. IMX93 specific +.. |dt-somnetwork| replace:: :imx-dt:`imx93-phycore-som.dtsi?h=v6.1.36_2.1.0-phy1#n61` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`mickledore` +.. |yocto-bsp-name| replace:: BSP-Yocto-i.MX93 +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: mickledore +.. |yocto-distro| replace:: ampliphy-vendor-wayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: wic.xz +.. |yocto-machinename| replace:: phyboard-segin-imx93-2 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX93-PD24.1.0 +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (mickledore) ` +.. |yocto-sdk-rev| replace:: 4.2.2 +.. |yocto-sdk-a-core| replace:: cortexa55 + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: serial connector on PEB-EVAL-01 +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X8 (USB micro/OTG connector) ` + + +.. IMX93 specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :imx-dt:`imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n114`. + +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M33 Core +.. |ref-m-core-connections| replace:: :ref:`X16 ` +.. |mcore-jtag-dev| replace:: MIMX8MM6_M4 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Yocto Manual | Mickledore | ++-----------------------+----------------------+ +| Release Date | 2024/01/31 | ++-----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================ ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================ ========== +|yocto-manifestname| Major 2024/01/31 Released +==================== ================ ================ ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname|, see `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware. + +.. _imx93-pd24.1.0-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx93-pd24.1.0-getting-started: +.. include:: /bsp/getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target (|ref-debugusbconnector|) and the host with **serial + cable** +* Power up the board +* Open serial port with 115200 baud and 8N1 (you should see u-boot/linux start on the console + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx93-pd24.1.0-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx93.bin**: ARM Trusted Firmware binary +* **lpddr4_dmem_1d_v202201.bin, lpddr4_dmem_2d_v202201.bin, + lpddr4_imem_1d_v202201.bin, + lpddr4_imem_2d_v202201.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx93-phyboard-segin.dtb**: Kernel device tree file +* **imx93-phy\*.dtbo**: Kernel device tree overlay files +* **phytec-\*.tar.gz**: Root file system, + of bitbake-image that was built. + + * **phytec-qt6demo-image-phyboard-segin-imx93-2.tar.gz**: when bitbake-build + was processed for ``phytec-qt6demo-image`` + * **phytec-headless-image-phyboard-segin-imx93-2.tar.gz**: when bitbake-build + was processed for ``phytec-headless-image`` +* **phytec-\*.wic.xz**: Compressed bootable SD + card image of bitbake-image that was built. Includes bootloader, DTBs, Kernel + and Root file system. + + * **phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz**: when bitbake-build + was processed for ``phytec-qt6demo-image`` + * **phytec-headless-image-phyboard-segin-imx93-2.wic.xz**: when bitbake-build + was processed for ``phytec-headless-image`` +* **imx93-11x11-evk_m33_\*.bin**, binaries of demo applications for the + Cortex-M33 MCU; can be manually loaded and started with U-Boot or Linux + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1472.5 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx93-pd24.1.0-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **eMMC**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If |emmcdev|\p1 + and mmcblk1p1 have an identical UUID, the setup is affected. + +Flash eMMC from SD Card +....................... + +If there is no network available, you can update the eMMC from SD card. For +that, you only need a ready-to-use image file (``*.wic``) located on the +SD card. Because the image file is quite large, you have to enlarge your SD card +to use its full space (if it was not enlarged before). To enlarge your SD card, +see Resizing ext4 Root Filesystem. + +Alternatively, flash a partup package to the SD card, as described in +|ref-getting-started|. This will ensure the full space of the SD card is used. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can flash the eMMC on Linux. You only need a partup package or WIC image +saved on the SD card. + +* Show your saved partup package or WIC image or WIC.XZ image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.partup + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + +* Show list of available MMC devices: + + .. code-block:: console + :substitutions: + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + |emmcdev| + |emmcdev|boot0 + |emmcdev|boot1 + |emmcdev|p1 + |emmcdev|p2 + |emmcdev|rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (|emmcdev|\ **boot0**; |emmcdev|\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (/dev/|emmcdev| **without** + partition) using `partup`_: + + .. code-block:: console + :substitutions: + + target:~$ partup install |yocto-imagename|-|yocto-machinename|.partup /dev/|emmcdev| + + .. tip:: + + **Using partup is highly recommended since it is easier to use and has the + advantage of using the full capacity of the eMMC device, adjusting + partitions accordingly.** + + .. note:: + + Alternatively, ``dd`` may be used instead. + + For uncompressed WIC images (\*.wic): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/|emmcdev| bs=1M conv=fsync status=progress + + For compressed WIC images (\*.wic.xz): + + .. code-block:: console + :substitutions: + + target:~$ zstdcat |yocto-imagename|-|yocto-machinename|.wic.xz | sudo dd of=/dev/|emmcdev| bs=1M conv=fsync status=progress + + Keep in mind that the root partition does not make use of the full space + when flashing with ``dd``. + +* After a complete write, your board can boot from eMMC. + + .. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to eMMC. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +.. note:: + + Some PHYTECs BSPs produce compressed ``.wic.xz`` images. In this case, the + compressed image must first be uncompressed. + + .. code-block:: console + :substitutions: + + host:~$ unxz phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Take an uncompressed image on the host and send it with ssh through +the network to the eMMC of the target with a one-line command: + +.. code-block:: console + :substitutions: + + target:~$ ssh @192.168.3.10 "dd if=/|yocto-imagename|-|yocto-machinename|.wic" | dd of=/dev/|emmcdev| bs=1M conv=fsync status=progress + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +Send the image with the ``dd`` command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic bs=1M status=progress | ssh root@192.168.3.11 "dd of=/dev/|emmcdev| conv=fsync" + +Flash eMMC U-Boot image via Network from running U-Boot +....................................................... + +Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 0 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB +................... + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the |ref-bootswitch| to SD Card. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ cd /mnt + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + :substitutions: + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + |emmcdev| + |emmcdev|boot0 + |emmcdev|boot1 + |emmcdev|p1 + |emmcdev|p2 + |emmcdev|rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (|emmcdev|\ **boot0**; |emmcdev|\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (/dev/|emmcdev| without partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/|emmcdev| bs=1M conv=fsync status=progress + +* After a complete write, your board can boot from eMMC. + + .. tip:: + + Before this will work, you need to configure the |ref-bootswitch| to + **eMMC**. + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A5 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx93-pd24.1.0-development: + +Development +=========== + +.. include:: ../../imx-common/development/host_network_setup.rsti +.. include:: ../../imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: ../../imx-common/development/standalone_build_preface.rsti +.. include:: ../../imx-common/development/standalone_build_u-boot_imxmkimage.rsti +.. include:: ../../imx-common/development/standalone_build_kernel.rsti + +.. include:: ../../imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx93-pd24.1.0-device-tree: +.. include:: /bsp/device-tree.rsti + +:: + + imx93-phyboard-segin-peb-av-02.dtbo + imx93-phyboard-segin-peb-eval-01.dtbo + imx93-phycore-rpmsg.dtbo + +.. _imx93-pd24.1.0-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX93_PAD_UART1_RXD__LPUART1_RX 0x31e + MX93_PAD_UART1_TXD__LPUART1_TX 0x30e + >; + }; + +The first part of the string MX93_PAD_UART1_RXD__LPUART1_RX names the pad +(in this example UART1_RXD). The second part of the string (LPUART1_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal pull up is +activated. + +The device tree representation for UART1 pinmuxing: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n267` + +.. _imx93-pd24.1.0-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A 100 megabit Ethernet is provided by our +module and board. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n216` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx93-phycore-som.dtsi?h=v6.1.36_2.1.0-phy1#n195` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/gpios.rsti + +.. include:: ../peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx93-phyboard-segin-peb-eval-01.dtso?h=v6.1.36_2.1.0-phy1#n33` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx93-phycore-som.dtsi?h=v6.1.36_2.1.0-phy1#n88` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n155` + + +EEPROM +------ + +There are two different I2C EEPROM flashes populated on |som| SoM and on the +|sbc|. For now only the one on the |som| is enabled, and it is used for board +detection. + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file can be found in our PHYTEC git: +:imx-dt:`imx93-phycore-som.dtsi?h=v6.1.36_2.1.0-phy1#n173` + +.. include:: ../../peripherals/rtc.rsti + +DT representation for I²C RTCs: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n173` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 480 Mbps (HighSpeed +'HS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host, but on the |sbc| +one of them is used as a host-only port (USB-A connector). + +.. include:: /bsp/peripherals/usb-host.rsti + +The OTG port provides an additional pin for over-current protection, which is +not used on the |sbc|. Since it's not used, the driver part is also disabled +from within the device tree. In case this pin is used, activate this +over-current in the device tree and set the correct polarity (active high/low) +according to the device specification. For the correct setup, please refer to +the Kernel documentation under +Linux/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt. + +DT representation for USB Host: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n190` + +CAN FD +------ + +The |sbc| has one flexCAN interface supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon the Linux network layer. Using +this framework, the CAN interfaces behave like an ordinary Linux network device, +with some additional features special to CAN. More information can be found in +the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n147` + +Audio +----- + +On |sbc| the TI TLV320AIC3007 audio codec is used. It uses I2S for data +transmission and I2C for codec control. The audio signals available are: + +* Stereo LINE IN, +* Stereo LINE OUT, +* Output where D-Class 1W speaker can be connected + +.. include:: /bsp/peripherals/audio.rsti + :end-before: .. audio_alsa_configuration_start_label + +.. include:: /bsp/peripherals/audio.rsti + :start-after: .. audio_playback_start_label + :end-before: .. audio_capture_start_label + +If Speaker volume it too low you can increase its volume with (values 0-3): + +.. code-block:: console + + target:~$ amixer -c 0 sset Class-D 3 + +.. hint:: + + Speaker output is only mono so when stereo track is played only left channel + will be played by speaker. + +Capture +....... + +``arecord`` is a command-line tool for capturing audio streams which use Line In +as the default input source. + +.. code-block:: console + + target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav + +.. hint:: + + Since playback and capture share hardware interfaces, it is not possible to + use different sampling rates and formats for simultaneous playback and + capture operations. + +Device Tree Audio configuration: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n62` + +.. include:: /bsp/peripherals/video.rsti + +.. include:: display.rsti + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +The device tree of PEB-AV-02 can be found here: +:imx-dt:`imx93-phyboard-segin-peb-av-02.dtso?h=v6.1.36_2.1.0-phy1` + +.. include:: peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/bbnsm-power-key.rsti + +.. include:: ../peripherals/pxp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti diff --git a/previews/271/_sources/bsp/imx9/imx93/pd24.1.1.rst.txt b/previews/271/_sources/bsp/imx9/imx93/pd24.1.1.rst.txt new file mode 100644 index 000000000..3f9097290 --- /dev/null +++ b/previews/271/_sources/bsp/imx9/imx93/pd24.1.1.rst.txt @@ -0,0 +1,933 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX93-PD24.1.1 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-91-93/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/sdk/ampliphy-vendor-wayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools/ +.. _`static-pdf-dl`: ../../../_static/imx93-pd24.1.1.pdf + +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx93 + +.. General Substitutions +.. |kit| replace:: **phyBOARD-Segin i.MX 93 and phyBOARD-Nash i.MX 93 Kit** +.. |kit-ram-size| replace:: 1GiB +.. |sbc| replace:: phyBOARD-Segin/Nash i.MX 93 +.. |soc| replace:: i.MX 93 +.. |socfamily| replace:: i.MX 9 +.. |som| replace:: phyCORE-i.MX93 +.. |debug-uart| replace:: ttyLP0 +.. |serial-uart| replace:: ttyLP6 +.. |expansion-connector| replace:: X16 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx9_phytec_distro.config imx9_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx93 +.. |kernel-tag| replace:: v6.1.55_2.2.0-phy3 +.. |emmcdev| replace:: mmcblk0 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 0 +.. |u-boot-defconfig| replace:: imx93-phyboard-segin_defconfig +.. |u-boot-multiple-defconfig-note| replace:: In command above replace ```` with ``imx93-phyboard-segin_defconfig`` or ``imx93-phyboard-nash_defconfig``, depending on the board you are about to build for. +.. |u-boot-multiple-dtb-note| replace:: In command above replace ```` with ``imx93-phyboard-segin.dtb`` or ``imx93-phyboard-nash.dtb``, depending on the board you are about to build for. +.. |u-boot-imx-mkimage-tag| replace:: lf-6.1.55-2.2.0 +.. |u-boot-soc-name| replace:: iMX9 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX93 specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX93 +.. |u-boot-tag| replace:: v2023.04_2.2.0-phy3 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx93-phyboard-segin +.. |dt-som| replace:: imx93-phycore-som +.. |dtbo-rpmsg| replace:: imx93-phycore-rpmsg.dtso + +.. IMX93 specific +.. |dt-somnetwork| replace:: :imx-dt:`imx93-phycore-som.dtsi?h=v6.1.55_2.2.0-phy3#n61` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`mickledore` +.. |yocto-bsp-name| replace:: BSP-Yocto-i.MX93 +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: mickledore +.. |yocto-distro| replace:: ampliphy-vendor-wayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: wic.xz +.. |yocto-machinename| replace:: phyboard-segin-imx93-2 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX93-PD24.1.1 +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (mickledore) ` +.. |yocto-sdk-rev| replace:: 4.2.3 +.. |yocto-sdk-a-core| replace:: cortexa55 + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: UART1 console on PEB-EVAL-01 for **phyBOARD-Segin** and X-37 + USB-C debug for **phyBOARD-Nash** +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X8 (USB micro/OTG connector) ` + + +.. IMX93 specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :imx-dt:`imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n114` or here: + :imx-dt:`imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n83`. + +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M33 Core +.. |ref-m-core-connections| replace:: :ref:`X16 ` +.. |mcore-jtag-dev| replace:: MIMX8MM6_M4 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Yocto Manual | Mickledore | ++-----------------------+----------------------+ +| Release Date | 2024/01/31 | ++-----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================ ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================ ========== +|yocto-manifestname| Minor 2024/05/07 Released +==================== ================ ================ ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname|, see `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware. + +.. tip:: + + **Console examples in this BSP manual only focus on phyBOARD-Segin i.MX 93. + Similar commands can also be executed for/on phyBOARD-Nash i.MX 93** + +.. _imx93-PD24.1.1-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx93-PD24.1.1-getting-started: +.. include:: /bsp/getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the + following position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the targets debug console with your host. Use |ref-debugusbconnector|. +* Power up the board +* Open serial/usb port with 115200 baud and 8N1 (you should see u-boot/linux + start on the console + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx93-PD24.1.1-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx93.bin**: ARM Trusted Firmware binary +* **lpddr4_dmem_1d_v202201.bin, lpddr4_dmem_2d_v202201.bin, + lpddr4_imem_1d_v202201.bin, + lpddr4_imem_2d_v202201.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which + is bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx93-phyboard-*.dtb**: Kernel device tree file +* **imx93-phy\*.dtbo**: Kernel device tree overlay files +* **phytec-\*.tar.gz**: Root file system, + of bitbake-image that was built. + + * **phytec-qt6demo-image-phyboard-*-imx93-*.tar.gz**: when bitbake-build + was processed for ``phytec-qt6demo-image`` + * **phytec-headless-image-phyboard-*-imx93-*.tar.gz**: when bitbake-build + was processed for ``phytec-headless-image`` +* **phytec-\*.wic.xz**: Compressed bootable SD + card image of bitbake-image that was built. Includes bootloader, DTBs, Kernel + and Root file system. + + * **phytec-qt6demo-image-phyboard-*-imx93-*.wic.xz**: when bitbake-build + was processed for ``phytec-qt6demo-image`` + * **phytec-headless-image-phyboard-*-imx93-*.wic.xz**: when bitbake-build + was processed for ``phytec-headless-image`` +* **imx93-11x11-evk_m33_\*.bin**, binaries of demo applications for the + Cortex-M33 MCU; can be manually loaded and started with U-Boot or Linux + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: + + * phyBOARD-Segin-i.MX 93: 1472.5 + * phyBOARD-Nash-i.MX 93: 1616.0 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx93-PD24.1.1-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **eMMC**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If |emmcdev|\p1 + and mmcblk1p1 have an identical UUID, the setup is affected. + +Flash eMMC from SD Card +....................... + +If there is no network available, you can update the eMMC from SD card. For +that, you only need a ready-to-use image file (``*.wic``) located on the +SD card. Because the image file is quite large, you have to enlarge your SD card +to use its full space (if it was not enlarged before). To enlarge your SD card, +see Resizing ext4 Root Filesystem. + +Alternatively, flash a partup package to the SD card, as described in +|ref-getting-started|. This will ensure the full space of the SD card is used. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can flash the eMMC on Linux. You only need a partup package or WIC image +saved on the SD card. + +* Show your saved partup package or WIC image or WIC.XZ image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.partup + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + +* Show list of available MMC devices: + + .. code-block:: console + :substitutions: + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + |emmcdev| + |emmcdev|boot0 + |emmcdev|boot1 + |emmcdev|p1 + |emmcdev|p2 + |emmcdev|rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (|emmcdev|\ **boot0**; |emmcdev|\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (/dev/|emmcdev| **without** + partition) using `partup`_: + + .. code-block:: console + :substitutions: + + target:~$ partup install |yocto-imagename|-|yocto-machinename|.partup /dev/|emmcdev| + + .. tip:: + + **Using partup is highly recommended since it is easier to use and has the + advantage of using the full capacity of the eMMC device, adjusting + partitions accordingly.** + + .. note:: + + Alternatively, ``dd`` may be used instead. + + For uncompressed WIC images (\*.wic): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/|emmcdev| bs=1M conv=fsync status=progress + + For compressed WIC images (\*.wic.xz): + + .. code-block:: console + :substitutions: + + target:~$ zstdcat |yocto-imagename|-|yocto-machinename|.wic.xz | sudo dd of=/dev/|emmcdev| bs=1M conv=fsync status=progress + + Keep in mind that the root partition does not make use of the full space + when flashing with ``dd``. + +* After a complete write, your board can boot from eMMC. + + .. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to eMMC. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +.. note:: + + Some PHYTECs BSPs produce compressed ``.wic.xz`` images. In this case, the + compressed image must first be uncompressed. + + .. code-block:: console + :substitutions: + + host:~$ unxz phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Take an uncompressed image on the host and send it with ssh through +the network to the eMMC of the target with a one-line command: + +.. code-block:: console + :substitutions: + + target:~$ ssh @192.168.3.10 "dd if=/|yocto-imagename|-|yocto-machinename|.wic" | dd of=/dev/|emmcdev| bs=1M conv=fsync status=progress + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +Send the image with the ``dd`` command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic bs=1M status=progress | ssh root@192.168.3.11 "dd of=/dev/|emmcdev| conv=fsync" + +Flash eMMC U-Boot image via Network from running U-Boot +....................................................... + +Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 0 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB +................... + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the |ref-bootswitch| to SD Card. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ cd /mnt + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + :substitutions: + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + |emmcdev| + |emmcdev|boot0 + |emmcdev|boot1 + |emmcdev|p1 + |emmcdev|p2 + |emmcdev|rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (|emmcdev|\ **boot0**; |emmcdev|\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (/dev/|emmcdev| without partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/|emmcdev| bs=1M conv=fsync status=progress + +* After a complete write, your board can boot from eMMC. + + .. tip:: + + Before this will work, you need to configure the |ref-bootswitch| to + **eMMC**. + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A5 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx93-PD24.1.1-development: + +Development +=========== + +.. include:: ../../imx-common/development/host_network_setup.rsti +.. include:: ../../imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: ../../imx-common/development/standalone_build_preface.rsti +.. include:: ../../imx-common/development/standalone_build_u-boot_imxmkimage.rsti +.. include:: ../../imx-common/development/standalone_build_kernel.rsti + +.. include:: ../../imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx93-PD24.1.1-device-tree: +.. include:: /bsp/device-tree.rsti + +:: + + imx93-phyboard-segin-peb-av-02.dtbo + imx93-phyboard-segin-peb-eval-01.dtbo + imx93-phycore-rpmsg.dtbo + imx93-phycore-no-emmc.dtbo + imx93-phycore-no-eth.dtbo + +Available overlays for phyboard-nash-imx93-1.conf are: + +:: + + imx93-phyboard-nash-peb-av-010.dtbo + imx93-phycore-rpmsg.dtbo + imx93-phycore-no-emmc.dtbo + imx93-phycore-no-eth.dtbo + +.. _imx93-PD24.1.1-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX93_PAD_UART1_RXD__LPUART1_RX 0x31e + MX93_PAD_UART1_TXD__LPUART1_TX 0x30e + >; + }; + +The first part of the string MX93_PAD_UART1_RXD__LPUART1_RX names the pad +(in this example UART1_RXD). The second part of the string (LPUART1_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal pull up is +activated. + +The device tree representation for UART1 pinmuxing: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n262` + +.. _imx93-PD24.1.1-network: + +Network +------- + +|sbc| provides two ethernet interfaces. + +* On **phyBOARD-Segin** we have: + + * a 100 megabit Ethernet provided by |som| + * and 100 megabit Ethernet provided by phyBOARD. + +* On **phyBOARD-Nash** we have: + + * a 100 megabit Ethernet provided by |som| + * and 1 gigabit Ethernet provided by phyBOARD. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n216` or here: +:imx-dt:`imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n201` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx93-phycore-som.dtsi?h=v6.1.55_2.2.0-phy3#n194` or here: + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/gpios.rsti + +.. include:: /bsp/peripherals/adc.rsti + +On phyBOARD-Nash the ADC lines are accessible on X16 expansion connector: + +========= ======== +ADC input X16 pin +========= ======== +ADC_IN0 47 +ADC_IN2 49 +========= ======== + +.. include:: ../peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx93-phyboard-segin-peb-eval-01.dtso?h=v6.1.55_2.2.0-phy3#n33` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx93-phycore-som.dtsi?h=v6.1.55_2.2.0-phy3#n88` + +General I²C2 bus configuration for |dt-carrierboard|.dts: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n155` or for +imx93-phyboard-nash.dts: +:imx-dt:`imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n113` + + +EEPROM +------ + +There are two different I2C EEPROM flashes populated on |som| SoM and on the +|sbc|. For now only the one on the |som| is enabled, and it is used for board +detection. + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file can be found in our PHYTEC git: +:imx-dt:`imx93-phycore-som.dtsi?h=v6.1.55_2.2.0-phy3#n172` + +.. include:: ../../peripherals/rtc.rsti + +DT representation for I²C RTCs: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n173` or +:imx-dt:`imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n122` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 480 Mbps (HighSpeed +'HS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host, but on the |sbc| +one of them is used as a host-only port (USB-A connector). + +.. include:: /bsp/peripherals/usb-host.rsti + +The OTG port provides an additional pin for over-current protection, which is +not used on the |sbc|. Since it's not used, the driver part is also disabled +from within the device tree. In case this pin is used, activate this +over-current in the device tree and set the correct polarity (active high/low) +according to the device specification. For the correct setup, please refer to +the Kernel documentation under +Linux/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt. + +DT representation for USB Host: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n190` or +:imx-dt:`imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n180` + +RS232/RS485 +----------- + +The **phyBOARD-Nash** i.MX 93 SoC provides one RS232/RS485 serial port. + +.. warning:: + RS232 with HW flow control and RS485 are not working due to HW bug on the + phyBOARD-Nash PCB revision 1616.0 + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n173` + +CAN FD +------ + +The |sbc| has one flexCAN interface supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon the Linux network layer. Using +this framework, the CAN interfaces behave like an ordinary Linux network device, +with some additional features special to CAN. More information can be found in +the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n147` or +:imx-dt:`imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n105` + +Audio on phyBOARD-Segin +----------------------- + +On phyBOARD-Segin i.MX 93 the TI TLV320AIC3007 audio codec is used. It uses I2S +for data transmission and I2C for codec control. The audio signals available +are: + +* Stereo LINE IN, +* Stereo LINE OUT, +* Output where D-Class 1W speaker can be connected + +.. include:: /bsp/peripherals/audio.rsti + :end-before: .. audio_alsa_configuration_start_label + +.. include:: /bsp/peripherals/audio.rsti + :start-after: .. audio_playback_start_label + :end-before: .. audio_capture_start_label + +If Speaker volume it too low you can increase its volume with (values 0-3): + +.. code-block:: console + + target:~$ amixer -c 0 sset Class-D 3 + +.. hint:: + + Speaker output is only mono so when stereo track is played only left channel + will be played by speaker. + +Capture +....... + +``arecord`` is a command-line tool for capturing audio streams which use Line In +as the default input source. + +.. code-block:: console + + target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav + +.. hint:: + + Since playback and capture share hardware interfaces, it is not possible to + use different sampling rates and formats for simultaneous playback and + capture operations. + +Device Tree Audio configuration: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n62` + +Audio on phyBOARD-Nash +---------------------- + +.. warning:: + + Due to HW bug Audio is broken on phyBOARD-Nash i.MX 93 PCB revision: 1616.0 + +To use audio with phyBOARD-Nash an additional adapter for the Audio/Video +connector is needed. The PEB-AV-10 (1531.1 revision) can be bought separately to +the Kit. PEB-AV-10 is populated with a TI TLV320AIC3007 audio codec. Audio +support is done via the I2S interface and controlled via I2C. + +There is a 3.5mm headset jack with OMTP standard and an 8-pin header to connect +audio devices with the AV-Connector. The 8-pin header contains a mono speaker, +headphones, and line-in signals. + +.. include:: /bsp/peripherals/audio.rsti + +Device Tree Audio configuration: +:imx-dt:`imx93-phyboard-nash-peb-av-010.dtso?h=v6.1.55_2.2.0-phy3#n57` + +.. include:: /bsp/peripherals/video.rsti + +.. include:: display.rsti + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +The device tree of PEB-AV-02 can be found here: +:imx-dt:`imx93-phyboard-segin-peb-av-02.dtso?h=v6.1.55_2.2.0-phy3` + +The device tree of PEB-AV-10 can be found here: +:imx-dt:`imx93-phyboard-nash-peb-av-010.dtso?h=v6.1.55_2.2.0-phy3` + +.. include:: peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/bbnsm-power-key.rsti + +.. include:: ../peripherals/pxp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. include:: /bsp/imx9/imx93/peripherals/tpm.rsti + +Device tree TPM configuration can be found here: +:imx-dt:`imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n151` + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti diff --git a/previews/271/_sources/bsp/imx9/imx93/pd24.2.0.rst.txt b/previews/271/_sources/bsp/imx9/imx93/pd24.2.0.rst.txt new file mode 100644 index 000000000..35fa7bf43 --- /dev/null +++ b/previews/271/_sources/bsp/imx9/imx93/pd24.2.0.rst.txt @@ -0,0 +1,676 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX93-PD24.2.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-91-93/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/sdk/ampliphy-vendor-wayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic.xz +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools/ +.. _`static-pdf-dl`: ../../../_static/imx93-pd24.2.0.pdf + +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx93 + +.. General Substitutions +.. |kit| replace:: **phyBOARD-Segin i.MX 93 and phyBOARD-Nash i.MX 93 Kit** +.. |kit-ram-size| replace:: 1GiB +.. |sbc| replace:: phyBOARD-Segin/Nash i.MX 93 +.. |sbc-segin| replace:: phyBOARD-Segin i.MX 93 +.. |sbc-nash| replace:: phyBOARD-Nash i.MX 93 +.. |soc| replace:: i.MX 93 +.. |socfamily| replace:: i.MX 9 +.. |som| replace:: phyCORE-i.MX93 +.. |debug-uart| replace:: ttyLP0 +.. |serial-uart| replace:: ttyLP6 +.. |expansion-connector| replace:: X16 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx9_phytec_defconfig +.. |kernel-recipe-path| replace:: meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb +.. |kernel-repo-name| replace:: linux-phytec-imx +.. |kernel-repo-url| replace:: git://github.com/phytec/linux-phytec-imx.git +.. |kernel-socname| replace:: imx93 +.. |kernel-tag| replace:: v6.6.23-2.0.0-phy8 +.. |emmcdev| replace:: mmcblk0 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 0 +.. |u-boot-defconfig| replace:: imx93-phycore_defconfig +.. |u-boot-multiple-defconfig-note| replace:: In command above replace ```` with ``imx93-phycore_defconfig`` +.. |u-boot-multiple-dtb-note| replace:: In command above replace ```` with ``imx93-phyboard-segin.dtb`` +.. |u-boot-imx-mkimage-tag| replace:: lf-6.6.23-2.0.0 +.. |u-boot-soc-name| replace:: iMX9 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX93 specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX93 +.. |u-boot-tag| replace:: v2024.04-2.0.0-phy6 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx93-phyboard-segin +.. |dt-som| replace:: imx93-phycore-som +.. |dtbo-rpmsg| replace:: imx93-phycore-rpmsg.dtso + +.. IMX93 specific +.. |dt-somnetwork| replace:: :linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi#L61` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`scarthgap` +.. |yocto-bsp-name| replace:: BSP-Yocto-i.MX93 +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: scarthgap +.. |yocto-distro| replace:: ampliphy-vendor-wayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: wic.xz +.. |yocto-machinename| replace:: phyboard-segin-imx93-2 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX93-PD24.2.0 +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (scarthgap) ` +.. |yocto-sdk-rev| replace:: 5.0 +.. |yocto-sdk-a-core| replace:: cortexa55 + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: UART1 console on PEB-EVAL-01 for **phyBOARD-Segin** and X-37 + USB-C debug for **phyBOARD-Nash** +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X8 (USB micro/OTG connector) ` + + +.. IMX93 specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L114` or here: + :linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L83`. + +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M33 Core +.. |ref-m-core-connections| replace:: :ref:`X16 ` +.. |mcore-jtag-dev| replace:: MIMX8MM6_M4 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Yocto Manual | Scarthgap | ++-----------------------+----------------------+ +| Release Date | 2024/10/08 | ++-----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================ ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================ ========== +|yocto-manifestname| Major 2024/10/08 Released +==================== ================ ================ ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname|, see `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware. + +.. tip:: + + **Console examples in this BSP manual only focus on phyBOARD-Segin i.MX 93. + Similar commands can also be executed for/on phyBOARD-Nash i.MX 93** + +.. _imx93-PD24.2.0-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx93-PD24.2.0-getting-started: +.. include:: /bsp/getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the + following position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the targets debug console with your host. Use |ref-debugusbconnector|. +* Power up the board +* Open serial/usb port with 115200 baud and 8N1 (you should see u-boot/linux + start on the console + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx93-PD24.2.0-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx93.bin**: ARM Trusted Firmware binary +* **lpddr4_dmem_1d_v202201.bin, lpddr4_dmem_2d_v202201.bin, + lpddr4_imem_1d_v202201.bin, + lpddr4_imem_2d_v202201.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which + is bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx93-phyboard-*.dtb**: Kernel device tree file +* **imx93-phy\*.dtbo**: Kernel device tree overlay files +* **phytec-\*.tar.gz**: Root file system, + of bitbake-image that was built. + + * **phytec-qt6demo-image-phyboard-*-imx93-*.tar.gz**: when bitbake-build + was processed for ``phytec-qt6demo-image`` + * **phytec-headless-image-phyboard-*-imx93-*.tar.gz**: when bitbake-build + was processed for ``phytec-headless-image`` +* **phytec-\*.rootfs.wic.xz**: Compressed bootable SD + card image of bitbake-image that was built. Includes bootloader, DTBs, Kernel + and Root file system. + + * **phytec-qt6demo-image-phyboard-*-imx93-*.rootfs.wic.xz**: when bitbake-build + was processed for ``phytec-qt6demo-image`` + * **phytec-headless-image-phyboard-*-imx93-*.rootfs.wic.xz**: when bitbake-build + was processed for ``phytec-headless-image`` +* **imx93-11x11-evk_m33_\*.bin**, binaries of demo applications for the + Cortex-M33 MCU; can be manually loaded and started with U-Boot or Linux + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: + + * |sbc-segin|: 1472.5 + * |sbc-nash|: 1616.0, 1616.1 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx93-PD24.2.0-bootswitch: +.. include:: bootmode-switch.rsti + +.. include:: ../installing-os.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx93-PD24.2.0-development: + +Development +=========== + +.. include:: ../../imx-common/development/host_network_setup.rsti +.. include:: ../../imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: ../../imx-common/development/standalone_build_preface.rsti +.. include:: ../../imx-common/development/standalone_build_u-boot_imxmkimage.rsti +.. include:: ../../imx-common/development/standalone_build_kernel.rsti + +.. include:: ../../imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx93-PD24.2.0-device-tree: +.. include:: /bsp/device-tree.rsti + +:: + + imx93-phyboard-segin-peb-av-02.dtbo + imx93-phyboard-segin-peb-eval-01.dtbo + imx93-phyboard-segin-peb-wlbt-05.dtbo + imx93-phycore-rpmsg.dtbo + imx93-phycore-no-emmc.dtbo + imx93-phycore-no-eth.dtbo + +Available overlays for phyboard-nash-imx93-1.conf are: + +:: + + imx93-phyboard-nash-jtag.dtbo + imx93-phyboard-nash-peb-av-10.dtbo + imx93-phyboard-nash-pwm-fan.dtbo + imx93-phyboard-nash-vm016.dtbo + imx93-phycore-rpmsg.dtbo + imx93-phycore-no-emmc.dtbo + imx93-phycore-no-eth.dtbo + +.. _imx93-PD24.2.0-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX93_PAD_UART1_RXD__LPUART1_RX 0x31e + MX93_PAD_UART1_TXD__LPUART1_TX 0x30e + >; + }; + +The first part of the string MX93_PAD_UART1_RXD__LPUART1_RX names the pad +(in this example UART1_RXD). The second part of the string (LPUART1_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal pull up is +activated. + +The device tree representation for UART1 pinmuxing: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L259` + +.. _imx93-PD24.2.0-network: + +Network +------- + +|sbc| provides two ethernet interfaces. + +* On |sbc-segin| we have: + + * a 100 megabit Ethernet provided by |som| + * and 100 megabit Ethernet provided by phyBOARD. + +* On |sbc-nash| we have: + + * a 100 megabit Ethernet provided by |som| + * and 1 gigabit Ethernet provided by phyBOARD. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +.. include:: wireless-network.rsti + +.. include:: ../../peripherals/wireless-network.rsti + :end-before: .. no-bluetooth-marker + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L213` or here: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L202` + +DT configuration for the eMMC interface can be found here: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi#L194` or here: + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/gpios.rsti + +.. include:: /bsp/peripherals/adc.rsti + +On |sbc-nash| the ADC lines are accessible on X16 expansion connector: + +========= ======== +ADC input X16 pin +========= ======== +ADC_IN0 47 +ADC_IN2 49 +========= ======== + +.. include:: ../peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-eval-01.dtso#L33` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C3 bus configuration (e.g. |dt-som|.dtsi): +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi#L88` + +General I²C2 bus configuration for |dt-carrierboard|.dts: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L155` or for +imx93-phyboard-nash.dts: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L113` + + +EEPROM +------ + +There are two different I2C EEPROM flashes populated on |som| SoM and on the +|sbc|. For now only the one on the |som| is enabled, and it is used for board +detection. + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file can be found in our PHYTEC git: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi#L172` + +.. include:: ../../peripherals/rtc.rsti + +DT representation for I²C RTCs: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L173` or +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L122` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 480 Mbps (HighSpeed +'HS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host, but on the |sbc| +one of them is used as a host-only port (USB-A connector). + +.. include:: /bsp/peripherals/usb-host.rsti + +The OTG port provides an additional pin for over-current protection, which is +not used on the |sbc|. Since it's not used, the driver part is also disabled +from within the device tree. In case this pin is used, activate this +over-current in the device tree and set the correct polarity (active high/low) +according to the device specification. For the correct setup, please refer to +the Kernel documentation under +Linux/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt. + +DT representation for USB Host: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L193` or +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L181` + +RS232/RS485 +----------- + +The |sbc-nash| i.MX 93 SoC provides one RS232/RS485 serial port. + +.. warning:: + RS232 with HW flow control and RS485 are not working due to HW bug on the + |sbc-nash| PCB revision 1616.0 + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti + +The device tree representation for RS232 and RS485: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L174` + +CAN FD +------ + +The |sbc| has one flexCAN interface supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon the Linux network layer. Using +this framework, the CAN interfaces behave like an ordinary Linux network device, +with some additional features special to CAN. More information can be found in +the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L147` or +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L105` + +Audio on |sbc-segin| +-------------------- + +On |sbc-segin| the TI TLV320AIC3007 audio codec is used. It uses I2S +for data transmission and I2C for codec control. The audio signals available +are: + +* Stereo LINE IN, +* Stereo LINE OUT, +* Output where D-Class 1W speaker can be connected + +.. include:: /bsp/peripherals/audio.rsti + :end-before: .. audio_alsa_configuration_start_label + +.. include:: /bsp/peripherals/audio.rsti + :start-after: .. audio_playback_start_label + :end-before: .. audio_capture_start_label + +If Speaker volume it too low you can increase its volume with (values 0-3): + +.. code-block:: console + + target:~$ amixer -c 0 sset Class-D 3 + +.. hint:: + + Speaker output is only mono so when stereo track is played only left channel + will be played by speaker. + +Capture +....... + +``arecord`` is a command-line tool for capturing audio streams which use Line In +as the default input source. + +.. code-block:: console + + target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav + +.. hint:: + + Since playback and capture share hardware interfaces, it is not possible to + use different sampling rates and formats for simultaneous playback and + capture operations. + +Device Tree Audio configuration: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L62` + +Audio on |sbc-nash| +------------------- + +.. warning:: + + Due to HW bug Audio is broken on |sbc-nash| PCB revision: 1616.0 + +To use audio with |sbc-nash| an additional adapter for the Audio/Video +connector is needed. The PEB-AV-10 (1531.1 revision) can be bought separately to +the Kit. PEB-AV-10 is populated with a TI TLV320AIC3007 audio codec. Audio +support is done via the I2S interface and controlled via I2C. + +There is a 3.5mm headset jack with OMTP standard and an 8-pin header to connect +audio devices with the AV-Connector. The 8-pin header contains a mono speaker, +headphones, and line-in signals. + +.. include:: /bsp/peripherals/audio.rsti + +Device Tree Audio configuration: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash-peb-av-10.dtso#L56` + +.. include:: /bsp/peripherals/video.rsti + +.. include:: display.rsti + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +The device tree of PEB-AV-02 can be found here: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-02.dtso` + +The device tree of PEB-AV-10 can be found here: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash-peb-av-10.dtso` + +.. include:: peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/bbnsm-power-key.rsti + +.. include:: ../peripherals/pxp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. include:: /bsp/imx9/imx93/peripherals/tpm.rsti + +Device tree TPM configuration can be found here: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L151` + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti diff --git a/previews/271/_sources/contributing_links.rst.txt b/previews/271/_sources/contributing_links.rst.txt new file mode 100644 index 000000000..7397e9c7f --- /dev/null +++ b/previews/271/_sources/contributing_links.rst.txt @@ -0,0 +1,15 @@ +========== +Contribute +========== + +Phytec's Yocto BSPs are released under open source licenses and we welcome +contributions to our Yocto BSPs and this documentation. Please check the Git +repositories for the individual projects and layers for contribution +guidelines. + +If you have a **question related to our Yocto BSPs** or notice **issues with +this documentation**, we encourage you to open an Issue or Pull-Request on the +Github repository `doc-bsp-yocto `__. +Have a look at the `Contributing guide +`__ for +more information. diff --git a/previews/271/_sources/index.rst.txt b/previews/271/_sources/index.rst.txt new file mode 100644 index 000000000..4c702990a --- /dev/null +++ b/previews/271/_sources/index.rst.txt @@ -0,0 +1,19 @@ +Welcome to the PHYTEC BSP Documentation +======================================= + +Welcome to the Documentation for our Yocto BSPs. + +.. toctree:: + :maxdepth: 1 + :caption: Contents + + yocto/manual-index + rauc/manual-index + bsp/imx8/imx8 + bsp/imx9/imx9 + +.. toctree:: + :maxdepth: 1 + :caption: Contribute + + contributing_links diff --git a/previews/271/_sources/rauc/kirkstone.rst.txt b/previews/271/_sources/rauc/kirkstone.rst.txt new file mode 100644 index 000000000..15f08b50d --- /dev/null +++ b/previews/271/_sources/rauc/kirkstone.rst.txt @@ -0,0 +1,1107 @@ +.. Download links +.. _`static-pdf-dl`: ../_static/rauc-kirkstone.pdf + +.. RAUC +.. |yocto-codename| replace:: Kirkstone +.. |rauc-manual| replace:: RAUC Update & Device Management Manual + +.. only:: html + + Documentation in pdf format: `Download `_ + ++---------------------------------------------------------------+ +| |rauc-manual| | ++=======================+=======================================+ +| Document Title | |rauc-manual| |yocto-codename| | ++-----------------------+---------------------------------------+ +| Document Type | RAUC Update & Device Management | +| | Manual | ++-----------------------+---------------------------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+---------------------------------------+ +| Is Branch of | |rauc-manual| | ++-----------------------+---------------------------------------+ + ++-------------------------------------+------------------+------------------+------------+ +| Compatible BSPs | BSP Release Type | BSP Release Date | BSP Status | ++=====================================+==================+==================+============+ +| BSP-Yocto-Ampliphy-i.MX6-PD22.1.0 | Major | 14.12.2022 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX6-PD22.1.1 | Minor | 20.06.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.0 | Major | 11.08.2022 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1 | Minor | 23.05.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX8MM-PD23.1.0 | Major | 12.12.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX8MP-PD23.1.0 | Major | 12.12.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM62x-PD23.2.0 | Major | 28.09.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM62Ax-PD23.1.0 | Major | 28.09.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM64x-PD23.2.0 | Major | 28.09.2023 | released | ++-------------------------------------+------------------+------------------+------------+ + +This manual was tested using the Yocto version |yocto-codename|. + +Introduction +============ + +PHYTEC's Yocto distribution Ampliphy (former Yogurt) supports the `RAUC +`_ (Robust Auto-Update Controller) +mechanism. RAUC controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. For +eMMC devices only, it can also update the bootloader. + +This manual describes how RAUC is used and implemented on various PHYTEC +platforms. Note, that different modules use different bootloaders and flash +storage devices, which affects the way things are handled by RAUC. Make sure to +read the correct sections fitting your platform. + +.. note:: + + This manual contains machine-specific paths and variable contents. Make sure + you are using the correct machine and device names for your application when + executing any commands. + + +System Configuration +==================== + +RAUC can be used with both eMMC and NAND flash storage. Using the distro +``ampliphy-rauc`` or ``ampliphy-vendor-rauc``, it is enabled by default and requires +no additional setup to get started. RAUC can be used in different update +scenarios. As an example, we configured the BSP to use an A/B setup to have a +completely redundant system (including the bootloader on eMMC devices). Note, +that there is an additional partition named ``config`` storing persistent +configuration data not being changed when updating. + +.. image:: /rauc/images/rauc-ab-system.png + +RAUC BSP Example Setup +---------------------- + +The partition layout is defined in the ``/etc/rauc/system.conf`` file. As an +example, this is what it looks like for i.MX 8M Mini with eMMC flash storage: + +.. code-block:: cfg + :caption: /etc/rauc/system.conf + + [system] + compatible=phyboard-polis-imx8mm-4 + bootloader=uboot + mountprefix=/mnt/rauc + + [handlers] + pre-install=/usr/lib/rauc/rauc-pre-install.sh + post-install=/usr/lib/rauc/rauc-post-install.sh + + [keyring] + path=mainca-rsa.crt.pem + + [slot.bootloader.0] + device=/dev/mmcblk2 + type=boot-emmc + + # System A + [slot.rootfs.0] + device=/dev/mmcblk2p5 + type=ext4 + bootname=system0 + + [slot.boot.0] + device=/dev/mmcblk2p1 + type=vfat + parent=rootfs.0 + + # System B + [slot.rootfs.1] + device=/dev/mmcblk2p6 + type=ext4 + bootname=system1 + + [slot.boot.1] + device=/dev/mmcblk2p2 + type=vfat + parent=rootfs.1 + +Note, that the devices specified in the slots are different depending on the +selected machine. + +.. warning:: + + Updates with RAUC use an OpenSSL certificate to verify the validity of an + image. The BSP includes a certificate that can be used for development. In a + productive system, however, it is highly recommended to use a self-created + key and certificate. If you need to change the keyring on an existing device, + see :ref:`Switching RAUC Keyrings ` for more + information. + +Design Considerations +===================== + +In order to prevent the system from locking up, it may be a good idea to utilize +a hardware watchdog. In case the Linux Kernel does not boot or another +catastrophic event occurs that prevents the system from operating normally, the +hardware watchdog then resets the system. By default, the hardware watchdog is +disabled. To enable it, refer to the corresponding BSP manual that fits your +SoM. + +Other important design considerations, as well as a checklist, can be found in +the official RAUC documentation: +https://rauc.readthedocs.io/en/latest/checklist.html + +Initial Setup +============= + +To use RAUC, the flash device needs to be written with a complete Linux system +and bootloader. The preferred method to do this is using the included tool +`partup `_. + +Flash Storage +------------- + +To flash the device with the correct partitions/volumes, use a partup package +built with the ``ampliphy-rauc`` or ``ampliphy-vendor-rauc`` distribution. +Prebuilt partup packages can be found in the BSP release. It is also possible to +build a package with this distribution yourself using Yocto. Change +``local.conf`` so separate build directories are created, storing the images and +packages for the RAUC system: + +.. code-block:: + :caption: build/conf/local.conf + + # When building multiple distros in the same TOPDIR + TMPDIR = "${TOPDIR}/tmp-${DISTRO}" + DEPLOY_DIR = "${TOPDIR}/deploy-${DISTRO}" + +Then initialize the build directory with the OE init script: + +.. code-block:: console + + host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source sources/poky/oe-init-build-env + +Change the distribution to ``ampliphy-rauc`` (for i.MX6, AM6x) or +``ampliphy-vendor-rauc`` (for i.MX8): + +.. code-block:: + :caption: build/conf/local.conf + + DISTRO ?= "ampliphy-rauc" + +Any image built with this distro now includes a full A/B system. Build the image +as usual: + +.. code-block:: console + + host:~$ bitbake phytec-headless-image + +The resulting partup package is stored in the ``deploy-ampliphy-vendor-rauc`` directory, e.g.: + +.. code-block:: + + deploy-ampliphy-vendor-rauc/images/phyboard-segin-imx93-2/phytec-headless-image-phyboard-segin-imx93-2.partup + +This partup package contains all the necessary data and configuration to flash +an eMMC. `Partup `__ can be obtained from its +`release page `_. Also, see its +README for detailed `installation instructions +`_. Partup is already installed +in our Ampliphy images, ``phytec-headless-image`` and can be directly used e.g. +from an SD card. + +.. note:: + To flash the initial RAUC system, a booted non-RAUC system is needed first on + a different flash device. E.g. you could boot a regular + ``phytec-headless-image`` image with distro ``ampliphy`` from an SD card. + +eMMC +.... + +While running a non-RAUC system from an SD card on the target, copy the +``.partup`` package built with distro ``ampliphy-rauc`` or +``ampliphy-vendor-rauc`` to the running target first: + +.. code-block:: console + + host:~$ scp phytec-headless-image-phyboard-segin-imx93-2.partup 192.168.3.11:/root + +Then install the partup package to the eMMC: + +.. code-block:: console + + target:~$ partup install phytec-headless-image-phyboard-segin-imx93-2.partup /dev/mmcblk0 + +Now the target can boot the flashed A/B system. + +NAND +.... + +.. note:: + + There are scripts provided with the bootloader barebox that previously were + used to initialize NAND flash with an A/B system: ``rauc_init_nand``, + ``rauc_flash_nand_from_tftp`` and ``rauc_flash_nand_from_mmc``. These scripts + are deprecated. It is advised to use the script ``rauc-flash-nand`` provided + in the Linux environment with PHYTEC's distribution *Ampliphy*. + +With raw NAND flash the kernel, device tree, and root filesystem are written +individually. Initialize the NAND flash with the correct volumes from a Linux on +the target: + +.. code-block:: console + + target:~$ rauc-flash-nand -k /path/to/zImage -d /path/to/oftree -r /path/to/root.ubifs + +The initialization script will automatically utilize all available space of NAND +flash. The NAND device is also determined automatically by finding the device +root in ``/proc/mtd``. + +On i.MX6 and i.MX6UL devices with barebox, use bbu (barebox update) to flash the +bootloader: + +.. code-block:: console + + target:~$ bbu.sh -f /path/to/barebox.bin + +The A/B system on NAND Flash is now ready to be booted. + +Bootloader +---------- + +Booting the A/B System by Default +................................. + +Booting the A/B system is done mostly automatically by the bootloader since the +Yocto release *hardknott*. For devices with eMMC flash storage, the +corresponding setting is written into the bootloader environment during the +building of the BSP. In particular, if the distribution ``ampliphy-rauc`` or +``ampliphy-vendor-rauc`` is used, as described previously, the bootloader should +automatically start the A/B system and have the variables set for RAUC +accordingly. + +This automatic setting can be manually changed by setting one variable in the +bootloader. The procedure is described in more detail in the following chapters +for U-Boot and barebox. + +U-Boot +...... + +After a successful boot into a Linux environment, this command is used to view +the available parameters: + +.. code-block:: console + + target:~$ fw_printenv + +You may see this parameter along with others in the output: + +.. code-block:: + + doraucboot=1 + +To manually disable or enable booting the A/B system with RAUC, set this +variable to ``0`` or ``1``: + +.. code-block:: console + + target:~$ fw_setenv doraucboot 1 + +This parameter can also be edited in U-Boot. Restart your board and hit any key +to stop the automatic boot. The environment variables can now be viewed: + +.. code-block:: + + u-boot=> printenv + +and set: + +.. code-block:: + + u-boot=> setenv doraucboot 1 + u-boot=> saveenv + +Barebox +....... + +In barebox, the system to be booted can be selected directly by its name. To +boot the A/B system, including RAUC, ``bootchooser`` is used. To boot e.g. a +regular SD card without RAUC use ``mmc`` instead, or ``nand`` for NAND devices: + +.. code-block:: + + barebox$ nv boot.default=bootchooser + +Creating RAUC Bundles +===================== + +To update your system with RAUC, a RAUC bundle (``.raucb``) needs to be created. +It contains all required images and scripts for the update and a RAUC +``manifest.raucm`` that describes the content of the bundle for the RAUC update +on the target. The BSP includes a Yocto target that lets you build a RAUC bundle +from your Yocto build. + +To create the bundle with Yocto, run the following in ``build/`` with the +distribution ``ampliphy-rauc`` or ``ampliphy-vendor-rauc`` set up, as described +previously: + +.. code-block:: console + + host:~$ bitbake phytec-headless-bundle + +This results in the creation of a ``.raucb`` bundle file in +``deploy/images//`` which can be used for updating the system as +described later. There is no need to create a ``manifest.raucm`` manually as it +is created automatically during the build of the bundle. As a reference, the +created manifest would look something like this: + +.. code-block:: cfg + :caption: manifest.raucm + + [update] + compatible=phyboard-polis-imx8mm-3 + version=r0 + description=PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0 + build=20200624074335 + + [image.rootfs] + sha256=cc3f65cd1c1993951d7a39bdb7b7d723617ac46460f8b640cd8d1622ad6e4c17 + size=99942000 + filename=phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz + + [image.boot] + sha256=bafe46679af8c6292dba22b9d402e3119ef78c6f8b458bcb6993326060de3aa4 + size=12410534 + filename=boot.tar.gz.img + +For more information about the manifest format, see +https://rauc.readthedocs.io/en/latest/reference.html#manifest. + +Updating with RAUC +================== + +To update the target system with RAUC, the RAUC bundle file previously created +first needs to be copied to the board or to a memory device that can be mounted +in Linux. One way is to copy the bundle file with ``scp``, but this requires +enough space left on the board's filesystem. To do this, boot the target board +to Linux and connect it via Ethernet to your host PC. + +On the host, run: + +.. code-block:: console + + host:~$ scp phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb root@192.168.3.11:/tmp/ + +On the target, the bundle can be verified: + +.. code-block:: console + + target:~$ rauc info /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + +and the output should look similar to this: + +.. code-block:: + + rauc-Message: 12:52:49.821: Reading bundle: /phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + rauc-Message: 12:52:49.830: Verifying bundle... + Compatible: 'phyboard-polis-imx8mm-3' + Version: 'r0' + Description: 'PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0' + Build: '20200624073212' + Hooks: '' + 2 Images: + (1) phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz + Slotclass: rootfs + Checksum: 342f67f7678d7af3f77710e1b68979f638c7f4d20393f6ffd0c36beff2789070 + Size: 180407809 + Hooks: + (2) boot.tar.gz.img + Slotclass: boot + Checksum: 8c84465b4715cc142eca2785fea09804bd970755142c9ff57e08c791e2b71f28 + Size: 12411786 + Hooks: + 0 Files + + Certificate Chain: + 0 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH Development-1 + Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + SPKI sha256: E2:47:5F:32:05:37:04:D4:8C:48:8D:A6:74:A8:21:2E:97:41:EE:88:74:B5:F4:65:75:97:76:1D:FF:1D:7B:EE + Not Before: Jan 1 00:00:00 1970 GMT + Not After: Dec 31 23:59:59 9999 GMT + 1 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + SPKI sha256: AB:5C:DB:C6:0A:ED:A4:48:B9:40:AC:B1:48:06:AA:BA:92:09:83:8C:DC:6F:E1:5F:B6:FB:0C:39:3C:3B:E6:A2 + Not Before: Jan 1 00:00:00 1970 GMT + Not After: Dec 31 23:59:59 9999 GMT + +To check the current state of the system, run: + +.. code-block:: console + + target:~$ rauc status + +and get output similar to this: + +.. code-block:: + + === System Info === + Compatible: phyboard-segin-imx6ul-6 + Variant: + Booted from: rootfs.0 (system0) + + === Bootloader === + Activated: rootfs.0 (system0) + + === Slot States === + o [rootfs.1] (/dev/ubi0_6, ubifs, inactive) + bootname: system1 + boot status: good + [dtb.1] (/dev/ubi0_3, ubivol, inactive) + [kernel.1] (/dev/ubi0_2, ubivol, inactive) + + x [rootfs.0] (/dev/ubi0_5, ubifs, booted) + bootname: system0 + boot status: good + [kernel.0] (/dev/ubi0_0, ubivol, active) + [dtb.0] (/dev/ubi0_1, ubivol, active) + +To update the currently inactive system with the downloaded bundle, run: + +.. code-block:: console + + target:~$ rauc install /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + +and reboot afterward: + +.. code-block:: console + + target:~$ reboot + +With the success of the update, RAUC automatically switches the active system to +the newly updated system. Now during reboot, RAUC counts the boot attempts of +the kernel and if it fails more often than specified in the state framework of +the system, RAUC switches back to the old system and marks the new system as +bad. If the boot attempt to the kernel is successful, the new system is marked +as good and the old system can now be updated with the same instructions. After +two successful ``rauc install`` and ``reboot``, both systems are updated. + +.. tip:: + + When you update from a USB stick, make sure to remove the stick after a + successful update before rebooting. If not, an automatic update will be + started after each boot. This is due to the :ref:`Automatic Update from USB Flash + Drive with RAUC ` you can find below. + +Changing the Active Boot Slot +----------------------------- + +It is possible to switch the active system manually: + +.. code-block:: console + + target:~$ rauc status mark-active other + +After a reboot, the target now starts from the other system. + +.. _kirkstone_rauc-switch-keyrings: + +Switching RAUC Keyrings +======================= + +PHYTEC's distribution comes with keys and certificates used for development and +demonstration purposes only. To change to a different PKI when devices are +already rolled out, RAUC's keyring must be changed. This chapter describes the +full procedure from a development state to a production state. Keep in mind, +that it is always a better idea to roll out your devices with a production +keyring in the first place, instead of relying on a development one for too +long. The following diagram shows the general process of switching keyrings for +RAUC: + +.. image:: /rauc/images/rauc-switching-keyrings.png + +Keyring Switching Process +------------------------- + +Create new certificates and keys for your own PKI. See our security manual for a +detailed description on how to create a custom PKI. For this document, we refer +to this newly created PKI as "production", as opposed to the existing +"development" keys. + +Move the generated keys and certificates, to your main Yocto build directory +root, alongside with ``build/`` and ``sources/``. + +.. warning:: + + Be careful where you store the private keys! These should in no way be made + publicly available. E.g. do not store the private keys in a public Git + repository. Otherwise, unauthorized entities could create RAUC bundles that + can be installed on your target system! + +Now, a RAUC bundle must be created that contains the new "production" CA keyring +in its root filesystem but is still signed by the "development" CA. With this, +the system is converted from a "development" system to a "production" system. To +achieve this, exchange the file ``ca.cert.pem`` installed by the RAUC recipe in +the Yocto sources. Create a file ``rauc_%.bbappend`` in your own Yocto layer: + +.. code-block:: + :caption: recipes-core/rauc/rauc_%.bbappend + + FILESEXTRAPATHS_prepend := "${THISDIR}/files:" + + RAUC_KEYRING_FILE = "${CERT_PATH}/rauc-customer/ca.cert.pem" + +Build the same RAUC bundle as before, now with the exchanged keyring: + +.. code-block:: console + + host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source source/poky/oe-init-build-env + host:~$ bitbake phytec-headless-bundle # Build the desired RAUC bundle + +Install the resulting RAUC bundle as usual. The target now has the image with +the "production" keyring installed in its other slot ("System B" in the figure +above). Reboot to start that system. + +All future RAUC bundles for the "production" system must now also be signed by +the "production" CA. For this, change the key and certificate to your newly +generated "production" ones in the bundle recipe: + +.. code-block:: + :caption: recipes-images/bundles/customer-headless-bundle.bb + + require phytec-base-bundle.inc + + RAUC_SLOT_rootfs ?= "phytec-headless-image" + + RAUC_KEY_FILE = "${CERT_PATH}/rauc-customer/private/production-1.key.pem" + RAUC_CERT_FILE = "${CERT_PATH/rauc-customer/production-1.cert.pem" + + RAUC_INTERMEDIATE_CERT_FILE = "" + +Rebuild the RAUC bundle: + +.. code-block:: console + + host:~$ bitbake customer-headless-bundle + +These and any future bundles are now ready to be installed on your "production" +target system and have been fully migrated away from the "development" system. +This also means that now only bundles signed by the "production" CA can be +installed on the target (and e.g. "development" bundles cannot). + +Use Case Examples +================= + +.. _kirkstone_rauc-automatic-updates-usb: + +Automatic Updates from USB Flash Drive with RAUC +------------------------------------------------ + +One of the most prominent use cases for RAUC might be an automatic update system +from a USB flash drive. This use case is implemented in the BSP as a reference +example. We combine only standard Linux mechanisms with RAUC to build the +system. The kernel notifies *udev* when a device gets plugged into the USB port. +We use a custom *udev* rule to trigger a systemd service when this event +happens. + +.. code-block:: + :caption: 10-update-usb.rules + + KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end" + + # Trigger systemd service + ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}="update-usb@%k.service" + + # Exit + LABEL="media_by_label_auto_mount_end" + +The service automatically mounts the USB flash drive and notifies the +application. + +.. code-block:: systemd + :caption: update-usb@.service + + [Unit] + Description=usb media RAUC service + After=multi-user.target + Requires=rauc.service + + [Service] + Type=oneshot + Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket + ExecStartPre=/bin/mkdir -p /media/%I + ExecStartPre=/bin/mount -t auto /dev/%I /media/%I + ExecStart=/usr/bin/update_usb.sh %I + ExecStop=/bin/umount -l /media/%i + ExecStopPost=-/bin/rmdir /media/%I + +In our reference implementation, we simply use a shell script for the +application logic. + +.. code-block:: sh + :caption: update_usb.sh + + #!/bin/sh + + MOUNT=/media/$1 + + NUMRAUCM=$(find ${MOUNT}/*.raucb -maxdepth 0 | wc -l) + + [ "$NUMRAUCM" -eq 0 ] && echo "${MOUNT}*.raucb not found" && exit + [ "$NUMRAUCM" -ne 1 ] && echo "more than one ${MOUNT}/*.raucb" && exit + + rauc install $MOUNT/*.raucb + if [ "$?" -ne 0 ]; then + echo "Failed to install RAUC bundle." + else + echo "Update successful." + fi + exit $? + +The update logic can be integrated into an application using the *systemd D-Bus +API*. RAUC does not need to be called by its command-line interface but can be +integrated with D-Bus. + +.. tip:: + + RAUC features a D-Bus API interface (see + https://rauc.readthedocs.io/en/latest/using.html#using-the-d-bus-api). + +Security Measurement: Downgrade Barrier +--------------------------------------- + +As a second reference example, we will implement a security mechanism: a +downgrade barrier. When you detect a security vulnerability on your system, you +will fix it and update your system. The systems with the new software will now +be secure again. If an attacker gets a hold of the old software update bundle, +which still has a valid signature, the attacker might have the possibility to +install the old software and still take advantage of the previously fixed +security vulnerability. To prevent this from happening, you could revoke the +updated certificate for every single update and create a new one. This might be +difficult to handle, depending on the environment. A simpler solution would be +to allow updates only in one direction using a version check. + +.. code-block:: sh + :caption: rauc_downgrade_barrier.sh + + #!/bin/sh + + VERSION_FILE=/etc/rauc/downgrade_barrier_version + MANIFEST_FILE=${RAUC_UPDATE_SOURCE}/manifest.raucm + + [ ! -f ${VERSION_FILE} ] && exit 1 + [ ! -f ${MANIFEST_FILE} ] && exit 2 + + VERSION=`cat ${VERSION_FILE} | cut -d 'r' -f 2` + BUNDLE_VERSION=`grep "version" -rI ${MANIFEST_FILE} | cut -d 'r' -f 3` + + # check from empty or unset variables + [ -z "${VERSION}" ] && exit 3 + [ -z "${BUNDLE_VERSION}" ] && exit 4 + + # developer mode, allow all updates if version is r0 + #[ ${VERSION} -eq 0 ] && exit 0 + + # downgrade barrier + if [ ${VERSION} -gt ${BUNDLE_VERSION} ]; then + echo "Downgrade barrier blocked rauc update! CODE5\n" + else + exit 0 + fi + exit 5 + +The script is installed on the target but it is not activated. You need to +remove the developer mode line in the script to activate it. + +Streaming Bundles over HTTP +--------------------------- + +Instead of copying the bundle to the device, the bundle can be streamed over +HTTP. Using bundle streaming has the advantage of not requiring local storage on +the target. A simple approach to this is running NGINX inside a Docker +container. The following example shows how to implement a minimal download +server enabling HTTP range requests to support this feature. + +Create a Dockerfile with the following content: + +.. code-block:: dockerfile + :caption: Dockerfile + + FROM nginx + + COPY bundles /bundles + COPY nginx.conf /etc/nginx/nginx.conf + +Configure NGINX to enable HTTP range requests and point it to the bundle file. + +.. code-block:: nginx + :caption: nginx.conf + + events {} + http { + server { + proxy_force_ranges on; + + location / { + root /bundles; + } + } + } + +Place a bundle in the ``bundles`` sub-directory. The folder structure looks like +the following after creating all configuration files: + +.. code-block:: console + + user@host:rauc-bundle-streaming$ find + . + ./bundles + ./bundles/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb + ./nginx.conf + ./Dockerfile + +Build and run the docker container on the host system: + +.. code-block:: console + + host:~$ sudo docker build -t rauc-bundle-streaming . + host:~$ sudo docker run --name bundles -p 80:80 -d rauc-bundle-streaming + +Install the bundle on the currently inactive target partitions: + +.. code-block:: console + + target:~$ rauc install http://192.168.3.10/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb + +.. note:: + + After the update finishes the target may display the following error which + has no impact on the success of the update: + + .. code-block:: + + [ 7416.336609] block nbd0: NBD_DISCONNECT + [ 7416.340413] block nbd0: Send disconnect failed -32 + +Reference +========= + +Boot Logic Implementation +------------------------- + +.. tip:: + + The implementation details described in this chapter serve as a reference + guide. PHYTEC BSPs that have RAUC support include these by default and the + changes are already incorporated. + +U-Boot Environment Variables +............................ + +For U-Boot, the boot logic that selects the correct partitions to boot from is +implemented in its environment. As a reference, these are the most important +U-Boot variables that are used for the A/B system with RAUC: + +For BSP-Yocto-NXP-i.MX8M*-PD23.1.0: + ++-------------------+--------------------------------------------------------+ +| Name | Function | ++===================+========================================================+ +| BOOT_ORDER | Contains a space-separated list of boot targets in the | +| | order they should be tried. This parameter is | +| | automatically set by RAUC. | ++-------------------+--------------------------------------------------------+ +| BOOT__LEFT | Contains the number of remaining boot attempts to | +| | perform for the respective slot. This parameter is | +| | automatically set by RAUC. | ++-------------------+--------------------------------------------------------+ +| ``raucboot`` | Contains the boot logic that sets the partitions so | +| | the correct system is loaded. | ++-------------------+--------------------------------------------------------+ +| ``doraucboot`` | Enables booting the A/B system if set to 1 and | +| | disables it if set to 0. | ++-------------------+--------------------------------------------------------+ +| ``raucslot`` | Contains the current boot slot used in | +| | BOOT__LEFT. | ++-------------------+--------------------------------------------------------+ +| ``raucargs`` | Sets the Kernel bootargs like console, root, and RAUC | +| | lot. | ++-------------------+--------------------------------------------------------+ +| ``raucdev`` | Sets the eMMC as the boot device. | ++-------------------+--------------------------------------------------------+ +| ``raucrootpart`` | Sets the root filesystem partitions of the device. | ++-------------------+--------------------------------------------------------+ +| ``raucpart`` | Sets the boot partitions of the device. | ++-------------------+--------------------------------------------------------+ +| ``loadraucimage`` | Loads the Kernel image into RAM. | ++-------------------+--------------------------------------------------------+ +| ``loadraucfdt`` | Loads the device tree into RAM. | ++-------------------+--------------------------------------------------------+ + +These environment variables are defined in ``include/configs/phycore_.h`` +in the u-boot source code. + +For BSP-Yocto-Ampliphy-AM6xx-PD23.2.0: + ++-------------------+--------------------------------------------------------+ +| Name | Function | ++===================+========================================================+ +| BOOT_ORDER | Contains a space-separated list of boot targets in the | +| | order they should be tried. This parameter is | +| | automatically set by RAUC. | ++-------------------+--------------------------------------------------------+ +| BOOT__LEFT | Contains the number of remaining boot attempts to | +| | perform for the respective slot. This parameter is | +| | automatically set by RAUC. | ++-------------------+--------------------------------------------------------+ +| ``init_rauc`` | Contains the boot logic that sets the partitions so | +| | the correct system is loaded. | ++-------------------+--------------------------------------------------------+ +| ``doraucboot`` | Enables booting the A/B system if set to 1 and | +| | disables it if set to 0. | ++-------------------+--------------------------------------------------------+ +| ``raucslot`` | Contains the current boot slot used in | +| | BOOT__LEFT. | ++-------------------+--------------------------------------------------------+ +| ``raucrootpart`` | Sets the root filesystem partitions of the device. | ++-------------------+--------------------------------------------------------+ +| ``raucbootpart`` | Sets the boot partitions of the device. | ++-------------------+--------------------------------------------------------+ + +These environment variables are defined in +``include/environment/phytec/rauc.env`` in the u-boot source code. + +.. note:: + + A change in the partition layout, e.g. when using an additional data + partition, may require changing the variables ``raucrootpart`` and + ``raucpart``. Make sure to rebuild your image with the new bootloader + environment after you have made the appropriate changes. + +Barebox Bootchooser Framework +............................. + +For the barebox, the boot logic that selects the correct partitions to boot from +is implemented using the bootchooser and state framework. See the barebox +documentation for detailed information about these: `Barebox Bootchooser +Framework `_, `Barebox +State Framework `_. + +First, the state framework configuration needs to be added to the barebox device +tree. Check out the :ref:`Customizing the BSP ` +chapter in the Yocto reference manual. The state framework configuration is +already included with our BSP for the supported SoC and can be directly included +in the main barebox device tree. E.g. for i.MX6 based module: + +.. code-block:: devicetree + + #include "imx6qdl-phytec-state.dtsi" + +Afterward, rebuild the image and flash the new bootloader. + +.. warning:: + + Be aware that by adding the state framework configuration, the first 160 + bytes of the EEPROM are occupied and can no longer be used for user-specific + purposes. + +The following device tree snippet shows an example of the state framework +configuration used with the BSP. As can be seen, the EEPROM is used as a backend +for the state information: + +.. code-block:: devicetree + + / { + aliases { + state = &state; + }; + + state: imx6qdl_phytec_boot_state { + magic = <0x883b86a6>; + compatible = "barebox,state"; + backend-type = "raw"; + backend = <&backend_update_eeprom>; + backend-stridesize = <54>; + + #address-cells = <1>; + #size-cells = <1>; + bootstate { + #address-cells = <1>; + #size-cells = <1>; + last_chosen { + reg = <0x0 0x4>; + type = "uint32"; + }; + system0 { + #address-cells = <1>; + #size-cells = <1>; + remaining_attempts { + reg = <0x4 0x4>; + type = "uint32"; + default = <3>; + }; + priority { + reg = <0x8 0x4>; + type = "uint32"; + default = <21>; + }; + ok { + reg = <0xc 0x4>; + type = "uint32"; + default = <0>; + }; + }; + system1 { + #address-cells = <1>; + #size-cells = <1>; + remaining_attempts { + reg = <0x10 0x4>; + type = "uint32"; + default = <3>; + }; + priority { + reg = <0x14 0x4>; + type = "uint32"; + default = <20>; + }; + ok { + reg = <0x18 0x4>; + type = "uint32"; + default = <0>; + }; + }; + }; + }; + }; + + &eeprom { + status = "okay"; + partitions { + compatible = "fixed-partitions"; + #size-cells = <1>; + #address-cells = <1>; + backend_update_eeprom: state@0 { + reg = <0x0 0x100>; + label = "update-eeprom"; + }; + }; + }; + +To be able to boot from two systems alternately, the bootchooser needs to be +aware of the state framework configuration. For each system, a boot script is +required. For a system with NAND flash, the boot script of the first system may +look like the following: + +.. code-block:: sh + :caption: /env/boot/system0 + + #!/bin/sh + + [ -e /env/config-expansions ] && /env/config-expansions + + [ ! -e /dev/nand0.root.ubi ] && ubiattach /dev/nand0.root + + global.bootm.image="/dev/nand0.root.ubi.kernel0" + global.bootm.oftree="/dev/nand0.root.ubi.oftree0" + global.linux.bootargs.dyn.root="root=ubi0:root0 ubi.mtd=root rootfstype=ubifs" + +The second boot script has the same structure but uses the partitions containing +the second system. Machines with eMMC flash use similar boot scripts, albeit the +mounting and boot arguments look different. + +Run the following commands to create the required bootchooser non-volatile +environment variables: + +.. code-block:: + + barebox$ nv bootchooser.state_prefix=state.bootstate + barebox$ nv bootchooser.system0.boot=system0 + barebox$ nv bootchooser.system1.boot=system1 + barebox$ nv bootchooser.targets="system0 system1" + +eMMC Boot Partitions +-------------------- + +With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. + +By default, bundles built with our BSP (e.g. ``phytec-headless-bundle``) contain +the bootloader for updating eMMC boot partitions accordingly. + +Note, that the U-Boot environment still resides in the user area before the +first partition. The user area also still contains the bootloader which the +image first shipped during its initialization process. + +To manually write the bootloader to the eMMC boot partitions, first disable the +write protection: + +.. code-block:: console + + target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro + target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro + +Write the bootloader to the eMMC boot partitions: + +.. code-block:: console + + target:~$ dd if=imx-boot of=/dev/mmcblk2boot0 bs=1k seek=33 + target:~$ dd if=imx-boot of=/dev/mmcblk2boot1 bs=1k seek=33 + +This example is valid for the i.MX 8M Mini SoC. Note, that other SoCs may have +different bootloader files and require different offsets where the bootloader is +expected, specified by the seek parameter. See the following table for the +different offsets being required by each SoC: + ++--------------+------------------+-----------------------+--------------+-------------+ +| SoC | Offset User Area | Offset Boot Partition | eMMC Device | Bootloader | ++==============+==================+=======================+==============+=============+ +| i.MX 6 | 1 kiB | 0 kiB | /dev/mmcblk3 | barebox.bin | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 6UL | 1 kiB | 0 kiB | /dev/mmcblk1 | barebox.bin | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M | 33 kiB | 33 kiB | /dev/mmcblk0 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Mini | 33 kiB | 33 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Nano | 32 kiB | 0 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Plus | 32 kiB | 0 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| AM62x | N/A | 0 kiB | /dev/mmcblk0 | tiboot3.bin | +| AM62Ax | | 512 kiB | | tispl.bin | +| AM64x | | 2560 kiB | | u-boot.img | ++--------------+------------------+-----------------------+--------------+-------------+ + +Bootloader Offsets +.................. + +Note that the offset is different, depending on whether the bootloader resides +in the user area or the boot partitions of the eMMC. + +After a bootloader has been written to the eMMC boot partitions, booting from +these can be enabled by using the following command: + +.. code-block:: console + + target:~$ mmc bootpart enable 1 0 /dev/mmcblk2 + +This also means that only the bootloaders written in the eMMC boot partitions +are used. The bootloader in the user area is not used anymore. These steps are +also executed by RAUC internally when updating the target system with a bundle. + +To disable booting from the eMMC boot partitions simply enter the following +command: + +.. code-block:: console + + target:~$ mmc bootpart enable 0 0 /dev/mmcblk2 + +After this command, the eMMC user area is used to provide the bootloader. + +When using U-Boot, a similar command is also available in the bootloader: + +.. code-block:: + + u-boot=> mmc partconf 2 0 0 0 # disable + u-boot=> mmc partconf 2 0 1 0 # enable diff --git a/previews/271/_sources/rauc/manual-index.rst.txt b/previews/271/_sources/rauc/manual-index.rst.txt new file mode 100644 index 000000000..7a2efb1f0 --- /dev/null +++ b/previews/271/_sources/rauc/manual-index.rst.txt @@ -0,0 +1,33 @@ +======================================= +RAUC Update & Device Management Manuals +======================================= + +Kirkstone +========= + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + kirkstone + +Mickledore +========== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + mickledore + +Scarthgap +========= + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + scarthgap diff --git a/previews/271/_sources/rauc/mickledore.rst.txt b/previews/271/_sources/rauc/mickledore.rst.txt new file mode 100644 index 000000000..8441d18b3 --- /dev/null +++ b/previews/271/_sources/rauc/mickledore.rst.txt @@ -0,0 +1,1045 @@ +.. Download links +.. _`static-pdf-dl`: ../_static/rauc-mickledore.pdf + +.. RAUC +.. |yocto-codename| replace:: Mickledore +.. |rauc-manual| replace:: RAUC Update & Device Management Manual + +.. only:: html + + Documentation in pdf format: `Download `_ + ++---------------------------------------------------------------+ +| |rauc-manual| | ++=======================+=======================================+ +| Document Title | |rauc-manual| |yocto-codename| | ++-----------------------+---------------------------------------+ +| Document Type | RAUC Update & Device Management | +| | Manual | ++-----------------------+---------------------------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+---------------------------------------+ +| Is Branch of | |rauc-manual| | ++-----------------------+---------------------------------------+ + ++-------------------------------------+------------------+------------------+------------+ +| Compatible BSPs | BSP Release Type | BSP Release Date | BSP Status | ++=====================================+==================+==================+============+ +| BSP-Yocto-NXP-i.MX93-PD24.1.0 | Major | 05.02.2024 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX93-PD24.1.1 | Minor | 08.05.2024 | released | ++-------------------------------------+------------------+------------------+------------+ + +This manual was tested using the Yocto version |yocto-codename|. + +Introduction +============ + +PHYTEC's Yocto distribution Ampliphy (former Yogurt) supports the `RAUC +`_ (Robust Auto-Update Controller) +mechanism. RAUC controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. For +eMMC devices only, it can also update the bootloader. + +This manual describes how RAUC is used and implemented on various PHYTEC +platforms. Note, that different modules use different bootloaders and flash +storage devices, which affects the way things are handled by RAUC. Make sure to +read the correct sections fitting your platform. + +.. note:: + + This manual contains machine-specific paths and variable contents. Make sure + you are using the correct machine and device names for your application when + executing any commands. + + +System Configuration +==================== + +RAUC can be used with both eMMC and NAND flash storage. Using the distro +``ampliphy-rauc`` or ``ampliphy-vendor-rauc``, it is enabled by default and requires +no additional setup to get started. RAUC can be used in different update +scenarios. As an example, we configured the BSP to use an A/B setup to have a +completely redundant system (including the bootloader on eMMC devices). Note, +that there is an additional partition named ``config`` storing persistent +configuration data not being changed when updating. + +.. image:: /rauc/images/rauc-ab-system.png + +RAUC BSP Example Setup +---------------------- + +The partition layout is defined in the ``/etc/rauc/system.conf`` file. As an +example, this is what it looks like for i.MX 8M Mini with eMMC flash storage: + +.. code-block:: cfg + :caption: /etc/rauc/system.conf + + [system] + compatible=phyboard-polis-imx8mm-4 + bootloader=uboot + mountprefix=/mnt/rauc + + [handlers] + pre-install=/usr/lib/rauc/rauc-pre-install.sh + post-install=/usr/lib/rauc/rauc-post-install.sh + + [keyring] + path=mainca-rsa.crt.pem + + [slot.bootloader.0] + device=/dev/mmcblk2 + type=boot-emmc + + # System A + [slot.rootfs.0] + device=/dev/mmcblk2p5 + type=ext4 + bootname=system0 + + [slot.boot.0] + device=/dev/mmcblk2p1 + type=vfat + parent=rootfs.0 + + # System B + [slot.rootfs.1] + device=/dev/mmcblk2p6 + type=ext4 + bootname=system1 + + [slot.boot.1] + device=/dev/mmcblk2p2 + type=vfat + parent=rootfs.1 + +Note, that the devices specified in the slots are different depending on the +selected machine. + +.. warning:: + + Updates with RAUC use an OpenSSL certificate to verify the validity of an + image. The BSP includes a certificate that can be used for development. In a + productive system, however, it is highly recommended to use a self-created + key and certificate. If you need to change the keyring on an existing device, + see :ref:`Switching RAUC Keyrings ` for more + information. + +Design Considerations +===================== + +In order to prevent the system from locking up, it may be a good idea to utilize +a hardware watchdog. In case the Linux Kernel does not boot or another +catastrophic event occurs that prevents the system from operating normally, the +hardware watchdog then resets the system. By default, the hardware watchdog is +disabled. To enable it, refer to the corresponding BSP manual that fits your +SoM. + +Other important design considerations, as well as a checklist, can be found in +the official RAUC documentation: +https://rauc.readthedocs.io/en/latest/checklist.html + +Initial Setup +============= + +To use RAUC, the flash device needs to be written with a complete Linux system +and bootloader. The preferred method to do this is using the included tool +`partup `_. + +Flash Storage +------------- + +To flash the device with the correct partitions/volumes, use a partup package +built with the ``ampliphy-rauc`` or ``ampliphy-vendor-rauc`` distribution. +Prebuilt partup packages can be found in the BSP release. It is also possible to +build an image with this distribution yourself using Yocto. Separate build +directories are created, storing the images and packages for the RAUC system. +Initialize the build directory with the OE init script: + +.. code-block:: console + + host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source sources/poky/oe-init-build-env + +Change the distribution to ``ampliphy-rauc`` (for i.MX6, AM6x, i.MX8 mainline BSP) or +``ampliphy-vendor-rauc`` (for i.MX8, i.MX9 vendor BSP): + +.. code-block:: + :caption: build/conf/local.conf + + DISTRO ?= "ampliphy-rauc" + +Any image built with this distro now includes a full A/B system. Build the image +as usual: + +.. code-block:: console + + host:~$ bitbake phytec-headless-image + +The resulting partup package is stored in the ``deploy-ampliphy-vendor-rauc`` directory, e.g.: + +.. code-block:: + + deploy-ampliphy-vendor-rauc/images/phyboard-segin-imx93-2/phytec-headless-image-phyboard-segin-imx93-2.partup + +This partup package contains all the necessary data and configuration to flash +an eMMC. `Partup `__ can be obtained from its +`release page `_. Also, see its +README for detailed `installation instructions +`_. Partup is already installed +in our Ampliphy images, ``phytec-headless-image`` and can be directly used e.g. +from an SD card. + +.. note:: + To flash the initial RAUC system, a booted non-RAUC system is needed first on + a different flash device. E.g. you could boot a regular + ``phytec-headless-image`` image with distro ``ampliphy`` from an SD card. + +eMMC +.... + +While running a non-RAUC system from an SD card on the target, copy the +``.partup`` package built with distro ``ampliphy-rauc`` or +``ampliphy-vendor-rauc`` to the running target first: + +.. code-block:: console + + host:~$ scp phytec-headless-image-phyboard-segin-imx93-2.partup 192.168.3.11:/root + +Then install the partup package to the eMMC: + +.. code-block:: console + + target:~$ partup install phytec-headless-image-phyboard-segin-imx93-2.partup /dev/mmcblk0 + +Now the target can boot the flashed A/B system. + +NAND +.... + +.. note:: + + There are scripts provided with the bootloader barebox that previously were + used to initialize NAND flash with an A/B system: ``rauc_init_nand``, + ``rauc_flash_nand_from_tftp`` and ``rauc_flash_nand_from_mmc``. These scripts + are deprecated. It is advised to use the script ``rauc-flash-nand`` provided + in the Linux environment with PHYTEC's distribution *Ampliphy*. + +With raw NAND flash the kernel, device tree, and root filesystem are written +individually. Initialize the NAND flash with the correct volumes from a Linux on +the target: + +.. code-block:: console + + target:~$ rauc-flash-nand -k /path/to/zImage -d /path/to/oftree -r /path/to/root.ubifs + +The initialization script will automatically utilize all available space of NAND +flash. The NAND device is also determined automatically by finding the device +root in ``/proc/mtd``. + +On i.MX6 and i.MX6UL devices with barebox, use bbu (barebox update) to flash the +bootloader: + +.. code-block:: console + + target:~$ bbu.sh -f /path/to/barebox.bin + +The A/B system on NAND Flash is now ready to be booted. + +Bootloader +---------- + +Booting the A/B System by Default +................................. + +Booting the A/B system is done mostly automatically by the bootloader since the +Yocto release *hardknott*. For devices with eMMC flash storage, the +corresponding setting is written into the bootloader environment during the +building of the BSP. In particular, if the distribution ``ampliphy-rauc`` or +``ampliphy-vendor-rauc`` is used, as described previously, the bootloader should +automatically start the A/B system and have the variables set for RAUC +accordingly. + +This automatic setting can be manually changed by setting one variable in the +bootloader. The procedure is described in more detail in the following chapters +for U-Boot and barebox. + +U-Boot +...... + +After a successful boot into a Linux environment, this command is used to view +the available parameters: + +.. code-block:: console + + target:~$ fw_printenv + +You may see this parameter along with others in the output: + +.. code-block:: + + doraucboot=1 + +To manually disable or enable booting the A/B system with RAUC, set this +variable to ``0`` or ``1``: + +.. code-block:: console + + target:~$ fw_setenv doraucboot 1 + +This parameter can also be edited in U-Boot. Restart your board and hit any key +to stop the automatic boot. The environment variables can now be viewed: + +.. code-block:: + + u-boot=> printenv + +and set: + +.. code-block:: + + u-boot=> setenv doraucboot 1 + u-boot=> saveenv + +Barebox +....... + +In barebox, the system to be booted can be selected directly by its name. To +boot the A/B system, including RAUC, ``bootchooser`` is used. To boot e.g. a +regular SD card without RAUC use ``mmc`` instead, or ``nand`` for NAND devices: + +.. code-block:: + + barebox$ nv boot.default=bootchooser + +Creating RAUC Bundles +===================== + +To update your system with RAUC, a RAUC bundle (``.raucb``) needs to be created. +It contains all required images and scripts for the update and a RAUC +``manifest.raucm`` that describes the content of the bundle for the RAUC update +on the target. The BSP includes a Yocto target that lets you build a RAUC bundle +from your Yocto build. + +To create the bundle with Yocto, run the following in ``build/`` with the +distribution ``ampliphy-rauc`` or ``ampliphy-vendor-rauc`` set up, as described +previously: + +.. code-block:: console + + host:~$ bitbake phytec-headless-bundle + +This results in the creation of a ``.raucb`` bundle file in +``deploy/images//`` which can be used for updating the system as +described later. There is no need to create a ``manifest.raucm`` manually as it +is created automatically during the build of the bundle. As a reference, the +created manifest would look something like this: + +.. code-block:: cfg + :caption: manifest.raucm + + [update] + compatible=phyboard-polis-imx8mm-3 + version=r0 + description=PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0 + build=20200624074335 + + [image.rootfs] + sha256=cc3f65cd1c1993951d7a39bdb7b7d723617ac46460f8b640cd8d1622ad6e4c17 + size=99942000 + filename=phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz + + [image.boot] + sha256=bafe46679af8c6292dba22b9d402e3119ef78c6f8b458bcb6993326060de3aa4 + size=12410534 + filename=boot.tar.gz.img + +For more information about the manifest format, see +https://rauc.readthedocs.io/en/latest/reference.html#manifest. + +Updating with RAUC +================== + +To update the target system with RAUC, the RAUC bundle file previously created +first needs to be copied to the board or to a memory device that can be mounted +in Linux. One way is to copy the bundle file with ``scp``, but this requires +enough space left on the board's filesystem. To do this, boot the target board +to Linux and connect it via Ethernet to your host PC. + +On the host, run: + +.. code-block:: console + + host:~$ scp phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb root@192.168.3.11:/tmp/ + +On the target, the bundle can be verified: + +.. code-block:: console + + target:~$ rauc info /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + +and the output should look similar to this: + +.. code-block:: + + rauc-Message: 12:52:49.821: Reading bundle: /phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + rauc-Message: 12:52:49.830: Verifying bundle... + Compatible: 'phyboard-polis-imx8mm-3' + Version: 'r0' + Description: 'PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0' + Build: '20200624073212' + Hooks: '' + 2 Images: + (1) phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz + Slotclass: rootfs + Checksum: 342f67f7678d7af3f77710e1b68979f638c7f4d20393f6ffd0c36beff2789070 + Size: 180407809 + Hooks: + (2) boot.tar.gz.img + Slotclass: boot + Checksum: 8c84465b4715cc142eca2785fea09804bd970755142c9ff57e08c791e2b71f28 + Size: 12411786 + Hooks: + 0 Files + + Certificate Chain: + 0 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH Development-1 + Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + SPKI sha256: E2:47:5F:32:05:37:04:D4:8C:48:8D:A6:74:A8:21:2E:97:41:EE:88:74:B5:F4:65:75:97:76:1D:FF:1D:7B:EE + Not Before: Jan 1 00:00:00 1970 GMT + Not After: Dec 31 23:59:59 9999 GMT + 1 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + SPKI sha256: AB:5C:DB:C6:0A:ED:A4:48:B9:40:AC:B1:48:06:AA:BA:92:09:83:8C:DC:6F:E1:5F:B6:FB:0C:39:3C:3B:E6:A2 + Not Before: Jan 1 00:00:00 1970 GMT + Not After: Dec 31 23:59:59 9999 GMT + +To check the current state of the system, run: + +.. code-block:: console + + target:~$ rauc status + +and get output similar to this: + +.. code-block:: + + === System Info === + Compatible: phyboard-segin-imx6ul-6 + Variant: + Booted from: rootfs.0 (system0) + + === Bootloader === + Activated: rootfs.0 (system0) + + === Slot States === + o [rootfs.1] (/dev/ubi0_6, ubifs, inactive) + bootname: system1 + boot status: good + [dtb.1] (/dev/ubi0_3, ubivol, inactive) + [kernel.1] (/dev/ubi0_2, ubivol, inactive) + + x [rootfs.0] (/dev/ubi0_5, ubifs, booted) + bootname: system0 + boot status: good + [kernel.0] (/dev/ubi0_0, ubivol, active) + [dtb.0] (/dev/ubi0_1, ubivol, active) + +To update the currently inactive system with the downloaded bundle, run: + +.. code-block:: console + + target:~$ rauc install /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + +and reboot afterward: + +.. code-block:: console + + target:~$ reboot + +With the success of the update, RAUC automatically switches the active system to +the newly updated system. Now during reboot, RAUC counts the boot attempts of +the kernel and if it fails more often than specified in the state framework of +the system, RAUC switches back to the old system and marks the new system as +bad. If the boot attempt to the kernel is successful, the new system is marked +as good and the old system can now be updated with the same instructions. After +two successful ``rauc install`` and ``reboot``, both systems are updated. + +.. tip:: + + When you update from a USB stick, make sure to remove the stick after a + successful update before rebooting. If not, an automatic update will be + started after each boot. This is due to the :ref:`Automatic Update from USB Flash + Drive with RAUC ` you can find below. + +Changing the Active Boot Slot +----------------------------- + +It is possible to switch the active system manually: + +.. code-block:: console + + target:~$ rauc status mark-active other + +After a reboot, the target now starts from the other system. + +.. _mickledore_rauc-switch-keyrings: + +Switching RAUC Keyrings +======================= + +PHYTEC's distribution comes with keys and certificates used for development and +demonstration purposes only. To change to a different PKI when devices are +already rolled out, RAUC's keyring must be changed. This chapter describes the +full procedure from a development state to a production state. Keep in mind, +that it is always a better idea to roll out your devices with a production +keyring in the first place, instead of relying on a development one for too +long. The following diagram shows the general process of switching keyrings for +RAUC: + +.. image:: /rauc/images/rauc-switching-keyrings.png + +Keyring Switching Process +------------------------- + +Create new certificates and keys for your own PKI. See our security manual for a +detailed description on how to create a custom PKI. For this document, we refer +to this newly created PKI as "production", as opposed to the existing +"development" keys. + +Move the generated keys and certificates, to your main Yocto build directory +root, alongside with ``build/`` and ``sources/``. + +.. warning:: + + Be careful where you store the private keys! These should in no way be made + publicly available. E.g. do not store the private keys in a public Git + repository. Otherwise, unauthorized entities could create RAUC bundles that + can be installed on your target system! + +Now, a RAUC bundle must be created that contains the new "production" CA keyring +in its root filesystem but is still signed by the "development" CA. With this, +the system is converted from a "development" system to a "production" system. To +achieve this, exchange the file ``ca.cert.pem`` installed by the RAUC recipe in +the Yocto sources. Create a file ``rauc_%.bbappend`` in your own Yocto layer: + +.. code-block:: + :caption: recipes-core/rauc/rauc_%.bbappend + + FILESEXTRAPATHS_prepend := "${THISDIR}/files:" + + RAUC_KEYRING_FILE = "${CERT_PATH}/rauc-customer/ca.cert.pem" + +Build the same RAUC bundle as before, now with the exchanged keyring: + +.. code-block:: console + + host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source source/poky/oe-init-build-env + host:~$ bitbake phytec-headless-bundle # Build the desired RAUC bundle + +Install the resulting RAUC bundle as usual. The target now has the image with +the "production" keyring installed in its other slot ("System B" in the figure +above). Reboot to start that system. + +All future RAUC bundles for the "production" system must now also be signed by +the "production" CA. For this, change the key and certificate to your newly +generated "production" ones in the bundle recipe: + +.. code-block:: + :caption: recipes-images/bundles/customer-headless-bundle.bb + + require phytec-base-bundle.inc + + RAUC_SLOT_rootfs ?= "phytec-headless-image" + + RAUC_KEY_FILE = "${CERT_PATH}/rauc-customer/private/production-1.key.pem" + RAUC_CERT_FILE = "${CERT_PATH/rauc-customer/production-1.cert.pem" + + RAUC_INTERMEDIATE_CERT_FILE = "" + +Rebuild the RAUC bundle: + +.. code-block:: console + + host:~$ bitbake customer-headless-bundle + +These and any future bundles are now ready to be installed on your "production" +target system and have been fully migrated away from the "development" system. +This also means that now only bundles signed by the "production" CA can be +installed on the target (and e.g. "development" bundles cannot). + +Use Case Examples +================= + +.. _mickledore_rauc-automatic-updates-usb: + +Automatic Updates from USB Flash Drive with RAUC +------------------------------------------------ + +One of the most prominent use cases for RAUC might be an automatic update system +from a USB flash drive. This use case is implemented in the BSP as a reference +example. We combine only standard Linux mechanisms with RAUC to build the +system. The kernel notifies *udev* when a device gets plugged into the USB port. +We use a custom *udev* rule to trigger a systemd service when this event +happens. + +.. code-block:: + :caption: 10-update-usb.rules + + KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end" + + # Trigger systemd service + ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}="update-usb@%k.service" + + # Exit + LABEL="media_by_label_auto_mount_end" + +The service automatically mounts the USB flash drive and notifies the +application. + +.. code-block:: systemd + :caption: update-usb@.service + + [Unit] + Description=usb media RAUC service + After=multi-user.target + Requires=rauc.service + + [Service] + Type=oneshot + Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket + ExecStartPre=/bin/mkdir -p /media/%I + ExecStartPre=/bin/mount -t auto /dev/%I /media/%I + ExecStart=/usr/bin/update_usb.sh %I + ExecStop=/bin/umount -l /media/%i + ExecStopPost=-/bin/rmdir /media/%I + +In our reference implementation, we simply use a shell script for the +application logic. + +.. code-block:: sh + :caption: update_usb.sh + + #!/bin/sh + + MOUNT=/media/$1 + + NUMRAUCM=$(find ${MOUNT}/*.raucb -maxdepth 0 | wc -l) + + [ "$NUMRAUCM" -eq 0 ] && echo "${MOUNT}*.raucb not found" && exit + [ "$NUMRAUCM" -ne 1 ] && echo "more than one ${MOUNT}/*.raucb" && exit + + rauc install $MOUNT/*.raucb + if [ "$?" -ne 0 ]; then + echo "Failed to install RAUC bundle." + else + echo "Update successful." + fi + exit $? + +The update logic can be integrated into an application using the *systemd D-Bus +API*. RAUC does not need to be called by its command-line interface but can be +integrated with D-Bus. + +.. tip:: + + RAUC features a D-Bus API interface (see + https://rauc.readthedocs.io/en/latest/using.html#using-the-d-bus-api). + +Security Measurement: Downgrade Barrier +--------------------------------------- + +As a second reference example, we will implement a security mechanism: a +downgrade barrier. When you detect a security vulnerability on your system, you +will fix it and update your system. The systems with the new software will now +be secure again. If an attacker gets a hold of the old software update bundle, +which still has a valid signature, the attacker might have the possibility to +install the old software and still take advantage of the previously fixed +security vulnerability. To prevent this from happening, you could revoke the +updated certificate for every single update and create a new one. This might be +difficult to handle, depending on the environment. A simpler solution would be +to allow updates only in one direction using a version check. + +.. code-block:: sh + :caption: rauc_downgrade_barrier.sh + + #!/bin/sh + + VERSION_FILE=/etc/rauc/downgrade_barrier_version + MANIFEST_FILE=${RAUC_UPDATE_SOURCE}/manifest.raucm + + [ ! -f ${VERSION_FILE} ] && exit 1 + [ ! -f ${MANIFEST_FILE} ] && exit 2 + + VERSION=`cat ${VERSION_FILE} | cut -d 'r' -f 2` + BUNDLE_VERSION=`grep "version" -rI ${MANIFEST_FILE} | cut -d 'r' -f 3` + + # check from empty or unset variables + [ -z "${VERSION}" ] && exit 3 + [ -z "${BUNDLE_VERSION}" ] && exit 4 + + # developer mode, allow all updates if version is r0 + #[ ${VERSION} -eq 0 ] && exit 0 + + # downgrade barrier + if [ ${VERSION} -gt ${BUNDLE_VERSION} ]; then + echo "Downgrade barrier blocked rauc update! CODE5\n" + else + exit 0 + fi + exit 5 + +The script is installed on the target but it is not activated. You need to +remove the developer mode line in the script to activate it. + +Streaming Bundles over HTTP +--------------------------- + +Instead of copying the bundle to the device, the bundle can be streamed over +HTTP. Using bundle streaming has the advantage of not requiring local storage on +the target. A simple approach to this is running NGINX inside a Docker +container. The following example shows how to implement a minimal download +server enabling HTTP range requests to support this feature. + +Create a Dockerfile with the following content: + +.. code-block:: dockerfile + :caption: Dockerfile + + FROM nginx + + COPY bundles /bundles + COPY nginx.conf /etc/nginx/nginx.conf + +Configure NGINX to enable HTTP range requests and point it to the bundle file. + +.. code-block:: nginx + :caption: nginx.conf + + events {} + http { + server { + proxy_force_ranges on; + + location / { + root /bundles; + } + } + } + +Place a bundle in the ``bundles`` sub-directory. The folder structure looks like +the following after creating all configuration files: + +.. code-block:: console + + user@host:rauc-bundle-streaming$ find + . + ./bundles + ./bundles/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb + ./nginx.conf + ./Dockerfile + +Build and run the docker container on the host system: + +.. code-block:: console + + host:~$ sudo docker build -t rauc-bundle-streaming . + host:~$ sudo docker run --name bundles -p 80:80 -d rauc-bundle-streaming + +Install the bundle on the currently inactive target partitions: + +.. code-block:: console + + target:~$ rauc install http://192.168.3.10/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb + +.. note:: + + After the update finishes the target may display the following error which + has no impact on the success of the update: + + .. code-block:: + + [ 7416.336609] block nbd0: NBD_DISCONNECT + [ 7416.340413] block nbd0: Send disconnect failed -32 + +Reference +========= + +Boot Logic Implementation +------------------------- + +.. tip:: + + The implementation details described in this chapter serve as a reference + guide. PHYTEC BSPs that have RAUC support include these by default and the + changes are already incorporated. + +U-Boot Environment Variables +............................ + +For U-Boot, the boot logic that selects the correct partitions to boot from is +implemented in its environment. As a reference, these are the most important +U-Boot variables that are used for the A/B system with RAUC: + ++-------------------+--------------------------------------------------------+ +| Name | Function | ++===================+========================================================+ +| BOOT_ORDER | Contains a space-separated list of boot targets in the | +| | order they should be tried. This parameter is | +| | automatically set by RAUC. | ++-------------------+--------------------------------------------------------+ +| BOOT__LEFT | Contains the number of remaining boot attempts to | +| | perform for the respective slot. This parameter is | +| | automatically set by RAUC. | ++-------------------+--------------------------------------------------------+ +| ``raucinit`` | Contains the boot logic that sets the partitions so | +| | the correct system is loaded. | ++-------------------+--------------------------------------------------------+ +| ``doraucboot`` | Enables booting the A/B system if set to 1 and | +| | disables it if set to 0. | ++-------------------+--------------------------------------------------------+ +| ``raucargs`` | Sets the Kernel bootargs like console, root, and RAUC | +| | slot. | ++-------------------+--------------------------------------------------------+ +| ``raucrootpart`` | Sets the root filesystem partitions of the device. | ++-------------------+--------------------------------------------------------+ +| ``raucbootpart`` | Sets the boot partitions of the device. | ++-------------------+--------------------------------------------------------+ + +These environment variables are defined in ``include/environment/phytec/rauc.env`` in +the u-boot source code. + +.. note:: + + A change in the partition layout, e.g. when using an additional data + partition, may require changing the variables ``raucrootpart`` and + ``raucbootpart``. Make sure to rebuild your image with the new bootloader + environment after you have made the appropriate changes. + +Barebox Bootchooser Framework +............................. + +For the barebox, the boot logic that selects the correct partitions to boot from +is implemented using the bootchooser and state framework. See the barebox +documentation for detailed information about these: `Barebox Bootchooser +Framework `_, `Barebox +State Framework `_. + +First, the state framework configuration needs to be added to the barebox device +tree. Check out the :ref:`Customizing the BSP ` +chapter in the Yocto reference manual. The state framework configuration is +already included with our BSP for the supported SoC and can be directly included +in the main barebox device tree. E.g. for i.MX6 based module: + +.. code-block:: devicetree + + #include "imx6qdl-phytec-state.dtsi" + +Afterward, rebuild the image and flash the new bootloader. + +.. warning:: + + Be aware that by adding the state framework configuration, the first 160 + bytes of the EEPROM are occupied and can no longer be used for user-specific + purposes. + +The following device tree snippet shows an example of the state framework +configuration used with the BSP. As can be seen, the EEPROM is used as a backend +for the state information: + +.. code-block:: devicetree + + / { + aliases { + state = &state; + }; + + state: imx6qdl_phytec_boot_state { + magic = <0x883b86a6>; + compatible = "barebox,state"; + backend-type = "raw"; + backend = <&backend_update_eeprom>; + backend-stridesize = <54>; + + #address-cells = <1>; + #size-cells = <1>; + bootstate { + #address-cells = <1>; + #size-cells = <1>; + last_chosen { + reg = <0x0 0x4>; + type = "uint32"; + }; + system0 { + #address-cells = <1>; + #size-cells = <1>; + remaining_attempts { + reg = <0x4 0x4>; + type = "uint32"; + default = <3>; + }; + priority { + reg = <0x8 0x4>; + type = "uint32"; + default = <21>; + }; + ok { + reg = <0xc 0x4>; + type = "uint32"; + default = <0>; + }; + }; + system1 { + #address-cells = <1>; + #size-cells = <1>; + remaining_attempts { + reg = <0x10 0x4>; + type = "uint32"; + default = <3>; + }; + priority { + reg = <0x14 0x4>; + type = "uint32"; + default = <20>; + }; + ok { + reg = <0x18 0x4>; + type = "uint32"; + default = <0>; + }; + }; + }; + }; + }; + + &eeprom { + status = "okay"; + partitions { + compatible = "fixed-partitions"; + #size-cells = <1>; + #address-cells = <1>; + backend_update_eeprom: state@0 { + reg = <0x0 0x100>; + label = "update-eeprom"; + }; + }; + }; + +To be able to boot from two systems alternately, the bootchooser needs to be +aware of the state framework configuration. For each system, a boot script is +required. For a system with NAND flash, the boot script of the first system may +look like the following: + +.. code-block:: sh + :caption: /env/boot/system0 + + #!/bin/sh + + [ -e /env/config-expansions ] && /env/config-expansions + + [ ! -e /dev/nand0.root.ubi ] && ubiattach /dev/nand0.root + + global.bootm.image="/dev/nand0.root.ubi.kernel0" + global.bootm.oftree="/dev/nand0.root.ubi.oftree0" + global.linux.bootargs.dyn.root="root=ubi0:root0 ubi.mtd=root rootfstype=ubifs" + +The second boot script has the same structure but uses the partitions containing +the second system. Machines with eMMC flash use similar boot scripts, albeit the +mounting and boot arguments look different. + +Run the following commands to create the required bootchooser non-volatile +environment variables: + +.. code-block:: + + barebox$ nv bootchooser.state_prefix=state.bootstate + barebox$ nv bootchooser.system0.boot=system0 + barebox$ nv bootchooser.system1.boot=system1 + barebox$ nv bootchooser.targets="system0 system1" + +eMMC Boot Partitions +-------------------- + +With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. + +By default, bundles built with our BSP (e.g. ``phytec-headless-bundle``) contain +the bootloader for updating eMMC boot partitions accordingly. + +Note, that the U-Boot environment still resides in the user area before the +first partition. The user area also still contains the bootloader which the +image first shipped during its initialization process. + +To manually write the bootloader to the eMMC boot partitions, first disable the +write protection: + +.. code-block:: console + + target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro + target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro + +Write the bootloader to the eMMC boot partitions: + +.. code-block:: console + + target:~$ dd if=imx-boot of=/dev/mmcblk2boot0 bs=1k seek=33 + target:~$ dd if=imx-boot of=/dev/mmcblk2boot1 bs=1k seek=33 + +This example is valid for the i.MX 8M Mini SoC. Note, that other SoCs may have +different bootloader files and require different offsets where the bootloader is +expected, specified by the seek parameter. See the following table for the +different offsets being required by each SoC: + ++--------------+------------------+-----------------------+--------------+-------------+ +| SoC | Offset User Area | Offset Boot Partition | eMMC Device | Bootloader | ++==============+==================+=======================+==============+=============+ +| i.MX 6 | 1 kiB | 0 kiB | /dev/mmcblk3 | barebox.bin | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 6UL | 1 kiB | 0 kiB | /dev/mmcblk1 | barebox.bin | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M | 33 kiB | 33 kiB | /dev/mmcblk0 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Mini | 33 kiB | 33 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Nano | 32 kiB | 0 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Plus | 32 kiB | 0 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 93 | 32 kiB | 0 kiB | /dev/mmcblk0 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| AM62x | N/A | 0 kiB | /dev/mmcblk0 | tiboot3.bin | +| AM62Ax | | 512 kiB | | tispl.bin | +| AM64x | | 2560 kiB | | u-boot.img | ++--------------+------------------+-----------------------+--------------+-------------+ + +Bootloader Offsets +.................. + +Note that the offset is different, depending on whether the bootloader resides +in the user area or the boot partitions of the eMMC. + +After a bootloader has been written to the eMMC boot partitions, booting from +these can be enabled by using the following command: + +.. code-block:: console + + target:~$ mmc bootpart enable 1 0 /dev/mmcblk2 + +This also means that only the bootloaders written in the eMMC boot partitions +are used. The bootloader in the user area is not used anymore. These steps are +also executed by RAUC internally when updating the target system with a bundle. + +To disable booting from the eMMC boot partitions simply enter the following +command: + +.. code-block:: console + + target:~$ mmc bootpart enable 0 0 /dev/mmcblk2 + +After this command, the eMMC user area is used to provide the bootloader. + +When using U-Boot, a similar command is also available in the bootloader: + +.. code-block:: console + + u-boot=> mmc partconf 2 0 0 0 # disable + u-boot=> mmc partconf 2 0 1 0 # enable diff --git a/previews/271/_sources/rauc/scarthgap.rst.txt b/previews/271/_sources/rauc/scarthgap.rst.txt new file mode 100644 index 000000000..09063ef86 --- /dev/null +++ b/previews/271/_sources/rauc/scarthgap.rst.txt @@ -0,0 +1,1073 @@ +.. Download links +.. _`static-pdf-dl`: ../_static/rauc-scarthgap.pdf + +.. RAUC +.. |yocto-codename| replace:: Scarthgap +.. |rauc-manual| replace:: RAUC Update & Device Management Manual + +.. only:: html + + Documentation in pdf format: `Download `_ + ++---------------------------------------------------------------+ +| |rauc-manual| | ++=======================+=======================================+ +| Document Title | |rauc-manual| |yocto-codename| | ++-----------------------+---------------------------------------+ +| Document Type | RAUC Update & Device Management | +| | Manual | ++-----------------------+---------------------------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+---------------------------------------+ +| Is Branch of | |rauc-manual| | ++-----------------------+---------------------------------------+ + ++-------------------------------------+------------------+------------------+------------+ +| Compatible BSPs | BSP Release Type | BSP Release Date | BSP Status | ++=====================================+==================+==================+============+ +| BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.0 | Major | 2024-04-02 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 | Minor | 2024-04-09 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 | Minor | 2024-06-26 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX8MP-PD24.1.0 | Major | 2024-11-07 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX93-PD24.2.0 | Major | 2024-10-08 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX6UL-PD24.1.0 | Major | 2024-07-19 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM62Ax-PD24.1.0 | Major | 2024-06-27 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM62x-PD24.1.0 | Major | 2024-06-27 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM64x-PD24.1.0 | Major | 2024-06-27 | released | ++-------------------------------------+------------------+------------------+------------+ + +This manual was tested using the Yocto version |yocto-codename|. + +Introduction +============ + +PHYTEC's Yocto distribution Ampliphy (former Yogurt) supports the `RAUC +`_ (Robust Auto-Update Controller) +mechanism. RAUC controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. For +eMMC devices only, it can also update the bootloader. + +This manual describes how RAUC is used and implemented on various PHYTEC +platforms. Note, that different modules use different bootloaders and flash +storage devices, which affects the way things are handled by RAUC. Make sure to +read the correct sections fitting your platform. + +.. note:: + + This manual contains machine-specific paths and variable contents. Make sure + you are using the correct machine and device names for your application when + executing any commands. + + +System Configuration +==================== + +RAUC can be used with both eMMC and NAND flash storage. Using the distro +``ampliphy-rauc`` or ``ampliphy-vendor-rauc``, it is enabled by default and requires +no additional setup to get started. RAUC can be used in different update +scenarios. As an example, we configured the BSP to use an A/B setup to have a +completely redundant system (including the bootloader on eMMC devices). Note, +that there is an additional partition named ``config`` storing persistent +configuration data not being changed when updating. + +.. image:: /rauc/images/rauc-ab-system.png + +RAUC BSP Example Setup +---------------------- + +The partition layout is defined in the ``/etc/rauc/system.conf`` file. As an +example, this is what it looks like for i.MX 8M Mini with eMMC flash storage: + +.. code-block:: cfg + :caption: /etc/rauc/system.conf + + [system] + compatible=phyboard-polis-imx8mm-4 + bootloader=uboot + mountprefix=/mnt/rauc + + [handlers] + pre-install=/usr/lib/rauc/rauc-pre-install.sh + post-install=/usr/lib/rauc/rauc-post-install.sh + + [keyring] + path=mainca-rsa.crt.pem + + [slot.bootloader.0] + device=/dev/mmcblk2 + type=boot-emmc + + # System A + [slot.rootfs.0] + device=/dev/mmcblk2p5 + type=ext4 + bootname=system0 + + [slot.boot.0] + device=/dev/mmcblk2p1 + type=vfat + parent=rootfs.0 + + # System B + [slot.rootfs.1] + device=/dev/mmcblk2p6 + type=ext4 + bootname=system1 + + [slot.boot.1] + device=/dev/mmcblk2p2 + type=vfat + parent=rootfs.1 + +Note, that the devices specified in the slots are different depending on the +selected machine. + +.. warning:: + + Updates with RAUC use an OpenSSL certificate to verify the validity of an + image. The BSP includes a certificate that can be used for development. In a + productive system, however, it is highly recommended to use a self-created + key and certificate. If you need to change the keyring on an existing device, + see :ref:`Switching RAUC Keyrings ` for more + information. + +Design Considerations +===================== + +In order to prevent the system from locking up, it may be a good idea to utilize +a hardware watchdog. In case the Linux Kernel does not boot or another +catastrophic event occurs that prevents the system from operating normally, the +hardware watchdog then resets the system. By default, the hardware watchdog is +disabled. To enable it, refer to the corresponding BSP manual that fits your +SoM. + +Other important design considerations, as well as a checklist, can be found in +the official RAUC documentation: +https://rauc.readthedocs.io/en/latest/checklist.html + +Initial Setup +============= + +To use RAUC, the flash device needs to be written with a complete Linux system +and bootloader. The preferred method to do this is using the included tool +`partup `_. + +Flash Storage +------------- + +To flash the device with the correct partitions/volumes, use a partup package +built with the ``ampliphy-rauc`` or ``ampliphy-vendor-rauc`` distribution. +Prebuilt partup packages can be found in the BSP release. It is also possible to +build an image with this distribution yourself using Yocto. Separate build +directories are created, storing the images and packages for the RAUC system. +Initialize the build directory with the OE init script: + +.. code-block:: console + + host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source sources/poky/oe-init-build-env + +Change the distribution to ``ampliphy-rauc`` (for i.MX6, AM6x, i.MX8 mainline BSP) or +``ampliphy-vendor-rauc`` (for i.MX8, i.MX9 vendor BSP): + +.. code-block:: + :caption: build/conf/local.conf + + DISTRO ?= "ampliphy-rauc" + +Any image built with this distro now includes a full A/B system. Build the image +as usual: + +.. code-block:: console + + host:~$ bitbake phytec-headless-image + +The resulting partup package is stored in the ``deploy-ampliphy-vendor-rauc`` directory, e.g.: + +.. code-block:: + + deploy-ampliphy-vendor-rauc/images/phyboard-segin-imx93-2/phytec-headless-image-phyboard-segin-imx93-2.partup + +This partup package contains all the necessary data and configuration to flash +an eMMC. `Partup `__ can be obtained from its +`release page `_. Also, see its +README for detailed `installation instructions +`_. Partup is already installed +in our Ampliphy images, ``phytec-headless-image`` and can be directly used e.g. +from an SD card. + +.. note:: + To flash the initial RAUC system, a booted non-RAUC system is needed first on + a different flash device. E.g. you could boot a regular + ``phytec-headless-image`` image with distro ``ampliphy`` from an SD card. + +eMMC +.... + +While running a non-RAUC system from an SD card on the target, copy the +``.partup`` package built with distro ``ampliphy-rauc`` or +``ampliphy-vendor-rauc`` to the running target first: + +.. code-block:: console + + host:~$ scp phytec-headless-image-phyboard-segin-imx93-2.partup 192.168.3.11:/root + +Then install the partup package to the eMMC: + +.. code-block:: console + + target:~$ partup install phytec-headless-image-phyboard-segin-imx93-2.partup /dev/mmcblk0 + +Now the target can boot the flashed A/B system. + +NAND +.... + +.. note:: + + There are scripts provided with the bootloader barebox that previously were + used to initialize NAND flash with an A/B system: ``rauc_init_nand``, + ``rauc_flash_nand_from_tftp`` and ``rauc_flash_nand_from_mmc``. These scripts + are deprecated. It is advised to use the script ``rauc-flash-nand`` provided + in the Linux environment with PHYTEC's distribution *Ampliphy*. + +With raw NAND flash the kernel, device tree, and root filesystem are written +individually. Initialize the NAND flash with the correct volumes from a Linux on +the target: + +.. code-block:: console + + target:~$ rauc-flash-nand -k /path/to/zImage -d /path/to/oftree -r /path/to/root.ubifs + +The initialization script will automatically utilize all available space of NAND +flash. The NAND device is also determined automatically by finding the device +root in ``/proc/mtd``. + +On i.MX6 and i.MX6UL devices with barebox, use bbu (barebox update) to flash the +bootloader: + +.. code-block:: console + + target:~$ bbu.sh -f /path/to/barebox.bin + +The A/B system on NAND Flash is now ready to be booted. + +Bootloader +---------- + +Booting the A/B System by Default +................................. + +Booting the A/B system is done mostly automatically by the bootloader since the +Yocto release *hardknott*. For devices with eMMC flash storage, the +corresponding setting is written into the bootloader environment during the +building of the BSP. In particular, if the distribution ``ampliphy-rauc`` or +``ampliphy-vendor-rauc`` is used, as described previously, the bootloader should +automatically start the A/B system and have the variables set for RAUC +accordingly. + +This automatic setting can be manually changed by setting one variable in the +bootloader. The procedure is described in more detail in the following chapters +for U-Boot and barebox. + +U-Boot +...... + +After a successful boot into a Linux environment, this command is used to view +the available parameters: + +.. code-block:: console + + target:~$ fw_printenv + +You may see this parameter along with others in the output: + +.. code-block:: + + doraucboot=1 + +To manually disable or enable booting the A/B system with RAUC, set this +variable to ``0`` or ``1``: + +.. code-block:: console + + target:~$ fw_setenv doraucboot 1 + +This parameter can also be edited in U-Boot. Restart your board and hit any key +to stop the automatic boot. The environment variables can now be viewed: + +.. code-block:: + + u-boot=> printenv + +and set: + +.. code-block:: + + u-boot=> setenv doraucboot 1 + u-boot=> saveenv + +Barebox +....... + +In barebox, the system to be booted can be selected directly by its name. To +boot the A/B system, including RAUC, ``bootchooser`` is used. To boot e.g. a +regular SD card without RAUC use ``mmc`` instead, or ``nand`` for NAND devices: + +.. code-block:: + + barebox$ nv boot.default=bootchooser + +Creating RAUC Bundles +===================== + +To update your system with RAUC, a RAUC bundle (``.raucb``) needs to be created. +It contains all required images and scripts for the update and a RAUC +``manifest.raucm`` that describes the content of the bundle for the RAUC update +on the target. The BSP includes a Yocto target that lets you build a RAUC bundle +from your Yocto build. + +To create the bundle with Yocto, run the following in ``build/`` with the +distribution ``ampliphy-rauc`` or ``ampliphy-vendor-rauc`` set up, as described +previously: + +.. code-block:: console + + host:~$ bitbake phytec-headless-bundle + +This results in the creation of a ``.raucb`` bundle file in +``deploy/images//`` which can be used for updating the system as +described later. There is no need to create a ``manifest.raucm`` manually as it +is created automatically during the build of the bundle. As a reference, the +created manifest would look something like this: + +.. code-block:: cfg + :caption: manifest.raucm + + [update] + compatible=phyboard-polis-imx8mm-3 + version=r0 + description=PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0 + build=20200624074335 + + [image.rootfs] + sha256=cc3f65cd1c1993951d7a39bdb7b7d723617ac46460f8b640cd8d1622ad6e4c17 + size=99942000 + filename=phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz + + [image.boot] + sha256=bafe46679af8c6292dba22b9d402e3119ef78c6f8b458bcb6993326060de3aa4 + size=12410534 + filename=boot.tar.gz.img + +For more information about the manifest format, see +https://rauc.readthedocs.io/en/latest/reference.html#manifest. + +Creating transition bundles +--------------------------- + +Updating to a new major release can require a special RAUC bundle. + +When updating to a Scarthgap based release, add the following to your +``local.conf`` and rebuild the RAUC bundle: + +.. code-block:: + :caption: build/conf/local.conf + + RAUC_IMAGE_FSTYPE = "tar.gz" + RAUC_SLOT_rootfs[adaptive] = "" + +Updating with RAUC +================== + +To update the target system with RAUC, the RAUC bundle file previously created +first needs to be copied to the board or to a memory device that can be mounted +in Linux. One way is to copy the bundle file with ``scp``, but this requires +enough space left on the board's filesystem. To do this, boot the target board +to Linux and connect it via Ethernet to your host PC. + +On the host, run: + +.. code-block:: console + + host:~$ scp phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb root@192.168.3.11:/tmp/ + +On the target, the bundle can be verified: + +.. code-block:: console + + target:~$ rauc info /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + +and the output should look similar to this: + +.. code-block:: + + rauc-Message: 12:52:49.821: Reading bundle: /phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + rauc-Message: 12:52:49.830: Verifying bundle... + Compatible: 'phyboard-polis-imx8mm-3' + Version: 'r0' + Description: 'PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0' + Build: '20200624073212' + Hooks: '' + 2 Images: + (1) phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz + Slotclass: rootfs + Checksum: 342f67f7678d7af3f77710e1b68979f638c7f4d20393f6ffd0c36beff2789070 + Size: 180407809 + Hooks: + (2) boot.tar.gz.img + Slotclass: boot + Checksum: 8c84465b4715cc142eca2785fea09804bd970755142c9ff57e08c791e2b71f28 + Size: 12411786 + Hooks: + 0 Files + + Certificate Chain: + 0 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH Development-1 + Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + SPKI sha256: E2:47:5F:32:05:37:04:D4:8C:48:8D:A6:74:A8:21:2E:97:41:EE:88:74:B5:F4:65:75:97:76:1D:FF:1D:7B:EE + Not Before: Jan 1 00:00:00 1970 GMT + Not After: Dec 31 23:59:59 9999 GMT + 1 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + SPKI sha256: AB:5C:DB:C6:0A:ED:A4:48:B9:40:AC:B1:48:06:AA:BA:92:09:83:8C:DC:6F:E1:5F:B6:FB:0C:39:3C:3B:E6:A2 + Not Before: Jan 1 00:00:00 1970 GMT + Not After: Dec 31 23:59:59 9999 GMT + +To check the current state of the system, run: + +.. code-block:: console + + target:~$ rauc status + +and get output similar to this: + +.. code-block:: + + === System Info === + Compatible: phyboard-segin-imx6ul-6 + Variant: + Booted from: rootfs.0 (system0) + + === Bootloader === + Activated: rootfs.0 (system0) + + === Slot States === + o [rootfs.1] (/dev/ubi0_6, ubifs, inactive) + bootname: system1 + boot status: good + [dtb.1] (/dev/ubi0_3, ubivol, inactive) + [kernel.1] (/dev/ubi0_2, ubivol, inactive) + + x [rootfs.0] (/dev/ubi0_5, ubifs, booted) + bootname: system0 + boot status: good + [kernel.0] (/dev/ubi0_0, ubivol, active) + [dtb.0] (/dev/ubi0_1, ubivol, active) + +To update the currently inactive system with the downloaded bundle, run: + +.. code-block:: console + + target:~$ rauc install /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + +and reboot afterward: + +.. code-block:: console + + target:~$ reboot + +With the success of the update, RAUC automatically switches the active system to +the newly updated system. Now during reboot, RAUC counts the boot attempts of +the kernel and if it fails more often than specified in the state framework of +the system, RAUC switches back to the old system and marks the new system as +bad. If the boot attempt to the kernel is successful, the new system is marked +as good and the old system can now be updated with the same instructions. After +two successful ``rauc install`` and ``reboot``, both systems are updated. + +.. tip:: + + When you update from a USB stick, make sure to remove the stick after a + successful update before rebooting. If not, an automatic update will be + started after each boot. This is due to the :ref:`Automatic Update from USB Flash + Drive with RAUC ` you can find below. + +Changing the Active Boot Slot +----------------------------- + +It is possible to switch the active system manually: + +.. code-block:: console + + target:~$ rauc status mark-active other + +After a reboot, the target now starts from the other system. + +.. _scarthgap_rauc-switch-keyrings: + +Switching RAUC Keyrings +======================= + +PHYTEC's distribution comes with keys and certificates used for development and +demonstration purposes only. To change to a different PKI when devices are +already rolled out, RAUC's keyring must be changed. This chapter describes the +full procedure from a development state to a production state. Keep in mind, +that it is always a better idea to roll out your devices with a production +keyring in the first place, instead of relying on a development one for too +long. The following diagram shows the general process of switching keyrings for +RAUC: + +.. image:: /rauc/images/rauc-switching-keyrings.png + +Keyring Switching Process +------------------------- + +Create new certificates and keys for your own PKI. See our security manual for a +detailed description on how to create a custom PKI. For this document, we refer +to this newly created PKI as "production", as opposed to the existing +"development" keys. + +Move the generated keys and certificates, to your main Yocto build directory +root, alongside with ``build/`` and ``sources/``. + +.. warning:: + + Be careful where you store the private keys! These should in no way be made + publicly available. E.g. do not store the private keys in a public Git + repository. Otherwise, unauthorized entities could create RAUC bundles that + can be installed on your target system! + +Now, a RAUC bundle must be created that contains the new "production" CA keyring +in its root filesystem but is still signed by the "development" CA. With this, +the system is converted from a "development" system to a "production" system. To +achieve this, exchange the file ``ca.cert.pem`` installed by the RAUC recipe in +the Yocto sources. Create a file ``rauc_%.bbappend`` in your own Yocto layer: + +.. code-block:: + :caption: recipes-core/rauc/rauc_%.bbappend + + FILESEXTRAPATHS_prepend := "${THISDIR}/files:" + + RAUC_KEYRING_FILE = "${CERT_PATH}/rauc-customer/ca.cert.pem" + +Build the same RAUC bundle as before, now with the exchanged keyring: + +.. code-block:: console + + host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source source/poky/oe-init-build-env + host:~$ bitbake phytec-headless-bundle # Build the desired RAUC bundle + +Install the resulting RAUC bundle as usual. The target now has the image with +the "production" keyring installed in its other slot ("System B" in the figure +above). Reboot to start that system. + +All future RAUC bundles for the "production" system must now also be signed by +the "production" CA. For this, change the key and certificate to your newly +generated "production" ones in the bundle recipe: + +.. code-block:: + :caption: recipes-images/bundles/customer-headless-bundle.bb + + require phytec-base-bundle.inc + + RAUC_SLOT_rootfs ?= "phytec-headless-image" + + RAUC_KEY_FILE = "${CERT_PATH}/rauc-customer/private/production-1.key.pem" + RAUC_CERT_FILE = "${CERT_PATH/rauc-customer/production-1.cert.pem" + + RAUC_INTERMEDIATE_CERT_FILE = "" + +Rebuild the RAUC bundle: + +.. code-block:: console + + host:~$ bitbake customer-headless-bundle + +These and any future bundles are now ready to be installed on your "production" +target system and have been fully migrated away from the "development" system. +This also means that now only bundles signed by the "production" CA can be +installed on the target (and e.g. "development" bundles cannot). + +Use Case Examples +================= + +.. _scarthgap_rauc-automatic-updates-usb: + +Automatic Updates from USB Flash Drive with RAUC +------------------------------------------------ + +One of the most prominent use cases for RAUC might be an automatic update system +from a USB flash drive. This use case is implemented in the BSP as a reference +example. We combine only standard Linux mechanisms with RAUC to build the +system. The kernel notifies *udev* when a device gets plugged into the USB port. +We use a custom *udev* rule to trigger a systemd service when this event +happens. + +.. code-block:: + :caption: 10-update-usb.rules + + KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end" + + # Trigger systemd service + ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}="update-usb@%k.service" + + # Exit + LABEL="media_by_label_auto_mount_end" + +The service automatically mounts the USB flash drive and notifies the +application. + +.. code-block:: systemd + :caption: update-usb@.service + + [Unit] + Description=usb media RAUC service + After=multi-user.target + Requires=rauc.service + + [Service] + Type=oneshot + Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket + ExecStartPre=/bin/mkdir -p /media/%I + ExecStartPre=/bin/mount -t auto /dev/%I /media/%I + ExecStart=/usr/bin/update_usb.sh %I + ExecStop=/bin/umount -l /media/%i + ExecStopPost=-/bin/rmdir /media/%I + +In our reference implementation, we simply use a shell script for the +application logic. + +.. code-block:: sh + :caption: update_usb.sh + + #!/bin/sh + + MOUNT=/media/$1 + + NUMRAUCM=$(find ${MOUNT}/*.raucb -maxdepth 0 | wc -l) + + [ "$NUMRAUCM" -eq 0 ] && echo "${MOUNT}*.raucb not found" && exit + [ "$NUMRAUCM" -ne 1 ] && echo "more than one ${MOUNT}/*.raucb" && exit + + rauc install $MOUNT/*.raucb + if [ "$?" -ne 0 ]; then + echo "Failed to install RAUC bundle." + else + echo "Update successful." + fi + exit $? + +The update logic can be integrated into an application using the *systemd D-Bus +API*. RAUC does not need to be called by its command-line interface but can be +integrated with D-Bus. + +.. tip:: + + RAUC features a D-Bus API interface (see + https://rauc.readthedocs.io/en/latest/using.html#using-the-d-bus-api). + +Security Measurement: Downgrade Barrier +--------------------------------------- + +As a second reference example, we will implement a security mechanism: a +downgrade barrier. When you detect a security vulnerability on your system, you +will fix it and update your system. The systems with the new software will now +be secure again. If an attacker gets a hold of the old software update bundle, +which still has a valid signature, the attacker might have the possibility to +install the old software and still take advantage of the previously fixed +security vulnerability. To prevent this from happening, you could revoke the +updated certificate for every single update and create a new one. This might be +difficult to handle, depending on the environment. A simpler solution would be +to allow updates only in one direction using a version check. + +.. code-block:: sh + :caption: rauc_downgrade_barrier.sh + + #!/bin/sh + + VERSION_FILE=/etc/rauc/downgrade_barrier_version + MANIFEST_FILE=${RAUC_UPDATE_SOURCE}/manifest.raucm + + [ ! -f ${VERSION_FILE} ] && exit 1 + [ ! -f ${MANIFEST_FILE} ] && exit 2 + + VERSION=`cat ${VERSION_FILE} | cut -d 'r' -f 2` + BUNDLE_VERSION=`grep "version" -rI ${MANIFEST_FILE} | cut -d 'r' -f 3` + + # check from empty or unset variables + [ -z "${VERSION}" ] && exit 3 + [ -z "${BUNDLE_VERSION}" ] && exit 4 + + # developer mode, allow all updates if version is r0 + #[ ${VERSION} -eq 0 ] && exit 0 + + # downgrade barrier + if [ ${VERSION} -gt ${BUNDLE_VERSION} ]; then + echo "Downgrade barrier blocked rauc update! CODE5\n" + else + exit 0 + fi + exit 5 + +The script is installed on the target but it is not activated. You need to +remove the developer mode line in the script to activate it. + +Streaming Bundles over HTTP +--------------------------- + +Instead of copying the bundle to the device, the bundle can be streamed over +HTTP. Using bundle streaming has the advantage of not requiring local storage on +the target. A simple approach to this is running NGINX inside a Docker +container. The following example shows how to implement a minimal download +server enabling HTTP range requests to support this feature. + +Create a Dockerfile with the following content: + +.. code-block:: dockerfile + :caption: Dockerfile + + FROM nginx + + COPY bundles /bundles + COPY nginx.conf /etc/nginx/nginx.conf + +Configure NGINX to enable HTTP range requests and point it to the bundle file. + +.. code-block:: nginx + :caption: nginx.conf + + events {} + http { + server { + proxy_force_ranges on; + + location / { + root /bundles; + } + } + } + +Place a bundle in the ``bundles`` sub-directory. The folder structure looks like +the following after creating all configuration files: + +.. code-block:: console + + user@host:rauc-bundle-streaming$ find + . + ./bundles + ./bundles/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb + ./nginx.conf + ./Dockerfile + +Build and run the docker container on the host system: + +.. code-block:: console + + host:~$ sudo docker build -t rauc-bundle-streaming . + host:~$ sudo docker run --name bundles -p 80:80 -d rauc-bundle-streaming + +Install the bundle on the currently inactive target partitions: + +.. code-block:: console + + target:~$ rauc install http://192.168.3.10/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb + +.. note:: + + After the update finishes the target may display the following error which + has no impact on the success of the update: + + .. code-block:: + + [ 7416.336609] block nbd0: NBD_DISCONNECT + [ 7416.340413] block nbd0: Send disconnect failed -32 + +Reference +========= + +Boot Logic Implementation +------------------------- + +.. tip:: + + The implementation details described in this chapter serve as a reference + guide. PHYTEC BSPs that have RAUC support include these by default and the + changes are already incorporated. + +U-Boot Environment Variables +............................ + +For U-Boot, the boot logic that selects the correct partitions to boot from is +implemented in its environment. As a reference, these are the most important +U-Boot variables that are used for the A/B system with RAUC: + ++-------------------+--------------------------------------------------------+ +| Name | Function | ++===================+========================================================+ +| BOOT_ORDER | Contains a space-separated list of boot targets in the | +| | order they should be tried. This parameter is | +| | automatically set by RAUC. | ++-------------------+--------------------------------------------------------+ +| BOOT__LEFT | Contains the number of remaining boot attempts to | +| | perform for the respective slot. This parameter is | +| | automatically set by RAUC. | ++-------------------+--------------------------------------------------------+ +| ``raucinit`` | Contains the boot logic that sets the partitions so | +| | the correct system is loaded. | ++-------------------+--------------------------------------------------------+ +| ``doraucboot`` | Enables booting the A/B system if set to 1 and | +| | disables it if set to 0. | ++-------------------+--------------------------------------------------------+ +| ``raucargs`` | Sets the Kernel bootargs like console, root, and RAUC | +| | slot. | ++-------------------+--------------------------------------------------------+ +| ``raucrootpart`` | Sets the root filesystem partitions of the device. | ++-------------------+--------------------------------------------------------+ +| ``raucbootpart`` | Sets the boot partitions of the device. | ++-------------------+--------------------------------------------------------+ + +These environment variables are defined in ``include/env/phytec/rauc.env`` in +the u-boot source code. + +.. note:: + + A change in the partition layout, e.g. when using an additional data + partition, may require changing the variables ``raucrootpart`` and + ``raucbootpart``. Make sure to rebuild your image with the new bootloader + environment after you have made the appropriate changes. + +Barebox Bootchooser Framework +............................. + +For the barebox, the boot logic that selects the correct partitions to boot from +is implemented using the bootchooser and state framework. See the barebox +documentation for detailed information about these: `Barebox Bootchooser +Framework `_, `Barebox +State Framework `_. + +First, the state framework configuration needs to be added to the barebox device +tree. Check out the :ref:`Customizing the BSP ` +chapter in the Yocto reference manual. The state framework configuration is +already included with our BSP for the supported SoC and can be directly included +in the main barebox device tree. E.g. for i.MX6 based module: + +.. code-block:: devicetree + + #include "imx6qdl-phytec-state.dtsi" + +Afterward, rebuild the image and flash the new bootloader. + +.. warning:: + + Be aware that by adding the state framework configuration, the first 160 + bytes of the EEPROM are occupied and can no longer be used for user-specific + purposes. + +The following device tree snippet shows an example of the state framework +configuration used with the BSP. As can be seen, the EEPROM is used as a backend +for the state information: + +.. code-block:: devicetree + + / { + aliases { + state = &state; + }; + + state: imx6qdl_phytec_boot_state { + magic = <0x883b86a6>; + compatible = "barebox,state"; + backend-type = "raw"; + backend = <&backend_update_eeprom>; + backend-stridesize = <54>; + + #address-cells = <1>; + #size-cells = <1>; + bootstate { + #address-cells = <1>; + #size-cells = <1>; + last_chosen { + reg = <0x0 0x4>; + type = "uint32"; + }; + system0 { + #address-cells = <1>; + #size-cells = <1>; + remaining_attempts { + reg = <0x4 0x4>; + type = "uint32"; + default = <3>; + }; + priority { + reg = <0x8 0x4>; + type = "uint32"; + default = <21>; + }; + ok { + reg = <0xc 0x4>; + type = "uint32"; + default = <0>; + }; + }; + system1 { + #address-cells = <1>; + #size-cells = <1>; + remaining_attempts { + reg = <0x10 0x4>; + type = "uint32"; + default = <3>; + }; + priority { + reg = <0x14 0x4>; + type = "uint32"; + default = <20>; + }; + ok { + reg = <0x18 0x4>; + type = "uint32"; + default = <0>; + }; + }; + }; + }; + }; + + &eeprom { + status = "okay"; + partitions { + compatible = "fixed-partitions"; + #size-cells = <1>; + #address-cells = <1>; + backend_update_eeprom: state@0 { + reg = <0x0 0x100>; + label = "update-eeprom"; + }; + }; + }; + +To be able to boot from two systems alternately, the bootchooser needs to be +aware of the state framework configuration. For each system, a boot script is +required. For a system with NAND flash, the boot script of the first system may +look like the following: + +.. code-block:: sh + :caption: /env/boot/system0 + + #!/bin/sh + + [ -e /env/config-expansions ] && /env/config-expansions + + [ ! -e /dev/nand0.root.ubi ] && ubiattach /dev/nand0.root + + global.bootm.image="/dev/nand0.root.ubi.kernel0" + global.bootm.oftree="/dev/nand0.root.ubi.oftree0" + global.linux.bootargs.dyn.root="root=ubi0:root0 ubi.mtd=root rootfstype=ubifs" + +The second boot script has the same structure but uses the partitions containing +the second system. Machines with eMMC flash use similar boot scripts, albeit the +mounting and boot arguments look different. + +Run the following commands to create the required bootchooser non-volatile +environment variables: + +.. code-block:: + + barebox$ nv bootchooser.state_prefix=state.bootstate + barebox$ nv bootchooser.system0.boot=system0 + barebox$ nv bootchooser.system1.boot=system1 + barebox$ nv bootchooser.targets="system0 system1" + +eMMC Boot Partitions +-------------------- + +With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. + +By default, bundles built with our BSP (e.g. ``phytec-headless-bundle``) contain +the bootloader for updating eMMC boot partitions accordingly. + +Note, that the U-Boot environment still resides in the user area before the +first partition. The user area also still contains the bootloader which the +image first shipped during its initialization process. + +To manually write the bootloader to the eMMC boot partitions, first disable the +write protection: + +.. code-block:: console + + target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro + target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro + +Write the bootloader to the eMMC boot partitions: + +.. code-block:: console + + target:~$ dd if=imx-boot of=/dev/mmcblk2boot0 bs=1k seek=33 + target:~$ dd if=imx-boot of=/dev/mmcblk2boot1 bs=1k seek=33 + +This example is valid for the i.MX 8M Mini SoC. Note, that other SoCs may have +different bootloader files and require different offsets where the bootloader is +expected, specified by the seek parameter. See the following table for the +different offsets being required by each SoC: + ++--------------+------------------+-----------------------+--------------+-------------+ +| SoC | Offset User Area | Offset Boot Partition | eMMC Device | Bootloader | ++==============+==================+=======================+==============+=============+ +| i.MX 6 | 1 kiB | 0 kiB | /dev/mmcblk3 | barebox.bin | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 6UL | 1 kiB | 0 kiB | /dev/mmcblk1 | barebox.bin | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M | 33 kiB | 33 kiB | /dev/mmcblk0 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Mini | 33 kiB | 33 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Nano | 32 kiB | 0 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Plus | 32 kiB | 0 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 93 | 32 kiB | 0 kiB | /dev/mmcblk0 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| AM62x | N/A | 0 kiB | /dev/mmcblk0 | tiboot3.bin | +| AM62Ax | | 512 kiB | | tispl.bin | +| AM64x | | 2560 kiB | | u-boot.img | ++--------------+------------------+-----------------------+--------------+-------------+ + +Bootloader Offsets +.................. + +Note that the offset is different, depending on whether the bootloader resides +in the user area or the boot partitions of the eMMC. + +After a bootloader has been written to the eMMC boot partitions, booting from +these can be enabled by using the following command: + +.. code-block:: console + + target:~$ mmc bootpart enable 1 0 /dev/mmcblk2 + +This also means that only the bootloaders written in the eMMC boot partitions +are used. The bootloader in the user area is not used anymore. These steps are +also executed by RAUC internally when updating the target system with a bundle. + +To disable booting from the eMMC boot partitions simply enter the following +command: + +.. code-block:: console + + target:~$ mmc bootpart enable 0 0 /dev/mmcblk2 + +After this command, the eMMC user area is used to provide the bootloader. + +When using U-Boot, a similar command is also available in the bootloader: + +.. code-block:: + + u-boot=> mmc partconf 2 0 0 0 # disable + u-boot=> mmc partconf 2 0 1 0 # enable diff --git a/previews/271/_sources/yocto/kirkstone.rst.txt b/previews/271/_sources/yocto/kirkstone.rst.txt new file mode 100644 index 000000000..bfb5eca76 --- /dev/null +++ b/previews/271/_sources/yocto/kirkstone.rst.txt @@ -0,0 +1,3128 @@ +.. Download links +.. _`static-pdf-dl`: ../_static/kirkstone.pdf + +.. Yocto +.. |yocto-codename| replace:: Kirkstone +.. |yocto-ref-manual| replace:: Yocto Reference Manual +.. |distro| replace:: ampliphy-vendor-xwayland + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-------------------------------------------------------------+ +| |yocto-ref-manual| | ++=======================+=====================================+ +| Document Title | |yocto-ref-manual| |yocto-codename| | ++-----------------------+-------------------------------------+ +| Document Type | Yocto Manual | ++-----------------------+-------------------------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+-------------------------------------+ +| Is Branch of | |yocto-ref-manual| | ++-----------------------+-------------------------------------+ + ++-------------------------------------+------------------+------------------+------------+ +| Compatible BSPs | BSP Release Type | BSP Release Date | BSP Status | ++=====================================+==================+==================+============+ +| BSP-Yocto-Ampliphy-i.MX6-PD22.1.0 | Major | 14.12.2022 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX6-PD22.1.1 | Minor | 20.06.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.0 | Major | 11.08.2022 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1 | Minor | 23.05.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM335x-PD23.1.0 | Major | 25.04.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX8MM-PD23.1.0 | Major | 12.12.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX8MP-PD23.1.0 | Major | 12.12.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM62x-PD23.2.0 | Major | 28.09.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM62Ax-PD23.1.0 | Major | 28.09.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM64x-PD23.2.0 | Major | 28.09.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX7-PD23.1.0 | Major | 15.12.2023 | released | ++-------------------------------------+------------------+------------------+------------+ + + +This manual applies to all |yocto-codename| based PHYTEC releases. + +.. _yocto-man-kirkstone: + +The Yocto Project +================= + +PHYTEC Documentation +-------------------- + +PHYTEC will provide a variety of hardware and software documentation for all of +our products. This includes any or all of the following: + +- **QS Guide**: A short guide on how to set up and boot a phyCORE board along + with brief information on building a BSP, the device tree, and accessing + peripherals. +- **Hardware Manual**: A detailed description of the System on Module and + accompanying carrier board. +- **Yocto Guide**: A comprehensive guide for the Yocto version the phyCORE + uses. This guide contains an overview of Yocto; introducing, installing, and + customizing the PHYTEC BSP; how to work with programs like Poky and Bitbake; + and much more. +- **BSP Manual**: A manual specific to the BSP version of the phyCORE. + Information such as how to build the BSP, booting, updating software, device + tree, and accessing peripherals can be found here. +- **Development Environment Guide**: This guide shows how to work with the + Virtual Machine (VM) Host PHYTEC has developed and prepared to run various + Development Environments. There are detailed step-by-step instructions for + Eclipse and Qt Creator, which are included in the VM. There are instructions + for running demo projects for these programs on a phyCORE product as well. + Information on how to build a Linux host PC yourself is also a part of this + guide. +- **Pin Muxing Table**: phyCORE SOMs have an accompanying pin table (in Excel + format). This table will show the complete default signal path, from + processor to carrier board. The default device tree muxing option will also + be included. This gives a developer all the information needed in one + location to make muxing changes and design options when developing a + specialized carrier board or adapting a PHYTEC phyCORE SOM to an application. + +On top of these standard manuals and guides, PHYTEC will also provide Product +Change Notifications, Application Notes, and Technical Notes. These will be done +on a case-by-case basis. Most of the documentation can be found in the +applicable download page of our products. + +Yocto Introduction +------------------ + +Yocto is the smallest SI metric system prefix. Like milli equates to ``m = +10^-3``, and so is yocto ``y = 10^-24``. Yocto is also a project working group +of the `Linux Foundation `_ and therefore +backed up by several major companies in the field. On the `Yocto Project website +`_ you can read the official introduction: + + The Yocto Project is an open-source collaboration project that provides + templates, tools, and methods to help you create custom Linux-based systems + for embedded products regardless of the hardware architecture. It was founded + in 2010 as a collaboration among many hardware manufacturers, open-source + operating systems vendors, and electronics companies to bring some order to + the chaos of embedded Linux development. + +As said, the project wants to provide toolsets for embedded developers. It +builds on top of the long-lasting `OpenEmbedded +`_ project. It is not a Linux +distribution. But it contains the tools to create a Linux distribution +specially fitted to the product requirements. The most important step in +bringing order to the set of tools is to define a common versioning scheme and +a reference system. All subprojects have then to comply with the reference +system and have to comply with the versioning scheme. + +The release process is similar to the `Linux kernel `_. +Yocto increases its version number every six months and gives the release a +codename. The release list can be found here: +https://wiki.yoctoproject.org/wiki/Releases + +Core Components +--------------- + +The most important tools or subprojects of the *Yocto* Project are: + +- Bitbake: build engine, a task scheduler like make, interprets metadata +- OpenEmbedded-Core, a set of base layers, containing metadata of software, no + sources +- Yocto kernel + + - Optimized for embedded devices + - Includes many subprojects: rt-kernel, vendor patches + - The infrastructure provided by Wind River + - Alternative: classic kernel build → we use it to integrate our kernel into + *Yocto* + +- *Yocto* Reference BSP: *beagleboneblack*, *minnow max* +- *Poky*, the reference system, a collection of projects and tools, used to + bootstrap a new distribution based on *Yocto* + +Vocabulary +---------- + +Recipes +....... + +Recipes contain information about the software project (author, homepage, and +license). A recipe is versioned, defines dependencies, contains the URL of the +source code, and describes how to fetch, configure, and compile the sources. It +describes how to package the software, e.g. into different .deb packages, which +then contain the installation path. Recipes are basically written in *Bitbake's* +own programming language, which has a simple syntax. However, a recipe can +contain *Python* as well as a bash code. + +Classes +....... + +Classes combine functionality used inside recipes into reusable blocks. + +Layers +...... + +A layer is a collection of recipes, classes, and configuration metadata. +A layer can depend on other layers and can be included or excluded one +by one. It encapsulates a specific functionality and fulfills a specific +purpose. Each layer falls into a specific category: + +- Base +- Machine (BSP) +- Software +- Distribution +- Miscellaneous + +*Yocto's* versioning scheme is reflected in every layer as version branches. For +each *Yocto* version, every layer has a named branch in its *Git* repository. +You can add one or many layers of each category in your build. + +A collection of OpenEmbedded layers can be found here. The search function is +very helpful to see if a software package can be retrieved and integrated +easily: https://layers.openembedded.org/layerindex/branch/kirkstone/layers/ + +Machine +....... + +Machines are configuration variables that describe the aspects of the target +hardware. + +Distribution (Distro) +..................... + +Distribution describes the software configuration and comes with a set of +software features. + +Poky +---- + +*Poky* is the reference system to define *Yocto* Project compatibility. It +combines several subprojects into releases: + +- *Bitbake* +- *Toaster* +- OpenEmbedded Core +- *Yocto* Documentation +- *Yocto* Reference BSP + +Bitbake +....... + +*Bitbake* is the task scheduler. It is written in *Python* and interprets +recipes that contain code in *Bitbake's* own programming language, *Python*, and +bash code. The official documentation can be found here: +https://docs.yoctoproject.org/bitbake/2.0/index.html + +Toaster +....... + +*Toaster* is a web frontend for *Bitbake* to start and investigate builds. It +provides information about the build history and statistics on created images. +There are several use cases where the installation and maintenance of +a *Toaster* instance are beneficial. PHYTEC did not add or remove any features +to the upstream *Toaster*, provided by *Poky*. The best source for more +information is the official documentation: +https://docs.yoctoproject.org/4.0.6/toaster-manual/index.html + +Official Documentation +---------------------- + +For more general questions about *Bitbake* and *Poky* consult the mega-manual: +https://docs.yoctoproject.org/4.0.6/singleindex.html + +Compatible Linux Distributions +============================== + +To build *Yocto* you need a compatible *Linux* host development machine. The +list of supported distributions can be found in the reference manual: +https://docs.yoctoproject.org/4.0.6/ref-manual/system-requirements.html#supported-linux-distributions + +PHYTEC BSP Introduction +======================= + +BSP Structure +------------- + +The BSP consists roughly of three parts. BSP management, BSP metadata, and BSP +content. The management consists of *Repo* and phyLinux while the metadata +depends on the SOC, which describes how to build the software. The content +comprises PHYTEC's *Git* repositories and external sources. + +BSP Management +.............. + +*Yocto* is an umbrella project. Naturally, this will force the user to base +their work on several external repositories. They need to be managed in a +deterministic way. We use manifest files, which contain an XML data structure, +to describe all git repositories with pinned-down versions. The *Repo* tool and +our phyLinux wrapper script are used to manage the manifests and set up the BSP, +as described in the manifest file. + +phyLinux +~~~~~~~~ + +phyLinux is a wrapper for *Repo* to handle downloading and setting up the BSP +with an "out of the box" experience. + +Repo +~~~~ + +*Repo* is a wrapper around the *Repo* toolset. The phyLinux script will install +the wrapper in a global path. This is only a wrapper, though. Whenever you run +``repo init -u ``, you first download the *Repo* tools from *Googles* Git +server in a specific version to the ``.repo/repo`` directory. The next time you +run *Repo*, all the commands will be available. Be aware that the *Repo* version +in different build directories can differ over the years if you do not run *Repo +sync*. Also if you store information for your archives, you need to include the +complete ``.repo`` folder. + +*Repo* expects a *Git* repository which will be parsed from the command line. In +the PHYTEC BSP, it is called phy²octo. In this repository, all information about +a software BSP release is stored in the form of a *Repo* XML manifest. This data +structure defines URLs of *Git* servers (called "remotes") and *Git* +repositories and their states (called "projects"). The *Git* repositories can be +seen in different states. The revision field can be a branch, tag, or commit id +of a repository. This means the state of the software is not necessarily unique +and can change over time. That is the reason we use only tags or commit ids for +our releases. The state of the working directory is then unique and does not +change. + +The manifests for the releases have the same name as the release itself. It is a +unique identifier for the complete BSP. The releases are sorted by the SoC +platform. The selected SoC will define the branch of the phy²octo *Git* +repository which will be used for the manifest selection. + +BSP Metadata +............ + +We include several third-party layers in our BSP to get a complete *Linux* +distribution up and running without the need to integrate external projects. All +used repositories are described in the following section. + +Poky +~~~~ + +The PHYTEC BSP is built on top of *Poky*. It comes with a specific version, +defined in the *Repo* manifest. *Poky* comes with a specific version of +*Bitbake*. The OpenEmbedded-core layer "meta" is used as a base for our *Linux* +system. + +meta-openembedded +~~~~~~~~~~~~~~~~~ + +OpenEmbedded is a collection of different layers containing the meta description +for many open-source software projects. We ship all OpenEmbedded layers with our +BSP, but not all of them are activated. Our example images pull several software +packages generated from OpenEmbedded recipes. + +meta-qt6 +~~~~~~~~ + +This layer provides an integration of *Qt6* in the *Poky*-based root filesystem +and is integrated into our BSP. + +meta-nodejs +~~~~~~~~~~~ + +This is an application layer to add recent Node.js versions. + +meta-gstreamer1.0 +~~~~~~~~~~~~~~~~~ + +This is an application layer to add recent GStreamer versions. + +meta-rauc +~~~~~~~~~ + +This layer contains the tools required to build an updated infrastructure with +`RAUC `_. A comparison with +other update systems can be found here: `Yocto update tools +`_. + +meta-phytec +~~~~~~~~~~~ + +This layer contains all machines and common features for all our BSPs. It is +PHYTEC's `Yocto Board Support Package +`_ for all supported +hardware (since *fido*) and is designed to be standalone with *Poky*. Only these +two parts are required if you want to integrate the PHYTEC's hardware into your +existing *Yocto* workflow. The features are: + +- Bootloaders in ``recipes-bsp/barebox/`` and ``recipes-bsp/u-boot/`` +- Kernels in ``recipes-kernel/linux/`` and + ``dynamic-layers/fsl-bsp-release/recipes-kernel/linux/`` +- Many machines in ``conf/machine/`` +- Proprietary *OpenGL ES/EGL* user space libraries for AM335x and i.MX 6 + platforms +- Proprietary *OpenCL* libraries for i.MX 6 platforms + +meta-ampliphy +~~~~~~~~~~~~~ + +This is our example distribution and BSP layer. It extends the basic +configuration of *Poky* with software projects described by all the other BSP +components. It provides a base for your specific development scenarios. The +current features are: + +- `systemd `_ init system +- Images: ``phytec-headless-image`` for non-graphics applications +- Camera integration with OpenCV and GStreamer examples for the i.MX 6 platform + bundled in a ``phytec-vision-image`` +- RAUC integration: we set up basic support for an A/B system image update, + which is possible locally and over-the-air + +meta-qt6-phytec +~~~~~~~~~~~~~~~ + +This is our layer for Qt6 board integration and examples. The features are: + +- `Qt6 with eglfs backend `_ for + PHYTEC's AM335x, i.MX 6 and RK3288 platforms +- Images: ``phytec-qt6demo-image`` for *Qt6* and video applications +- A *Qt6* demo application demonstrating how to create a *Qt6* project using + *QML* widgets and a *Bitbake* recipe for the *Yocto* and *systemd* + integration. It can be found in + ``sources/meta-qt6-phytec/recipes-qt/examples/phytec-qtdemo_git.bb`` + +meta-virtualization +~~~~~~~~~~~~~~~~~~~ + +- This layer provides support for building Xen, KVM, Libvirt, and associated + packages necessary for constructing OE-based virtualized solutions. + +meta-security +~~~~~~~~~~~~~ + +- This layer provides security tools, hardening tools for Linux kernels, and + libraries for implementing security mechanisms. + +meta-selinux +~~~~~~~~~~~~ + +- This layer's purpose is to enable SE Linux support. The majority of this + layer's work is accomplished in *bbappend* files, used to enable SE Linux + support in existing recipes. + +meta-browser +~~~~~~~~~~~~ + +- This is an application layer to add recent web browsers (Chromium, Firefox, + etc.). + +meta-rust +~~~~~~~~~ + +- Includes the Rust compiler and the Cargo package manager for Rust. + +meta-timesys +~~~~~~~~~~~~ + +- Timesys layer for Vigiles Yocto CVE monitoring, security notifications, and + image manifest generation. + +meta-freescale +~~~~~~~~~~~~~~ + +- This layer provides support for the i.MX, Layerscape, and QorIQ product + lines. + +meta-freescale-3rdparty +~~~~~~~~~~~~~~~~~~~~~~~ + +- Provides support for boards from various vendors. + +meta-freescale-distro +~~~~~~~~~~~~~~~~~~~~~ + +- This layer provides support for Freescale's Demonstration images for use with + OpenEmbedded and/or Yocto Freescale's BSP layer. + +base (fsl-community-bsp-base) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- This layer provides BSP base files of NXP. + +meta-fsl-bsp-release +~~~~~~~~~~~~~~~~~~~~ + +- This is the i.MX Yocto Project Release Layer. + +BSP Content +........... + +The BSP content gets pulled from different online sources when you first start +using *Bitbake*. All files will be downloaded and cloned in a local directory +configured as ``DL_DIR`` in *Yocto*. If you backup your BSP with the complete +content, those sources have to be backed up, too. How you can do this will be +explained in the chapter :ref:`kirkstone_gen-source-mirrors`. + +Build Configuration +------------------- + +The BSP initializes a build folder that will contain all files you +create by running *Bitbake* commands. It contains a ``conf`` folder +that handles build input variables. + +- ``bblayers.conf`` defines activated meta-layers, +- ``local.conf`` defines build input variables specific to your build +- ``site.conf`` defines build input variables specific to the development host + +The two topmost build input variables are ``DISTRO`` and ``MACHINE``. They are +preconfigured ``local.conf`` when you check out the BSP using phyLinux. + +We use "*Ampliphy*" as ``DISTRO`` with our BSP. This distribution will be +preselected and give you a starting point for implementing your own +configuration. + +A ``MACHINE`` defines a binary image that supports specific hardware +combinations of module and baseboard. Check the ``machine.conf`` file or our +webpage for a description of the hardware. + +Pre-built Images +================ + +For each BSP we provide pre-built target images that can be downloaded from the +PHYTEC FTP server: https://download.phytec.de/Software/Linux/ + +These images are also used for the BSP tests, which are flashed to the boards +during production. You can use the provided ``.wic`` images to create a bootable +SD card at any time. Identify your hardware and flash the downloaded image file +to an empty SD card using ``dd``. Please see section Images for information +about the correct usage of the command. + +BSP Workspace Installation +========================== + +Setting Up the Host +------------------- + +You can set up the host or use one of our build-container to run a Yocto build. +You need to have a running *Linux* distribution. It should be running on a +powerful machine since a lot of compiling will need to be done. + +If you want to use a build-container, you only need to install following +packages on your host + +.. code-block:: console + + host:~$ sudo apt install wget git + +Continue with the next step :ref:`kirkstone_git-config` after that. The documentation for +using build-container can be found in this manual after +:ref:`kirkstone_phylinux-advanced-usage` of phyLinux. + +Else *Yocto* needs a handful of additional packages on your host. For *Ubuntu +20.04* you need + +.. code-block:: console + + host:~$ sudo apt install gawk wget git diffstat unzip texinfo \ + gcc build-essential chrpath socat cpio python3 python3-pip \ + python3-pexpect xz-utils debianutils iputils-ping python3-git \ + python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm \ + python3-subunit mesa-common-dev zstd liblz4-tool + +For other distributions you can find information in the *Yocto* Quick Build: +https://docs.yoctoproject.org/4.0.6/brief-yoctoprojectqs/index.html + +.. _kirkstone_git-config: + +Git Configuration +----------------- + +The BSP heavily utilizes *Git*. *Git* needs some information from +you as a user to identify who made changes. Create a ``~/.gitconfig`` with the +following content, if you do not have one + +.. code-block:: kconfig + + [user] + name = + email = + [core] + editor = vim + [merge] + tool = vimdiff + [alias] + co = checkout + br = branch + ci = commit + st = status + unstage = reset HEAD -- + last = log -1 HEAD + [push] + default = current + [color] + ui = auto + +You should set ``name`` and ``email`` in your *Git* configuration, otherwise, +*Bitbake* will complain during the first build. You can use the two commands to +set them directly without editing ``~/.gitconfig`` manually + +.. code-block:: console + + host:~$ git config --global user.email "your_email@example.com" + host:~$ git config --global user.name "name surname" + +site.conf Setup +--------------- + +Before starting the *Yocto* build, it is advisable to configure the development +setup. Two things are most important: the download directory and the cache +directory. PHYTEC strongly recommends configuring the setup as it will reduce +the compile time of consequent builds. + +A download directory is a place where *Yocto* stores all sources fetched from +the internet. It can contain tar.gz, *Git* mirror, etc. It is very useful to set +this to a common shared location on the machine. Create this directory with 777 +access rights. To share this directory with different users, all files need to +have group write access. This will most probably be in conflict with default +*umask* settings. One possible solution would be to use ACLs for this +directory + +.. code-block:: console + + host:~$ sudo apt-get install acl + host:~$ sudo setfacl -R -d -m g::rwx + +If you have already created a download directory and want to fix the permissions +afterward, you can do so with + +.. code-block:: console + + host:~$ sudo find /home/share/ -perm /u=r ! -perm /g=r -exec chmod g+r \{\} \; + host:~$ sudo find /home/share/ -perm /u=w ! -perm /g=w -exec chmod g+w \{\} \; + host:~$ sudo find /home/share/ -perm /u=x ! -perm /g=x -exec chmod g+x \{\} \; + +The cache directory stores all stages of the build process. *Poky* has quite an +involved caching infrastructure. It is advisable to create a shared directory, +as all builds can access this cache directory, called the shared state cache. + +Create the two directories on a drive where you have approximately 50 GB of +space and assign the two variables in your ``build/conf/local.conf`` + +.. code-block:: kconfig + + DL_DIR ?= "/yocto_downloads" + SSTATE_DIR ?= "/yocto_sstate" + +If you want to know more about configuring your build, see the documented +example settings + +.. code-block:: + + sources/poky/meta-yocto/conf/local.conf.sample + sources/poky/meta-yocto/conf/local.conf.sample.extended + +phyLinux Documentation +====================== + +The phyLinux script is a basic management tool for PHYTEC *Yocto* BSP releases +written in *Python*. It is mainly a helper to get started with the BSP +structure. You can get all the BSP sources without the need of interacting with +*Repo* or *Git*. + +The phyLinux script has only one real dependency. It requires the *wget* tool +installed on your host. It will also install the `Repo tool +`_ in a global path +(/usr/local/bin) on your host PC. You can install it in a different location +manually. *Repo* will be automatically detected by phyLinux if it is found in +the PATH. The *Repo* tool will be used to manage the different *Git* +repositories of the *Yocto* BSP. + +Get phyLinux +------------ + +The phyLinux script can be found on the PHYTEC download server: +https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux + +Basic Usage +----------- + +For the basic usage of phyLinux, type + +.. code-block:: console + + host:~$ ./phyLinux --help + +which will result in + +.. code-block:: + + usage: phyLinux [-h] [-v] [--verbose] {init,info,clean} ... + + This Programs sets up an environment to work with The Yocto Project on Phytecs + Development Kits. Use phyLinx -h to display the help text for the + available commands. + + positional arguments: + {init,info,clean} commands + init init the phytec bsp in the current directory + info print info about the phytec bsp in the current directory + clean Clean up the current working directory + + optional arguments: + -h, --help show this help message and exit + -v, --version show program's version number and exit + --verbose + +Initialization +-------------- + +Create a fresh project folder + +.. code-block:: console + + host:~$ mkdir ~/yocto + +Calling phyLinux will use the default Python version. Starting with Ubuntu 20.04 +it will be Python3. If you want to initiate a BSP, which is not compatible with +Python3, you need to set Python2 as default (temporarily) before running +phyLinux + +.. code-block:: console + + host:~$ ln -s \`which python2\` python && export PATH=`pwd`:$PATH + +Now run phyLinux from the new folder + +.. code-block:: console + + host:~$ ./phyLinux init + +A clean folder is important because phyLinux will clean its working directory. +Calling phyLinux from a directory that isn't empty will result in the following +**warning**:: + + This current directory is not empty. It could lead to errors in the BSP configuration + process if you continue from here. At the very least, you have to check your build directory + for settings in bblayers.conf and local.conf, which will not be handled correctly in + all cases. It is advisable to start from an empty directory of call: + $ ./phyLinux clean + Do you really want to continue from here? + [yes/no]: + +On the first initialization, the phyLinux script will ask you to install the +*Repo* tool in your */usr/local/bin* directory. During the execution of the +*init* command, you need to choose your processor platform (SoC), PHYTEC's BSP +release number, and the hardware you are working on + +.. code-block:: + + *************************************************** + * Please choose one of the available SoC Platforms: + * + * 1: am335x + * 2: am57x + * 3: am62ax + * 4: am62x + * 5: am64x + * 6: am68x + * 7: imx6 + * 8: imx6ul + * 9: imx7 + * 10: imx8 + * 11: imx8m + * 12: imx8mm + * 13: imx8mp + * 14: imx8x + * 15: imx93 + * 16: nightly + * 17: rk3288 + * 18: stm32mp13x + * 19: stm32mp15x + * 20: topic + + # Exemplary output for chosen imx6ul + *************************************************** + * Please choose one of the available Releases: + * + * 1: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc1 + * 2: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc2 + * 3: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc3 + * 4: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc4 + * 5: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc5 + * 6: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2.0 + * 7: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2.1-rc1 + * 8: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2.1 + * 9: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1-rc2 + * 10: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1-rc3 + * 11: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1-rc4 + * 12: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.0 + * 13: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1-rc1 + * 14: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1 + * 15: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.y + * 16: BSP-Yocto-Vendor-phyBOARD-Segin-PD17.1.0 + * 17: BSP-Yocto-Vendor-phyBOARD-Segin-PD17.1.1 + * 18: BSP-Yocto-Vendor-phyBOARD-Segin-PD17.1.2 + * 19: BSP-Yocto-i.MX6UL-PD19.1-rc1 + * 20: BSP-Yocto-i.MX6UL-PD19.1-rc2 + * 21: BSP-Yocto-i.MX6UL-PD19.1-rc3 + * 22: BSP-Yocto-i.MX6UL-PD19.1.0 + * 23: BSP-Yocto-i.MX6UL-PD19.1.1-rc1 + * 24: BSP-Yocto-i.MX6UL-PD19.1.1 + * 25: BSP-Yocto-i.MX6UL-PD19.1.2-rc1 + * 26: BSP-Yocto-i.MX6UL-PD19.1.2-rc2 + * 27: BSP-Yocto-i.MX6UL-PD19.1.2 + * 28: BSP-Yocto-i.MX6UL-PD21.1.0 + * 29: BSP-Yocto-i.MX6UL-PD21.1.y + * 30: BSP-Yocto-phyBOARD-Segin-PD17.2.0 + * 31: BSP-Yocto-phyBOARD-Segin-i.MX6UL-ALPHA1 + * 32: BSP-Yocto-phyBOARD-Segin-i.MX6UL-ALPHA2 + + # Exemplary output for chosen BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1 + ********************************************************************* + * Please choose one of the available builds: + * + no: machine: description and article number + distro: supported yocto distribution + target: supported build target + + 1: phyboard-segin-imx6ul-2: PHYTEC phyBOARD-Segin i.MX6 UltraLite + 512MB RAM, NAND + PB-02013-001.A2, PB-02013-110I.A2, PCL-063-23300CI.A2 + distro: ampliphy + target: phytec-headless-image + target: phytec-qt5demo-image + 2: phyboard-segin-imx6ul-6: PHYTEC phyBOARD-Segin i.MX6 ULL + 512MB RAM, NAND + PB-02013-001.A5, PB-02013-310I.A0, PCL-063-23900CI.A0 + distro: ampliphy + target: -c populate_sdk phytec-qt5demo-image + target: phytec-headless-image + target: phytec-qt5demo-image + target: phytec-vision-image + 3: phyboard-segin-imx6ul-6: PHYTEC phyBOARD-Segin i.MX6 ULL + 512MB RAM, NAND + PB-02013-001.A5, PB-02013-310I.A0, PCL-063-23900CI.A0 + distro: ampliphy-rauc + target: phytec-headless-bundle + target: phytec-headless-image + ... + + 10: phygate-tauri-s-imx6ul-1: PHYTEC phyGATE-Tauri-S i.MX6 ULL + 512MB RAM, eMMC + PB-03513.A1, PCL-063-20910CI.A0 + distro: ampliphy + target: phytec-headless-image + 11: phygate-tauri-s-imx6ul-1: PHYTEC phyGATE-Tauri-S i.MX6 ULL + 512MB RAM, eMMC + PB-03513.A1, PCL-063-20910CI.A0 + distro: ampliphy-provisioning + target: phytec-provisioning-image + 12: phygate-tauri-s-imx6ul-1: PHYTEC phyGATE-Tauri-S i.MX6 ULL + 512MB RAM, eMMC + PB-03513.A1, PCL-063-20910CI.A0 + distro: ampliphy-secure + target: phytec-security-bundle + target: phytec-security-image + +If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. After the configuration is done, +you can always run + +.. code-block:: console + + host:~$ ./phyLinux info + + # Exemplary output + *********************************************** + * The current BSP configuration is: + * + * SoC: refs/heads/imx6ul + * Release: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1 + * + *********************************************** + +to see which SoC and Release are selected in the current workspace. If +you do not want to use the selector, phyLinux also supports command-line +arguments for several settings + +.. code-block:: console + + host:~$ MACHINE=phyboard-segin-imx6ul-2 ./phyLinux init -p imx6ul -r BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1 + +or view the help command for more information + +.. code-block:: console + + host:~$ ./phyLinux init --help + + usage: phyLinux init [-h] [--verbose] [--no-init] [-o REPOREPO] [-b REPOREPO_BRANCH] [-x XML] [-u URL] [-p PLATFORM] [-r RELEASE] + + options: + -h, --help show this help message and exit + --verbose + --no-init dont execute init after fetch + -o REPOREPO Use repo tool from another url + -b REPOREPO_BRANCH Checkout different branch of repo tool + -x XML Use a local XML manifest + -u URL Manifest git url + -p PLATFORM Processor platform + -r RELEASE Release version + +After the execution of the *init* command, phyLinux will print a few important +notes as well as information for the next steps in the build process. + +.. _kirkstone_phylinux-advanced-usage: + +Advanced Usage +-------------- + +phyLinux can be used to transport software states over any medium. The state of +the software is uniquely identified by *manifest.xml*. You can create a +manifest, send it to another place and recover the software state with + +.. code-block:: console + + host:~$ ./phyLinux init -x manifest.xml + +You can also create a *Git* repository containing your software states. The +*Git* repository needs to have branches other than master, as we reserved the +master branch for different usage. Use phyLinux to check out the states + +.. code-block:: console + + host:~$ ./phyLinux -u + +Using build-container +===================== + +.. warning:: + Currently, it is not possible to run the phyLinux script inside of a container. + After a complete init with the phyLinux script on your host machine, you can use a container for the build. + If you do not have phyLinux script running on your machine, please see phyLinux Documentation. + +There are various possibilities to run a build-container. Commonly used is +docker and podman, though we prefer podman as it does not need root privileges +to run. + +Installation +------------ + +How to install podman: https://podman.io +How to install docker: https://docs.docker.com/engine/install/ + +Available container +------------------- + +Right now we provide 4 different container based on Ubuntu LTS versions: +https://hub.docker.com/u/phybuilder + +- yocto-ubuntu-16.04 +- yocto-ubuntu-18.04 +- yocto-ubuntu-20.04 +- yocto-ubuntu-22.04 + +These containers can be run with podman or docker. With Yocto Project branch |yocto-codename| the container "yocto-ubuntu-20.04" is preferred. + +Download/Pull container +----------------------- + +.. code-block:: console + + host:~$ podman pull docker.io/phybuilder/yocto-ubuntu-20.04 + + OR + + host:~$ docker pull docker.io/phybuilder/yocto-ubuntu-20.04 + +By adding a tag at the end separated by a colon, you can also pull or run a special tagged container. + + podman pull docker.io/phybuilder/yocto-ubuntu-20.04:phy2 + +You can find all available tags in our duckerhub space: + +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-16.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-18.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-20.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-22.04/tags + +If you try to run a container, which is not pulled/downloaded, it will be pulled/downloaded automatically. + +You can have a look at all downloaded/pulled container with: + +.. code-block:: console + + $USERNAME@$HOSTNAME:~$ podman images + REPOSITORY TAG IMAGE ID CREATED SIZE + docker.io/phybuilder/yocto-ubuntu-22.04 latest d626178e448d 4 months ago 935 MB + docker.io/phybuilder/yocto-ubuntu-22.04 phy2 d626178e448d 4 months ago 935 MB + docker.io/phybuilder/yocto-ubuntu-20.04 phy2 e29a88b7172a 4 months ago 900 MB + docker.io/phybuilder/yocto-ubuntu-20.04 latest e29a88b7172a 4 months ago 900 MB + docker.io/phybuilder/yocto-ubuntu-18.04 phy1 14c9c3e477d4 7 months ago 567 MB + docker.io/phybuilder/yocto-ubuntu-18.04 latest 14c9c3e477d4 7 months ago 567 MB + docker.io/phybuilder/yocto-ubuntu-16.04 phy1 28c73e13ab4f 7 months ago 599 MB + docker.io/phybuilder/yocto-ubuntu-16.04 latest 28c73e13ab4f 7 months ago 599 MB + docker.io/phybuilder/yocto-ubuntu-22.04 phy1 5a0ef4b41935 8 months ago 627 MB + docker.io/phybuilder/yocto-ubuntu-20.04 phy1 b5a26a86c39f 8 months ago 680 MB + +Run container +------------- + +To run and use container for a Yocto build, first enter to your folder, where +you run phyLinux init before. Then start the container + +.. code-block:: console + + host:~$ podman run --rm=true -v /home:/home --userns=keep-id --workdir=$PWD -it docker.io/phybuilder/yocto-ubuntu-20.04 bash + +.. note:: + To run and use a container with docker, it is not that simple like with podman. + Therefore the container-user has to be defined and configured. + Furthermore forwarding of credentials is not given per default and has to be configured as well. + +Now your commandline should look something like that (where $USERNAME is the +user, who called "podman run" and the char/number code diffs every time a +container is started) + +.. code-block:: console + + $USERNAME@6593e2c7b8f6:~$ + +.. warning:: + If the given username is "root" you will not be able to run bitbake at all. + Please be sure, you run the container with your own user. + +Now you are ready to go on and starting the build. +To stop/close the container, just call + +.. code-block:: console + + $USERNAME@6593e2c7b8f6:~$ exit + +Working with Poky and Bitbake +============================= + +Start the Build +--------------- + +After you download all the metadata with phyLinux init, you have to set up the +shell environment variables. This needs to be done every time you open a new +shell for starting builds. We use the shell script provided by *Poky* in its +default configuration. From the root of your project directory type + +.. code-block:: console + + host:~$ source sources/poky/oe-init-build-env + +The abbreviation for the source command is a single dot + +.. code-block:: console + + host:~$ . sources/poky/oe-init-build-env + +The current working directory of the shell should change to *build/*. Before +building for the first time, you should take a look at the main configuration +file + +.. code-block:: console + + host:~$ vim conf/local.conf + +Your local modifications for the current build are stored here. Depending on +the SoC, you might need to accept license agreements. For example, to build the +image for Freescale/NXP processors you need to accept the GPU and VPU binary +license agreements. You have to uncomment the corresponding line + +.. code-block:: kconfig + + # Uncomment to accept NXP EULA # EULA can be found under + ../sources/meta-freescale/EULA ACCEPT_FSL_EULA = "1" + +Now you are ready to build your first image. We suggest starting with our +smaller non-graphical image *phytec-headless-image* to see if everything is +working correctly + +.. code-block:: console + + host:~$ bitbake phytec-headless-image + +The first compile process takes about 40 minutes on a modern Intel Core i7. All +subsequent builds will use the filled caches and should take about 3 minutes. + +Images +------ + +If everything worked, the images can be found under + +.. code-block:: console + + host:~$ cd deploy/images/ + +The easiest way to test your image is to configure your board for SD card boot +and to flash the build image to the SD card + +.. code-block:: console + + host:~$ sudo dd if=phytec-headless-image-.wic of=/dev/ bs=1M conv=fsync + +Here could be "sde", for example, depending on your system. Be +very careful when selecting the right drive! Selecting the wrong drive can +erase your hard drive! The parameter conv=fsync forces a data buffer to write +to the device before dd returns. + +After booting you can log in using a serial cable or over *ssh*. There is no +root password. That is because of the debug settings in *conf/local.conf*. If +you uncomment the line + +.. code-block:: kconfig + + #EXTRA_IMAGE_FEATURES = "debug-tweaks" + +the debug settings, like setting an empty root password, will not be applied. + +Accessing the Development States between Releases +------------------------------------------------- + +Special release manifests exist to give you access to the current development +states of the *Yocto* BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line + +.. code-block:: console + + host:~$ ./phyLinux init -p master -r kirkstone + +This will initialize a BSP that will track the latest development state. From +now on running + +.. code-block:: console + + host:~$ repo sync + +this folder will pull all the latest changes from our Git repositories. + +Inspect your Build Configuration +-------------------------------- + +*Poky* includes several tools to inspect your build layout. You can inspect the +commands of the layer tool + +.. code-block:: console + + host:~$ bitbake-layers + +It can, for example, be used to view in which layer a specific recipe gets +modified + +.. code-block:: console + + host:~$ bitbake-layers show-appends + +Before running a build you can also launch *Toaster* to be able to inspect the +build details with the Toaster web GUI + +.. code-block:: console + + host:~$ source toaster start + +Maybe you need to install some requirements, first + +.. code-block:: console + + host:~$ pip3 install -r + ../sources/poky/bitbake/toaster-requirements.txt + +You can then point your browser to *http://0.0.0.0:8000/* and continue working +with *Bitbake*. All build activity can be monitored and analyzed from this web +server. If you want to learn more about *Toaster*, look at +https://docs.yoctoproject.org/4.0.6/toaster-manual/index.html. +To shut down the *Toaster* web GUI again, execute + +.. code-block:: console + + host:~$ source toaster stop + +BSP Features of meta-phytec and meta-ampliphy +--------------------------------------------- + +*Buildinfo* +........... + +The *buildinfo* task is a feature in our recipes that prints instructions to +fetch the source code from the public repositories. So you do not have to look +into the recipes yourself. To see the instructions, e.g. for the *barebox* +package, execute + +.. code-block:: console + + host:~$ bitbake barebox -c buildinfo + +in your shell. This will print something like + +.. code-block:: + + (mini) HOWTO: Use a local git repository to build barebox: + + To get source code for this package and version (barebox-2022.02.0-phy1), execute + + $ mkdir -p ~/git + $ cd ~/git + $ git clone git://git.phytec.de/barebox barebox + $ cd ~/git/barebox + $ git switch --create v2022.02.0-phy1-local-development 7fe12e65d770f7e657e683849681f339a996418b + + You now have two possible workflows for your changes: + + 1. Work inside the git repository: + Copy and paste the following snippet to your "local.conf": + + SRC_URI:pn-barebox = "git://${HOME}/git/barebox;branch=${BRANCH}" + SRCREV:pn-barebox = "${AUTOREV}" + BRANCH:pn-barebox = "v2022.02.0-phy1-local-development" + + After that you can recompile and deploy the package with + + $ bitbake barebox -c compile + $ bitbake barebox -c deploy + + Note: You have to commit all your changes. Otherwise yocto doesn't pick them up! + + 2. Work and compile from the local working directory + To work and compile in an external source directory we provide the + externalsrc.bbclass. To use it, copy and paste the following snippet to your + "local.conf": + + INHERIT += "externalsrc" + EXTERNALSRC:pn-barebox = "${HOME}/git/barebox" + EXTERNALSRC_BUILD:pn-barebox = "${HOME}/git/barebox" + + Note: All the compiling is done in the EXTERNALSRC directory. Every time + you build an Image, the package will be recompiled and build. + + NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded. + NOTE: Writing buildhistory + +As you can see, everything is explained in the output. + +.. warning:: + + Using *externalsrc* breaks a lot of *Yocto's* internal dependency + mechanisms. It is not guaranteed that any changes to the source + directory are automatically picked up by the build process and + incorporated into the root filesystem or SD card image. You have to + always use *--force*. E.g. to compile *barebox* and redeploy it to + *deploy/images/* execute + + .. code-block:: console + + host:~$ bitbake barebox -c compile --force + host:~$ bitbake barebox -c deploy + +To update the SD card image with a new kernel or image first force the +compilation of it and then force a rebuild of the root filesystem. Use + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image -c rootfs --force + +Note that the build system is not modifying the external source directory. If +you want to apply all patches the *Yocto* recipe is carrying to the external +source directory, run the line + +.. code-block:: kconfig + + SRCTREECOVEREDTASKS="" BB_ENV_PASSTHROUGH_ADDITIONS="$BB_ENV_PASSTHROUGH_ADDITIONS SRCTREECOVEREDTASKS" bitbake -c patch + +.. _kirkstone_bsp-customization: + +BSP Customization +----------------- + +To get you started with the BSP, we have summarized some basic tasks from the +*Yocto* official documentation. It describes how to add additional software to +the image, change the kernel and bootloader configuration, and integrate +patches for the kernel and bootloader. + +Minor modifications, such as adding software, are done in the file +*build/conf/local.conf*. There you can overwrite global configuration variables +and make small modifications to recipes. + +There are 2 ways to make major changes: + +1. Either create your own layer and use *bbappend* files. +2. Add everything to PHYTEC's Distro layer *meta-ampliphy*. + +Creating your own layer is described in the section Create your own Layer. + +Disable Qt Demo +............... + +By default, the BSP image *phytec-qt6demo-image* starts a Qt6 Demo application +on the attached display or monitor. If you want to stop the demo and use the +*Linux* framebuffer console behind it, connect to the target via serial cable +or *ssh* and execute the shell command + +.. code-block:: console + + target:~$ systemctl stop phytec-qtdemo.service + +This command stops the demo temporarily. To start it again, reboot the +board or execute + +.. code-block:: console + + target:~$ systemctl start phytec-qtdemo.service + +You can disable the service permanently, so it does not start on boot + +.. code-block:: console + + target:~$ systemctl disable phytec-qtdemo.service + +.. tip:: + + The last command only disables the service. It does not *stop* immediately. + To see the current status execute + + .. code-block:: console + + target:~$ systemctl status phytec-qtdemo.service + +If you want to disable the service by default, edit the file +*build/conf/local.conf* and add the following line + +.. code-block:: kconfig + + # file build/conf/local.conf + SYSTEMD_AUTO_ENABLE:pn-phytec-qtdemo = "disable" + +After that, rebuild the image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +Framebuffer Console +................... + +On boards with a display interface, the framebuffer console is enabled per +default. You can attach a USB keyboard and log in. To change the keyboard +layout from the English default to German, type + +.. code-block:: console + + target:~$ loadkeys /usr/share/keymaps/i386/qwertz/de-latin1.map.gz + +To detach the framebuffer console, run + +.. code-block:: console + + target:~$ echo 0 > sys/class/vtconsole/vtcon1/bind + +To completely deactivate the framebuffer console, disable the following kernel +configuration option + +.. code-block:: + + Device Drivers->Graphics Support->Support for framebuffer devices->Framebuffer Console Support + +More information can be found at: +https://www.kernel.org/doc/Documentation/fb/fbcon.txt + +Tools Provided in the Prebuild Image +.................................... + +RAM Benchmark +~~~~~~~~~~~~~ + +Performing RAM and cache performance tests can best be done by using *pmbw* +(Parallel Memory Bandwidth Benchmark/Measurement Tool). *Pmbw* runs several +assembly routines which all use different access patterns to the caches and RAM +of the SoC. Before running the test, make sure that you have about 2 MiB of +space left on the device for the log files. We also lower the level of the +benchmark to ask the kernel more aggressively for resources. The benchmark test +will take several hours. + +To start the test type + +.. code-block:: console + + target:~$ nice -n -2 pmbw + +Upon completion of the test run, the log file can be converted to a *gnuplot* +script with + +.. code-block:: console + + target:~$ stats2gnuplot stats.txt > run1.gnuplot + +Now you can transfer the file to the host machine and install any version of +*gnuplot* + +.. code-block:: console + + host:~$ sudo apt-get install gnuplot host:~$ gnuplot run1.gnuplot + +The generated *plots-.pdf* file contains all plots. To render single +plots as *png* files for any web output you can use *Ghostscript* + +.. code-block:: console + + host:~$ sudo apt-get install ghostscript + host:~$ gs -dNOPAUSE -dBATCH -sDEVICE=png16m -r150 -sOutputFile='page-%00d.png' plots-phyboard-wega-am335x-1.pdf + +Add Additional Software for the BSP Image +......................................... + +To add additional software to the image, look at the OpenEmbedded layer index: +https://layers.openembedded.org/layerindex/branch/kirkstone/layers/ + +First, select the *Yocto* version of the BSP you have from the drop-down list in +the top left corner and click **Recipes**. Now you can search for a software +project name and find which layer it is in. In some cases, the program is in +*meta-openembedded*, *openembedded-core*, or *Poky* which means that the recipe +is already in your build tree. This section describes how to add additional +software when this is the case. If the package is in another layer, see the next +section. + +You can also search the list of available recipes + +.. code-block:: console + + host:~$ bitbake -s | grep # fill in program name, like in + host:~$ bitbake -s | grep lsof + +When the recipe for the program is already in the *Yocto* build, you can simply +add it by appending a configuration option to your file *build/conf/local.conf*. +The general syntax to add additional software to an image is + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " " + +For example, the line + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " ldd strace file lsof" + +installs some helper programs on the target image. + +.. warning:: + + The leading whitespace is essential for the append command. + +All configuration options in local.conf apply to all images. Consequently, the +tools are now included in both images phytec-headless-image and +phytec-qt6demo-image. + +Notes about Packages and Recipes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You are adding packages to the IMAGE_INSTALL variable. Those are not necessarily +equivalent to the recipes in your meta-layers. A recipe defines per default a +package with the same name. But a recipe can set the PACKAGES variable to +something different and is able to generate packages with arbitrary names. +Whenever you look for software, you have to search for the package name and, +strictly speaking, not for the recipe. In the worst case, you have to look at +all PACKAGES variables. A tool such as *Toaster* can be helpful in some cases. + +If you can not find your software in the layers provided in the folder +*sources*, see the next section to include another layer into the *Yocto* +build. + +References: `Yocto 4.0.6 Documentation - Customizing Yocto builds +`_ + +Add an Additional Layer +....................... + +This is a step-by-step guide on how to add another layer to your *Yocto* build +and install additional software from it. As an example, we include the network +security scanner *nmap* in the layer *meta-security*. First, you must locate the +layer on which the software is hosted. Check out the `OpenEmbedded MetaData +Index `_ +and guess a little bit. The network scanner *nmap* is in the *meta-security* +layer. See `meta-security on layers.openembedded.org +`_. +To integrate it into the *Yocto* build, you have to check out the repository and +then switch to the correct stable branch. Since the BSP is based on the *Yocto* +'sumo' build, you should try to use the 'sumo' branch in the layer, too. + +.. code-block:: console + + host:~$ cd sources + host:~$ git clone git://git.yoctoproject.org/meta-security + host:~$ cd meta-security + host:~$ git branch -r + +All available remote branches will show up. Usually there should be 'fido', +'jethro', 'krogoth', 'master', ... + +.. code-block:: console + + host:~$ git checkout kirkstone + +Now we add the directory of the layer to the file *build/conf/bblayers.conf* by +appending the line + +.. code-block:: kconfig + + # file build/conf/bblayers.conf + BBLAYERS += "${BSPDIR}/sources/meta-security" + +to the end of the file. After that, you can check if the layer is available in +the build configuration by executing + +.. code-block:: console + + host:~$ bitbake-layers show-layers + +If there is an error like + +.. code-block:: + + ERROR: Layer 'security' depends on layer 'perl-layer', but this layer is not enabled in your configuration + +the layer that you want to add (here *meta-security*), depends on another layer, +which you need to enable first. E.g. the dependency required here is a layer in +*meta-openembedded* (in the PHYTEC BSP it is in the path +*sources/meta-openembedded/meta-perl/*). To enable it, add the following line to +*build/conf/bblayers.conf* + +.. code-block:: kconfig + + # file build/conf/bblayers.conf + BBLAYERS += "${BSPDIR}/sources/meta-openembedded/meta-perl" + +Now the command *bitbake-layers show-layers* should print a list of all layers +enabled including *meta-security* and *meta-perl*. After the layer is included, +you can install additional software from it as already described above. The +easiest way is to add the following line (here is the package *nmap*) + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " nmap" + +to your *build/conf/local.conf*. Do not forget to rebuild the image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +Create your own layer +.................................. + +Creating your layer should be one of the first tasks when customizing the BSP. +You have two basic options. You can either copy and rename our *meta-ampliphy*, +or you can create a new layer that will contain your changes. The better option +depends on your use case. *meta-ampliphy* is our example of how to create a +custom *Linux* distribution that will be updated in the future. If you want to +benefit from those changes and are, in general, satisfied with the userspace +configuration, it could be the best solution to create your own layer on top of +*Ampliphy*. If you need to rework a lot of information and only need the basic +hardware support from PHYTEC, it would be better to copy *meta-ampliphy*, rename +it, and adapt it to your needs. You can also have a look at the OpenEmbedded +layer index to find different distribution layers. If you just need to add your +own application to the image, create your own layer. + +In the following chapter, we have an embedded project called "racer" which we +will implement using our *Ampliphy Linux* distribution. First, we need to create +a new layer. + +*Yocto* provides a script for that. If you set up the BSP and the shell is +ready, type + +.. code-block:: console + + host:~$ bitbake-layers create-layer meta-racer + +Default options are fine for now. Move the layer to the source directory + +.. code-block:: console + + host:~$ mv meta-racer ../sources/ + +Create a *Git* repository in this layer to track your changes + +.. code-block:: console + + host:~$ cd ../sources/meta-racer + host:~$ git init && git add . && git commit -s + +Now you can add the layer directly to your build/conf/bblayers.conf + +.. code-block:: kconfig + + BBLAYERS += "${BSPDIR}/sources/meta-racer" + +or with a script provided by *Yocto* + +.. code-block:: console + + host:~$ bitbake-layers add-layer meta-racer + +Kernel and Bootloader Recipe and Version +........................................ + +First, you need to know which kernel and version are used for your target +machine. PHYTEC provides multiple kernel recipes *linux-mainline*, *linux-ti* +and *linux-imx*. The first one provides support for PHYTEC's i.MX 6 and AM335x +modules and is based on the *Linux* kernel stable releases from `kernel.org +`_. +The *Git* repositories URLs are: + +- *linux-mainline*: git://git.phytec.de/linux-mainline +- *linux-ti*: git://git.phytec.de/linux-ti +- *linux-imx:* git://git.phytec.de/linux-imx +- *barebox*: git://git.phytec.de/barebox +- *u-boot-imx*: git://git.phytec.de/u-boot-imx + +To find your kernel provider, execute the following command + +.. code-block:: console + + host:~$ bitbake virtual/kernel -e | grep "PREFERRED_PROVIDER_virtual/kernel" + +The command prints the value of the variable +*PREFERRED_PROVIDER_virtual/kernel*. The variable is used in the internal +*Yocto* build process to select the kernel recipe to use. The following lines +are different outputs you might see + +.. code-block:: kconfig + + PREFERRED_PROVIDER_virtual/kernel="linux-mainline" + PREFERRED_PROVIDER_virtual/kernel="linux-ti" + PREFERRED_PROVIDER_virtual/kernel="linux-imx" + +To see which version is used, execute *bitbake -s*. For example + +.. code-block:: console + + host:~$ bitbake -s | egrep -e "linux-mainline|linux-ti|linux-imx|barebox|u-boot-imx" + +The parameter *-s* prints the version of all recipes. The output contains the +recipe name on the left and the version on the right + +.. code-block:: + + barebox :2022.02.0-phy1-r7.0 + barebox-hosttools-native :2022.02.0-phy1-r7.0 + barebox-targettools :2022.02.0-phy1-r7.0 + linux-mainline :5.15.102-phy1-r0.0 + +As you can see, the recipe *linux-mainline* has version *5.15.102-phy1*. In +the PHYTEC's *linux-mainline* *Git* repository, you will find a corresponding +tag *v5.15.102-phy1*. The version of the *barebox* recipe is 2022.02.0-phy1. +On i.MX8M\* modules the output will contain *linux-imx* and *u-boot-imx*. + +.. _yocto-man-kirkstone-kernel-and-bootloader-conf: + +Kernel and Bootloader Configuration +................................... + +The bootloader used by PHYTEC, *barebox*, uses the same build system as the +*Linux* kernel. Therefore, all commands in this section can be used to configure +the kernel and bootloader. To configure the kernel or bootloader, execute one of +the following commands + +.. code-block:: console + + host:~$ bitbake -c menuconfig virtual/kernel # Using the virtual provider name + host:~$ bitbake -c menuconfig linux-ti # Or use the recipe name directly + host:~$ bitbake -c menuconfig linux-mainline # Or use the recipe name directly (If you use an i.MX 6 or RK3288 Module) + host:~$ bitbake -c menuconfig linux-imx # Or use the recipe name directly (If you use an i.MX 8M*) + host:~$ bitbake -c menuconfig barebox # Or change the configuration of the bootloader + host:~$ bitbake -c menuconfig u-boot-imx # Or change the configuration of the bootloader (If you use an i.MX 8M*) + +After that, you can recompile and redeploy the kernel or bootloader + +.. code-block:: console + + host:~$ bitbake virtual/kernel -c compile # Or 'barebox' for the bootloader + host:~$ bitbake virtual/kernel -c deploy # Or 'barebox' for the bootloader + +Instead, you can also just rebuild the complete build output with + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # To update the kernel/bootloader, modules and the images + +In the last command, you can replace the image name with the name of an image of +your choice. The new images and binaries are in +*build/deploy/images//*. + +.. warning:: + + The build configuration is not permanent yet. Executing *bitbake + virtual/kernel -c clean* will remove everything. + +To make your changes permanent in the build system, you have to integrate your +configuration modifications into a layer. For the configuration you have two +options: + +- Include only a configuration fragment (a minimal *diff* between the + old and new configuration) +- Complete default configuration (*defconfig*) after your + modifications. + +Having a set of configuration fragments makes what was changed at which stage +more transparent. You can turn on and off the changes, you can manage +configurations for different situations and it helps when porting changes to new +kernel versions. You can also group changes together to reflect specific use +cases. A fully assembled kernel configuration will be deployed in the directory +*build/deploy/images/*. If you do not have any of those requirements, +it might be simpler to just manage a separate *defconfig* file. + +Add a Configuration Fragment to a Recipe +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The following steps can be used for both kernel and bootloader. Just replace the +recipe name *linux-mainline* in the commands with *linux-ti*, or *barebox* for +the bootloader. If you did not already take care of this, start with a clean +build. Otherwise, the diff of the configuration may be wrong + +.. code-block:: console + + host:~$ bitbake linux-mainline -c clean + host:~$ bitbake linux-mainline -c menuconfig + +Make your configuration changes in the menu and generate a config +fragment + +.. code-block:: console + + host:~$ bitbake linux-mainline -c diffconfig + +which prints the path of the written file + +.. code-block:: + + Config fragment has been dumped into: + /home//build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg + +All config changes are in the file *fragment.cfg* which should consist of only +some lines. The following example shows how to create a *bbappend* file and how +to add the necessary lines for the config fragment. You just have to adjust the +directories and names for the specific recipe: *linux-mainline*, *linux-ti*, +linux-imx, u-boot-imx, or *barebox*. + +.. code-block:: + + sources//recipes-kernel/linux/linux-mainline_%.bbappend # For the recipe linux-mainline + sources//recipes-kernel/linux/linux-ti_%.bbappend # For the recipe linux-ti + sources//recipes-kernel/linux/linux-imx_%.bbappend # For the recipe linux-imx + sources//recipes-bsp/barebox/barebox_%.bbappend # For the recipe barebox + sources//recipes-bsp/u-boot/u-boot-imx_%.bbappend # For the recipe u-boot-imx + +Replace the string *layer* with your own layer created as shown above (e.g. +*meta-racer*), or just use *meta-ampliphy*. To use *meta-ampliphy*, first, +create the directory for the config fragment and give it a new name (here +*enable-r8169.cfg*) and move the fragment to the layer. + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features + # copy the path from the output of *diffconfig* + host:~$ cp /home//build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg \ + sources/meta-ampliphy/recipes-kernel/linux/features/enable-r8169.cfg + +Then open the *bbappend* file (in this case +*sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend* ) with +your favorite editor and add the following lines + +.. code-block:: kconfig + + # contents of the file linux-mainline_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://enable-r8169.cfg \ + " + +.. warning:: + + Do not forget to use the correct *bbappend* filenames: *linux-ti_%.bbappend* + for the linux-ti recipe and *barebox_%.bbappend* for the bootloader in the + folder *recipes-bsp/barebox/* ! + +After saving the *bbappend* file, you have to rebuild the image. *Yocto* should +pick up the recipe changes automatically and generate a new image + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +Add a Complete Default Configuration (*defconfig*) to a Recipe +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This approach is similar to the one above, but instead of adding a fragment, a +*defconfig* is used. First, create the necessary folders in the layer you want +to use, either your own layer or *meta-ampliphy* + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features/ # For both linux-mainline and linux-ti + host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features/ # Or for the bootloader + +Then you have to create a suitable *defconfig* file. Make your configuration +changes using *menuconfig* and then save the *defconfig* file to the layer + +.. code-block:: console + + host:~$ bitbake linux-mainline -c menuconfig # Or use recipe name linux-ti or barebox + host:~$ bitbake linux-mainline -c savedefconfig # Create file 'defconfig.temp' in the work directory + +This will print the path to the generated file + +.. code-block:: + + Saving defconfig to ..../defconfig.temp + +Then, as above, copy the generated file to your layer, rename it to *defconfig*, +and add the following lines to the *bbappend* file (here +*sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend*) + +.. code-block:: kconfig + + # contents of the file linux-mainline_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://defconfig \ + " + +.. tip:: + + Do not forget to use the correct bbappend filenames: *linux-ti_%.bbappend* + for the linux-ti recipe and *barebox_%.bbappend* for the bootloader in the + folder *recipes-bsp/barebox/* ! + +After that, rebuild your image as the changes are picked up automatically + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +Patch the Kernel or Bootloader with *devtool* +............................................. + +*Apart from using the standard versions of kernel and bootloader which are +provided in the recipes, you can modify the source code or use our own +repositories to build your customized kernel.* + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| Standard workflow of the | Uses additional hard drive space | +| official *Yocto* documentation | as the sources get duplicated | ++----------------------------------+----------------------------------+ +| Toolchain does not have to | No optimal cache usage, build | +| recompile everything | overhead | ++----------------------------------+----------------------------------+ + +*Devtool* is a set of helper scripts to enhance the user workflow of *Yocto*. It +was integrated with version 1.8. It is available as soon as you set up your +shell environment. *Devtool* can be used to: + +- modify existing sources +- integrate software projects into your build setup +- build software and deploy software modifications to your target + +Here we will use *devtool* to patch the kernel. We use *linux-mainline* as an +example for the AM335x Kernel. The first command we use is *devtool modify - x + * + +.. code-block:: console + + host:~$ devtool modify -x linux-mainline linux-mainline + +*Devtool* will create a layer in *build/workspace* where you can see all +modifications done by *devtool* . It will extract the sources corresponding to +the recipe to the specified directory. A *bbappend* will be created in the +workspace directing the SRC_URI to this directory. Building an image with +*Bitbake* will now use the sources in this directory. Now you can modify lines +in the kernel + +.. code-block:: console + + host:~$ vim linux-mainline/arch/arm/boot/dts/am335x-phycore-som.dtsi + -> make a change + host:~$ bitbake phytec-qt6demo-image + +Your changes will now be recompiled and added to the image. If you want to store +your changes permanently, it is advisable to create a patch from the changes, +then store and backup only the patch. You can go into the *linux-mainline* +directory and create a patch using *Git*. How to create a patch is described in +:ref:`kirkstone_temporary-method` and is the same for all methods. + +If you want to learn more about *devtool*, visit: + +`Yocto 4.0.6 - Devtool +`_ +or `Devtool Quick Reference +`_ + +.. _kirkstone_temporary-method: + +Patch the Kernel or Bootloader using the "Temporary Method" +........................................................... + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| No overhead, no extra | Changes are easily overwritten | +| configuration | by *Yocto* (Everything is | +| | lost!!). | ++----------------------------------+----------------------------------+ +| Toolchain does not have to | | +| recompile everything | | ++----------------------------------+----------------------------------+ + +It is possible to alter the source code before *Bitbake* configures and compiles +the recipe. Use *Bitbake'* s *devshell* command to jump into the source +directory of the recipe. Here is the *barebox* recipe + +.. code-block:: console + + host:~$ bitbake barebox -c devshell # or linux-mainline, linux-ti, linux-imx, u-boot-imx + +After executing the command, a shell window opens. The current working directory +of the shell will be changed to the source directory of the recipe inside the +*tmp* folder. Here you can use your favorite editor, e.g. *vim*, *emacs*, or any +other graphical editor, to alter the source code. When you are finished, exit +the *devshell* by typing *exit* or hitting **CTRL-D**. + +After leaving the *devshell* you can recompile the package + +.. code-block:: console + + host:~$ bitbake barebox -c compile --force # or linux-mainline, linux-ti, linux-imx, u-boot-imx + +The extra argument '--force' is important because *Yocto* does not recognize +that the source code was changed. + +.. tip:: + + You cannot execute the *bitbake* command in the *devshell* . You have + to leave it first. + +If the build fails, execute the devshell command again and fix it. If the build +is successful, you can deploy the package and create a new SD card image + +.. code-block:: console + + host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox.bin + host:~$ bitbake phytec-headless-image # new WIC image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic + +.. warning:: + + If you execute a clean e.g *bitbake barebox -c clean* , or if *Yocto* fetches + the source code again, all your changes are lost!!! + + To avoid this, you can create a patch and add it to a *bbappend* file. It is + the same workflow as described in the section about changing the + configuration. + + You have to create the patch in the *devshell* if you use the temporary + method and in the subdirectory created by *devtool* if you used *devtool*. + +.. code-block:: console + + host:~$ bitbake barebox -c devshell # Or linux-mainline, linux-ti + host(devshell):~$ git status # Show changes files + host(devshell):~$ git add # Add a special file to the staging area + host(devshell):~$ git commit -m "important modification" # Creates a commit with a not so useful commit message + host(devshell):~$ git format-patch -1 -o ~/ # Creates a patch of the last commit and saves it in your home folder + /home//0001-important-modification.patch # Git prints the path of the written patch file + host(devshell):~$ exit + +After you have created the patch, you must create a *bbappend* file for it. The +locations for the three different recipes - *linux-mainline* , *linux-ti* , and +*barebox* - are + +.. code-block:: + + sources//recipes-kernel/linux/linux-mainline_%.bbappend # For the recipe linux-mainline + sources//recipes-kernel/linux/linux-ti_%.bbappend # For the recipe linux-ti + sources//recipes-kernel/linux/linux-imx_%.bbappend # For the recipe linux-imx + sources//recipes-bsp/barebox/barebox_%.bbappend # For the recipe barebox + sources//recipes-bsp/u-boot/u-boot-imx_%.bbappend # For the recipe u-boot-imx + +The following example is for the recipe *barebox*. You have to adjust the paths. +First, create the folders and move the patch into them. Then create the +*bbappend* file + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features # Or use your own layer instead of *meta-ampliphy* + host:~$ cp ~/0001-important-modification.patch sources/meta-ampliphy/recipes-bsp/barebox/features # copy patch + host:~$ touch sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend + +.. tip:: + + Pay attention to your current work directory. You have to execute the + commands in the BSP top-level directory. Not in the *build* directory! + +After that use your favorite editor to add the following snipped into the +*bbappend* file (here +*sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend*) + +.. code-block:: kconfig + + # contents of the file barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://0001-important-modification.patch \ + " + +Save the file and rebuild the *barebox* recipe with + +.. code-block:: console + + host:~$ bitbake barebox -c clean # Or linux-ti, linux-mainline, linux-imx, u-boot-imx + host:~$ bitbake barebox + +If the build is successful, you can rebuild the final image with + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +**Further Resources:** + +The *Yocto* Project has some documentation for software developers. Check the +'Kernel Development Manual' for more information about how to configure the +kernel. Please note that not all of the information from the *Yocto* manual can +be applied to the PHYTEC BSP as we use the classic kernel approach of *Yocto* +and most of the documentation assumes the *Yocto* kernel approach. + +- `Yocto - Kernel Development Manual + `_ +- `Yocto - Development Manual + `_ + +Working with the Kernel and Bootloader using SRC_URI in *local.conf* +.................................................................... + +*Here we present a third option to make kernel and bootloader changes. You have +external checkouts of the linux-mainline, linux-ti, or barebox Git +repositories. You will overwrite the URL of the source code fetcher, the +variable SRC_URI, to point to your local checkout instead of the remote +repositories.* + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| All changes are saved with | Many working directories in | +| *Git* | *build/tmp-\ | +| | glibc/work///* | ++----------------------------------+----------------------------------+ +| | You have to commit every change | +| | before recompiling | ++----------------------------------+----------------------------------+ +| | For each change, the toolchain | +| | compiles everything from scratch | +| | (avoidable with *ccache*) | ++----------------------------------+----------------------------------+ + +First, you need a local clone of the *Git* repository *barebox* or +kernel. If you do not have one, use the commands + +.. code-block:: console + + host:~$ mkdir ~/git + host:~$ cd ~/git + host:~$ git clone git://git.phytec.de/barebox + host:~$ cd barebox + host:~$ git switch --create v2022.02.0-phy remotes/origin/v2022.02.0-phy + +Add the following snippet to the file build/conf/local.conf + +.. code-block:: kconfig + + # Use your own path to the git repository + # NOTE: Branch name in variable "BRANCH_pn-barebox" should be the same as the + # branch which is used in the repository folder. Otherwise your commits won't be recognized later. + BRANCH:pn-barebox = "v2022.02.0-phy" + SRC_URI:pn-barebox = "git:///${HOME}/git/barebox;branch=${BRANCH}" + SRCREV:pn-barebox = "${AUTOREV}" + +You also have to set the correct BRANCH name in the file. Either you create your +own branch in the *Git* repository, or you use the default (here +"v2015.02.0-phy"). Now you should recompile *barebox* from your own source + +.. code-block:: console + + host:~$ bitbake barebox -c clean + host:~$ bitbake barebox -c compile + +The build should be successful because the source was not changed yet. + +You can alter the source in *~/git/barebox* or the default *defconfig* (e.g. +*~/git/barebox/arch/arm/configs/imx_v7_defconfig*). After you are satisfied with +your changes, you have to make a dummy commit for *Yocto*. If you do not, +*Yocto* will not notice that the source code was modified in your repository +folder (e.g. ~/git/barebox/) + +.. code-block:: console + + host:~$ git status # show modified files + host:~$ git diff # show changed lines + host:~$ git commit -a -m "dummy commit for yocto" # This command is important! + +Try to compile your new changes. *Yocto* will automatically notice that the +source code was changed and fetches and configures everything from scratch. + +.. code-block:: console + + host:~$ bitbake barebox -c compile + +If the build fails, go back to the source directory, fix the problem, and +recommit your changes. If the build was successful, you can deploy *barebox* and +even create a new SD card image. + +.. code-block:: console + + host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox-phyflex-imx6-2.bin + host:~$ bitbake phytec-headless-image # new sd-card image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic + +If you want to make additional changes, just make another commit in the +repository and rebuild *barebox* again. + +Add Existing Software with "Sustainable Method" +............................................... + +Now that you have created your own layer, you have a second option to add +existing software to existing image definitions. Our standard image is defined +in meta-ampliphy + +.. code-block:: + + meta-ampliphy/recipes-images/images/phytec-headless-image.bb + +In your layer, you can now modify the recipe with a *bbappend* without modifying +any BSP code + +.. code-block:: + + meta-racer/recipes-images/images/phytec-headless-image.bbappend + +The append will be parsed together with the base recipe. As a result, you can +easily overwrite all variables set in the base recipe, which is not always what +you want. If we want to include additional software, we need to append it to the +IMAGE_INSTALL variable + +.. code-block:: kconfig + + IMAGE_INSTALL:append = " rsync" + +Add Linux Firmware Files to the Root Filesystem +............................................... + +It is a common task to add an extra firmware file to your root filesystem into +*/lib/firmware/*. For example, WiFi adapters or PCIe Ethernet cards might need +proprietary firmware. As a solution, we use a *bbappend* in our layer. To create +the necessary folders, *bbappend* and copy the firmware file type + +.. code-block:: console + + host:~$ cd meta-racer # go into your layer + host:~$ mkdir -p recipes-kernel/linux-firmware/linux-firmware/ + host:~$ touch recipes-kernel/linux-firmware/linux-firmware_%.bbappend + host:~$ cp ~/example-firmware.bin recipes-kernel/linux-firmware/linux-firmware/ # adapt filename + +Then add the following content to the *bbappend* file and replace every +occurrence of *example-firmware.bin* with your firmware file name. + +.. code-block:: kconfig + + # file recipes-kernel/linux-firmware/linux-firmware_%.bbappend + + FILESEXTRAPATHS:prepend := "${THISDIR}/linux-firmware:" + SRC_URI += "file://example-firmware.bin" + + do_install:append () { + install -m 0644 ${WORKDIR}/example-firmware.bin ${D}/lib/firmware/example-firmware.bin + } + + # NOTE: Use "=+" instead of "+=". Otherwise file is placed into the linux-firmware package. + PACKAGES =+ "${PN}-example" + FILES:${PN}-example = "/lib/firmware/example-firmware.bin" + +Now try to build the linux-firmware recipe + +.. code-block:: console + + host:~$ . sources/poky/oe-init-build-env + host:~$ bitbake linux-firmware + +This should generate a new package *deploy/ipk/all/linux-firmware-example*. + +As the final step, you have to install the firmware package to your image. You +can do that in your *local.conf* or image recipe via + +.. code-block:: kconfig + + # file local.conf or image recipe + IMAGE_INSTALL += "linux-firmware-example" + +.. warning:: + + Ensure that you have adapted the package name *linux-firmware-example* with + the name you assigned in *linux-firmware_%.bbappend*. + +Change the *u-boot* Environment via *bbappend* Files +.................................................... + +All i.MX8M\* products use the u-boot bootloader. The u-boot environment can be +modified using the Temporary Method. In the *u-boot-imx* sources modify the +header file corresponding to the processor located in +*include/configs/phycore_imx8m\**. New environment variables should be added at +the end of *CONFIG_EXTRA_ENV_SETTINGS* + +.. code-block:: kconfig + + #define CONFIG_EXTRA_ENV_SETTINGS \ + [...] + PHYCORE_FITIMAGE_ENV_BOOTLOGIC \ + "newvariable=1\0" + +Commit the changes and and create the file *u-boot-imx_%.bbappend* in your layer +at */recipes-bsp/u-boot/u-boot-imx_%.bbappend* + +.. code-block:: kconfig + + # contents of the file u-boot-imx_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://0001-environment-addition.patch \ + " + +Change the *barebox* Environment via *bbappend* Files +..................................................... + +Since *BSP-Yocto-AM335x-16.2.0* and *BSP-Yocto-i.MX6-PD16.1.0*, the *barebox* +environment handling in *meta-phytec* has changed. Now it is possible to add, +change, and remove files in the *barebox* environment via the *Python* bitbake +task *do_env*. There are two *Python* functions to change the environment. Their +signatures are: + +- *env_add(d, *\ **filename as string**\ *, *\ **file content as string**\ *)*: + to add a new file or overwrite an existing file +- *env_rm(d, *\ **filename as string**\ *)*: to remove a file + +The first example of a *bbappend* file in the custom layer *meta-racer* shows +how to add a new non-volatile variable *linux.bootargs.fb* in the *barebox* +environment folder */env/nv/* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_add(d, "nv/linux.bootargs.fb", "imxdrm.legacyfb_depth=32\n") + } + +The next example shows how to replace the network configuration file +*/env/network/eth0* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_add(d, "network/eth0", + """#!/bin/sh + + # ip setting (static/dhcp) + ip=static + global.dhcp.vendor_id=barebox-${global.hostname} + + # static setup used if ip=static + ipaddr=192.168.178.5 + netmask=255.255.255.0 + gateway=192.168.178.1 + serverip=192.168.178.1 + """) + } + +In the above example, the *Python* multiline string syntax **""" text """** is +used to avoid adding multiple newline characters *\\n* into the recipe *Python* +code. The *Python* function *env_add* can add and overwrite environment files. + +The next example shows how to remove an already added environment file, for +example *,* */env/boot/mmc* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_rm(d, "boot/mmc") + } + +Debugging the Environment +~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you want to see all environment files that are added in the build process, +you can enable a debug flag in the *local.conf* + +.. code-block:: kconfig + + # file local.conf + ENV_VERBOSE = "1" + +After that, you have to rebuild the *barebox* recipe to see the debugging +output + +.. code-block:: console + + host:~$ bitbake barebox -c clean + host:~$ bitbake barebox -c configure + +The output of the last command looks like this + +.. code-block:: + + [...] + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/allow_color' content "false" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.base' content "consoleblank=0" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.fb' content "imxdrm.legacyfb_depth=32" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.rootfs' content "rootwait ro fsck.repair=yes" + +Changing the Environment (depending on Machines) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you need to apply some *barebox* environment modifications only to a single +or only a few machines, you can use *Bitbake'* s machine overwrite syntax. For +the machine overwrite syntax, you append a machine name or SoC name (such as +*mx6* , *ti33x,* or *rk3288* ) with an underscore to a variable or task + +.. code-block:: kconfig + + DEPENDS:remove:mx6 = "virtual/libgl" or + python do_env_append_phyboard-mira-imx6-4(). + +The next example adds the environment variables only if the MACHINE is set to +*phyboard-mira-imx6-4* + +.. code-block:: kconfig + + # file meta-phytec/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append:phyboard-mira-imx6-4() { + env_add(d, "nv/linux.bootargs.cma", "cma=64M\n") + } + +*Bitbake's* override syntax for variables is explained in more detail at: +https://docs.yoctoproject.org/bitbake/2.0/bitbake-user-manual/bitbake-user-manual-metadata.html#conditional-metadata + +Upgrading the *barebox* Environment from Previous BSP Releases +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Prior to BSP version *BSP-Yocto-AM335x-16.2.0* and *BSP-Yocto-i.MX6-PD16.1.0* , +*barebox* environment changes via *bbappend* file were done differently. For +example, the directory structure in your meta layer (here *meta-skeleton* ) may +have looked like this + +.. code-block:: console + + $ tree -a sources/meta-skeleton/recipes-bsp/barebox/ + sources/meta-skeleton/recipes-bsp/barebox + ├── barebox + │ └── phyboard-wega-am335x-3 + │ ├── boardenv + │ │ └── .gitignore + │ └── machineenv + │ └── nv + │ └── linux.bootargs.cma + └── barebox_%.bbappend + +and the file *barebox_%.bbappend* contained + +.. code-block:: kconfig + + # file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:" + +In this example, all environment changes from the directory *boardenv* in the +layer *meta-phytec* are ignored and the file *nv/linux.bootargs.cma* is added. +For the new handling of the *barebox* environment, you use the *Python* +functions *env_add* and *env_rm* in the *Python* task *do_env*. Now the above +example translates to a single *Python* function in the file +*barebox_%.bbappend* that looks like + +.. code-block:: kconfig + + # file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:" + python do_env:append() { + # Removing files (previously boardenv) + env_rm(d, "config-expansions") + # Adding new files (previously machineenv) + env_add(d, "nv/linux.bootargs.cma", "cma=64M\n") + } + +.. _kirkstone_changing-net-config: + +Changing the Network Configuration +.................................. + +To tweak IP addresses, routes, and gateways at runtime you can use the tools +*ifconfig* and *ip* . Some examples + +.. code-block:: console + + target:~$ ip addr # Show all network interfaces + target:~$ ip route # Show all routes + target:~$ ip addr add 192.168.178.11/24 dev eth0 # Add static ip and route to interface eth0 + target:~$ ip route add default via 192.168.178.1 dev eth0 # Add default gateway 192.168.178.1 + target:~$ ip addr del 192.168.178.11/24 dev eth0 # Remove static ip address from interface eth0 + +The network configuration is managed by *systemd-networkd* . To query the +current status use + +.. code-block:: console + + target:~$ networkctl status + target:~$ networkctl list + +The network daemon reads its configuration from the directories +*/etc/systemd/network/* , */run/systemd/network/* , and */lib/systemd/network/* +(from higher to lower priority). A sample configuration in +*/lib/systemd/network/10-eth0.network* looks like this + +.. code-block:: kconfig + + # file /lib/systemd/network/10-eth0.network + [Match] + Name=eth0 + + [Network] + Address=192.168.3.11/24 + Gateway=192.168.3.10 + +These files *\*.network* replace */etc/network/interfaces* from other +distributions. You can either edit the file *10-eth0.network* in-place or copy +it to */etc/systemd/network/* and make your changes there. After changing a file +you must restart the daemon to apply your changes + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +To see the syslog message of the network daemon, use + +.. code-block:: console + + target:~$ journalctl --unit=systemd-networkd.service + +To modify the network configuration at build time, look at the recipe +*sources/meta-ampliphy/recipes-core/systemd/systemd-machine-units.bb* +and the interface files in the folder +*meta-ampliphy/recipes-core/systemd/systemd-machine-units/* where the static IP +address configuration for *eth0* (and optionally *eth1*) is done. + +For more information, see https://wiki.archlinux.org/title/Systemd-networkd +and https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html. + +Changing the Wireless Network Configuration +........................................... + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- First set the correct regulatory domain for your country + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +- Set up the wireless interface + +.. code-block:: console + + target:~$ ip link # list all interfaces. Search for wlan* + target:~$ ip link set up dev wlan0 + +- Now you can scan for available networks + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for *WEP*, *WPA*, and +*WPA2* called *wpa_supplicant* for an encrypted connection. + +- To do so, add the network credentials to the file + */etc/wpa_supplicant.conf* + +.. code-block:: kconfig + + Confluence country=DE network={ ssid="" proto=WPA2 psk="" } + +- Now a connection can be established + +.. code-block:: console + + target:~$ wpa_supplicant -Dnl80211 -c/etc/wpa_supplicant.conf -iwlan0 -B + +This should result in the following output + +.. code-block:: + + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see the section :ref:`kirkstone_changing-net-config`. + +- First, create the directory + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +- Then add the following configuration snippet in + */etc/systemd/network/10-wlan0.network* + +.. code-block:: kconfig + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +- Now, restart the network daemon so that the configuration takes effect + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Creating a WLAN Access Point +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This section provides a basic access point (AP) configuration for a +secured *WPA2* network. + +Find the name of the WLAN interface with + +.. code-block:: console + + target:~$ ip link + +Edit the configuration in */etc/hostapd.conf*. It is strongly dependent on +the use case. The following shows an example + +.. code-block:: kconfig + + # file /etc/hostapd.conf + interface=wlan0 + driver=nl80211 + ieee80211d=1 + country_code=DE + hw_mode=g + ieee80211n=1 + ssid=Test-Wifi + channel=2 + wpa=2 + wpa_passphrase=12345678 + wpa_key_mgmt=WPA-PSK + wpa_pairwise=CCMP + +Set up and start the DHCP server for the network interface *wlan0* via +*systemd-networkd* + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + target:~$ vi /etc/systemd/network/10-wlan0.network + +Insert the following text into the file + +.. code-block:: kconfig + + [Match] + Name=wlan0 + + [Network] + Address=192.168.0.1/24 + DHCPServer=yes + + [DHCPServer] + EmitDNS=yes + target:~$ systemctl restart systemd-networkd + target:~$ systemctl status systemd-networkd -l # check status and see errors + +Start the userspace daemon *hostapd* + +.. code-block:: console + + target:~$ systemctl start hostapd + target:~$ systemctl status hostapd -l # check for errors + +Now, you should see the WLAN network *Test-Wifi* on your terminal device +(laptop, smartphone, etc.). + +If there are problems with the access point, you can either check the log +messages with + +.. code-block:: console + + target:~$ journalctl --unit=hostapd + +or start the daemon in debugging mode from the command line + +.. code-block:: console + + target:~$ systemctl stop hostapd + target:~$ hostapd -d /etc/hostapd.conf -P /var/run/hostapd.pid + +You should see + +.. code-block:: + + ... + wlan0: interface state UNINITIALIZED->ENABLED + wlan0: AP-ENABLED + +Further information about AP settings and the userspace daemon +*hostapd* can be found at + +.. code-block:: + + https://wireless.wiki.kernel.org/en/users/documentation/hostapd + https://w1.fi/hostapd/ + +phyCORE-i.MX 6UL/ULL Bluetooth +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Special consideration must be paid when working with any Bluetooth on a +phyCORE-i.MX 6UL/ULL. For further information, please check `L-844e.A5 i.MX +6UL/ULL BSP Manual - Bluetooth +`_. + +Add OpenCV Libraries and Examples +................................. + +*OpenCV* (Opensource Computer Vision https://opencv.org/) is an open-source +library for computer vision applications. + +To install the libraries and examples edit the file *conf/local.conf* in the +*Yocto* build system and add + +.. code-block:: kconfig + + # file conf/local.conf + # Installing OpenCV libraries and examples + LICENSE_FLAGS_ACCEPTED += "commercial_libav" + LICENSE_FLAGS_ACCEPTED += "commercial_x264" + IMAGE_INSTALL:append = " \ + opencv \ + opencv-samples \ + libopencv-calib3d2.4 \ + libopencv-contrib2.4 \ + libopencv-core2.4 \ + libopencv-flann2.4 \ + libopencv-gpu2.4 \ + libopencv-highgui2.4 \ + libopencv-imgproc2.4 \ + libopencv-legacy2.4 \ + libopencv-ml2.4 \ + libopencv-nonfree2.4 \ + libopencv-objdetect2.4 \ + libopencv-ocl2.4 \ + libopencv-photo2.4 \ + libopencv-stitching2.4 \ + libopencv-superres2.4 \ + libopencv-video2.4 \ + libopencv-videostab2.4 \ + " + +Then rebuild your image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +.. tip:: + + Most examples do not work out of the box, because they depend on the *GTK* + graphics library. The BSP only supports *Qt6* . + +Add Minimal PHP web runtime with *lightpd* +.......................................... + +This is one example of how to add a small runtime for PHP applications and a web +server on your target. Lighttpd can be used together with the PHP command line +tool over cgi. This solution weights only 5.5 MiB of disk storage. It is already +preconfigured in meta-ampliphy. Just modify the build configuration to install +it on the image + +.. code-block:: kconfig + + # file conf/local.conf + # install lighttpd with php cgi module + IMAGE_INSTALL:append = " lighttpd" + +After booting the image, you should find the example web content in */www/pages* +. For testing php, you can delete the *index.html* and replace it with a +*index.php* file + +.. code-block:: html + + + + PHP-Test + + + + + + +On your host, you can point your browser to the board's IP, (e.g. 192.168.3.11) +and the phpinfo should show up. + +Common Tasks +------------ + +Debugging a User Space Application +.................................. + +The phytec-qt6demo-image can be cross-debugged without any change. For +cross-debugging, you just have to match the host sysroot with the image in use. +So you need to create a toolchain for your image + +.. code-block:: console + + host:~$ bitbake -c populate_sdk phytec-qt6demo-image + +Additionally, if you want to have full debug and backtrace capabilities for all +programs and libraries in the image, you could add + +.. code-block:: kconfig + + DEBUG_BUILD = "1" + +to the ``conf/local.conf``. This is not necessary in all cases. The compiler +options will then be switched from FULL_OPTIMIZATION to DEBUG_OPTIMIZATION. Look +at the *Poky* source code for the default assignment of DEBUG_OPTIMIZATION. + +To start a cross debug session, install the SDK as mentioned previously, source +the SDK environment, and run *Qt Creator* in the same shell. If you do not use +*Qt Creator*, you can directly call the arm-<..>-gdb debugger instead which +should be in your path after sourcing the environment script. + +If you work with *Qt Creator*, have a look at the appropriate documentation +delivered with your product (either QuickStart or Application Guide) for +information on how to set up the toolchain. + +When starting the debugger with your userspace application you will get a +SIGILL, an illegal instruction from the *libcrypto*. *Openssl* probes for the +system capabilities by trapping illegal instructions, which will trigger *GDB*. +You can ignore this and hit **Continue** (c command). You can permanently ignore +this stop by adding + +.. code-block:: kconfig + + handle SIGILL nostop + +to your *GDB* startup script or in the *Qt Creator GDB* configuration panel. +Secondly, you might need to disable a security feature by adding + +.. code-block:: kconfig + + set auto-load safe-path / + +to the same startup script, which will enable the automatic loading of libraries +from any location. + +If you need to have native debugging, you might want to install the debug +symbols on the target. You can do this by adding the following line to your +*conf/local.conf* + +.. code-block:: kconfig + + EXTRA_IMAGE_FEATURES += "dbg-pkgs" + +For cross-debugging, this is not required as the debug symbols will be loaded +from the host side and the dbg-pkgs are included in the SDK of your image +anyway. + +.. _kirkstone_gen-source-mirrors: + +Generating Source Mirrors, working Offline +.......................................... + +Modify your *site.conf* (or *local.conf* if you do not use a *site.conf* ) as +follows + +.. code-block:: kconfig + + #DL_DIR ?= "" don't set it! It will default to a directory inside /build + SOURCE_MIRROR_URL = "file:///home/share/yocto_downloads/" + INHERIT += "own-mirrors" + BB_GENERATE_MIRROR_TARBALLS = "1" + +Now run + +.. code-block:: console + + host:~$ bitbake --runall=fetch + +for all images and for all machines you want to provide sources for. This will +create all the necessary *tar* archives. We can remove all SCM subfolders, as +they are duplicated with the tarballs + +.. code-block:: console + + host:~$ rm -rf build/download/git2/ + etc... + +Please consider that we used a local source mirror for generating the dl_dir. +Because of that, some archives will be linked locally. + +First, we need to copy all files, resolving symbolic links into the new mirror +directory + +.. code-block:: console + + host:~$ rsync -vaL ${TOPDIR}/../src_mirror/ + +Now we clean the */build* directory by deleting everything except */build/conf/* +but including */build/conf/sanity*. We change *site.conf* as follows + +.. code-block:: kconfig + + SOURCE_MIRROR_URL = "file://${TOPDIR}/../src_mirror" + INHERIT += "own-mirrors" + BB_NO_NETWORK = "1" + SCONF_VERSION = "1" + +The BSP directory can now be compressed with + +.. code-block:: console + + host:~$ tar cfJ .tar.xz + +where filename and folder should be the full BSP Name. + +Compiling on the Target +....................... + +To your *local.conf* add + +.. code-block:: kconfig + + IMAGE_FEATURES:append = " tools-sdk dev-pkgs" + +Different Toolchains +.................... + +There are several ways to create a toolchain installer in *Poky*. One option is +to run + +.. code-block:: console + + host:~$ bitbake meta-toolchain + +This will generate a toolchain installer in *build/deploy/sdk* which can be used +for cross-compiling of target applications. However, the installer does not +include libraries added to your image, so it is a bare *GCC* compiler only. This +is suited for bootloader and kernel development. + +Another you can run is + +.. code-block:: console + + host:~$ bitbake -c populate_sdk + +This will generate a toolchain installer containing all necessary development +packages of the software installed on the root filesystem of the target. This +installer can be handed over to the user space application development team and +includes all necessary parts to develop an application. If the image contains +the *QT* libraries, all of those will be available in the installer too. + +The third option is to create the ADT (Application Development Toolkit) +installer. It will contain the cross-toolchain and some tools to aid the +software developers, for example, an *Eclipse* plugin and a *QEMU* target +simulator. + +.. code-block:: console + + host:~$ bitbake adt-installer + +The ADT is untested for our BSP at the moment. + +Using the SDK +~~~~~~~~~~~~~ + +After generating the SDK with + +.. code-block:: console + + host:~$ source sources/poky/oe-init-build-env + host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image + +run the generated binary with + +.. code-block:: console + + host:~$ deploy/sdk/ampliphy-glibc-x86_64-phytec-qt6demo-image-cortexa9hf-vfp-neon-toolchain-i.MX6-PD15.3-rc.sh + Enter target directory for SDK (default: /opt/ampliphy/i.MX6-PD15.3-rc): + You are about to install the SDK to "/opt/ampliphy/i.MX6-PD15.3-rc". Proceed[Y/n]? + Extracting SDK...done + Setting it up...done + SDK has been successfully set up and is ready to be used. + +You can activate the toolchain for your shell by sourcing the file +*environment-setup* in the toolchain directory + +.. code-block:: console + + host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + +Then the necessary tools like the cross compiler and linker are in your PATH. To +compile a simple *C* program, use + +.. code-block:: console + + host:~$ $CC main.c -o main + +The environment variable $CC contains the path to the ARM cross compiler and +other compiler arguments needed like *-march* , *-sysroot* and *--mfloat-abi*. + +.. tip:: + + You cannot compile programs only with the compiler name like + + .. code-block:: console + + host:~$ arm-phytec-linux-gnueabi-gcc main.c -o main + + It will fail in many cases. Always use *CC*, CFLAGS, LDFLAGS, and so on. + +For convenience, the *environment-setup* exports other environment variables +like CXX, LD, SDKTARGETSYSROOT. + +A simple makefile compiling a *C* and *C++* program may look like this + +.. code-block:: kconfig + + # Makefile + TARGETS=c-program cpp-program + + all: $(TARGETS) + + c-program: c-program.c + $(CC) $(CFLAGS) $(LDFLAGS) $< -o $@ + + cpp-program: cpp-program.cpp + $(CXX) $(CXXFLAGS) $(LDFLAGS) $< -o $@ + + .PHONY: clean + clean: + rm -f $(TARGETS) + +To compile for the target, just source the toolchain in your shell before +executing make + +.. code-block:: console + + host:~$ make # Compiling with host CC, CXX for host architecture + host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + host:~$ make # Compiling with target CC, CXX for target architecture + +If you need to specify additionally included directories in the sysroot of the +toolchain, you can use an '=' sign in the *-I* argument like + +.. code-block:: kconfig + + -I=/usr/include/SDL + +*GCC* replaces it by the sysroot path (here +*/opt/ampliphy/i.MX6-PD15.3-rc/sysroots/cortexa9hf-vfp-neon-phytec-linux-gnueabi/*). +See the main page of *GCC* for more information. + +.. tip:: + + The variables $CFLAGS and $CXXFLAGS contain the compiler debug flag '-g' by + default. This includes debugging information in the binary and making it + bigger. Those should be removed from the production image. If you create a + *Bitbake* recipe, the default behavior is to turn on '-g' too. The debugging + symbols are used in the SDK rootfs to be able to get debugging information + when invoking *GDB* from the host. Before installing the package to the + target rootfs, *Bitbake* will invoke *strip* on the program which removes the + debugging symbols. By default, they are not found nor required on the target + root filesystem + +Using the SDK with GNU Autotools +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +*Yocto* SDK is a straightforward tool for a project that uses the *GNU +Autotools*. The traditional compile steps for the host are usually + +.. code-block:: console + + host:~$ ./autogen.sh # maybe not needed + host:~$ ./configure + host:~$ make + host:~$ make install DESTDIR=$PWD/build/ + +The commands to compile for the target machine with the *Yocto* SDK are quite +similar. The following commands assume that the SDK was unpacked to the +directory */opt/phytec-ampliphy/i.MX6-PD15.3.0/* (adapt the path as needed) + +.. code-block:: console + + host:~$ source /opt/phytec-ampliphy/i.MX6-PD15.3.0/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + host:~$ ./autogen.sh # maybe not needed + host:~$ ./configure ${CONFIGURE_FLAGS} + host:~$ make + host:~$ make install DESTDIR=$PWD/build/ + +Refer to the official *Yocto* documentation for more information: +https://docs.yoctoproject.org/4.0.6/singleindex.html#autotools-based-projects + +Working with Kernel Modules +........................... + +You will come to the point where you either need to set some options for a +kernel module or you want to blacklist a module. Those things are handled by +*udev* and go into *\*.conf* files in + +.. code-block:: + + /etc/modprobe.d/\*.conf. + +If you want to specify an option at build time, there are three relevant +variables. If you just want to autoload a module that has no autoload +capabilities, add it to + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + +either in the kernel recipe or in the global variable scope. If you need to +specify options for a module, you can do so with + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + KERNEL_MODULE_PROBECONF += "your-module" + module_conf_your-module = "options your-module parametername=parametervalue" + +if you want to blacklist a module from autoloading, you can do it intuitively +with + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + KERNEL_MODULE_PROBECONF += "your-module" + module_conf_your-module = "blacklist your-module" + +Working with *udev* +................... + +Udev (Linux dynamic device management) is a system daemon that handles dynamic +device management in /dev. It is controlled by *udev* \ rules that are located +in */etc/udev/rules.d* (sysadmin configuration space) and\ */lib/udev/rules.d/* +(vendor-provided). Here is an example of an *udev* \ rule file + +.. code-block:: kconfig + + # file /etc/udev/rules.d/touchscreen.rules + # Create a symlink to any touchscreen input device + SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="input:*-e0*,3,*a0,1,*18,*", SYMLINK+="input/touchscreen0" + SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="ads7846", SYMLINK+="input/touchscreen0" + +See https://www.freedesktop.org/software/systemd/man/latest/udev.html for more details +about the syntax and usage. To get the list of attributes for a specific device +that can be used in an *udev* rule you can use the *udevadm info* tool. It +prints all existing attributes of the device node and its parents. The key-value +pairs from the output can be copied and pasted into a rule file. Some examples + +.. code-block:: console + + target:~$ udevadm info -a /dev/mmcblk0 + target:~$ udevadm info -a /dev/v4l-subdev25 + target:~$ udevadm info -a -p /sys/class/net/eth0 + +After changing an *udev* rule, you have to notify the daemon. Otherwise, your +changes are not reflected. Use the following command + +.. code-block:: console + + target:~$ udevadm control --reload-rules + +While developing *udev* rules you should monitor the events in order to see when +devices are attached or unattached to the system. Use + +.. code-block:: console + + target:~$ udevadm monitor + +Furthermore, it is very useful to monitor the system log in another shell, +especially if the rule executes external scripts. Execute + +.. code-block:: console + + target:~$ journalctl -f + +.. tip:: + + You cannot start daemons or heavy scripts in a *RUN* attribute. See + https://www.freedesktop.org/software/systemd/man/latest/udev.html . + + This can only be used for very short-running foreground tasks. Running an + event process for a long period of time may block all further events for this + or a dependent device. Starting daemons or other long-running processes is + not appropriate for *udev*; the forked processes, detached or not, will be + unconditionally killed after the event handling has finished. You can use the + special attribute *ENV{SYSTEMD_WANTS}="service-name.service"* and a + *systemd*\ service instead. + + See + https://unix.stackexchange.com/questions/63232/what-is-the-correct-way-to-write-a-udev-rule-to-stop-a-service-under-systemd. + +Troubleshooting +=============== + +Setscene Task Warning +--------------------- + +This warning occurs when the Yocto cache is in a dirty state. + +.. code-block:: + + WARNING: Setscene task X ([...]) failed with exit code '1' - real task + +You should avoid canceling the build process or if you have to, press Ctrl-C +once and wait until the build process has stopped. To remove all these warnings +just clean the sstate cache and remove the build folders. + +.. code-block:: console + + host:~$ bitbake phytec-headless-image -c cleansstate && rm -rf tmp deploy/ipk + +Yocto Documentation +=================== + +The most important piece of documentation for a BSP user is probably the +developer manual. +https://docs.yoctoproject.org/4.0.6/dev-manual/index.html + +The chapter about common tasks is a good starting point. +https://docs.yoctoproject.org/4.0.6/dev-manual/common-tasks.html#common-tasks + +The complete documentation is available on one single HTML page, which is good +for searching for a feature or a variable name. +https://docs.yoctoproject.org/4.0.6/singleindex.html diff --git a/previews/271/_sources/yocto/manual-index.rst.txt b/previews/271/_sources/yocto/manual-index.rst.txt new file mode 100644 index 000000000..e1f7541d3 --- /dev/null +++ b/previews/271/_sources/yocto/manual-index.rst.txt @@ -0,0 +1,33 @@ +======================= +Yocto Reference Manuals +======================= + +Kirkstone +========= + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + kirkstone + +Mickledore +========== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + mickledore + +Scarthgap +========= + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + scarthgap \ No newline at end of file diff --git a/previews/271/_sources/yocto/mickledore.rst.txt b/previews/271/_sources/yocto/mickledore.rst.txt new file mode 100644 index 000000000..6e7ccddb6 --- /dev/null +++ b/previews/271/_sources/yocto/mickledore.rst.txt @@ -0,0 +1,3077 @@ +.. Download links +.. _`static-pdf-dl`: ../_static/mickledore.pdf + +.. Yocto +.. |yocto-codename| replace:: Mickledore +.. |yocto-ref-manual| replace:: Yocto Reference Manual +.. |distro| replace:: ampliphy-vendor-xwayland + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-------------------------------------------------------------+ +| |yocto-ref-manual| | ++=======================+=====================================+ +| Document Title | |yocto-ref-manual| |yocto-codename| | ++-----------------------+-------------------------------------+ +| Document Type | Yocto Manual | ++-----------------------+-------------------------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+-------------------------------------+ +| Is Branch of | |yocto-ref-manual| | ++-----------------------+-------------------------------------+ + ++----------------------------------+------------------+------------------+------------+ +| Compatible BSPs | BSP Release Type | BSP Release Date | BSP Status | ++==================================+==================+==================+============+ +| BSP-Yocto-NXP-i.MX93-PD24.1.0 | Major | 05.02.2024 | released | ++----------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX93-PD24.1.1 | Minor | 08.05.2024 | released | ++----------------------------------+------------------+------------------+------------+ + + +This manual applies to all |yocto-codename| based PHYTEC releases. + +.. _yocto-man-mickledore: + +The Yocto Project +================= + +PHYTEC Documentation +-------------------- + +PHYTEC will provide a variety of hardware and software documentation for all of +our products. This includes any or all of the following: + +- **QS Guide**: A short guide on how to set up and boot a phyCORE board along + with brief information on building a BSP, the device tree, and accessing + peripherals. +- **Hardware Manual**: A detailed description of the System on Module and + accompanying carrier board. +- **Yocto Guide**: A comprehensive guide for the Yocto version the phyCORE + uses. This guide contains an overview of Yocto; introducing, installing, and + customizing the PHYTEC BSP; how to work with programs like Poky and Bitbake; + and much more. +- **BSP Manual**: A manual specific to the BSP version of the phyCORE. + Information such as how to build the BSP, booting, updating software, device + tree, and accessing peripherals can be found here. +- **Development Environment Guide**: This guide shows how to work with the + Virtual Machine (VM) Host PHYTEC has developed and prepared to run various + Development Environments. There are detailed step-by-step instructions for + Eclipse and Qt Creator, which are included in the VM. There are instructions + for running demo projects for these programs on a phyCORE product as well. + Information on how to build a Linux host PC yourself is also a part of this + guide. +- **Pin Muxing Table**: phyCORE SOMs have an accompanying pin table (in Excel + format). This table will show the complete default signal path, from + processor to carrier board. The default device tree muxing option will also + be included. This gives a developer all the information needed in one + location to make muxing changes and design options when developing a + specialized carrier board or adapting a PHYTEC phyCORE SOM to an application. + +On top of these standard manuals and guides, PHYTEC will also provide Product +Change Notifications, Application Notes, and Technical Notes. These will be done +on a case-by-case basis. Most of the documentation can be found in the +applicable download page of our products. + +Yocto Introduction +------------------ + +Yocto is the smallest SI metric system prefix. Like milli equates to ``m = +10^-3``, and so is yocto ``y = 10^-24``. Yocto is also a project working group +of the `Linux Foundation `_ and therefore +backed up by several major companies in the field. On the `Yocto Project website +`_ you can read the official introduction: + + The Yocto Project is an open-source collaboration project that provides + templates, tools, and methods to help you create custom Linux-based systems + for embedded products regardless of the hardware architecture. It was founded + in 2010 as a collaboration among many hardware manufacturers, open-source + operating systems vendors, and electronics companies to bring some order to + the chaos of embedded Linux development. + +As said, the project wants to provide toolsets for embedded developers. It +builds on top of the long-lasting `OpenEmbedded +`_ project. It is not a Linux distribution. But +it contains the tools to create a Linux distribution specially fitted to the +product requirements. The most important step in bringing order to the set of +tools is to define a common versioning scheme and a reference system. All +subprojects have then to comply with the reference system and have to comply +with the versioning scheme. + +The release process is similar to the `Linux kernel `_. +Yocto increases its version number every six months and gives the release a +codename. The release list can be found here: +https://wiki.yoctoproject.org/wiki/Releases + +Core Components +--------------- + +The most important tools or subprojects of the *Yocto* Project are: + +- Bitbake: build engine, a task scheduler like make, interprets metadata +- OpenEmbedded-Core, a set of base layers, containing metadata of software, no + sources +- Yocto kernel + + - Optimized for embedded devices + - Includes many subprojects: rt-kernel, vendor patches + - The infrastructure provided by Wind River + - Alternative: classic kernel build → we use it to integrate our kernel into + *Yocto* + +- *Yocto* Reference BSP: *beagleboneblack*, *minnow max* +- *Poky*, the reference system, a collection of projects and tools, used to + bootstrap a new distribution based on *Yocto* + +Vocabulary +---------- + +Recipes +....... + +Recipes contain information about the software project (author, homepage, and +license). A recipe is versioned, defines dependencies, contains the URL of the +source code, and describes how to fetch, configure, and compile the sources. It +describes how to package the software, e.g. into different .deb packages, which +then contain the installation path. Recipes are basically written in *Bitbake's* +own programming language, which has a simple syntax. However, a recipe can +contain *Python* as well as a bash code. + +Classes +....... + +Classes combine functionality used inside recipes into reusable blocks. + +Layers +...... + +A layer is a collection of recipes, classes, and configuration metadata. +A layer can depend on other layers and can be included or excluded one +by one. It encapsulates a specific functionality and fulfills a specific +purpose. Each layer falls into a specific category: + +- Base +- Machine (BSP) +- Software +- Distribution +- Miscellaneous + +*Yocto's* versioning scheme is reflected in every layer as version branches. For +each *Yocto* version, every layer has a named branch in its *Git* repository. +You can add one or many layers of each category in your build. + +A collection of OpenEmbedded layers can be found here. The search function is +very helpful to see if a software package can be retrieved and integrated +easily: https://layers.openembedded.org/layerindex/branch/mickledore/layers/ + +Machine +....... + +Machines are configuration variables that describe the aspects of the target +hardware. + +Distribution (Distro) +..................... + +Distribution describes the software configuration and comes with a set of +software features. + +Poky +---- + +*Poky* is the reference system to define *Yocto* Project compatibility. It +combines several subprojects into releases: + +- *Bitbake* +- *Toaster* +- OpenEmbedded Core +- *Yocto* Documentation +- *Yocto* Reference BSP + +Bitbake +....... + +*Bitbake* is the task scheduler. It is written in *Python* and interprets +recipes that contain code in *Bitbake's* own programming language, *Python*, and +bash code. The official documentation can be found here: +https://docs.yoctoproject.org/bitbake/2.4/index.html + +Toaster +....... + +*Toaster* is a web frontend for *Bitbake* to start and investigate builds. It +provides information about the build history and statistics on created images. +There are several use cases where the installation and maintenance of +a *Toaster* instance are beneficial. PHYTEC did not add or remove any features +to the upstream *Toaster*, provided by *Poky*. The best source for more +information is the official documentation: +https://docs.yoctoproject.org/4.2.4/toaster-manual/index.html + +Official Documentation +---------------------- + +For more general questions about *Bitbake* and *Poky* consult the mega-manual: +https://docs.yoctoproject.org/4.2.4/singleindex.html + +Compatible Linux Distributions +============================== + +To build *Yocto* you need a compatible *Linux* host development machine. The +list of supported distributions can be found in the reference manual: +https://docs.yoctoproject.org/4.2.4/ref-manual/system-requirements.html#supported-linux-distributions + +PHYTEC BSP Introduction +======================= + +BSP Structure +------------- + +The BSP consists roughly of three parts. BSP management, BSP metadata, and BSP +content. The management consists of *Repo* and phyLinux while the metadata +depends on the SOC, which describes how to build the software. The content +comprises PHYTEC's *Git* repositories and external sources. + +BSP Management +.............. + +*Yocto* is an umbrella project. Naturally, this will force the user to base +their work on several external repositories. They need to be managed in a +deterministic way. We use manifest files, which contain an XML data structure, +to describe all git repositories with pinned-down versions. The *Repo* tool and +our phyLinux wrapper script are used to manage the manifests and set up the BSP, +as described in the manifest file. + +phyLinux +~~~~~~~~ + +phyLinux is a wrapper for *Repo* to handle downloading and setting up the BSP +with an "out of the box" experience. + +Repo +~~~~ + +*Repo* is a wrapper around the *Repo* toolset. The phyLinux script will install +the wrapper in a global path. This is only a wrapper, though. Whenever you run +``repo init -u ``, you first download the *Repo* tools from *Googles* Git +server in a specific version to the ``.repo/repo`` directory. The next time you +run *Repo*, all the commands will be available. Be aware that the *Repo* version +in different build directories can differ over the years if you do not run *Repo +sync*. Also if you store information for your archives, you need to include the +complete ``.repo`` folder. + +*Repo* expects a *Git* repository which will be parsed from the command line. In +the PHYTEC BSP, it is called phy²octo. In this repository, all information about +a software BSP release is stored in the form of a *Repo* XML manifest. This data +structure defines URLs of *Git* servers (called "remotes") and *Git* +repositories and their states (called "projects"). The *Git* repositories can be +seen in different states. The revision field can be a branch, tag, or commit id +of a repository. This means the state of the software is not necessarily unique +and can change over time. That is the reason we use only tags or commit ids for +our releases. The state of the working directory is then unique and does not +change. + +The manifests for the releases have the same name as the release itself. It is a +unique identifier for the complete BSP. The releases are sorted by the SoC +platform. The selected SoC will define the branch of the phy²octo *Git* +repository which will be used for the manifest selection. + +BSP Metadata +............ + +We include several third-party layers in our BSP to get a complete *Linux* +distribution up and running without the need to integrate external projects. All +used repositories are described in the following section. + +Poky +~~~~ + +The PHYTEC BSP is built on top of *Poky*. It comes with a specific version, +defined in the *Repo* manifest. *Poky* comes with a specific version of +*Bitbake*. The OpenEmbedded-core layer "meta" is used as a base for our *Linux* +system. + +meta-openembedded +~~~~~~~~~~~~~~~~~ + +OpenEmbedded is a collection of different layers containing the meta description +for many open-source software projects. We ship all OpenEmbedded layers with our +BSP, but not all of them are activated. Our example images pull several software +packages generated from OpenEmbedded recipes. + +meta-qt6 +~~~~~~~~ + +This layer provides an integration of *Qt6* in the *Poky*-based root filesystem +and is integrated into our BSP. + +meta-nodejs +~~~~~~~~~~~ + +This is an application layer to add recent Node.js versions. + +meta-gstreamer1.0 +~~~~~~~~~~~~~~~~~ + +This is an application layer to add recent GStreamer versions. + +meta-rauc +~~~~~~~~~ + +This layer contains the tools required to build an updated infrastructure with +`RAUC `_. A comparison with +other update systems can be found here: `Yocto update tools +`_. + +meta-phytec +~~~~~~~~~~~ + +This layer contains all machines and common features for all our BSPs. It is +PHYTEC's `Yocto Board Support Package +`_ for all supported +hardware (since *fido*) and is designed to be standalone with *Poky*. Only these +two parts are required if you want to integrate the PHYTEC's hardware into your +existing *Yocto* workflow. The features are: + +- Bootloaders in ``recipes-bsp/barebox/`` and ``recipes-bsp/u-boot/`` +- Kernels in ``recipes-kernel/linux/`` and + ``dynamic-layers/fsl-bsp-release/recipes-kernel/linux/`` +- Many machines in ``conf/machine/`` +- Proprietary *OpenGL ES/EGL* user space libraries for AM335x and i.MX 6 + platforms +- Proprietary *OpenCL* libraries for i.MX 6 platforms + +meta-ampliphy +~~~~~~~~~~~~~ + +This is our example distribution and BSP layer. It extends the basic +configuration of *Poky* with software projects described by all the other BSP +components. It provides a base for your specific development scenarios. The +current features are: + +- `systemd `_ init system +- Images: ``phytec-headless-image`` for non-graphics applications +- Camera integration with OpenCV and GStreamer examples for the i.MX 6 platform + bundled in a ``phytec-vision-image`` +- RAUC integration: we set up basic support for an A/B system image update, + which is possible locally and over-the-air + +meta-qt6-phytec +~~~~~~~~~~~~~~~ + +This is our layer for Qt6 board integration and examples. The features are: + +- `Qt6 with eglfs backend `_ for + PHYTEC's AM335x, i.MX 6 and RK3288 platforms +- Images: ``phytec-qt6demo-image`` for *Qt6* and video applications +- A *Qt6* demo application demonstrating how to create a *Qt6* project using + *QML* widgets and a *Bitbake* recipe for the *Yocto* and *systemd* + integration. It can be found in + ``sources/meta-qt6-phytec/recipes-qt/examples/phytec-qtdemo_git.bb`` + +meta-virtualization +~~~~~~~~~~~~~~~~~~~ + +- This layer provides support for building Xen, KVM, Libvirt, and associated + packages necessary for constructing OE-based virtualized solutions. + +meta-security +~~~~~~~~~~~~~ + +- This layer provides security tools, hardening tools for Linux kernels, and + libraries for implementing security mechanisms. + +meta-selinux +~~~~~~~~~~~~ + +- This layer's purpose is to enable SE Linux support. The majority of this + layer's work is accomplished in *bbappend* files, used to enable SE Linux + support in existing recipes. + +meta-browser +~~~~~~~~~~~~ + +- This is an application layer to add recent web browsers (Chromium, Firefox, + etc.). + +meta-rust +~~~~~~~~~ + +- Includes the Rust compiler and the Cargo package manager for Rust. + +meta-timesys +~~~~~~~~~~~~ + +- Timesys layer for Vigiles Yocto CVE monitoring, security notifications, and + image manifest generation. + +meta-freescale +~~~~~~~~~~~~~~ + +- This layer provides support for the i.MX, Layerscape, and QorIQ product + lines. + +meta-freescale-3rdparty +~~~~~~~~~~~~~~~~~~~~~~~ + +- Provides support for boards from various vendors. + +meta-freescale-distro +~~~~~~~~~~~~~~~~~~~~~ + +- This layer provides support for Freescale's Demonstration images for use with + OpenEmbedded and/or Yocto Freescale's BSP layer. + +base (fsl-community-bsp-base) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- This layer provides BSP base files of NXP. + +meta-fsl-bsp-release +~~~~~~~~~~~~~~~~~~~~ + +- This is the i.MX Yocto Project Release Layer. + +BSP Content +........... + +The BSP content gets pulled from different online sources when you first start +using *Bitbake*. All files will be downloaded and cloned in a local directory +configured as ``DL_DIR`` in *Yocto*. If you backup your BSP with the complete +content, those sources have to be backed up, too. How you can do this will be +explained in the chapter :ref:`mickledore_gen-source-mirrors`. + +Build Configuration +------------------- + +The BSP initializes a build folder that will contain all files you +create by running *Bitbake* commands. It contains a ``conf`` folder +that handles build input variables. + +- ``bblayers.conf`` defines activated meta-layers, +- ``local.conf`` defines build input variables specific to your build +- ``site.conf`` defines build input variables specific to the development host + +The two topmost build input variables are ``DISTRO`` and ``MACHINE``. They are +preconfigured ``local.conf`` when you check out the BSP using phyLinux. + +We use "*Ampliphy*" as ``DISTRO`` with our BSP. This distribution will be +preselected and give you a starting point for implementing your own +configuration. + +A ``MACHINE`` defines a binary image that supports specific hardware +combinations of module and baseboard. Check the ``machine.conf`` file or our +webpage for a description of the hardware. + +Pre-built Images +================ + +For each BSP we provide pre-built target images that can be downloaded from the +PHYTEC FTP server: https://download.phytec.de/Software/Linux/ + +These images are also used for the BSP tests, which are flashed to the boards +during production. You can use the provided ``.wic`` images to create a bootable +SD card at any time. Identify your hardware and flash the downloaded image file +to an empty SD card using ``dd``. Please see section Images for information +about the correct usage of the command. + +BSP Workspace Installation +========================== + +Setting Up the Host +------------------- + +You can set up the host or use one of our build-container to run a Yocto build. +You need to have a running *Linux* distribution. It should be running on a +powerful machine since a lot of compiling will need to be done. + +If you want to use a build-container, you only need to install following +packages on your host + +.. code-block:: console + + host:~$ sudo apt install wget git + +Continue with the next step :ref:`mickledore_git-config` after that. The documentation for +using build-container can be found in this manual after +:ref:`mickledore_phylinux-advanced-usage` of phyLinux. + +Else *Yocto* needs a handful of additional packages on your host. For *Ubuntu* you need + +.. code-block:: console + + host:~$ sudo apt install gawk wget git diffstat unzip texinfo \ + gcc build-essential chrpath socat cpio python3 python3-pip \ + python3-pexpect xz-utils debianutils iputils-ping python3-git \ + python3-jinja2 libegl1-mesa libsdl1.2-dev \ + python3-subunit mesa-common-dev zstd liblz4-tool file locales + + +For other distributions you can find information in the *Yocto* Quick Build: +https://docs.yoctoproject.org/4.2.4/brief-yoctoprojectqs/index.html + +.. _mickledore_git-config: + +Git Configuration +----------------- + +The BSP heavily utilizes *Git*. *Git* needs some information from +you as a user to identify who made changes. Create a ``~/.gitconfig`` with the +following content, if you do not have one + +.. code-block:: kconfig + + [user] + name = + email = + [core] + editor = vim + [merge] + tool = vimdiff + [alias] + co = checkout + br = branch + ci = commit + st = status + unstage = reset HEAD -- + last = log -1 HEAD + [push] + default = current + [color] + ui = auto + +You should set ``name`` and ``email`` in your *Git* configuration, otherwise, +*Bitbake* will complain during the first build. You can use the two commands to +set them directly without editing ``~/.gitconfig`` manually + +.. code-block:: console + + host:~$ git config --global user.email "your_email@example.com" + host:~$ git config --global user.name "name surname" + +site.conf Setup +--------------- + +Before starting the *Yocto* build, it is advisable to configure the development +setup. Two things are most important: the download directory and the cache +directory. PHYTEC strongly recommends configuring the setup as it will reduce +the compile time of consequent builds. + +A download directory is a place where *Yocto* stores all sources fetched from +the internet. It can contain tar.gz, *Git* mirror, etc. It is very useful to set +this to a common shared location on the machine. Create this directory with 777 +access rights. To share this directory with different users, all files need to +have group write access. This will most probably be in conflict with default +*umask* settings. One possible solution would be to use ACLs for this +directory + +.. code-block:: console + + host:~$ sudo apt-get install acl + host:~$ sudo setfacl -R -d -m g::rwx + +If you have already created a download directory and want to fix the permissions +afterward, you can do so with + +.. code-block:: console + + host:~$ sudo find /home/share/ -perm /u=r ! -perm /g=r -exec chmod g+r \{\} \; + host:~$ sudo find /home/share/ -perm /u=w ! -perm /g=w -exec chmod g+w \{\} \; + host:~$ sudo find /home/share/ -perm /u=x ! -perm /g=x -exec chmod g+x \{\} \; + +The cache directory stores all stages of the build process. *Poky* has quite an +involved caching infrastructure. It is advisable to create a shared directory, +as all builds can access this cache directory, called the shared state cache. + +Create the two directories on a drive where you have approximately 50 GB of +space and assign the two variables in your ``build/conf/local.conf``:: + + DL_DIR ?= "/yocto_downloads" + SSTATE_DIR ?= "/yocto_sstate" + +If you want to know more about configuring your build, see the documented +example settings + +.. code-block:: + + sources/poky/meta-yocto/conf/local.conf.sample + sources/poky/meta-yocto/conf/local.conf.sample.extended + +phyLinux Documentation +====================== + +The phyLinux script is a basic management tool for PHYTEC *Yocto* BSP releases +written in *Python*. It is mainly a helper to get started with the BSP +structure. You can get all the BSP sources without the need of interacting with +*Repo* or *Git*. + +The phyLinux script has only one real dependency. It requires the *wget* tool +installed on your host. It will also install the `Repo tool +`_ in a global path +(/usr/local/bin) on your host PC. You can install it in a different location +manually. *Repo* will be automatically detected by phyLinux if it is found in +the PATH. The *Repo* tool will be used to manage the different *Git* +repositories of the *Yocto* BSP. + +Get phyLinux +------------ + +The phyLinux script can be found on the PHYTEC download server: +https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux + +Basic Usage +----------- + +For the basic usage of phyLinux, type + +.. code-block:: console + + host:~$ ./phyLinux --help + +which will result in + +.. code-block:: + + usage: phyLinux [-h] [-v] [--verbose] {init,info,clean} ... + + This Programs sets up an environment to work with The Yocto Project on Phytecs + Development Kits. Use phyLinx -h to display the help text for the + available commands. + + positional arguments: + {init,info,clean} commands + init init the phytec bsp in the current directory + info print info about the phytec bsp in the current directory + clean Clean up the current working directory + + optional arguments: + -h, --help show this help message and exit + -v, --version show program's version number and exit + --verbose + +Initialization +-------------- + +Create a fresh project folder + +.. code-block:: console + + host:~$ mkdir ~/yocto + +Calling phyLinux will use the default Python version. Starting with Ubuntu 20.04 +it will be Python3. If you want to initiate a BSP, which is not compatible with +Python3, you need to set Python2 as default (temporarily) before running +phyLinux + +.. code-block:: console + + host:~$ ln -s \`which python2\` python && export PATH=`pwd`:$PATH + +Now run phyLinux from the new folder + +.. code-block:: console + + host:~$ ./phyLinux init + +A clean folder is important because phyLinux will clean its working directory. +Calling phyLinux from a directory that isn't empty will result in the following +**warning**:: + + This current directory is not empty. It could lead to errors in the BSP configuration + process if you continue from here. At the very least, you have to check your build directory + for settings in bblayers.conf and local.conf, which will not be handled correctly in + all cases. It is advisable to start from an empty directory of call: + $ ./phyLinux clean + Do you really want to continue from here? + [yes/no]: + +On the first initialization, the phyLinux script will ask you to install the +*Repo* tool in your */usr/local/bin* directory. During the execution of the +*init* command, you need to choose your processor platform (SoC), PHYTEC's BSP +release number, and the hardware you are working on + +.. code-block:: + + *************************************************** + * Please choose one of the available SoC Platforms: + * + * 1: am335x + * 2: am57x + * 3: am62ax + * 4: am62x + * 5: am64x + * 6: am68x + * 7: imx6 + * 8: imx6ul + * 9: imx7 + * 10: imx8 + * 11: imx8m + * 12: imx8mm + * 13: imx8mp + * 14: imx8x + * 15: imx93 + * 16: nightly + * 17: rk3288 + * 18: stm32mp13x + * 19: stm32mp15x + * 20: topic + + # Exemplary output for chosen imx93 + *************************************************** + * Please choose one of the available Releases: + * + * 1: BSP-Yocto-NXP-i.MX93-ALPHA1 + * 2: BSP-Yocto-NXP-i.MX93-PD24.1-rc1 + * 3: BSP-Yocto-NXP-i.MX93-PD24.1.0 + * 4: BSP-Yocto-NXP-i.MX93-PD24.1.1-rc1 + * 5: BSP-Yocto-NXP-i.MX93-PD24.1.1-rc2 + * 6: BSP-Yocto-NXP-i.MX93-PD24.1.1-rc3 + * 7: BSP-Yocto-NXP-i.MX93-PD24.1.1 + + # Exemplary output for chosen BSP-Yocto-NXP-i.MX93-PD24.1.1 + ********************************************************************* + * Please choose one of the available builds: + * + no: machine: description and article number + distro: supported yocto distribution + target: supported build target + + 1: phyboard-nash-imx93-1: PHYTEC phyBOARD-Nash i.MX93 + 2 GB RAM, eMMC + PB-04729-001, PCL-077-23231211I + distro: ampliphy-vendor + target: phytec-headless-image + 2: phyboard-nash-imx93-1: PHYTEC phyBOARD-Nash i.MX93 + 2 GB RAM, eMMC + PB-04729-001, PCL-077-23231211I + distro: ampliphy-vendor-rauc + target: phytec-headless-bundle + 3: phyboard-nash-imx93-1: PHYTEC phyBOARD-Nash i.MX93 + 2 GB RAM, eMMC + PB-04729-001, PCL-077-23231211I + distro: ampliphy-vendor-wayland + target: -c populate_sdk phytec-qt6demo-image + target: phytec-qt6demo-image + 4: phyboard-segin-imx93-2: PHYTEC phyBOARD-Segin i.MX93 + 1 GB RAM, eMMC, silicon revision A1 + PB-02029-001, PCL-077-11231010I + distro: ampliphy-vendor + target: phytec-headless-image + 5: phyboard-segin-imx93-2: PHYTEC phyBOARD-Segin i.MX93 + 1 GB RAM, eMMC, silicon revision A1 + PB-02029-001, PCL-077-11231010I + distro: ampliphy-vendor-rauc + target: phytec-headless-bundle + 6: phyboard-segin-imx93-2: PHYTEC phyBOARD-Segin i.MX93 + 1 GB RAM, eMMC, silicon revision A1 + PB-02029-001, PCL-077-11231010I + distro: ampliphy-vendor-wayland + target: phytec-qt6demo-image + +If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. After the configuration is done, +you can always run + +.. code-block:: console + + host:~$ ./phyLinux info + + # Exemplary output + ********************************************** + * The current BSP configuration is: + * + * SoC: refs/heads/imx93 + * Release: BSP-Yocto-NXP-i.MX93-PD24.1.1 + * Machine: phyboard-segin-imx93-2 + * + ********************************************** + +to see which SoC and Release are selected in the current workspace. If +you do not want to use the selector, phyLinux also supports command-line +arguments for several settings + +.. code-block:: console + + host:~$ MACHINE=phyboard-segin-imx93-2 ./phyLinux init -p imx93 -r BSP-Yocto-NXP-i.MX93-PD24.1.1 + +or view the help command for more information + +.. code-block:: console + + host:~$ ./phyLinux init --help + + usage: phyLinux init [-h] [--verbose] [--no-init] [-o REPOREPO] [-b REPOREPO_BRANCH] [-x XML] [-u URL] [-p PLATFORM] [-r RELEASE] + + options: + -h, --help show this help message and exit + --verbose + --no-init dont execute init after fetch + -o REPOREPO Use repo tool from another url + -b REPOREPO_BRANCH Checkout different branch of repo tool + -x XML Use a local XML manifest + -u URL Manifest git url + -p PLATFORM Processor platform + -r RELEASE Release version + +After the execution of the *init* command, phyLinux will print a few important +notes as well as information for the next steps in the build process. + +.. _mickledore_phylinux-advanced-usage: + +Advanced Usage +-------------- + +phyLinux can be used to transport software states over any medium. The state of +the software is uniquely identified by *manifest.xml*. You can create a +manifest, send it to another place and recover the software state with + +.. code-block:: console + + host:~$ ./phyLinux init -x manifest.xml + +You can also create a *Git* repository containing your software states. The +*Git* repository needs to have branches other than master, as we reserved the +master branch for different usage. Use phyLinux to check out the states + +.. code-block:: console + + host:~$ ./phyLinux -u + +Using build-container +===================== + +.. warning:: + Currently, it is not possible to run the phyLinux script inside of a container. + After a complete init with the phyLinux script on your host machine, you can use a container for the build. + If you do not have phyLinux script running on your machine, please see phyLinux Documentation. + +There are various possibilities to run a build-container. Commonly used is +docker and podman, though we prefer podman as it does not need root privileges +to run. + +Installation +------------ + +How to install podman: https://podman.io +How to install docker: https://docs.docker.com/engine/install/ + +Available container +------------------- + +Right now we provide 4 different container based on Ubuntu LTS versions: +https://hub.docker.com/u/phybuilder + +- yocto-ubuntu-16.04 +- yocto-ubuntu-18.04 +- yocto-ubuntu-20.04 +- yocto-ubuntu-22.04 + +These containers can be run with podman or docker. With Yocto Project branch |yocto-codename| the container "yocto-ubuntu-20.04" is preferred. + +Download/Pull container +----------------------- + +.. code-block:: console + + host:~$ podman pull docker.io/phybuilder/yocto-ubuntu-20.04 + + OR + + host:~$ docker pull docker.io/phybuilder/yocto-ubuntu-20.04 + +By adding a tag at the end separated by a colon, you can also pull or run a special tagged container. + + podman pull docker.io/phybuilder/yocto-ubuntu-20.04:phy2 + +You can find all available tags in our duckerhub space: + +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-16.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-18.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-20.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-22.04/tags + +If you try to run a container, which is not pulled/downloaded, it will be pulled/downloaded automatically. + +You can have a look at all downloaded/pulled container with: + +.. code-block:: console + + $USERNAME@$HOSTNAME:~$ podman images + REPOSITORY TAG IMAGE ID CREATED SIZE + docker.io/phybuilder/yocto-ubuntu-22.04 latest d626178e448d 4 months ago 935 MB + docker.io/phybuilder/yocto-ubuntu-22.04 phy2 d626178e448d 4 months ago 935 MB + docker.io/phybuilder/yocto-ubuntu-20.04 phy2 e29a88b7172a 4 months ago 900 MB + docker.io/phybuilder/yocto-ubuntu-20.04 latest e29a88b7172a 4 months ago 900 MB + docker.io/phybuilder/yocto-ubuntu-18.04 phy1 14c9c3e477d4 7 months ago 567 MB + docker.io/phybuilder/yocto-ubuntu-18.04 latest 14c9c3e477d4 7 months ago 567 MB + docker.io/phybuilder/yocto-ubuntu-16.04 phy1 28c73e13ab4f 7 months ago 599 MB + docker.io/phybuilder/yocto-ubuntu-16.04 latest 28c73e13ab4f 7 months ago 599 MB + docker.io/phybuilder/yocto-ubuntu-22.04 phy1 5a0ef4b41935 8 months ago 627 MB + docker.io/phybuilder/yocto-ubuntu-20.04 phy1 b5a26a86c39f 8 months ago 680 MB + +Run container +------------- + +To run and use container for a Yocto build, first enter to your folder, where +you run phyLinux init before. Then start the container + +.. code-block:: console + + host:~$ podman run --rm=true -v /home:/home --userns=keep-id --workdir=$PWD -it docker.io/phybuilder/yocto-ubuntu-20.04 bash + +.. note:: + To run and use a container with docker, it is not that simple like with podman. + Therefore the container-user has to be defined and configured. + Furthermore forwarding of credentials is not given per default and has to be configured as well. + +Now your commandline should look something like that (where $USERNAME is the +user, who called "podman run" and the char/number code diffs every time a +container is started) + +.. code-block:: console + + $USERNAME@6593e2c7b8f6:~$ + +.. warning:: + If the given username is "root" you will not be able to run bitbake at all. + Please be sure, you run the container with your own user. + +Now you are ready to go on and starting the build. +To stop/close the container, just call + +.. code-block:: console + + $USERNAME@6593e2c7b8f6:~$ exit + +Working with Poky and Bitbake +============================= + +Start the Build +--------------- + +After you download all the metadata with phyLinux init, you have to set up the +shell environment variables. This needs to be done every time you open a new +shell for starting builds. We use the shell script provided by *Poky* in its +default configuration. From the root of your project directory type + +.. code-block:: console + + host:~$ source sources/poky/oe-init-build-env + +The abbreviation for the source command is a single dot + +.. code-block:: console + + host:~$ . sources/poky/oe-init-build-env + +The current working directory of the shell should change to *build/*. Before +building for the first time, you should take a look at the main configuration +file + +.. code-block:: console + + host:~$ vim conf/local.conf + +Your local modifications for the current build are stored here. Depending on +the SoC, you might need to accept license agreements. For example, to build the +image for Freescale/NXP processors you need to accept the GPU and VPU binary +license agreements. You have to uncomment the corresponding line + +.. code-block:: kconfig + + # Uncomment to accept NXP EULA # EULA can be found under + ../sources/meta-freescale/EULA ACCEPT_FSL_EULA = "1" + +Now you are ready to build your first image. We suggest starting with our +smaller non-graphical image *phytec-headless-image* to see if everything is +working correctly + +.. code-block:: console + + host:~$ bitbake phytec-headless-image + +The first compile process takes about 40 minutes on a modern Intel Core i7. All +subsequent builds will use the filled caches and should take about 3 minutes. + +Images +------ + +If everything worked, the images can be found under + +.. code-block:: console + + host:~$ cd deploy/images/ + +The easiest way to test your image is to configure your board for SD card boot +and to flash the build image to the SD card + +.. code-block:: console + + host:~$ sudo dd if=phytec-headless-image-.wic of=/dev/ bs=1M conv=fsync + +Here could be "sde", for example, depending on your system. Be +very careful when selecting the right drive! Selecting the wrong drive can +erase your hard drive! The parameter conv=fsync forces a data buffer to write +to the device before dd returns. + +After booting you can log in using a serial cable or over *ssh*. There is no +root password. That is because of the debug settings in *conf/local.conf*. If +you uncomment the line + +.. code-block:: kconfig + + #EXTRA_IMAGE_FEATURES = "debug-tweaks" + +the debug settings, like setting an empty root password, will not be applied. + +Accessing the Development States between Releases +------------------------------------------------- + +Special release manifests exist to give you access to the current development +states of the *Yocto* BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line + +.. code-block:: console + + host:~$ ./phyLinux init -p master -r mickledore + +This will initialize a BSP that will track the latest development state. From +now on running + +.. code-block:: console + + host:~$ repo sync + +this folder will pull all the latest changes from our Git repositories. + +Inspect your Build Configuration +-------------------------------- + +*Poky* includes several tools to inspect your build layout. You can inspect the +commands of the layer tool + +.. code-block:: console + + host:~$ bitbake-layers + +It can, for example, be used to view in which layer a specific recipe gets +modified + +.. code-block:: console + + host:~$ bitbake-layers show-appends + +Before running a build you can also launch *Toaster* to be able to inspect the +build details with the Toaster web GUI + +.. code-block:: console + + host:~$ source toaster start + +Maybe you need to install some requirements, first + +.. code-block:: console + + host:~$ pip3 install -r + ../sources/poky/bitbake/toaster-requirements.txt + +You can then point your browser to *http://0.0.0.0:8000/* and continue working +with *Bitbake*. All build activity can be monitored and analyzed from this web +server. If you want to learn more about *Toaster*, look at +https://docs.yoctoproject.org/4.2.4/toaster-manual/index.html. +To shut down the *Toaster* web GUI again, execute + +.. code-block:: console + + host:~$ source toaster stop + +BSP Features of meta-phytec and meta-ampliphy +--------------------------------------------- + +*Buildinfo* +........... + +The *buildinfo* task is a feature in our recipes that prints instructions to +fetch the source code from the public repositories. So you do not have to look +into the recipes yourself. To see the instructions, e.g. for the *barebox* +package, execute + +.. code-block:: console + + host:~$ bitbake barebox -c buildinfo + +in your shell. This will print something like + +.. code-block:: + + (mini) HOWTO: Use a local git repository to build barebox: + + To get source code for this package and version (barebox-2022.02.0-phy1), execute + + $ mkdir -p ~/git + $ cd ~/git + $ git clone git://git.phytec.de/barebox barebox + $ cd ~/git/barebox + $ git switch --create v2022.02.0-phy1-local-development 7fe12e65d770f7e657e683849681f339a996418b + + You now have two possible workflows for your changes: + + 1. Work inside the git repository: + Copy and paste the following snippet to your "local.conf": + + SRC_URI:pn-barebox = "git://${HOME}/git/barebox;branch=${BRANCH}" + SRCREV:pn-barebox = "${AUTOREV}" + BRANCH:pn-barebox = "v2022.02.0-phy1-local-development" + + After that you can recompile and deploy the package with + + $ bitbake barebox -c compile + $ bitbake barebox -c deploy + + Note: You have to commit all your changes. Otherwise yocto doesn't pick them up! + + 2. Work and compile from the local working directory + To work and compile in an external source directory we provide the + externalsrc.bbclass. To use it, copy and paste the following snippet to your + "local.conf": + + INHERIT += "externalsrc" + EXTERNALSRC:pn-barebox = "${HOME}/git/barebox" + EXTERNALSRC_BUILD:pn-barebox = "${HOME}/git/barebox" + + Note: All the compiling is done in the EXTERNALSRC directory. Every time + you build an Image, the package will be recompiled and build. + + NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded. + NOTE: Writing buildhistory + +As you can see, everything is explained in the output. + +.. warning:: + + Using *externalsrc* breaks a lot of *Yocto's* internal dependency + mechanisms. It is not guaranteed that any changes to the source + directory are automatically picked up by the build process and + incorporated into the root filesystem or SD card image. You have to + always use *--force*. E.g. to compile *barebox* and redeploy it to + *deploy/images/* execute + + .. code-block:: console + + host:~$ bitbake barebox -c compile --force + host:~$ bitbake barebox -c deploy + +To update the SD card image with a new kernel or image first force the +compilation of it and then force a rebuild of the root filesystem. Use + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image -c rootfs --force + +Note that the build system is not modifying the external source directory. If +you want to apply all patches the *Yocto* recipe is carrying to the external +source directory, run the line + +.. code-block:: kconfig + + SRCTREECOVEREDTASKS="" BB_ENV_PASSTHROUGH_ADDITIONS="$BB_ENV_PASSTHROUGH_ADDITIONS SRCTREECOVEREDTASKS" bitbake -c patch + +.. _mickledore_bsp-customization: + +BSP Customization +----------------- + +To get you started with the BSP, we have summarized some basic tasks from the +*Yocto* official documentation. It describes how to add additional software to +the image, change the kernel and bootloader configuration, and integrate +patches for the kernel and bootloader. + +Minor modifications, such as adding software, are done in the file +*build/conf/local.conf*. There you can overwrite global configuration variables +and make small modifications to recipes. + +There are 2 ways to make major changes: + +1. Either create your own layer and use *bbappend* files. +2. Add everything to PHYTEC's Distro layer *meta-ampliphy*. + +Creating your own layer is described in the section Create your own Layer. + +Disable Qt Demo +............... + +By default, the BSP image *phytec-qt6demo-image* starts a Qt6 Demo application +on the attached display or monitor. If you want to stop the demo and use the +*Linux* framebuffer console behind it, connect to the target via serial cable +or *ssh* and execute the shell command + +.. code-block:: console + + target:~$ systemctl stop phytec-qtdemo.service + +This command stops the demo temporarily. To start it again, reboot the +board or execute + +.. code-block:: console + + target:~$ systemctl start phytec-qtdemo.service + +You can disable the service permanently, so it does not start on boot + +.. code-block:: console + + target:~$ systemctl disable phytec-qtdemo.service + +.. tip:: + + The last command only disables the service. It does not *stop* immediately. + To see the current status execute + + .. code-block:: console + + target:~$ systemctl status phytec-qtdemo.service + +If you want to disable the service by default, edit the file +*build/conf/local.conf* and add the following line + +.. code-block:: kconfig + + # file build/conf/local.conf + SYSTEMD_AUTO_ENABLE:pn-phytec-qtdemo = "disable" + +After that, rebuild the image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +Framebuffer Console +................... + +On boards with a display interface, the framebuffer console is enabled per +default. You can attach a USB keyboard and log in. To change the keyboard +layout from the English default to German, type + +.. code-block:: console + + target:~$ loadkeys /usr/share/keymaps/i386/qwertz/de-latin1.map.gz + +To detach the framebuffer console, run + +.. code-block:: console + + target:~$ echo 0 > sys/class/vtconsole/vtcon1/bind + +To completely deactivate the framebuffer console, disable the following kernel +configuration option + +.. code-block:: + + Device Drivers->Graphics Support->Support for framebuffer devices->Framebuffer Console Support + +More information can be found at: +https://www.kernel.org/doc/Documentation/fb/fbcon.txt + +Tools Provided in the Prebuild Image +.................................... + +RAM Benchmark +~~~~~~~~~~~~~ + +Performing RAM and cache performance tests can best be done by using *pmbw* +(Parallel Memory Bandwidth Benchmark/Measurement Tool). *Pmbw* runs several +assembly routines which all use different access patterns to the caches and RAM +of the SoC. Before running the test, make sure that you have about 2 MiB of +space left on the device for the log files. We also lower the level of the +benchmark to ask the kernel more aggressively for resources. The benchmark test +will take several hours. + +To start the test type + +.. code-block:: console + + target:~$ nice -n -2 pmbw + +Upon completion of the test run, the log file can be converted to a *gnuplot* +script with + +.. code-block:: console + + target:~$ stats2gnuplot stats.txt > run1.gnuplot + +Now you can transfer the file to the host machine and install any version of +*gnuplot* + +.. code-block:: console + + host:~$ sudo apt-get install gnuplot host:~$ gnuplot run1.gnuplot + +The generated *plots-.pdf* file contains all plots. To render single +plots as *png* files for any web output you can use *Ghostscript* + +.. code-block:: console + + host:~$ sudo apt-get install ghostscript + host:~$ gs -dNOPAUSE -dBATCH -sDEVICE=png16m -r150 -sOutputFile='page-%00d.png' plots-phyboard-wega-am335x-1.pdf + +Add Additional Software for the BSP Image +......................................... + +To add additional software to the image, look at the OpenEmbedded layer index: +https://layers.openembedded.org/layerindex/branch/mickledore/layers/ + +First, select the *Yocto* version of the BSP you have from the drop-down list in +the top left corner and click **Recipes**. Now you can search for a software +project name and find which layer it is in. In some cases, the program is in +*meta-openembedded*, *openembedded-core*, or *Poky* which means that the recipe +is already in your build tree. This section describes how to add additional +software when this is the case. If the package is in another layer, see the next +section. + +You can also search the list of available recipes + +.. code-block:: console + + host:~$ bitbake -s | grep # fill in program name, like in + host:~$ bitbake -s | grep lsof + +When the recipe for the program is already in the *Yocto* build, you can simply +add it by appending a configuration option to your file *build/conf/local.conf*. +The general syntax to add additional software to an image is + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " " + +For example, the line + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " ldd strace file lsof" + +installs some helper programs on the target image. + +.. warning:: + + The leading whitespace is essential for the append command. + +All configuration options in local.conf apply to all images. Consequently, the +tools are now included in both images phytec-headless-image and +phytec-qt6demo-image. + +Notes about Packages and Recipes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You are adding packages to the IMAGE_INSTALL variable. Those are not necessarily +equivalent to the recipes in your meta-layers. A recipe defines per default a +package with the same name. But a recipe can set the PACKAGES variable to +something different and is able to generate packages with arbitrary names. +Whenever you look for software, you have to search for the package name and, +strictly speaking, not for the recipe. In the worst case, you have to look at +all PACKAGES variables. A tool such as *Toaster* can be helpful in some cases. + +If you can not find your software in the layers provided in the folder +*sources*, see the next section to include another layer into the *Yocto* +build. + +References: `Yocto 4.2.4 Documentation - Customizing Yocto builds +`_ + +Add an Additional Layer +....................... + +This is a step-by-step guide on how to add another layer to your *Yocto* build +and install additional software from it. As an example, we include the network +security scanner *nmap* in the layer *meta-security*. First, you must locate the +layer on which the software is hosted. Check out the `OpenEmbedded MetaData +Index `_ +and guess a little bit. The network scanner *nmap* is in the *meta-security* +layer. See `meta-security on layers.openembedded.org +`_. +To integrate it into the *Yocto* build, you have to check out the repository and +then switch to the correct stable branch. Since the BSP is based on the *Yocto* +'sumo' build, you should try to use the 'sumo' branch in the layer, too. + +.. code-block:: console + + host:~$ cd sources + host:~$ git clone git://git.yoctoproject.org/meta-security + host:~$ cd meta-security + host:~$ git branch -r + +All available remote branches will show up. Usually there should be 'fido', +'jethro', 'krogoth', 'master', ... + +.. code-block:: console + + host:~$ git checkout mickledore + +Now we add the directory of the layer to the file *build/conf/bblayers.conf* by +appending the line + +.. code-block:: kconfig + + # file build/conf/bblayers.conf + BBLAYERS += "${BSPDIR}/sources/meta-security" + +to the end of the file. After that, you can check if the layer is available in +the build configuration by executing + +.. code-block:: console + + host:~$ bitbake-layers show-layers + +If there is an error like + +.. code-block:: + + ERROR: Layer 'security' depends on layer 'perl-layer', but this layer is not enabled in your configuration + +the layer that you want to add (here *meta-security*), depends on another layer, +which you need to enable first. E.g. the dependency required here is a layer in +*meta-openembedded* (in the PHYTEC BSP it is in the path +*sources/meta-openembedded/meta-perl/*). To enable it, add the following line to +*build/conf/bblayers.conf* + +.. code-block:: kconfig + + # file build/conf/bblayers.conf + BBLAYERS += "${BSPDIR}/sources/meta-openembedded/meta-perl" + +Now the command *bitbake-layers show-layers* should print a list of all layers +enabled including *meta-security* and *meta-perl*. After the layer is included, +you can install additional software from it as already described above. The +easiest way is to add the following line (here is the package *nmap*) + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " nmap" + +to your *build/conf/local.conf*. Do not forget to rebuild the image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +Create your own layer +.................................. + +Creating your layer should be one of the first tasks when customizing the BSP. +You have two basic options. You can either copy and rename our *meta-ampliphy*, +or you can create a new layer that will contain your changes. The better option +depends on your use case. *meta-ampliphy* is our example of how to create a +custom *Linux* distribution that will be updated in the future. If you want to +benefit from those changes and are, in general, satisfied with the userspace +configuration, it could be the best solution to create your own layer on top of +*Ampliphy*. If you need to rework a lot of information and only need the basic +hardware support from PHYTEC, it would be better to copy *meta-ampliphy*, rename +it, and adapt it to your needs. You can also have a look at the OpenEmbedded +layer index to find different distribution layers. If you just need to add your +own application to the image, create your own layer. + +In the following chapter, we have an embedded project called "racer" which we +will implement using our *Ampliphy Linux* distribution. First, we need to create +a new layer. + +*Yocto* provides a script for that. If you set up the BSP and the shell is +ready, type + +.. code-block:: console + + host:~$ bitbake-layers create-layer meta-racer + +Default options are fine for now. Move the layer to the source directory + +.. code-block:: console + + host:~$ mv meta-racer ../sources/ + +Create a *Git* repository in this layer to track your changes + +.. code-block:: console + + host:~$ cd ../sources/meta-racer + host:~$ git init && git add . && git commit -s + +Now you can add the layer directly to your build/conf/bblayers.conf + +.. code-block:: kconfig + + BBLAYERS += "${BSPDIR}/sources/meta-racer" + +or with a script provided by *Yocto* + +.. code-block:: console + + host:~$ bitbake-layers add-layer meta-racer + +Kernel and Bootloader Recipe and Version +........................................ + +First, you need to know which kernel and version are used for your target +machine. PHYTEC provides multiple kernel recipes *linux-mainline*, *linux-ti* +and *linux-imx*. The first one provides support for PHYTEC's i.MX 6 and AM335x +modules and is based on the *Linux* kernel stable releases from `kernel.org +`_. +The *Git* repositories URLs are: + +- *linux-mainline*: git://git.phytec.de/linux-mainline +- *linux-ti*: git://git.phytec.de/linux-ti +- *linux-imx:* git://git.phytec.de/linux-imx +- *barebox*: git://git.phytec.de/barebox +- *u-boot-imx*: git://git.phytec.de/u-boot-imx + +To find your kernel provider, execute the following command + +.. code-block:: console + + host:~$ bitbake virtual/kernel -e | grep "PREFERRED_PROVIDER_virtual/kernel" + +The command prints the value of the variable +*PREFERRED_PROVIDER_virtual/kernel*. The variable is used in the internal +*Yocto* build process to select the kernel recipe to use. The following lines +are different outputs you might see + +.. code-block:: kconfig + + PREFERRED_PROVIDER_virtual/kernel="linux-mainline" + PREFERRED_PROVIDER_virtual/kernel="linux-ti" + PREFERRED_PROVIDER_virtual/kernel="linux-imx" + +To see which version is used, execute *bitbake -s*. For example + +.. code-block:: console + + host:~$ bitbake -s | egrep -e "linux-mainline|linux-ti|linux-imx|barebox|u-boot-imx" + +The parameter *-s* prints the version of all recipes. The output contains the +recipe name on the left and the version on the right + +.. code-block:: + + barebox :2022.02.0-phy1-r7.0 + barebox-hosttools-native :2022.02.0-phy1-r7.0 + barebox-targettools :2022.02.0-phy1-r7.0 + linux-mainline :5.15.102-phy1-r0.0 + +As you can see, the recipe *linux-mainline* has version *5.15.102-phy1*. In +the PHYTEC's *linux-mainline* *Git* repository, you will find a corresponding +tag *v5.15.102-phy1*. The version of the *barebox* recipe is 2022.02.0-phy1. +On i.MX8M\* modules the output will contain *linux-imx* and *u-boot-imx*. + +.. _yocto-man-mickledore-kernel-and-bootloader-conf: + +Kernel and Bootloader Configuration +................................... + +The bootloader used by PHYTEC, *barebox*, uses the same build system as the +*Linux* kernel. Therefore, all commands in this section can be used to configure +the kernel and bootloader. To configure the kernel or bootloader, execute one of +the following commands + +.. code-block:: console + + host:~$ bitbake -c menuconfig virtual/kernel # Using the virtual provider name + host:~$ bitbake -c menuconfig linux-ti # Or use the recipe name directly + host:~$ bitbake -c menuconfig linux-mainline # Or use the recipe name directly (If you use an i.MX 6 or RK3288 Module) + host:~$ bitbake -c menuconfig linux-imx # Or use the recipe name directly (If you use an i.MX 8M*) + host:~$ bitbake -c menuconfig barebox # Or change the configuration of the bootloader + host:~$ bitbake -c menuconfig u-boot-imx # Or change the configuration of the bootloader (If you use an i.MX 8M*) + +After that, you can recompile and redeploy the kernel or bootloader + +.. code-block:: console + + host:~$ bitbake virtual/kernel -c compile # Or 'barebox' for the bootloader + host:~$ bitbake virtual/kernel -c deploy # Or 'barebox' for the bootloader + +Instead, you can also just rebuild the complete build output with + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # To update the kernel/bootloader, modules and the images + +In the last command, you can replace the image name with the name of an image of +your choice. The new images and binaries are in +*build/deploy/images//*. + +.. warning:: + + The build configuration is not permanent yet. Executing *bitbake + virtual/kernel -c clean* will remove everything. + +To make your changes permanent in the build system, you have to integrate your +configuration modifications into a layer. For the configuration you have two +options: + +- Include only a configuration fragment (a minimal *diff* between the + old and new configuration) +- Complete default configuration (*defconfig*) after your + modifications. + +Having a set of configuration fragments makes what was changed at which stage +more transparent. You can turn on and off the changes, you can manage +configurations for different situations and it helps when porting changes to new +kernel versions. You can also group changes together to reflect specific use +cases. A fully assembled kernel configuration will be deployed in the directory +*build/deploy/images/*. If you do not have any of those requirements, +it might be simpler to just manage a separate *defconfig* file. + +Add a Configuration Fragment to a Recipe +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The following steps can be used for both kernel and bootloader. Just replace the +recipe name *linux-mainline* in the commands with *linux-ti*, or *barebox* for +the bootloader. If you did not already take care of this, start with a clean +build. Otherwise, the diff of the configuration may be wrong + +.. code-block:: console + + host:~$ bitbake linux-mainline -c clean + host:~$ bitbake linux-mainline -c menuconfig + +Make your configuration changes in the menu and generate a config +fragment + +.. code-block:: console + + host:~$ bitbake linux-mainline -c diffconfig + +which prints the path of the written file + +.. code-block:: + + Config fragment has been dumped into: + /home//build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg + +All config changes are in the file *fragment.cfg* which should consist of only +some lines. The following example shows how to create a *bbappend* file and how +to add the necessary lines for the config fragment. You just have to adjust the +directories and names for the specific recipe: *linux-mainline*, *linux-ti*, +linux-imx, u-boot-imx, or *barebox*. + +.. code-block:: + + sources//recipes-kernel/linux/linux-mainline_%.bbappend # For the recipe linux-mainline + sources//recipes-kernel/linux/linux-ti_%.bbappend # For the recipe linux-ti + sources//recipes-kernel/linux/linux-imx_%.bbappend # For the recipe linux-imx + sources//recipes-bsp/barebox/barebox_%.bbappend # For the recipe barebox + sources//recipes-bsp/u-boot/u-boot-imx_%.bbappend # For the recipe u-boot-imx + +Replace the string *layer* with your own layer created as shown above (e.g. +*meta-racer*), or just use *meta-ampliphy*. To use *meta-ampliphy*, first, +create the directory for the config fragment and give it a new name (here +*enable-r8169.cfg*) and move the fragment to the layer. + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features + # copy the path from the output of *diffconfig* + host:~$ cp /home//build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg \ + sources/meta-ampliphy/recipes-kernel/linux/features/enable-r8169.cfg + +Then open the *bbappend* file (in this case +*sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend* ) with +your favorite editor and add the following lines + +.. code-block:: kconfig + + # contents of the file linux-mainline_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://enable-r8169.cfg \ + " + +.. warning:: + + Do not forget to use the correct *bbappend* filenames: *linux-ti_%.bbappend* + for the linux-ti recipe and *barebox_%.bbappend* for the bootloader in the + folder *recipes-bsp/barebox/* ! + +After saving the *bbappend* file, you have to rebuild the image. *Yocto* should +pick up the recipe changes automatically and generate a new image + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +Add a Complete Default Configuration (*defconfig*) to a Recipe +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This approach is similar to the one above, but instead of adding a fragment, a +*defconfig* is used. First, create the necessary folders in the layer you want +to use, either your own layer or *meta-ampliphy* + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features/ # For both linux-mainline and linux-ti + host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features/ # Or for the bootloader + +Then you have to create a suitable *defconfig* file. Make your configuration +changes using *menuconfig* and then save the *defconfig* file to the layer + +.. code-block:: console + + host:~$ bitbake linux-mainline -c menuconfig # Or use recipe name linux-ti or barebox + host:~$ bitbake linux-mainline -c savedefconfig # Create file 'defconfig.temp' in the work directory + +This will print the path to the generated file + +.. code-block:: + + Saving defconfig to ..../defconfig.temp + +Then, as above, copy the generated file to your layer, rename it to *defconfig*, +and add the following lines to the *bbappend* file (here +*sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend*) + +.. code-block:: kconfig + + # contents of the file linux-mainline_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://defconfig \ + " + +.. tip:: + + Do not forget to use the correct bbappend filenames: *linux-ti_%.bbappend* + for the linux-ti recipe and *barebox_%.bbappend* for the bootloader in the + folder *recipes-bsp/barebox/* ! + +After that, rebuild your image as the changes are picked up automatically + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +Patch the Kernel or Bootloader with *devtool* +............................................. + +*Apart from using the standard versions of kernel and bootloader which are +provided in the recipes, you can modify the source code or use our own +repositories to build your customized kernel.* + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| Standard workflow of the | Uses additional hard drive space | +| official *Yocto* documentation | as the sources get duplicated | ++----------------------------------+----------------------------------+ +| Toolchain does not have to | No optimal cache usage, build | +| recompile everything | overhead | ++----------------------------------+----------------------------------+ + +*Devtool* is a set of helper scripts to enhance the user workflow of *Yocto*. It +was integrated with version 1.8. It is available as soon as you set up your +shell environment. *Devtool* can be used to: + +- modify existing sources +- integrate software projects into your build setup +- build software and deploy software modifications to your target + +Here we will use *devtool* to patch the kernel. We use *linux-mainline* as an +example for the AM335x Kernel. The first command we use is *devtool modify - x + * + +.. code-block:: console + + host:~$ devtool modify -x linux-mainline linux-mainline + +*Devtool* will create a layer in *build/workspace* where you can see all +modifications done by *devtool* . It will extract the sources corresponding to +the recipe to the specified directory. A *bbappend* will be created in the +workspace directing the SRC_URI to this directory. Building an image with +*Bitbake* will now use the sources in this directory. Now you can modify lines +in the kernel + +.. code-block:: console + + host:~$ vim linux-mainline/arch/arm/boot/dts/am335x-phycore-som.dtsi + -> make a change + host:~$ bitbake phytec-qt6demo-image + +Your changes will now be recompiled and added to the image. If you want to store +your changes permanently, it is advisable to create a patch from the changes, +then store and backup only the patch. You can go into the *linux-mainline* +directory and create a patch using *Git*. How to create a patch is described in +:ref:`mickledore_temporary-method` and is the same for all methods. + +If you want to learn more about *devtool*, visit: + +`Yocto 4.2.4 - Devtool +`_ +or `Devtool Quick Reference +`_ + +.. _mickledore_temporary-method: + +Patch the Kernel or Bootloader using the "Temporary Method" +........................................................... + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| No overhead, no extra | Changes are easily overwritten | +| configuration | by *Yocto* (Everything is | +| | lost!!). | ++----------------------------------+----------------------------------+ +| Toolchain does not have to | | +| recompile everything | | ++----------------------------------+----------------------------------+ + +It is possible to alter the source code before *Bitbake* configures and compiles +the recipe. Use *Bitbake'* s *devshell* command to jump into the source +directory of the recipe. Here is the *barebox* recipe + +.. code-block:: console + + host:~$ bitbake barebox -c devshell # or linux-mainline, linux-ti, linux-imx, u-boot-imx + +After executing the command, a shell window opens. The current working directory +of the shell will be changed to the source directory of the recipe inside the +*tmp* folder. Here you can use your favorite editor, e.g. *vim*, *emacs*, or any +other graphical editor, to alter the source code. When you are finished, exit +the *devshell* by typing *exit* or hitting **CTRL-D**. + +After leaving the *devshell* you can recompile the package + +.. code-block:: console + + host:~$ bitbake barebox -c compile --force # or linux-mainline, linux-ti, linux-imx, u-boot-imx + +The extra argument '--force' is important because *Yocto* does not recognize +that the source code was changed. + +.. tip:: + + You cannot execute the *bitbake* command in the *devshell* . You have + to leave it first. + +If the build fails, execute the devshell command again and fix it. If the build +is successful, you can deploy the package and create a new SD card image + +.. code-block:: console + + host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox.bin + host:~$ bitbake phytec-headless-image # new WIC image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic + +.. warning:: + + If you execute a clean e.g *bitbake barebox -c clean* , or if *Yocto* fetches + the source code again, all your changes are lost!!! + + To avoid this, you can create a patch and add it to a *bbappend* file. It is + the same workflow as described in the section about changing the + configuration. + + You have to create the patch in the *devshell* if you use the temporary + method and in the subdirectory created by *devtool* if you used *devtool*. + +.. code-block:: console + + host:~$ bitbake barebox -c devshell # Or linux-mainline, linux-ti + host(devshell):~$ git status # Show changes files + host(devshell):~$ git add # Add a special file to the staging area + host(devshell):~$ git commit -m "important modification" # Creates a commit with a not so useful commit message + host(devshell):~$ git format-patch -1 -o ~/ # Creates a patch of the last commit and saves it in your home folder + /home//0001-important-modification.patch # Git prints the path of the written patch file + host(devshell):~$ exit + +After you have created the patch, you must create a *bbappend* file for it. The +locations for the three different recipes - *linux-mainline* , *linux-ti* , and +*barebox* - are + +.. code-block:: + + sources//recipes-kernel/linux/linux-mainline_%.bbappend # For the recipe linux-mainline + sources//recipes-kernel/linux/linux-ti_%.bbappend # For the recipe linux-ti + sources//recipes-kernel/linux/linux-imx_%.bbappend # For the recipe linux-imx + sources//recipes-bsp/barebox/barebox_%.bbappend # For the recipe barebox + sources//recipes-bsp/u-boot/u-boot-imx_%.bbappend # For the recipe u-boot-imx + +The following example is for the recipe *barebox*. You have to adjust the paths. +First, create the folders and move the patch into them. Then create the +*bbappend* file + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features # Or use your own layer instead of *meta-ampliphy* + host:~$ cp ~/0001-important-modification.patch sources/meta-ampliphy/recipes-bsp/barebox/features # copy patch + host:~$ touch sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend + +.. tip:: + + Pay attention to your current work directory. You have to execute the + commands in the BSP top-level directory. Not in the *build* directory! + +After that use your favorite editor to add the following snipped into the +*bbappend* file (here +*sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend*) + +.. code-block:: kconfig + + # contents of the file barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://0001-important-modification.patch \ + " + +Save the file and rebuild the *barebox* recipe with + +.. code-block:: console + + host:~$ bitbake barebox -c clean # Or linux-ti, linux-mainline, linux-imx, u-boot-imx + host:~$ bitbake barebox + +If the build is successful, you can rebuild the final image with + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +**Further Resources:** + +The *Yocto* Project has some documentation for software developers. Check the +'Kernel Development Manual' for more information about how to configure the +kernel. Please note that not all of the information from the *Yocto* manual can +be applied to the PHYTEC BSP as we use the classic kernel approach of *Yocto* +and most of the documentation assumes the *Yocto* kernel approach. + +- `Yocto - Kernel Development Manual + `_ +- `Yocto - Development Manual + `_ + +Working with the Kernel and Bootloader using SRC_URI in *local.conf* +.................................................................... + +*Here we present a third option to make kernel and bootloader changes. You have +external checkouts of the linux-mainline, linux-ti, or barebox Git +repositories. You will overwrite the URL of the source code fetcher, the +variable SRC_URI, to point to your local checkout instead of the remote +repositories.* + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| All changes are saved with | Many working directories in | +| *Git* | *build/tmp-\ | +| | glibc/work///* | ++----------------------------------+----------------------------------+ +| | You have to commit every change | +| | before recompiling | ++----------------------------------+----------------------------------+ +| | For each change, the toolchain | +| | compiles everything from scratch | +| | (avoidable with *ccache*) | ++----------------------------------+----------------------------------+ + +First, you need a local clone of the *Git* repository *barebox* or +kernel. If you do not have one, use the commands + +.. code-block:: console + + host:~$ mkdir ~/git + host:~$ cd ~/git + host:~$ git clone git://git.phytec.de/barebox + host:~$ cd barebox + host:~$ git switch --create v2022.02.0-phy remotes/origin/v2022.02.0-phy + +Add the following snippet to the file build/conf/local.conf + +.. code-block:: kconfig + + # Use your own path to the git repository + # NOTE: Branch name in variable "BRANCH_pn-barebox" should be the same as the + # branch which is used in the repository folder. Otherwise your commits won't be recognized later. + BRANCH:pn-barebox = "v2022.02.0-phy" + SRC_URI:pn-barebox = "git:///${HOME}/git/barebox;branch=${BRANCH}" + SRCREV:pn-barebox = "${AUTOREV}" + +You also have to set the correct BRANCH name in the file. Either you create your +own branch in the *Git* repository, or you use the default (here +"v2015.02.0-phy"). Now you should recompile *barebox* from your own source + +.. code-block:: console + + host:~$ bitbake barebox -c clean + host:~$ bitbake barebox -c compile + +The build should be successful because the source was not changed yet. + +You can alter the source in *~/git/barebox* or the default *defconfig* (e.g. +*~/git/barebox/arch/arm/configs/imx_v7_defconfig*). After you are satisfied with +your changes, you have to make a dummy commit for *Yocto*. If you do not, +*Yocto* will not notice that the source code was modified in your repository +folder (e.g. ~/git/barebox/) + +.. code-block:: console + + host:~$ git status # show modified files + host:~$ git diff # show changed lines + host:~$ git commit -a -m "dummy commit for yocto" # This command is important! + +Try to compile your new changes. *Yocto* will automatically notice that the +source code was changed and fetches and configures everything from scratch. + +.. code-block:: console + + host:~$ bitbake barebox -c compile + +If the build fails, go back to the source directory, fix the problem, and +recommit your changes. If the build was successful, you can deploy *barebox* and +even create a new SD card image. + +.. code-block:: console + + host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox-phyflex-imx6-2.bin + host:~$ bitbake phytec-headless-image # new sd-card image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic + +If you want to make additional changes, just make another commit in the +repository and rebuild *barebox* again. + +Add Existing Software with "Sustainable Method" +............................................... + +Now that you have created your own layer, you have a second option to add +existing software to existing image definitions. Our standard image is defined +in meta-ampliphy + +.. code-block:: + + meta-ampliphy/recipes-images/images/phytec-headless-image.bb + +In your layer, you can now modify the recipe with a *bbappend* without modifying +any BSP code + +.. code-block:: + + meta-racer/recipes-images/images/phytec-headless-image.bbappend + +The append will be parsed together with the base recipe. As a result, you can +easily overwrite all variables set in the base recipe, which is not always what +you want. If we want to include additional software, we need to append it to the +IMAGE_INSTALL variable + +.. code-block:: kconfig + + IMAGE_INSTALL:append = " rsync" + +Add Linux Firmware Files to the Root Filesystem +............................................... + +It is a common task to add an extra firmware file to your root filesystem into +*/lib/firmware/*. For example, WiFi adapters or PCIe Ethernet cards might need +proprietary firmware. As a solution, we use a *bbappend* in our layer. To create +the necessary folders, *bbappend* and copy the firmware file type + +.. code-block:: console + + host:~$ cd meta-racer # go into your layer + host:~$ mkdir -p recipes-kernel/linux-firmware/linux-firmware/ + host:~$ touch recipes-kernel/linux-firmware/linux-firmware_%.bbappend + host:~$ cp ~/example-firmware.bin recipes-kernel/linux-firmware/linux-firmware/ # adapt filename + +Then add the following content to the *bbappend* file and replace every +occurrence of *example-firmware.bin* with your firmware file name. + +.. code-block:: kconfig + + # file recipes-kernel/linux-firmware/linux-firmware_%.bbappend + + FILESEXTRAPATHS:prepend := "${THISDIR}/linux-firmware:" + SRC_URI += "file://example-firmware.bin" + + do_install:append () { + install -m 0644 ${WORKDIR}/example-firmware.bin ${D}/lib/firmware/example-firmware.bin + } + + # NOTE: Use "=+" instead of "+=". Otherwise file is placed into the linux-firmware package. + PACKAGES =+ "${PN}-example" + FILES:${PN}-example = "/lib/firmware/example-firmware.bin" + +Now try to build the linux-firmware recipe + +.. code-block:: console + + host:~$ . sources/poky/oe-init-build-env + host:~$ bitbake linux-firmware + +This should generate a new package *deploy/ipk/all/linux-firmware-example*. + +As the final step, you have to install the firmware package to your image. You +can do that in your *local.conf* or image recipe via + +.. code-block:: kconfig + + # file local.conf or image recipe + IMAGE_INSTALL += "linux-firmware-example" + +.. warning:: + + Ensure that you have adapted the package name *linux-firmware-example* with + the name you assigned in *linux-firmware_%.bbappend*. + +Change the *u-boot* Environment via *bbappend* Files +.................................................... + +All i.MX8M\* products use the u-boot bootloader. The u-boot environment can be +modified using the Temporary Method. In the *u-boot-imx* sources modify the +header file corresponding to the processor located in +*include/configs/phycore_imx8m\**. New environment variables should be added at +the end of *CONFIG_EXTRA_ENV_SETTINGS* + +.. code-block:: kconfig + + #define CONFIG_EXTRA_ENV_SETTINGS \ + [...] + PHYCORE_FITIMAGE_ENV_BOOTLOGIC \ + "newvariable=1\0" + +Commit the changes and and create the file *u-boot-imx_%.bbappend* in your layer +at */recipes-bsp/u-boot/u-boot-imx_%.bbappend* + +.. code-block:: kconfig + + # contents of the file u-boot-imx_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://0001-environment-addition.patch \ + " + +Change the *barebox* Environment via *bbappend* Files +..................................................... + +Since *BSP-Yocto-AM335x-16.2.0* and *BSP-Yocto-i.MX6-PD16.1.0*, the *barebox* +environment handling in *meta-phytec* has changed. Now it is possible to add, +change, and remove files in the *barebox* environment via the *Python* bitbake +task *do_env*. There are two *Python* functions to change the environment. Their +signatures are: + +- *env_add(d, *\ **filename as string**\ *, *\ **file content as string**\ *)*: + to add a new file or overwrite an existing file +- *env_rm(d, *\ **filename as string**\ *)*: to remove a file + +The first example of a *bbappend* file in the custom layer *meta-racer* shows +how to add a new non-volatile variable *linux.bootargs.fb* in the *barebox* +environment folder */env/nv/* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_add(d, "nv/linux.bootargs.fb", "imxdrm.legacyfb_depth=32\n") + } + +The next example shows how to replace the network configuration file +*/env/network/eth0* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_add(d, "network/eth0", + """#!/bin/sh + + # ip setting (static/dhcp) + ip=static + global.dhcp.vendor_id=barebox-${global.hostname} + + # static setup used if ip=static + ipaddr=192.168.178.5 + netmask=255.255.255.0 + gateway=192.168.178.1 + serverip=192.168.178.1 + """) + } + +In the above example, the *Python* multiline string syntax **""" text """** is +used to avoid adding multiple newline characters *\\n* into the recipe *Python* +code. The *Python* function *env_add* can add and overwrite environment files. + +The next example shows how to remove an already added environment file, for +example *,* */env/boot/mmc* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_rm(d, "boot/mmc") + } + +Debugging the Environment +~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you want to see all environment files that are added in the build process, +you can enable a debug flag in the *local.conf* + +.. code-block:: kconfig + + # file local.conf + ENV_VERBOSE = "1" + +After that, you have to rebuild the *barebox* recipe to see the debugging +output + +.. code-block:: console + + host:~$ bitbake barebox -c clean + host:~$ bitbake barebox -c configure + +The output of the last command looks like this + +.. code-block:: + + [...] + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/allow_color' content "false" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.base' content "consoleblank=0" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.fb' content "imxdrm.legacyfb_depth=32" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.rootfs' content "rootwait ro fsck.repair=yes" + +Changing the Environment (depending on Machines) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you need to apply some *barebox* environment modifications only to a single +or only a few machines, you can use *Bitbake'* s machine overwrite syntax. For +the machine overwrite syntax, you append a machine name or SoC name (such as +*mx6* , *ti33x,* or *rk3288* ) with an underscore to a variable or task + +.. code-block:: kconfig + + DEPENDS:remove:mx6 = "virtual/libgl" or + python do_env_append_phyboard-mira-imx6-4(). + +The next example adds the environment variables only if the MACHINE is set to +*phyboard-mira-imx6-4* + +.. code-block:: kconfig + + # file meta-phytec/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append:phyboard-mira-imx6-4() { + env_add(d, "nv/linux.bootargs.cma", "cma=64M\n") + } + +*Bitbake's* override syntax for variables is explained in more detail at: +https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-metadata.html#conditional-metadata + +Upgrading the *barebox* Environment from Previous BSP Releases +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Prior to BSP version *BSP-Yocto-AM335x-16.2.0* and *BSP-Yocto-i.MX6-PD16.1.0* , +*barebox* environment changes via *bbappend* file were done differently. For +example, the directory structure in your meta layer (here *meta-skeleton* ) may +have looked like this + +.. code-block:: console + + host:~$ tree -a sources/meta-skeleton/recipes-bsp/barebox/ + sources/meta-skeleton/recipes-bsp/barebox + ├── barebox + │ └── phyboard-wega-am335x-3 + │ ├── boardenv + │ │ └── .gitignore + │ └── machineenv + │ └── nv + │ └── linux.bootargs.cma + └── barebox_%.bbappend + +and the file *barebox_%.bbappend* contained + +.. code-block:: kconfig + + # file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:" + +In this example, all environment changes from the directory *boardenv* in the +layer *meta-phytec* are ignored and the file *nv/linux.bootargs.cma* is added. +For the new handling of the *barebox* environment, you use the *Python* +functions *env_add* and *env_rm* in the *Python* task *do_env*. Now the above +example translates to a single *Python* function in the file +*barebox_%.bbappend* that looks like + +.. code-block:: kconfig + + # file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:" + python do_env:append() { + # Removing files (previously boardenv) + env_rm(d, "config-expansions") + # Adding new files (previously machineenv) + env_add(d, "nv/linux.bootargs.cma", "cma=64M\n") + } + +.. _mickledore_changing-net-config: + +Changing the Network Configuration +.................................. + +To tweak IP addresses, routes, and gateways at runtime you can use the tools +*ifconfig* and *ip* . Some examples + +.. code-block:: console + + target:~$ ip addr # Show all network interfaces + target:~$ ip route # Show all routes + target:~$ ip addr add 192.168.178.11/24 dev eth0 # Add static ip and route to interface eth0 + target:~$ ip route add default via 192.168.178.1 dev eth0 # Add default gateway 192.168.178.1 + target:~$ ip addr del 192.168.178.11/24 dev eth0 # Remove static ip address from interface eth0 + +The network configuration is managed by *systemd-networkd* . To query the +current status use + +.. code-block:: console + + target:~$ networkctl status + target:~$ networkctl list + +The network daemon reads its configuration from the directories +*/etc/systemd/network/* , */run/systemd/network/* , and */lib/systemd/network/* +(from higher to lower priority). A sample configuration in +*/lib/systemd/network/10-eth0.network* looks like this + +.. code-block:: kconfig + + # file /lib/systemd/network/10-eth0.network + [Match] + Name=eth0 + + [Network] + Address=192.168.3.11/24 + Gateway=192.168.3.10 + +These files *\*.network* replace */etc/network/interfaces* from other +distributions. You can either edit the file *10-eth0.network* in-place or copy +it to */etc/systemd/network/* and make your changes there. After changing a file +you must restart the daemon to apply your changes + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +To see the syslog message of the network daemon, use + +.. code-block:: console + + target:~$ journalctl --unit=systemd-networkd.service + +To modify the network configuration at build time, look at the recipe +*sources/meta-ampliphy/recipes-core/systemd/systemd-machine-units.bb* +and the interface files in the folder +*meta-ampliphy/recipes-core/systemd/systemd-machine-units/* where the static IP +address configuration for *eth0* (and optionally *eth1*) is done. + +For more information, see https://wiki.archlinux.org/title/Systemd-networkd +and https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html. + +Changing the Wireless Network Configuration +........................................... + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- First set the correct regulatory domain for your country + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +- Set up the wireless interface + +.. code-block:: console + + target:~$ ip link # list all interfaces. Search for wlan* + target:~$ ip link set up dev wlan0 + +- Now you can scan for available networks + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for *WEP*, *WPA*, and +*WPA2* called *wpa_supplicant* for an encrypted connection. + +- To do so, add the network credentials to the file + */etc/wpa_supplicant.conf* + +.. code-block:: kconfig + + Confluence country=DE network={ ssid="" proto=WPA2 psk="" } + +- Now a connection can be established + +.. code-block:: console + + target:~$ wpa_supplicant -Dnl80211 -c/etc/wpa_supplicant.conf -iwlan0 -B + +This should result in the following output + +.. code-block:: kconfig + + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see the section :ref:`mickledore_changing-net-config`. + +- First, create the directory + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +- Then add the following configuration snippet in + */etc/systemd/network/10-wlan0.network* + +.. code-block:: kconfig + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +- Now, restart the network daemon so that the configuration takes effect + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Creating a WLAN Access Point +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This section provides a basic access point (AP) configuration for a +secured *WPA2* network. + +Find the name of the WLAN interface with + +.. code-block:: console + + target:~$ ip link + +Edit the configuration in */etc/hostapd.conf*. It is strongly dependent on +the use case. The following shows an example + +.. code-block:: kconfig + + # file /etc/hostapd.conf + interface=wlan0 + driver=nl80211 + ieee80211d=1 + country_code=DE + hw_mode=g + ieee80211n=1 + ssid=Test-Wifi + channel=2 + wpa=2 + wpa_passphrase=12345678 + wpa_key_mgmt=WPA-PSK + wpa_pairwise=CCMP + +Set up and start the DHCP server for the network interface *wlan0* via +*systemd-networkd* + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + target:~$ vi /etc/systemd/network/10-wlan0.network + +Insert the following text into the file + +.. code-block:: kconfig + + [Match] + Name=wlan0 + + [Network] + Address=192.168.0.1/24 + DHCPServer=yes + + [DHCPServer] + EmitDNS=yes + target:~$ systemctl restart systemd-networkd + target:~$ systemctl status systemd-networkd -l # check status and see errors + +Start the userspace daemon *hostapd* + +.. code-block:: console + + target:~$ systemctl start hostapd + target:~$ systemctl status hostapd -l # check for errors + +Now, you should see the WLAN network *Test-Wifi* on your terminal device +(laptop, smartphone, etc.). + +If there are problems with the access point, you can either check the log +messages with + +.. code-block:: console + + target:~$ journalctl --unit=hostapd + +or start the daemon in debugging mode from the command line + +.. code-block:: console + + target:~$ systemctl stop hostapd + target:~$ hostapd -d /etc/hostapd.conf -P /var/run/hostapd.pid + +You should see + +.. code-block:: + + ... + wlan0: interface state UNINITIALIZED->ENABLED + wlan0: AP-ENABLED + +Further information about AP settings and the userspace daemon +*hostapd* can be found at + +.. code-block:: + + https://wireless.wiki.kernel.org/en/users/documentation/hostapd + https://w1.fi/hostapd/ + +phyCORE-i.MX 6UL/ULL Bluetooth +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Special consideration must be paid when working with any Bluetooth on a +phyCORE-i.MX 6UL/ULL. For further information, please check `L-844e.A5 i.MX +6UL/ULL BSP Manual - Bluetooth +`_. + +Add OpenCV Libraries and Examples +................................. + +*OpenCV* (Opensource Computer Vision https://opencv.org/) is an open-source +library for computer vision applications. + +To install the libraries and examples edit the file *conf/local.conf* in the +*Yocto* build system and add + +.. code-block:: kconfig + + # file conf/local.conf + # Installing OpenCV libraries and examples + LICENSE_FLAGS_ACCEPTED += "commercial_libav" + LICENSE_FLAGS_ACCEPTED += "commercial_x264" + IMAGE_INSTALL:append = " \ + opencv \ + opencv-samples \ + libopencv-calib3d2.4 \ + libopencv-contrib2.4 \ + libopencv-core2.4 \ + libopencv-flann2.4 \ + libopencv-gpu2.4 \ + libopencv-highgui2.4 \ + libopencv-imgproc2.4 \ + libopencv-legacy2.4 \ + libopencv-ml2.4 \ + libopencv-nonfree2.4 \ + libopencv-objdetect2.4 \ + libopencv-ocl2.4 \ + libopencv-photo2.4 \ + libopencv-stitching2.4 \ + libopencv-superres2.4 \ + libopencv-video2.4 \ + libopencv-videostab2.4 \ + " + +Then rebuild your image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +.. tip:: + + Most examples do not work out of the box, because they depend on the *GTK* + graphics library. The BSP only supports *Qt6* . + +Add Minimal PHP web runtime with *lightpd* +.......................................... + +This is one example of how to add a small runtime for PHP applications and a web +server on your target. Lighttpd can be used together with the PHP command line +tool over cgi. This solution weights only 5.5 MiB of disk storage. It is already +preconfigured in meta-ampliphy. Just modify the build configuration to install +it on the image + +.. code-block:: kconfig + + # file conf/local.conf + # install lighttpd with php cgi module + IMAGE_INSTALL:append = " lighttpd" + +After booting the image, you should find the example web content in */www/pages* +. For testing php, you can delete the *index.html* and replace it with a +*index.php* file + +.. code-block:: html + + + + PHP-Test + + + + + + +On your host, you can point your browser to the board's IP, (e.g. 192.168.3.11) +and the phpinfo should show up. + +Common Tasks +------------ + +Debugging a User Space Application +.................................. + +The phytec-qt6demo-image can be cross-debugged without any change. For +cross-debugging, you just have to match the host sysroot with the image in use. +So you need to create a toolchain for your image + +.. code-block:: console + + host:~$ bitbake -c populate_sdk phytec-qt6demo-image + +Additionally, if you want to have full debug and backtrace capabilities for all +programs and libraries in the image, you could add + +.. code-block:: kconfig + + DEBUG_BUILD = "1" + +to the ``conf/local.conf``. This is not necessary in all cases. The compiler +options will then be switched from FULL_OPTIMIZATION to DEBUG_OPTIMIZATION. Look +at the *Poky* source code for the default assignment of DEBUG_OPTIMIZATION. + +To start a cross debug session, install the SDK as mentioned previously, source +the SDK environment, and run *Qt Creator* in the same shell. If you do not use +*Qt Creator*, you can directly call the arm-<..>-gdb debugger instead which +should be in your path after sourcing the environment script. + +If you work with *Qt Creator*, have a look at the appropriate documentation +delivered with your product (either QuickStart or Application Guide) for +information on how to set up the toolchain. + +When starting the debugger with your userspace application you will get a +SIGILL, an illegal instruction from the *libcrypto*. *Openssl* probes for the +system capabilities by trapping illegal instructions, which will trigger *GDB*. +You can ignore this and hit **Continue** (c command). You can permanently ignore +this stop by adding + +.. code-block:: kconfig + + handle SIGILL nostop + +to your *GDB* startup script or in the *Qt Creator GDB* configuration panel. +Secondly, you might need to disable a security feature by adding + +.. code-block:: kconfig + + set auto-load safe-path / + +to the same startup script, which will enable the automatic loading of libraries +from any location. + +If you need to have native debugging, you might want to install the debug +symbols on the target. You can do this by adding the following line to your +*conf/local.conf* + +.. code-block:: kconfig + + EXTRA_IMAGE_FEATURES += "dbg-pkgs" + +For cross-debugging, this is not required as the debug symbols will be loaded +from the host side and the dbg-pkgs are included in the SDK of your image +anyway. + +.. _mickledore_gen-source-mirrors: + +Generating Source Mirrors, working Offline +.......................................... + +Modify your *site.conf* (or *local.conf* if you do not use a *site.conf* ) as +follows + +.. code-block:: kconfig + + #DL_DIR ?= "" don't set it! It will default to a directory inside /build + SOURCE_MIRROR_URL = "file:///home/share/yocto_downloads/" + INHERIT += "own-mirrors" + BB_GENERATE_MIRROR_TARBALLS = "1" + +Now run + +.. code-block:: console + + host:~$ bitbake --runall=fetch + +for all images and for all machines you want to provide sources for. This will +create all the necessary *tar* archives. We can remove all SCM subfolders, as +they are duplicated with the tarballs + +.. code-block:: console + + host:~$ rm -rf build/download/git2/ + etc... + +Please consider that we used a local source mirror for generating the dl_dir. +Because of that, some archives will be linked locally. + +First, we need to copy all files, resolving symbolic links into the new mirror +directory + +.. code-block:: console + + host:~$ rsync -vaL ${TOPDIR}/../src_mirror/ + +Now we clean the */build* directory by deleting everything except */build/conf/* +but including */build/conf/sanity*. We change *site.conf* as follows + +.. code-block:: kconfig + + SOURCE_MIRROR_URL = "file://${TOPDIR}/../src_mirror" + INHERIT += "own-mirrors" + BB_NO_NETWORK = "1" + SCONF_VERSION = "1" + +The BSP directory can now be compressed with + +.. code-block:: console + + host:~$ tar cfJ .tar.xz + +where filename and folder should be the full BSP Name. + +Compiling on the Target +....................... + +To your *local.conf* add + +.. code-block:: kconfig + + IMAGE_FEATURES:append = " tools-sdk dev-pkgs" + +Different Toolchains +.................... + +There are several ways to create a toolchain installer in *Poky*. One option is +to run + +.. code-block:: console + + host:~$ bitbake meta-toolchain + +This will generate a toolchain installer in *build/deploy/sdk* which can be used +for cross-compiling of target applications. However, the installer does not +include libraries added to your image, so it is a bare *GCC* compiler only. This +is suited for bootloader and kernel development. + +Another you can run is + +.. code-block:: console + + host:~$ bitbake -c populate_sdk + +This will generate a toolchain installer containing all necessary development +packages of the software installed on the root filesystem of the target. This +installer can be handed over to the user space application development team and +includes all necessary parts to develop an application. If the image contains +the *QT* libraries, all of those will be available in the installer too. + +The third option is to create the ADT (Application Development Toolkit) +installer. It will contain the cross-toolchain and some tools to aid the +software developers, for example, an *Eclipse* plugin and a *QEMU* target +simulator. + +.. code-block:: console + + host:~$ bitbake adt-installer + +The ADT is untested for our BSP at the moment. + +Using the SDK +~~~~~~~~~~~~~ + +After generating the SDK with + +.. code-block:: console + + host:~$ source sources/poky/oe-init-build-env + host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image + +run the generated binary with + +.. code-block:: console + + host:~$ deploy/sdk/ampliphy-glibc-x86_64-phytec-qt6demo-image-cortexa9hf-vfp-neon-toolchain-i.MX6-PD15.3-rc.sh + Enter target directory for SDK (default: /opt/ampliphy/i.MX6-PD15.3-rc): + You are about to install the SDK to "/opt/ampliphy/i.MX6-PD15.3-rc". Proceed[Y/n]? + Extracting SDK...done + Setting it up...done + SDK has been successfully set up and is ready to be used. + +You can activate the toolchain for your shell by sourcing the file +*environment-setup* in the toolchain directory + +.. code-block:: console + + host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + +Then the necessary tools like the cross compiler and linker are in your PATH. To +compile a simple *C* program, use + +.. code-block:: console + + host:~$ $CC main.c -o main + +The environment variable $CC contains the path to the ARM cross compiler and +other compiler arguments needed like *-march* , *-sysroot* and *--mfloat-abi*. + +.. tip:: + + You cannot compile programs only with the compiler name like + + .. code-block:: console + + host:~$ arm-phytec-linux-gnueabi-gcc main.c -o main + + It will fail in many cases. Always use *CC*, CFLAGS, LDFLAGS, and so on. + +For convenience, the *environment-setup* exports other environment variables +like CXX, LD, SDKTARGETSYSROOT. + +A simple makefile compiling a *C* and *C++* program may look like this + +.. code-block:: kconfig + + # Makefile + TARGETS=c-program cpp-program + + all: $(TARGETS) + + c-program: c-program.c + $(CC) $(CFLAGS) $(LDFLAGS) $< -o $@ + + cpp-program: cpp-program.cpp + $(CXX) $(CXXFLAGS) $(LDFLAGS) $< -o $@ + + .PHONY: clean + clean: + rm -f $(TARGETS) + +To compile for the target, just source the toolchain in your shell before +executing make + +.. code-block:: console + + host:~$ make # Compiling with host CC, CXX for host architecture + host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + host:~$ make # Compiling with target CC, CXX for target architecture + +If you need to specify additionally included directories in the sysroot of the +toolchain, you can use an '=' sign in the *-I* argument like + +.. code-block:: kconfig + + -I=/usr/include/SDL + +*GCC* replaces it by the sysroot path (here +*/opt/ampliphy/i.MX6-PD15.3-rc/sysroots/cortexa9hf-vfp-neon-phytec-linux-gnueabi/*). +See the main page of *GCC* for more information. + +.. tip:: + + The variables $CFLAGS and $CXXFLAGS contain the compiler debug flag '-g' by + default. This includes debugging information in the binary and making it + bigger. Those should be removed from the production image. If you create a + *Bitbake* recipe, the default behavior is to turn on '-g' too. The debugging + symbols are used in the SDK rootfs to be able to get debugging information + when invoking *GDB* from the host. Before installing the package to the + target rootfs, *Bitbake* will invoke *strip* on the program which removes the + debugging symbols. By default, they are not found nor required on the target + root filesystem + +Using the SDK with GNU Autotools +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +*Yocto* SDK is a straightforward tool for a project that uses the *GNU +Autotools*. The traditional compile steps for the host are usually + +.. code-block:: console + + host:~$ ./autogen.sh # maybe not needed + host:~$ ./configure + host:~$ make + host:~$ make install DESTDIR=$PWD/build/ + +The commands to compile for the target machine with the *Yocto* SDK are quite +similar. The following commands assume that the SDK was unpacked to the +directory */opt/phytec-ampliphy/i.MX6-PD15.3.0/* (adapt the path as needed) + +.. code-block:: console + + host:~$ source /opt/phytec-ampliphy/i.MX6-PD15.3.0/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + host:~$ ./autogen.sh # maybe not needed + host:~$ ./configure ${CONFIGURE_FLAGS} + host:~$ make + host:~$ make install DESTDIR=$PWD/build/ + +Refer to the official *Yocto* documentation for more information: +https://docs.yoctoproject.org/4.2.4/singleindex.html#autotools-based-projects + +Working with Kernel Modules +........................... + +You will come to the point where you either need to set some options for a +kernel module or you want to blacklist a module. Those things are handled by +*udev* and go into *\*.conf* files in + +.. code-block:: + + /etc/modprobe.d/\*.conf. + +If you want to specify an option at build time, there are three relevant +variables. If you just want to autoload a module that has no autoload +capabilities, add it to + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + +either in the kernel recipe or in the global variable scope. If you need to +specify options for a module, you can do so with + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + KERNEL_MODULE_PROBECONF += "your-module" + module_conf_your-module = "options your-module parametername=parametervalue" + +if you want to blacklist a module from autoloading, you can do it intuitively +with + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + KERNEL_MODULE_PROBECONF += "your-module" + module_conf_your-module = "blacklist your-module" + +Working with *udev* +................... + +Udev (Linux dynamic device management) is a system daemon that handles dynamic +device management in /dev. It is controlled by *udev* \ rules that are located +in */etc/udev/rules.d* (sysadmin configuration space) and\ */lib/udev/rules.d/* +(vendor-provided). Here is an example of an *udev* \ rule file + +.. code-block:: kconfig + + # file /etc/udev/rules.d/touchscreen.rules + # Create a symlink to any touchscreen input device + SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="input:*-e0*,3,*a0,1,*18,*", SYMLINK+="input/touchscreen0" + SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="ads7846", SYMLINK+="input/touchscreen0" + +See https://www.freedesktop.org/software/systemd/man/latest/udev.html for more details +about the syntax and usage. To get the list of attributes for a specific device +that can be used in an *udev* rule you can use the *udevadm info* tool. It +prints all existing attributes of the device node and its parents. The key-value +pairs from the output can be copied and pasted into a rule file. Some examples + +.. code-block:: console + + target:~$ udevadm info -a /dev/mmcblk0 + target:~$ udevadm info -a /dev/v4l-subdev25 + target:~$ udevadm info -a -p /sys/class/net/eth0 + +After changing an *udev* rule, you have to notify the daemon. Otherwise, your +changes are not reflected. Use the following command + +.. code-block:: console + + target:~$ udevadm control --reload-rules + +While developing *udev* rules you should monitor the events in order to see when +devices are attached or unattached to the system. Use + +.. code-block:: console + + target:~$ udevadm monitor + +Furthermore, it is very useful to monitor the system log in another shell, +especially if the rule executes external scripts. Execute + +.. code-block:: console + + target:~$ journalctl -f + +.. tip:: + + You cannot start daemons or heavy scripts in a *RUN* attribute. See + https://www.freedesktop.org/software/systemd/man/latest/udev.html#RUN%7Btype%7D . + + This can only be used for very short-running foreground tasks. Running an + event process for a long period of time may block all further events for this + or a dependent device. Starting daemons or other long-running processes is + not appropriate for *udev*; the forked processes, detached or not, will be + unconditionally killed after the event handling has finished. You can use the + special attribute *ENV{SYSTEMD_WANTS}="service-name.service"* and a + *systemd*\ service instead. + + See + https://unix.stackexchange.com/questions/63232/what-is-the-correct-way-to-write-a-udev-rule-to-stop-a-service-under-systemd. + +Troubleshooting +=============== + +Setscene Task Warning +--------------------- + +This warning occurs when the Yocto cache is in a dirty state. + +.. code-block:: + + WARNING: Setscene task X ([...]) failed with exit code '1' - real task + +You should avoid canceling the build process or if you have to, press Ctrl-C +once and wait until the build process has stopped. To remove all these warnings +just clean the sstate cache and remove the build folders. + +.. code-block:: console + + host:~$ bitbake phytec-headless-image -c cleansstate && rm -rf tmp deploy/ipk + +Yocto Documentation +=================== + +The most important piece of documentation for a BSP user is probably the +developer manual. +https://docs.yoctoproject.org/4.2.4/dev-manual/index.html + +The chapter about common tasks is a good starting point. +https://docs.yoctoproject.org/4.2.4/dev-manual/layers.html#understanding-and-creating-layers + +The complete documentation is available on one single HTML page, which is good +for searching for a feature or a variable name. +https://docs.yoctoproject.org/4.2.4/singleindex.html diff --git a/previews/271/_sources/yocto/scarthgap.rst.txt b/previews/271/_sources/yocto/scarthgap.rst.txt new file mode 100644 index 000000000..52f4e7472 --- /dev/null +++ b/previews/271/_sources/yocto/scarthgap.rst.txt @@ -0,0 +1,3131 @@ +.. Download links +.. _`static-pdf-dl`: ../_static/scarthgap.pdf + +.. Yocto +.. |yocto-codename| replace:: Scarthgap +.. |yocto-ref-manual| replace:: Yocto Reference Manual +.. |distro| replace:: ampliphy-vendor-xwayland + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-------------------------------------------------------------+ +| |yocto-ref-manual| | ++=======================+=====================================+ +| Document Title | |yocto-ref-manual| |yocto-codename| | ++-----------------------+-------------------------------------+ +| Document Type | Yocto Manual | ++-----------------------+-------------------------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+-------------------------------------+ +| Is Branch of | |yocto-ref-manual| | ++-----------------------+-------------------------------------+ + ++-------------------------------------+------------------+------------------+------------+ +| Compatible BSPs | BSP Release Type | BSP Release Date | BSP Status | ++=====================================+==================+==================+============+ +| BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.0 | Major | 2024-04-02 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 | Minor | 2024-04-09 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 | Minor | 2024-06-26 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX8MP-PD24.1.0 | Major | 2024-11-07 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX93-PD24.2.0 | Major | 2024-10-08 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX6UL-PD24.1.0 | Major | 2024-07-19 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM62Ax-PD24.1.0 | Major | 2024-06-27 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM62x-PD24.1.0 | Major | 2024-06-27 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM64x-PD24.1.0 | Major | 2024-06-27 | released | ++-------------------------------------+------------------+------------------+------------+ + + +This manual applies to all |yocto-codename| based PHYTEC releases. + +.. _yocto-man-scarthgap: + +The Yocto Project +================= + +PHYTEC Documentation +-------------------- + +PHYTEC will provide a variety of hardware and software documentation for all of +our products. This includes any or all of the following: + +- **QS Guide**: A short guide on how to set up and boot a phyCORE board along + with brief information on building a BSP, the device tree, and accessing + peripherals. +- **Hardware Manual**: A detailed description of the System on Module and + accompanying carrier board. +- **Yocto Guide**: A comprehensive guide for the Yocto version the phyCORE + uses. This guide contains an overview of Yocto; introducing, installing, and + customizing the PHYTEC BSP; how to work with programs like Poky and Bitbake; + and much more. +- **BSP Manual**: A manual specific to the BSP version of the phyCORE. + Information such as how to build the BSP, booting, updating software, device + tree, and accessing peripherals can be found here. +- **Development Environment Guide**: This guide shows how to work with the + Virtual Machine (VM) Host PHYTEC has developed and prepared to run various + Development Environments. There are detailed step-by-step instructions for + Eclipse and Qt Creator, which are included in the VM. There are instructions + for running demo projects for these programs on a phyCORE product as well. + Information on how to build a Linux host PC yourself is also a part of this + guide. +- **Pin Muxing Table**: phyCORE SOMs have an accompanying pin table (in Excel + format). This table will show the complete default signal path, from + processor to carrier board. The default device tree muxing option will also + be included. This gives a developer all the information needed in one + location to make muxing changes and design options when developing a + specialized carrier board or adapting a PHYTEC phyCORE SOM to an application. + +On top of these standard manuals and guides, PHYTEC will also provide Product +Change Notifications, Application Notes, and Technical Notes. These will be done +on a case-by-case basis. Most of the documentation can be found in the +applicable download page of our products. + +Yocto Introduction +------------------ + +Yocto is the smallest SI metric system prefix. Like milli equates to ``m = +10^-3``, and so is yocto ``y = 10^-24``. Yocto is also a project working group +of the `Linux Foundation `_ and therefore +backed up by several major companies in the field. On the `Yocto Project website +`_ you can read the official introduction: + + The Yocto Project is an open-source collaboration project that provides + templates, tools, and methods to help you create custom Linux-based systems + for embedded products regardless of the hardware architecture. It was founded + in 2010 as a collaboration among many hardware manufacturers, open-source + operating systems vendors, and electronics companies to bring some order to + the chaos of embedded Linux development. + +As said, the project wants to provide toolsets for embedded developers. It +builds on top of the long-lasting `OpenEmbedded +`_ project. It is not a Linux distribution. But +it contains the tools to create a Linux distribution specially fitted to the +product requirements. The most important step in bringing order to the set of +tools is to define a common versioning scheme and a reference system. All +subprojects have then to comply with the reference system and have to comply +with the versioning scheme. + +The release process is similar to the `Linux kernel `_. +Yocto increases its version number every six months and gives the release a +codename. The release list can be found here: +https://wiki.yoctoproject.org/wiki/Releases + +Core Components +--------------- + +The most important tools or subprojects of the *Yocto* Project are: + +- Bitbake: build engine, a task scheduler like make, interprets metadata +- OpenEmbedded-Core, a set of base layers, containing metadata of software, no + sources +- Yocto kernel + + - Optimized for embedded devices + - Includes many subprojects: rt-kernel, vendor patches + - The infrastructure provided by Wind River + - Alternative: classic kernel build → we use it to integrate our kernel into + *Yocto* + +- *Yocto* Reference BSP: *beagleboneblack*, *minnow max* +- *Poky*, the reference system, a collection of projects and tools, used to + bootstrap a new distribution based on *Yocto* + +Vocabulary +---------- + +Recipes +....... + +Recipes contain information about the software project (author, homepage, and +license). A recipe is versioned, defines dependencies, contains the URL of the +source code, and describes how to fetch, configure, and compile the sources. It +describes how to package the software, e.g. into different .deb packages, which +then contain the installation path. Recipes are basically written in *Bitbake's* +own programming language, which has a simple syntax. However, a recipe can +contain *Python* as well as a bash code. + +Classes +....... + +Classes combine functionality used inside recipes into reusable blocks. + +Layers +...... + +A layer is a collection of recipes, classes, and configuration metadata. +A layer can depend on other layers and can be included or excluded one +by one. It encapsulates a specific functionality and fulfills a specific +purpose. Each layer falls into a specific category: + +- Base +- Machine (BSP) +- Software +- Distribution +- Miscellaneous + +*Yocto's* versioning scheme is reflected in every layer as version branches. For +each *Yocto* version, every layer has a named branch in its *Git* repository. +You can add one or many layers of each category in your build. + +A collection of OpenEmbedded layers can be found here. The search function is +very helpful to see if a software package can be retrieved and integrated +easily: https://layers.openembedded.org/layerindex/branch/scarthgap/layers/ + +Machine +....... + +Machines are configuration variables that describe the aspects of the target +hardware. + +Distribution (Distro) +..................... + +Distribution describes the software configuration and comes with a set of +software features. + +Poky +---- + +*Poky* is the reference system to define *Yocto* Project compatibility. It +combines several subprojects into releases: + +- *Bitbake* +- *Toaster* +- OpenEmbedded Core +- *Yocto* Documentation +- *Yocto* Reference BSP + +Bitbake +....... + +*Bitbake* is the task scheduler. It is written in *Python* and interprets +recipes that contain code in *Bitbake's* own programming language, *Python*, and +bash code. The official documentation can be found here: +https://docs.yoctoproject.org/bitbake/2.8/index.html + +Toaster +....... + +*Toaster* is a web frontend for *Bitbake* to start and investigate builds. It +provides information about the build history and statistics on created images. +There are several use cases where the installation and maintenance of +a *Toaster* instance are beneficial. PHYTEC did not add or remove any features +to the upstream *Toaster*, provided by *Poky*. The best source for more +information is the official documentation: +https://docs.yoctoproject.org/dev/toaster-manual/index.html + +Official Documentation +---------------------- + +For more general questions about *Bitbake* and *Poky* consult the mega-manual: +https://docs.yoctoproject.org/dev/singleindex.html + +Compatible Linux Distributions +============================== + +To build *Yocto* you need a compatible *Linux* host development machine. The +list of supported distributions can be found in the reference manual: +https://docs.yoctoproject.org/dev/ref-manual/system-requirements.html#supported-linux-distributions + +PHYTEC BSP Introduction +======================= + +BSP Structure +------------- + +The BSP consists roughly of three parts. BSP management, BSP metadata, and BSP +content. The management consists of *Repo* and phyLinux while the metadata +depends on the SOC, which describes how to build the software. The content +comprises PHYTEC's *Git* repositories and external sources. + +BSP Management +.............. + +*Yocto* is an umbrella project. Naturally, this will force the user to base +their work on several external repositories. They need to be managed in a +deterministic way. We use manifest files, which contain an XML data structure, +to describe all git repositories with pinned-down versions. The *Repo* tool and +our phyLinux wrapper script are used to manage the manifests and set up the BSP, +as described in the manifest file. + +phyLinux +~~~~~~~~ + +phyLinux is a wrapper for *Repo* to handle downloading and setting up the BSP +with an "out of the box" experience. + +Repo +~~~~ + +*Repo* is a wrapper around the *Repo* toolset. The phyLinux script will install +the wrapper in a global path. This is only a wrapper, though. Whenever you run +``repo init -u ``, you first download the *Repo* tools from *Googles* Git +server in a specific version to the ``.repo/repo`` directory. The next time you +run *Repo*, all the commands will be available. Be aware that the *Repo* version +in different build directories can differ over the years if you do not run *Repo +sync*. Also if you store information for your archives, you need to include the +complete ``.repo`` folder. + +*Repo* expects a *Git* repository which will be parsed from the command line. In +the PHYTEC BSP, it is called phy²octo. In this repository, all information about +a software BSP release is stored in the form of a *Repo* XML manifest. This data +structure defines URLs of *Git* servers (called "remotes") and *Git* +repositories and their states (called "projects"). The *Git* repositories can be +seen in different states. The revision field can be a branch, tag, or commit id +of a repository. This means the state of the software is not necessarily unique +and can change over time. That is the reason we use only tags or commit ids for +our releases. The state of the working directory is then unique and does not +change. + +The manifests for the releases have the same name as the release itself. It is a +unique identifier for the complete BSP. The releases are sorted by the SoC +platform. The selected SoC will define the branch of the phy²octo *Git* +repository which will be used for the manifest selection. + +BSP Metadata +............ + +We include several third-party layers in our BSP to get a complete *Linux* +distribution up and running without the need to integrate external projects. All +used repositories are described in the following section. + +Poky +~~~~ + +The PHYTEC BSP is built on top of *Poky*. It comes with a specific version, +defined in the *Repo* manifest. *Poky* comes with a specific version of +*Bitbake*. The OpenEmbedded-core layer "meta" is used as a base for our *Linux* +system. + +meta-openembedded +~~~~~~~~~~~~~~~~~ + +OpenEmbedded is a collection of different layers containing the meta description +for many open-source software projects. We ship all OpenEmbedded layers with our +BSP, but not all of them are activated. Our example images pull several software +packages generated from OpenEmbedded recipes. + +meta-qt6 +~~~~~~~~ + +This layer provides an integration of *Qt6* in the *Poky*-based root filesystem +and is integrated into our BSP. + +meta-nodejs +~~~~~~~~~~~ + +This is an application layer to add recent Node.js versions. + +meta-gstreamer1.0 +~~~~~~~~~~~~~~~~~ + +This is an application layer to add recent GStreamer versions. + +meta-rauc +~~~~~~~~~ + +This layer contains the tools required to build an updated infrastructure with +`RAUC `_. A comparison with +other update systems can be found here: `Yocto update tools +`_. + +meta-phytec +~~~~~~~~~~~ + +This layer contains all machines and common features for all our BSPs. It is +PHYTEC's `Yocto Board Support Package +`_ for all supported +hardware (since *fido*) and is designed to be standalone with *Poky*. Only these +two parts are required if you want to integrate the PHYTEC's hardware into your +existing *Yocto* workflow. The features are: + +- Bootloaders in ``recipes-bsp/barebox/`` and ``recipes-bsp/u-boot/`` +- Kernels in ``recipes-kernel/linux/`` and + ``dynamic-layers/fsl-bsp-release/recipes-kernel/linux/`` +- Many machines in ``conf/machine/`` +- Proprietary *OpenGL ES/EGL* user space libraries for AM335x and i.MX 6 + platforms +- Proprietary *OpenCL* libraries for i.MX 6 platforms + +meta-ampliphy +~~~~~~~~~~~~~ + +This is our example distribution and BSP layer. It extends the basic +configuration of *Poky* with software projects described by all the other BSP +components. It provides a base for your specific development scenarios. The +current features are: + +- `systemd `_ init system +- Images: ``phytec-headless-image`` for non-graphics applications +- Camera integration with OpenCV and GStreamer examples for the i.MX 6 platform + bundled in a ``phytec-vision-image`` +- RAUC integration: we set up basic support for an A/B system image update, + which is possible locally and over-the-air + +meta-qt6-phytec +~~~~~~~~~~~~~~~ + +This is our layer for Qt6 board integration and examples. The features are: + +- `Qt6 with eglfs backend `_ for + PHYTEC's AM335x, i.MX 6 and RK3288 platforms +- Images: ``phytec-qt6demo-image`` for *Qt6* and video applications +- A *Qt6* demo application demonstrating how to create a *Qt6* project using + *QML* widgets and a *Bitbake* recipe for the *Yocto* and *systemd* + integration. It can be found in + ``sources/meta-qt6-phytec/recipes-qt/examples/phytec-qtdemo_git.bb`` + +meta-virtualization +~~~~~~~~~~~~~~~~~~~ + +- This layer provides support for building Xen, KVM, Libvirt, and associated + packages necessary for constructing OE-based virtualized solutions. + +meta-security +~~~~~~~~~~~~~ + +- This layer provides security tools, hardening tools for Linux kernels, and + libraries for implementing security mechanisms. + +meta-selinux +~~~~~~~~~~~~ + +- This layer's purpose is to enable SE Linux support. The majority of this + layer's work is accomplished in *bbappend* files, used to enable SE Linux + support in existing recipes. + +meta-browser +~~~~~~~~~~~~ + +- This is an application layer to add recent web browsers (Chromium, Firefox, + etc.). + +meta-rust +~~~~~~~~~ + +- Includes the Rust compiler and the Cargo package manager for Rust. + +meta-timesys +~~~~~~~~~~~~ + +- Timesys layer for Vigiles Yocto CVE monitoring, security notifications, and + image manifest generation. + +meta-freescale +~~~~~~~~~~~~~~ + +- This layer provides support for the i.MX, Layerscape, and QorIQ product + lines. + +meta-freescale-3rdparty +~~~~~~~~~~~~~~~~~~~~~~~ + +- Provides support for boards from various vendors. + +meta-freescale-distro +~~~~~~~~~~~~~~~~~~~~~ + +- This layer provides support for Freescale's Demonstration images for use with + OpenEmbedded and/or Yocto Freescale's BSP layer. + +base (fsl-community-bsp-base) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- This layer provides BSP base files of NXP. + +meta-fsl-bsp-release +~~~~~~~~~~~~~~~~~~~~ + +- This is the i.MX Yocto Project Release Layer. + +BSP Content +........... + +The BSP content gets pulled from different online sources when you first start +using *Bitbake*. All files will be downloaded and cloned in a local directory +configured as ``DL_DIR`` in *Yocto*. If you backup your BSP with the complete +content, those sources have to be backed up, too. How you can do this will be +explained in the chapter :ref:`scarthgap_gen-source-mirrors`. + +Build Configuration +------------------- + +The BSP initializes a build folder that will contain all files you +create by running *Bitbake* commands. It contains a ``conf`` folder +that handles build input variables. + +- ``bblayers.conf`` defines activated meta-layers, +- ``local.conf`` defines build input variables specific to your build +- ``site.conf`` defines build input variables specific to the development host + +The two topmost build input variables are ``DISTRO`` and ``MACHINE``. They are +preconfigured ``local.conf`` when you check out the BSP using phyLinux. + +We use "*Ampliphy*" as ``DISTRO`` with our BSP. This distribution will be +preselected and give you a starting point for implementing your own +configuration. + +A ``MACHINE`` defines a binary image that supports specific hardware +combinations of module and baseboard. Check the ``machine.conf`` file or our +webpage for a description of the hardware. + +Pre-built Images +================ + +For each BSP we provide pre-built target images that can be downloaded from the +PHYTEC FTP server: https://download.phytec.de/Software/Linux/ + +These images are also used for the BSP tests, which are flashed to the boards +during production. You can use the provided ``.wic`` images to create a bootable +SD card at any time. Identify your hardware and flash the downloaded image file +to an empty SD card using ``dd``. Please see section Images for information +about the correct usage of the command. + +BSP Workspace Installation +========================== + +Setting Up the Host +------------------- + +You can set up the host or use one of our build-container to run a Yocto build. +You need to have a running *Linux* distribution. It should be running on a +powerful machine since a lot of compiling will need to be done. + +If you want to use a build-container, you only need to install following +packages on your host + +.. code-block:: console + + host:~$ sudo apt install wget git + +Continue with the next step :ref:`scarthgap_git-config` after that. The documentation for +using build-container can be found in this manual after +:ref:`scarthgap_phylinux-advanced-usage` of phyLinux. + +Else *Yocto* needs a handful of additional packages on your host. For *Ubuntu* you need + +.. code-block:: console + + host:~$ sudo apt install gawk wget git diffstat unzip texinfo \ + gcc build-essential chrpath socat cpio python3 python3-pip \ + python3-pexpect xz-utils debianutils iputils-ping python3-git \ + python3-jinja2 libegl1-mesa libsdl1.2-dev \ + python3-subunit mesa-common-dev zstd liblz4-tool file locales + + +For other distributions you can find information in the *Yocto* Quick Build: +https://docs.yoctoproject.org/dev/brief-yoctoprojectqs/index.html + +.. _scarthgap_git-config: + +Git Configuration +----------------- + +The BSP heavily utilizes *Git*. *Git* needs some information from +you as a user to identify who made changes. Create a ``~/.gitconfig`` with the +following content, if you do not have one + +.. code-block:: kconfig + + [user] + name = + email = + [core] + editor = vim + [merge] + tool = vimdiff + [alias] + co = checkout + br = branch + ci = commit + st = status + unstage = reset HEAD -- + last = log -1 HEAD + [push] + default = current + [color] + ui = auto + +You should set ``name`` and ``email`` in your *Git* configuration, otherwise, +*Bitbake* will complain during the first build. You can use the two commands to +set them directly without editing ``~/.gitconfig`` manually + +.. code-block:: console + + host:~$ git config --global user.email "your_email@example.com" + host:~$ git config --global user.name "name surname" + +site.conf Setup +--------------- + +Before starting the *Yocto* build, it is advisable to configure the development +setup. Two things are most important: the download directory and the cache +directory. PHYTEC strongly recommends configuring the setup as it will reduce +the compile time of consequent builds. + +A download directory is a place where *Yocto* stores all sources fetched from +the internet. It can contain tar.gz, *Git* mirror, etc. It is very useful to set +this to a common shared location on the machine. Create this directory with 777 +access rights. To share this directory with different users, all files need to +have group write access. This will most probably be in conflict with default +*umask* settings. One possible solution would be to use ACLs for this +directory + +.. code-block:: console + + host:~$ sudo apt-get install acl + host:~$ sudo setfacl -R -d -m g::rwx + +If you have already created a download directory and want to fix the permissions +afterward, you can do so with + +.. code-block:: console + + host:~$ sudo find /home/share/ -perm /u=r ! -perm /g=r -exec chmod g+r \{\} \; + host:~$ sudo find /home/share/ -perm /u=w ! -perm /g=w -exec chmod g+w \{\} \; + host:~$ sudo find /home/share/ -perm /u=x ! -perm /g=x -exec chmod g+x \{\} \; + +The cache directory stores all stages of the build process. *Poky* has quite an +involved caching infrastructure. It is advisable to create a shared directory, +as all builds can access this cache directory, called the shared state cache. + +Create the two directories on a drive where you have approximately 50 GB of +space and assign the two variables in your ``build/conf/local.conf``:: + + DL_DIR ?= "/yocto_downloads" + SSTATE_DIR ?= "/yocto_sstate" + +If you want to know more about configuring your build, see the documented +example settings + +.. code-block:: + + sources/poky/meta-yocto/conf/local.conf.sample + sources/poky/meta-yocto/conf/local.conf.sample.extended + +phyLinux Documentation +====================== + +The phyLinux script is a basic management tool for PHYTEC *Yocto* BSP releases +written in *Python*. It is mainly a helper to get started with the BSP +structure. You can get all the BSP sources without the need of interacting with +*Repo* or *Git*. + +The phyLinux script has only one real dependency. It requires the *wget* tool +installed on your host. It will also install the `Repo tool +`_ in a global path +(/usr/local/bin) on your host PC. You can install it in a different location +manually. *Repo* will be automatically detected by phyLinux if it is found in +the PATH. The *Repo* tool will be used to manage the different *Git* +repositories of the *Yocto* BSP. + +Get phyLinux +------------ + +The phyLinux script can be found on the PHYTEC download server: +https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux + +Basic Usage +----------- + +For the basic usage of phyLinux, type + +.. code-block:: console + + host:~$ ./phyLinux --help + +which will result in + +.. code-block:: + + usage: phyLinux [-h] [-v] [--verbose] {init,info,clean} ... + + This Programs sets up an environment to work with The Yocto Project on Phytecs + Development Kits. Use phyLinx -h to display the help text for the + available commands. + + positional arguments: + {init,info,clean} commands + init init the phytec bsp in the current directory + info print info about the phytec bsp in the current directory + clean Clean up the current working directory + + optional arguments: + -h, --help show this help message and exit + -v, --version show program's version number and exit + --verbose + +Initialization +-------------- + +Create a fresh project folder + +.. code-block:: console + + host:~$ mkdir ~/yocto + +Calling phyLinux will use the default Python version. Starting with Ubuntu 20.04 +it will be Python3. If you want to initiate a BSP, which is not compatible with +Python3, you need to set Python2 as default (temporarily) before running +phyLinux + +.. code-block:: console + + host:~$ ln -s \`which python2\` python && export PATH=`pwd`:$PATH + +Now run phyLinux from the new folder + +.. code-block:: console + + host:~$ ./phyLinux init + +A clean folder is important because phyLinux will clean its working directory. +Calling phyLinux from a directory that isn't empty will result in the following +**warning**:: + + This current directory is not empty. It could lead to errors in the BSP configuration + process if you continue from here. At the very least, you have to check your build directory + for settings in bblayers.conf and local.conf, which will not be handled correctly in + all cases. It is advisable to start from an empty directory of call: + $ ./phyLinux clean + Do you really want to continue from here? + [yes/no]: + +On the first initialization, the phyLinux script will ask you to install the +*Repo* tool in your */usr/local/bin* directory. During the execution of the +*init* command, you need to choose your processor platform (SoC), PHYTEC's BSP +release number, and the hardware you are working on + +.. code-block:: + + *************************************************** + * Please choose one of the available SoC Platforms: + * + * 1: am335x + * 2: am57x + * 3: am62ax + * 4: am62x + * 5: am64x + * 6: am68x + * 7: imx6 + * 8: imx6ul + * 9: imx7 + * 10: imx8 + * 11: imx8m + * 12: imx8mm + * 13: imx8mp + * 14: imx8x + * 15: imx93 + * 16: nightly + * 17: rk3288 + * 18: stm32mp13x + * 19: stm32mp15x + * 20: topic + + # Exemplary output for chosen imx8mp + *************************************************** + * Please choose one of the available Releases: + * + * 1: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1-rc1 + * 2: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1-rc2 + * 3: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.0 + * 4: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 + * 5: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2-rc1 + * 6: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 + * 7: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.y + * 8: BSP-Yocto-Ampliphy-i.MX8MP-master + * 9: BSP-Yocto-FSL-i.MX8MP-ALPHA1 + * 10: BSP-Yocto-FSL-i.MX8MP-ALPHA2 + * 11: BSP-Yocto-FSL-i.MX8MP-PD21.1-rc1 + * 12: BSP-Yocto-FSL-i.MX8MP-PD21.1-rc2 + * 13: BSP-Yocto-FSL-i.MX8MP-PD21.1.0 + * 14: BSP-Yocto-FSL-i.MX8MP-PD21.1.1-rc1 + * 15: BSP-Yocto-FSL-i.MX8MP-PD21.1.1-rc2 + * 16: BSP-Yocto-FSL-i.MX8MP-PD21.1.1 + * 17: BSP-Yocto-FSL-i.MX8MP-PD21.1.2-rc1 + * 18: BSP-Yocto-FSL-i.MX8MP-PD21.1.2-rc2 + * 19: BSP-Yocto-FSL-i.MX8MP-PD21.1.2 + * 20: BSP-Yocto-FSL-i.MX8MP-PD21.1.3-rc1 + * 21: BSP-Yocto-FSL-i.MX8MP-PD21.1.3 + * 22: BSP-Yocto-NXP-i.MX8MP-PD22.1-rc1 + * 23: BSP-Yocto-NXP-i.MX8MP-PD22.1-rc2 + * 24: BSP-Yocto-NXP-i.MX8MP-PD22.1-rc3 + * 25: BSP-Yocto-NXP-i.MX8MP-PD22.1-rc4 + * 26: BSP-Yocto-NXP-i.MX8MP-PD22.1.0 + * 27: BSP-Yocto-NXP-i.MX8MP-PD22.1.1-rc1 + * 28: BSP-Yocto-NXP-i.MX8MP-PD22.1.1-rc2 + * 29: BSP-Yocto-NXP-i.MX8MP-PD22.1.1-rc3 + * 30: BSP-Yocto-NXP-i.MX8MP-PD22.1.1-rc4 + * 31: BSP-Yocto-NXP-i.MX8MP-PD22.1.1 + * 32: BSP-Yocto-NXP-i.MX8MP-PD22.1.2-rc1 + * 33: BSP-Yocto-NXP-i.MX8MP-PD22.1.2-rc2 + * 34: BSP-Yocto-NXP-i.MX8MP-PD22.1.2 + * 35: BSP-Yocto-NXP-i.MX8MP-PD22.1.y + * 36: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc1 + * 37: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc2 + * 38: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc3 + * 39: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc4 + * 40: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc5 + * 41: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc6 + * 42: BSP-Yocto-NXP-i.MX8MP-PD23.1.0 + * 43: BSP-Yocto-NXP-i.MX8MP-PD23.1.y + * 44: BSP-Yocto-NXP-i.MX8MP-PD24.1-rc1 + * 45: BSP-Yocto-NXP-i.MX8MP-PD24.1-rc2 + * 46: BSP-Yocto-NXP-i.MX8MP-PD24.1-rc3 + * 47: BSP-Yocto-NXP-i.MX8MP-PD24.1.0 + * 48: BSP-Yocto-NXP-i.MX8MP-PD24.1.y + + # Exemplary output for chosen BSP-Yocto-NXP-i.MX8MP-PD24.1.0 + ********************************************************************* + * Please choose one of the available builds: + * + no: machine: description and article number + distro: supported yocto distribution + target: supported build target + + 1: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM + Pollux PL1552.2 + PB-03123-001.A3 + distro: ampliphy-vendor + target: phytec-headless-image + 2: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM + Pollux PL1552.2 + PB-03123-001.A3 + distro: ampliphy-vendor-rauc + target: phytec-headless-bundle + target: phytec-headless-image + 3: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM + Pollux PL1552.2 + PB-03123-001.A3 + distro: ampliphy-vendor-xwayland + target: -c populate_sdk phytec-qt6demo-image + target: phytec-qt6demo-image + target: phytec-vision-image + 4: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM + Pollux PL1552.2 + PB-03123-001.A3 + distro: securiphy-vendor + target: phytec-securiphy-bundle + target: phytec-securiphy-image + 5: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM + Pollux PL1552.2 + PB-03123-001.A3 + distro: securiphy-vendor-provisioning + target: phytec-provisioning-image + + +If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. After the configuration is done, +you can always run + +.. code-block:: console + + host:~$ ./phyLinux info + + # Exemplary output + ********************************************** + * The current BSP configuration is: + * + * SoC: refs/heads/imx8mp + * Release: BSP-Yocto-NXP-i.MX8MP-PD24.1.0 + * + ********************************************** + +to see which SoC and Release are selected in the current workspace. If +you do not want to use the selector, phyLinux also supports command-line +arguments for several settings + +.. code-block:: console + + host:~$ MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.0 + +or view the help command for more information + +.. code-block:: console + + host:~$ ./phyLinux init --help + + usage: phyLinux init [-h] [--verbose] [--no-init] [-o REPOREPO] [-b REPOREPO_BRANCH] [-x XML] [-u URL] [-p PLATFORM] [-r RELEASE] + + options: + -h, --help show this help message and exit + --verbose + --no-init dont execute init after fetch + -o REPOREPO Use repo tool from another url + -b REPOREPO_BRANCH Checkout different branch of repo tool + -x XML Use a local XML manifest + -u URL Manifest git url + -p PLATFORM Processor platform + -r RELEASE Release version + +After the execution of the *init* command, phyLinux will print a few important +notes as well as information for the next steps in the build process. + +.. _scarthgap_phylinux-advanced-usage: + +Advanced Usage +-------------- + +phyLinux can be used to transport software states over any medium. The state of +the software is uniquely identified by *manifest.xml*. You can create a +manifest, send it to another place and recover the software state with + +.. code-block:: console + + host:~$ ./phyLinux init -x manifest.xml + +You can also create a *Git* repository containing your software states. The +*Git* repository needs to have branches other than master, as we reserved the +master branch for different usage. Use phyLinux to check out the states + +.. code-block:: console + + host:~$ ./phyLinux -u + +Using build-container +===================== + +.. warning:: + Currently, it is not possible to run the phyLinux script inside of a container. + After a complete init with the phyLinux script on your host machine, you can use a container for the build. + If you do not have phyLinux script running on your machine, please see phyLinux Documentation. + +There are various possibilities to run a build-container. Commonly used is +docker and podman, though we prefer podman as it does not need root privileges +to run. + +Installation +------------ + +How to install podman: https://podman.io +How to install docker: https://docs.docker.com/engine/install/ + +Available container +------------------- + +Right now we provide 4 different container based on Ubuntu LTS versions: +https://hub.docker.com/u/phybuilder + +- yocto-ubuntu-16.04 +- yocto-ubuntu-18.04 +- yocto-ubuntu-20.04 +- yocto-ubuntu-22.04 + +These containers can be run with podman or docker. With Yocto Project branch |yocto-codename| the container "yocto-ubuntu-20.04" is preferred. + +Download/Pull container +----------------------- + +.. code-block:: console + + host:~$ podman pull docker.io/phybuilder/yocto-ubuntu-20.04 + + OR + + host:~$ docker pull docker.io/phybuilder/yocto-ubuntu-20.04 + +By adding a tag at the end separated by a colon, you can also pull or run a special tagged container. + + podman pull docker.io/phybuilder/yocto-ubuntu-20.04:phy2 + +You can find all available tags in our duckerhub space: + +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-16.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-18.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-20.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-22.04/tags + +If you try to run a container, which is not pulled/downloaded, it will be pulled/downloaded automatically. + +You can have a look at all downloaded/pulled container with: + +.. code-block:: console + + $USERNAME@$HOSTNAME:~$ podman images + REPOSITORY TAG IMAGE ID CREATED SIZE + docker.io/phybuilder/yocto-ubuntu-22.04 latest d626178e448d 4 months ago 935 MB + docker.io/phybuilder/yocto-ubuntu-22.04 phy2 d626178e448d 4 months ago 935 MB + docker.io/phybuilder/yocto-ubuntu-20.04 phy2 e29a88b7172a 4 months ago 900 MB + docker.io/phybuilder/yocto-ubuntu-20.04 latest e29a88b7172a 4 months ago 900 MB + docker.io/phybuilder/yocto-ubuntu-18.04 phy1 14c9c3e477d4 7 months ago 567 MB + docker.io/phybuilder/yocto-ubuntu-18.04 latest 14c9c3e477d4 7 months ago 567 MB + docker.io/phybuilder/yocto-ubuntu-16.04 phy1 28c73e13ab4f 7 months ago 599 MB + docker.io/phybuilder/yocto-ubuntu-16.04 latest 28c73e13ab4f 7 months ago 599 MB + docker.io/phybuilder/yocto-ubuntu-22.04 phy1 5a0ef4b41935 8 months ago 627 MB + docker.io/phybuilder/yocto-ubuntu-20.04 phy1 b5a26a86c39f 8 months ago 680 MB + +Run container +------------- + +To run and use container for a Yocto build, first enter to your folder, where +you run phyLinux init before. Then start the container + +.. code-block:: console + + host:~$ podman run --rm=true -v /home:/home --userns=keep-id --workdir=$PWD -it docker.io/phybuilder/yocto-ubuntu-20.04 bash + +.. note:: + To run and use a container with docker, it is not that simple like with podman. + Therefore the container-user has to be defined and configured. + Furthermore forwarding of credentials is not given per default and has to be configured as well. + +Now your commandline should look something like that (where $USERNAME is the +user, who called "podman run" and the char/number code diffs every time a +container is started) + +.. code-block:: console + + $USERNAME@6593e2c7b8f6:~$ + +.. warning:: + If the given username is "root" you will not be able to run bitbake at all. + Please be sure, you run the container with your own user. + +Now you are ready to go on and starting the build. +To stop/close the container, just call + +.. code-block:: console + + $USERNAME@6593e2c7b8f6:~$ exit + +Working with Poky and Bitbake +============================= + +Start the Build +--------------- + +After you download all the metadata with phyLinux init, you have to set up the +shell environment variables. This needs to be done every time you open a new +shell for starting builds. We use the shell script provided by *Poky* in its +default configuration. From the root of your project directory type + +.. code-block:: console + + host:~$ source sources/poky/oe-init-build-env + +The abbreviation for the source command is a single dot + +.. code-block:: console + + host:~$ . sources/poky/oe-init-build-env + +The current working directory of the shell should change to *build/*. Before +building for the first time, you should take a look at the main configuration +file + +.. code-block:: console + + host:~$ vim conf/local.conf + +Your local modifications for the current build are stored here. Depending on +the SoC, you might need to accept license agreements. For example, to build the +image for Freescale/NXP processors you need to accept the GPU and VPU binary +license agreements. You have to uncomment the corresponding line + +.. code-block:: kconfig + + # Uncomment to accept NXP EULA # EULA can be found under + ../sources/meta-freescale/EULA ACCEPT_FSL_EULA = "1" + +Now you are ready to build your first image. We suggest starting with our +smaller non-graphical image *phytec-headless-image* to see if everything is +working correctly + +.. code-block:: console + + host:~$ bitbake phytec-headless-image + +The first compile process takes about 40 minutes on a modern Intel Core i7. All +subsequent builds will use the filled caches and should take about 3 minutes. + +Images +------ + +If everything worked, the images can be found under + +.. code-block:: console + + host:~$ cd deploy/images/ + +The easiest way to test your image is to configure your board for SD card boot +and to flash the build image to the SD card + +.. code-block:: console + + host:~$ sudo dd if=phytec-headless-image-.wic of=/dev/ bs=1M conv=fsync + +Here could be "sde", for example, depending on your system. Be +very careful when selecting the right drive! Selecting the wrong drive can +erase your hard drive! The parameter conv=fsync forces a data buffer to write +to the device before dd returns. + +After booting you can log in using a serial cable or over *ssh*. There is no +root password. That is because of the debug settings in *conf/local.conf*. If +you uncomment the line + +.. code-block:: kconfig + + #EXTRA_IMAGE_FEATURES = "debug-tweaks" + +the debug settings, like setting an empty root password, will not be applied. + +Accessing the Development States between Releases +------------------------------------------------- + +Special release manifests exist to give you access to the current development +states of the *Yocto* BSP. They will be displayed in the phyLinux selection +menu with the ending *PDXX.X.y* + +.. code-block:: console + + host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.y + +This will initialize a BSP that will track the latest development state. + +Inspect your Build Configuration +-------------------------------- + +*Poky* includes several tools to inspect your build layout. You can inspect the +commands of the layer tool + +.. code-block:: console + + host:~$ bitbake-layers + +It can, for example, be used to view in which layer a specific recipe gets +modified + +.. code-block:: console + + host:~$ bitbake-layers show-appends + +Before running a build you can also launch *Toaster* to be able to inspect the +build details with the Toaster web GUI + +.. code-block:: console + + host:~$ source toaster start + +Maybe you need to install some requirements, first + +.. code-block:: console + + host:~$ pip3 install -r + ../sources/poky/bitbake/toaster-requirements.txt + +You can then point your browser to *http://0.0.0.0:8000/* and continue working +with *Bitbake*. All build activity can be monitored and analyzed from this web +server. If you want to learn more about *Toaster*, look at +https://docs.yoctoproject.org/dev/toaster-manual/index.html. +To shut down the *Toaster* web GUI again, execute + +.. code-block:: console + + host:~$ source toaster stop + +BSP Features of meta-phytec and meta-ampliphy +--------------------------------------------- + +*Buildinfo* +........... + +The *buildinfo* task is a feature in our recipes that prints instructions to +fetch the source code from the public repositories. So you do not have to look +into the recipes yourself. To see the instructions, e.g. for the *barebox* +package, execute + +.. code-block:: console + + host:~$ bitbake barebox -c buildinfo + +in your shell. This will print something like + +.. code-block:: + + (mini) HOWTO: Use a local git repository to build barebox: + + To get source code for this package and version (barebox-2022.02.0-phy1), execute + + $ mkdir -p ~/git + $ cd ~/git + $ git clone git://git.phytec.de/barebox barebox + $ cd ~/git/barebox + $ git checkout -b v2022.02.0-phy1-local-development 7fe12e65d770f7e657e683849681f339a996418b + + You now have two possible workflows for your changes: + + 1. Work inside the git repository: + Copy and paste the following snippet to your "local.conf": + + SRC_URI:pn-barebox = "git://${HOME}/git/barebox;branch=${BRANCH}" + SRCREV:pn-barebox = "${AUTOREV}" + BRANCH:pn-barebox = "v2022.02.0-phy1-local-development" + + After that you can recompile and deploy the package with + + $ bitbake barebox -c compile + $ bitbake barebox -c deploy + + Note: You have to commit all your changes. Otherwise yocto doesn't pick them up! + + 2. Work and compile from the local working directory + To work and compile in an external source directory we provide the + externalsrc.bbclass. To use it, copy and paste the following snippet to your + "local.conf": + + INHERIT += "externalsrc" + EXTERNALSRC:pn-barebox = "${HOME}/git/barebox" + EXTERNALSRC_BUILD:pn-barebox = "${HOME}/git/barebox" + + Note: All the compiling is done in the EXTERNALSRC directory. Every time + you build an Image, the package will be recompiled and build. + + NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded. + NOTE: Writing buildhistory + +As you can see, everything is explained in the output. + +.. warning:: + + Using *externalsrc* breaks a lot of *Yocto's* internal dependency + mechanisms. It is not guaranteed that any changes to the source + directory are automatically picked up by the build process and + incorporated into the root filesystem or SD card image. You have to + always use *--force*. E.g. to compile *barebox* and redeploy it to + *deploy/images/* execute + + .. code-block:: console + + host:~$ bitbake barebox -c compile --force + host:~$ bitbake barebox -c deploy + +To update the SD card image with a new kernel or image first force the +compilation of it and then force a rebuild of the root filesystem. Use + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image -c rootfs --force + +Note that the build system is not modifying the external source directory. If +you want to apply all patches the *Yocto* recipe is carrying to the external +source directory, run the line + +.. code-block:: kconfig + + SRCTREECOVEREDTASKS="" BB_ENV_PASSTHROUGH_ADDITIONS="$BB_ENV_PASSTHROUGH_ADDITIONS SRCTREECOVEREDTASKS" bitbake -c patch + +.. _scarthgap_bsp-customization: + +BSP Customization +----------------- + +To get you started with the BSP, we have summarized some basic tasks from the +*Yocto* official documentation. It describes how to add additional software to +the image, change the kernel and bootloader configuration, and integrate +patches for the kernel and bootloader. + +Minor modifications, such as adding software, are done in the file +*build/conf/local.conf*. There you can overwrite global configuration variables +and make small modifications to recipes. + +There are 2 ways to make major changes: + +1. Either create your own layer and use *bbappend* files. +2. Add everything to PHYTEC's Distro layer *meta-ampliphy*. + +Creating your own layer is described in the section Create your own Layer. + +Disable Qt Demo +............... + +By default, the BSP image *phytec-qt6demo-image* starts a Qt6 Demo application +on the attached display or monitor. If you want to stop the demo and use the +*Linux* framebuffer console behind it, connect to the target via serial cable +or *ssh* and execute the shell command + +.. code-block:: console + + target:~$ systemctl stop phytec-qtdemo.service + +This command stops the demo temporarily. To start it again, reboot the +board or execute + +.. code-block:: console + + target:~$ systemctl start phytec-qtdemo.service + +You can disable the service permanently, so it does not start on boot + +.. code-block:: console + + target:~$ systemctl disable phytec-qtdemo.service + +.. tip:: + + The last command only disables the service. It does not *stop* immediately. + To see the current status execute + + .. code-block:: console + + target:~$ systemctl status phytec-qtdemo.service + +If you want to disable the service by default, edit the file +*build/conf/local.conf* and add the following line + +.. code-block:: kconfig + + # file build/conf/local.conf + SYSTEMD_AUTO_ENABLE:pn-phytec-qtdemo = "disable" + +After that, rebuild the image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +Framebuffer Console +................... + +On boards with a display interface, the framebuffer console is enabled per +default. You can attach a USB keyboard and log in. To change the keyboard +layout from the English default to German, type + +.. code-block:: console + + target:~$ loadkeys /usr/share/keymaps/i386/qwertz/de-latin1.map.gz + +To detach the framebuffer console, run + +.. code-block:: console + + target:~$ echo 0 > sys/class/vtconsole/vtcon1/bind + +To completely deactivate the framebuffer console, disable the following kernel +configuration option + +.. code-block:: + + Device Drivers->Graphics Support->Support for framebuffer devices->Framebuffer Console Support + +More information can be found at: +https://www.kernel.org/doc/Documentation/fb/fbcon.txt + +Tools Provided in the Prebuild Image +.................................... + +RAM Benchmark +~~~~~~~~~~~~~ + +Performing RAM and cache performance tests can best be done by using *pmbw* +(Parallel Memory Bandwidth Benchmark/Measurement Tool). *Pmbw* runs several +assembly routines which all use different access patterns to the caches and RAM +of the SoC. Before running the test, make sure that you have about 2 MiB of +space left on the device for the log files. We also lower the level of the +benchmark to ask the kernel more aggressively for resources. The benchmark test +will take several hours. + +To start the test type + +.. code-block:: console + + target:~$ nice -n -2 pmbw + +Upon completion of the test run, the log file can be converted to a *gnuplot* +script with + +.. code-block:: console + + target:~$ stats2gnuplot stats.txt > run1.gnuplot + +Now you can transfer the file to the host machine and install any version of +*gnuplot* + +.. code-block:: console + + host:~$ sudo apt-get install gnuplot host:~$ gnuplot run1.gnuplot + +The generated *plots-.pdf* file contains all plots. To render single +plots as *png* files for any web output you can use *Ghostscript* + +.. code-block:: console + + host:~$ sudo apt-get install ghostscript + host:~$ gs -dNOPAUSE -dBATCH -sDEVICE=png16m -r150 -sOutputFile='page-%00d.png' plots-phyboard-wega-am335x-1.pdf + +Add Additional Software for the BSP Image +......................................... + +To add additional software to the image, look at the OpenEmbedded layer index: +https://layers.openembedded.org/layerindex/branch/scarthgap/layers/ + +First, select the *Yocto* version of the BSP you have from the drop-down list in +the top left corner and click **Recipes**. Now you can search for a software +project name and find which layer it is in. In some cases, the program is in +*meta-openembedded*, *openembedded-core*, or *Poky* which means that the recipe +is already in your build tree. This section describes how to add additional +software when this is the case. If the package is in another layer, see the next +section. + +You can also search the list of available recipes + +.. code-block:: console + + host:~$ bitbake -s | grep # fill in program name, like in + host:~$ bitbake -s | grep lsof + +When the recipe for the program is already in the *Yocto* build, you can simply +add it by appending a configuration option to your file *build/conf/local.conf*. +The general syntax to add additional software to an image is + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " " + +For example, the line + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " ldd strace file lsof" + +installs some helper programs on the target image. + +.. warning:: + + The leading whitespace is essential for the append command. + +All configuration options in local.conf apply to all images. Consequently, the +tools are now included in both images phytec-headless-image and +phytec-qt6demo-image. + +Notes about Packages and Recipes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You are adding packages to the IMAGE_INSTALL variable. Those are not necessarily +equivalent to the recipes in your meta-layers. A recipe defines per default a +package with the same name. But a recipe can set the PACKAGES variable to +something different and is able to generate packages with arbitrary names. +Whenever you look for software, you have to search for the package name and, +strictly speaking, not for the recipe. In the worst case, you have to look at +all PACKAGES variables. A tool such as *Toaster* can be helpful in some cases. + +If you can not find your software in the layers provided in the folder +*sources*, see the next section to include another layer into the *Yocto* +build. + +References: `Yocto dev Documentation - Customizing Yocto builds +`_ + +Add an Additional Layer +....................... + +This is a step-by-step guide on how to add another layer to your *Yocto* build +and install additional software from it. As an example, we include the network +security scanner *nmap* in the layer *meta-security*. First, you must locate the +layer on which the software is hosted. Check out the `OpenEmbedded MetaData +Index `_ +and guess a little bit. The network scanner *nmap* is in the *meta-security* +layer. See `meta-security on layers.openembedded.org +`_. +To integrate it into the *Yocto* build, you have to check out the repository and +then switch to the correct stable branch. Since the BSP is based on the *Yocto* +|yocto-codename| build, you should try to use the |yocto-codename| branch in the layer, too. + +.. code-block:: console + + host:~$ cd sources + host:~$ git clone git://git.yoctoproject.org/meta-security + host:~$ cd meta-security + host:~$ git branch -r + +All available remote branches will show up. Usually there should be 'sumo', +'warrior', 'zeus', 'dunfell', 'hardnkott', 'kirkstone', 'mickledore', 'master'... + +.. code-block:: console + + host:~$ git checkout scarthgap + +Now we add the directory of the layer to the file *build/conf/bblayers.conf* by +appending the line + +.. code-block:: kconfig + + # file build/conf/bblayers.conf + BBLAYERS += "${BSPDIR}/sources/meta-security" + +to the end of the file. After that, you can check if the layer is available in +the build configuration by executing + +.. code-block:: console + + host:~$ bitbake-layers show-layers + +If there is an error like + +.. code-block:: + + ERROR: Layer 'security' depends on layer 'perl-layer', but this layer is not enabled in your configuration + +the layer that you want to add (here *meta-security*), depends on another layer, +which you need to enable first. E.g. the dependency required here is a layer in +*meta-openembedded* (in the PHYTEC BSP it is in the path +*sources/meta-openembedded/meta-perl/*). To enable it, add the following line to +*build/conf/bblayers.conf* + +.. code-block:: kconfig + + # file build/conf/bblayers.conf + BBLAYERS += "${BSPDIR}/sources/meta-openembedded/meta-perl" + +Now the command *bitbake-layers show-layers* should print a list of all layers +enabled including *meta-security* and *meta-perl*. After the layer is included, +you can install additional software from it as already described above. The +easiest way is to add the following line (here is the package *nmap*) + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " nmap" + +to your *build/conf/local.conf*. Do not forget to rebuild the image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +Create your own layer +.................................. + +Creating your layer should be one of the first tasks when customizing the BSP. +You have two basic options. You can either copy and rename our *meta-ampliphy*, +or you can create a new layer that will contain your changes. The better option +depends on your use case. *meta-ampliphy* is our example of how to create a +custom *Linux* distribution that will be updated in the future. If you want to +benefit from those changes and are, in general, satisfied with the userspace +configuration, it could be the best solution to create your own layer on top of +*Ampliphy*. If you need to rework a lot of information and only need the basic +hardware support from PHYTEC, it would be better to copy *meta-ampliphy*, rename +it, and adapt it to your needs. You can also have a look at the OpenEmbedded +layer index to find different distribution layers. If you just need to add your +own application to the image, create your own layer. + +In the following chapter, we have an embedded project called "racer" which we +will implement using our *Ampliphy Linux* distribution. First, we need to create +a new layer. + +*Yocto* provides a script for that. If you set up the BSP and the shell is +ready, type + +.. code-block:: console + + host:~$ bitbake-layers create-layer meta-racer + +Default options are fine for now. Move the layer to the source directory + +.. code-block:: console + + host:~$ mv meta-racer ../sources/ + +Create a *Git* repository in this layer to track your changes + +.. code-block:: console + + host:~$ cd ../sources/meta-racer + host:~$ git init && git add . && git commit -s + +Now you can add the layer directly to your build/conf/bblayers.conf + +.. code-block:: kconfig + + BBLAYERS += "${BSPDIR}/sources/meta-racer" + +or with a script provided by *Yocto* + +.. code-block:: console + + host:~$ bitbake-layers add-layer meta-racer + +Kernel and Bootloader Recipe and Version +........................................ + +First, you need to know which kernel and version are used for your target +machine. PHYTEC provides multiple kernel recipes *linux-mainline*, *linux-ti* +and *linux-imx*. The first one provides support for PHYTEC's i.MX 6 and AM335x +modules and is based on the *Linux* kernel stable releases from `kernel.org +`_. +The *Git* repositories URLs are: + +- *linux-mainline*: git://git.phytec.de/linux-mainline +- *linux-ti*: git://git.phytec.de/linux-ti +- *linux-imx:* git://git.phytec.de/linux-imx +- *barebox*: git://git.phytec.de/barebox +- *u-boot-imx*: git://git.phytec.de/u-boot-imx + +To find your kernel provider, execute the following command + +.. code-block:: console + + host:~$ bitbake virtual/kernel -e | grep "PREFERRED_PROVIDER_virtual/kernel" + +The command prints the value of the variable +*PREFERRED_PROVIDER_virtual/kernel*. The variable is used in the internal +*Yocto* build process to select the kernel recipe to use. The following lines +are different outputs you might see + +.. code-block:: kconfig + + PREFERRED_PROVIDER_virtual/kernel="linux-mainline" + PREFERRED_PROVIDER_virtual/kernel="linux-ti" + PREFERRED_PROVIDER_virtual/kernel="linux-imx" + +To see which version is used, execute *bitbake -s*. For example + +.. code-block:: console + + host:~$ bitbake -s | egrep -e "linux-mainline|linux-ti|linux-imx|barebox|u-boot-imx" + +The parameter *-s* prints the version of all recipes. The output contains the +recipe name on the left and the version on the right + +.. code-block:: + + barebox :2022.02.0-phy1-r7.0 + barebox-hosttools-native :2022.02.0-phy1-r7.0 + barebox-targettools :2022.02.0-phy1-r7.0 + linux-mainline :5.15.102-phy1-r0.0 + +As you can see, the recipe *linux-mainline* has version *5.15.102-phy1*. In +the PHYTEC's *linux-mainline* *Git* repository, you will find a corresponding +tag *v5.15.102-phy1*. The version of the *barebox* recipe is 2022.02.0-phy1. +On i.MX8M\* modules the output will contain *linux-imx* and *u-boot-imx*. + +.. _yocto-man-scarthgap-kernel-and-bootloader-conf: + +Kernel and Bootloader Configuration +................................... + +The bootloader used by PHYTEC, *barebox*, uses the same build system as the +*Linux* kernel. Therefore, all commands in this section can be used to configure +the kernel and bootloader. To configure the kernel or bootloader, execute one of +the following commands + +.. code-block:: console + + host:~$ bitbake -c menuconfig virtual/kernel # Using the virtual provider name + host:~$ bitbake -c menuconfig linux-ti # Or use the recipe name directly + host:~$ bitbake -c menuconfig linux-mainline # Or use the recipe name directly (If you use an i.MX 6 or RK3288 Module) + host:~$ bitbake -c menuconfig linux-imx # Or use the recipe name directly (If you use an i.MX 8M*) + host:~$ bitbake -c menuconfig barebox # Or change the configuration of the bootloader + host:~$ bitbake -c menuconfig u-boot-imx # Or change the configuration of the bootloader (If you use an i.MX 8M*) + +After that, you can recompile and redeploy the kernel or bootloader + +.. code-block:: console + + host:~$ bitbake virtual/kernel -c compile # Or 'barebox' for the bootloader + host:~$ bitbake virtual/kernel -c deploy # Or 'barebox' for the bootloader + +Instead, you can also just rebuild the complete build output with + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # To update the kernel/bootloader, modules and the images + +In the last command, you can replace the image name with the name of an image of +your choice. The new images and binaries are in +*build/deploy/images//*. + +.. warning:: + + The build configuration is not permanent yet. Executing *bitbake + virtual/kernel -c clean* will remove everything. + +To make your changes permanent in the build system, you have to integrate your +configuration modifications into a layer. For the configuration you have two +options: + +- Include only a configuration fragment (a minimal *diff* between the + old and new configuration) +- Complete default configuration (*defconfig*) after your + modifications. + +Having a set of configuration fragments makes what was changed at which stage +more transparent. You can turn on and off the changes, you can manage +configurations for different situations and it helps when porting changes to new +kernel versions. You can also group changes together to reflect specific use +cases. A fully assembled kernel configuration will be deployed in the directory +*build/deploy/images/*. If you do not have any of those requirements, +it might be simpler to just manage a separate *defconfig* file. + +Add a Configuration Fragment to a Recipe +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The following steps can be used for both kernel and bootloader. Just replace the +recipe name *linux-mainline* in the commands with *linux-ti*, or *barebox* for +the bootloader. If you did not already take care of this, start with a clean +build. Otherwise, the diff of the configuration may be wrong + +.. code-block:: console + + host:~$ bitbake linux-mainline -c clean + host:~$ bitbake linux-mainline -c menuconfig + +Make your configuration changes in the menu and generate a config +fragment + +.. code-block:: console + + host:~$ bitbake linux-mainline -c diffconfig + +which prints the path of the written file + +.. code-block:: + + Config fragment has been dumped into: + /home//build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg + +All config changes are in the file *fragment.cfg* which should consist of only +some lines. The following example shows how to create a *bbappend* file and how +to add the necessary lines for the config fragment. You just have to adjust the +directories and names for the specific recipe: *linux-mainline*, *linux-ti*, +linux-imx, u-boot-imx, or *barebox*. + +.. code-block:: + + sources//recipes-kernel/linux/linux-mainline_%.bbappend # For the recipe linux-mainline + sources//recipes-kernel/linux/linux-ti_%.bbappend # For the recipe linux-ti + sources//recipes-kernel/linux/linux-imx_%.bbappend # For the recipe linux-imx + sources//recipes-bsp/barebox/barebox_%.bbappend # For the recipe barebox + sources//recipes-bsp/u-boot/u-boot-imx_%.bbappend # For the recipe u-boot-imx + +Replace the string *layer* with your own layer created as shown above (e.g. +*meta-racer*), or just use *meta-ampliphy*. To use *meta-ampliphy*, first, +create the directory for the config fragment and give it a new name (here +*enable-r8169.cfg*) and move the fragment to the layer. + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features + # copy the path from the output of *diffconfig* + host:~$ cp /home//build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg \ + sources/meta-ampliphy/recipes-kernel/linux/features/enable-r8169.cfg + +Then open the *bbappend* file (in this case +*sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend* ) with +your favorite editor and add the following lines + +.. code-block:: kconfig + + # contents of the file linux-mainline_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://enable-r8169.cfg \ + " + +.. warning:: + + Do not forget to use the correct *bbappend* filenames: *linux-ti_%.bbappend* + for the linux-ti recipe and *barebox_%.bbappend* for the bootloader in the + folder *recipes-bsp/barebox/* ! + +After saving the *bbappend* file, you have to rebuild the image. *Yocto* should +pick up the recipe changes automatically and generate a new image + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +Add a Complete Default Configuration (*defconfig*) to a Recipe +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This approach is similar to the one above, but instead of adding a fragment, a +*defconfig* is used. First, create the necessary folders in the layer you want +to use, either your own layer or *meta-ampliphy* + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features/ # For both linux-mainline and linux-ti + host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features/ # Or for the bootloader + +Then you have to create a suitable *defconfig* file. Make your configuration +changes using *menuconfig* and then save the *defconfig* file to the layer + +.. code-block:: console + + host:~$ bitbake linux-mainline -c menuconfig # Or use recipe name linux-ti or barebox + host:~$ bitbake linux-mainline -c savedefconfig # Create file 'defconfig.temp' in the work directory + +This will print the path to the generated file + +.. code-block:: + + Saving defconfig to ..../defconfig.temp + +Then, as above, copy the generated file to your layer, rename it to *defconfig*, +and add the following lines to the *bbappend* file (here +*sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend*) + +.. code-block:: kconfig + + # contents of the file linux-mainline_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://defconfig \ + " + +.. tip:: + + Do not forget to use the correct bbappend filenames: *linux-ti_%.bbappend* + for the linux-ti recipe and *barebox_%.bbappend* for the bootloader in the + folder *recipes-bsp/barebox/* ! + +After that, rebuild your image as the changes are picked up automatically + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +Patch the Kernel or Bootloader with *devtool* +............................................. + +*Apart from using the standard versions of kernel and bootloader which are +provided in the recipes, you can modify the source code or use our own +repositories to build your customized kernel.* + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| Standard workflow of the | Uses additional hard drive space | +| official *Yocto* documentation | as the sources get duplicated | ++----------------------------------+----------------------------------+ +| Toolchain does not have to | No optimal cache usage, build | +| recompile everything | overhead | ++----------------------------------+----------------------------------+ + +*Devtool* is a set of helper scripts to enhance the user workflow of *Yocto*. It +was integrated with version 1.8. It is available as soon as you set up your +shell environment. *Devtool* can be used to: + +- modify existing sources +- integrate software projects into your build setup +- build software and deploy software modifications to your target + +Here we will use *devtool* to patch the kernel. We use *linux-mainline* as an +example for the AM335x Kernel. The first command we use is *devtool modify - x + * + +.. code-block:: console + + host:~$ devtool modify -x linux-mainline linux-mainline + +*Devtool* will create a layer in *build/workspace* where you can see all +modifications done by *devtool* . It will extract the sources corresponding to +the recipe to the specified directory. A *bbappend* will be created in the +workspace directing the SRC_URI to this directory. Building an image with +*Bitbake* will now use the sources in this directory. Now you can modify lines +in the kernel + +.. code-block:: console + + host:~$ vim linux-mainline/arch/arm/boot/dts/am335x-phycore-som.dtsi + -> make a change + host:~$ bitbake phytec-qt6demo-image + +Your changes will now be recompiled and added to the image. If you want to store +your changes permanently, it is advisable to create a patch from the changes, +then store and backup only the patch. You can go into the *linux-mainline* +directory and create a patch using *Git*. How to create a patch is described in +:ref:`scarthgap_temporary-method` and is the same for all methods. + +If you want to learn more about *devtool*, visit: + +`Yocto dev - Devtool +`_ +or `Devtool Quick Reference +`_ + +.. _scarthgap_temporary-method: + +Patch the Kernel or Bootloader using the "Temporary Method" +........................................................... + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| No overhead, no extra | Changes are easily overwritten | +| configuration | by *Yocto* (Everything is | +| | lost!!). | ++----------------------------------+----------------------------------+ +| Toolchain does not have to | | +| recompile everything | | ++----------------------------------+----------------------------------+ + +It is possible to alter the source code before *Bitbake* configures and compiles +the recipe. Use *Bitbake'* s *devshell* command to jump into the source +directory of the recipe. Here is the *barebox* recipe + +.. code-block:: console + + host:~$ bitbake barebox -c devshell # or linux-mainline, linux-ti, linux-imx, u-boot-imx + +After executing the command, a shell window opens. The current working directory +of the shell will be changed to the source directory of the recipe inside the +*tmp* folder. Here you can use your favorite editor, e.g. *vim*, *emacs*, or any +other graphical editor, to alter the source code. When you are finished, exit +the *devshell* by typing *exit* or hitting **CTRL-D**. + +After leaving the *devshell* you can recompile the package + +.. code-block:: console + + host:~$ bitbake barebox -c compile --force # or linux-mainline, linux-ti, linux-imx, u-boot-imx + +The extra argument '--force' is important because *Yocto* does not recognize +that the source code was changed. + +.. tip:: + + You cannot execute the *bitbake* command in the *devshell* . You have + to leave it first. + +If the build fails, execute the devshell command again and fix it. If the build +is successful, you can deploy the package and create a new SD card image + +.. code-block:: console + + host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox.bin + host:~$ bitbake phytec-headless-image # new WIC image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic + +.. warning:: + + If you execute a clean e.g *bitbake barebox -c clean* , or if *Yocto* fetches + the source code again, all your changes are lost!!! + + To avoid this, you can create a patch and add it to a *bbappend* file. It is + the same workflow as described in the section about changing the + configuration. + + You have to create the patch in the *devshell* if you use the temporary + method and in the subdirectory created by *devtool* if you used *devtool*. + +.. code-block:: console + + host:~$ bitbake barebox -c devshell # Or linux-mainline, linux-ti + host(devshell):~$ git status # Show changes files + host(devshell):~$ git add # Add a special file to the staging area + host(devshell):~$ git commit -m "important modification" # Creates a commit with a not so useful commit message + host(devshell):~$ git format-patch -1 -o ~/ # Creates a patch of the last commit and saves it in your home folder + /home//0001-important-modification.patch # Git prints the path of the written patch file + host(devshell):~$ exit + +After you have created the patch, you must create a *bbappend* file for it. The +locations for the three different recipes - *linux-mainline* , *linux-ti* , and +*barebox* - are + +.. code-block:: + + sources//recipes-kernel/linux/linux-mainline_%.bbappend # For the recipe linux-mainline + sources//recipes-kernel/linux/linux-ti_%.bbappend # For the recipe linux-ti + sources//recipes-kernel/linux/linux-imx_%.bbappend # For the recipe linux-imx + sources//recipes-bsp/barebox/barebox_%.bbappend # For the recipe barebox + sources//recipes-bsp/u-boot/u-boot-imx_%.bbappend # For the recipe u-boot-imx + +The following example is for the recipe *barebox*. You have to adjust the paths. +First, create the folders and move the patch into them. Then create the +*bbappend* file + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features # Or use your own layer instead of *meta-ampliphy* + host:~$ cp ~/0001-important-modification.patch sources/meta-ampliphy/recipes-bsp/barebox/features # copy patch + host:~$ touch sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend + +.. tip:: + + Pay attention to your current work directory. You have to execute the + commands in the BSP top-level directory. Not in the *build* directory! + +After that use your favorite editor to add the following snipped into the +*bbappend* file (here +*sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend*) + +.. code-block:: kconfig + + # contents of the file barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://0001-important-modification.patch \ + " + +Save the file and rebuild the *barebox* recipe with + +.. code-block:: console + + host:~$ bitbake barebox -c clean # Or linux-ti, linux-mainline, linux-imx, u-boot-imx + host:~$ bitbake barebox + +If the build is successful, you can rebuild the final image with + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +**Further Resources:** + +The *Yocto* Project has some documentation for software developers. Check the +'Kernel Development Manual' for more information about how to configure the +kernel. Please note that not all of the information from the *Yocto* manual can +be applied to the PHYTEC BSP as we use the classic kernel approach of *Yocto* +and most of the documentation assumes the *Yocto* kernel approach. + +- `Yocto - Kernel Development Manual + `_ +- `Yocto - Development Manual + `_ + +Working with the Kernel and Bootloader using SRC_URI in *local.conf* +.................................................................... + +*Here we present a third option to make kernel and bootloader changes. You have +external checkouts of the linux-mainline, linux-ti, or barebox Git +repositories. You will overwrite the URL of the source code fetcher, the +variable SRC_URI, to point to your local checkout instead of the remote +repositories.* + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| All changes are saved with | Many working directories in | +| *Git* | *build/tmp-\ | +| | glibc/work///* | ++----------------------------------+----------------------------------+ +| | You have to commit every change | +| | before recompiling | ++----------------------------------+----------------------------------+ +| | For each change, the toolchain | +| | compiles everything from scratch | +| | (avoidable with *ccache*) | ++----------------------------------+----------------------------------+ + +First, you need a local clone of the *Git* repository *barebox* or +kernel. If you do not have one, use the commands + +.. code-block:: console + + host:~$ mkdir ~/git + host:~$ cd ~/git + host:~$ git clone git://git.phytec.de/barebox + host:~$ cd barebox + host:~$ git checkout -b v2022.02.0-phy remotes/origin/v2022.02.0-phy + +Add the following snippet to the file build/conf/local.conf + +.. code-block:: kconfig + + # Use your own path to the git repository + # NOTE: Branch name in variable "BRANCH_pn-barebox" should be the same as the + # branch which is used in the repository folder. Otherwise your commits won't be recognized later. + BRANCH:pn-barebox = "v2022.02.0-phy" + SRC_URI:pn-barebox = "git:///${HOME}/git/barebox;branch=${BRANCH}" + SRCREV:pn-barebox = "${AUTOREV}" + +You also have to set the correct BRANCH name in the file. Either you create your +own branch in the *Git* repository, or you use the default (here +"v2015.02.0-phy"). Now you should recompile *barebox* from your own source + +.. code-block:: console + + host:~$ bitbake barebox -c clean + host:~$ bitbake barebox -c compile + +The build should be successful because the source was not changed yet. + +You can alter the source in *~/git/barebox* or the default *defconfig* (e.g. +*~/git/barebox/arch/arm/configs/imx_v7_defconfig*). After you are satisfied with +your changes, you have to make a dummy commit for *Yocto*. If you do not, +*Yocto* will not notice that the source code was modified in your repository +folder (e.g. ~/git/barebox/) + +.. code-block:: console + + host:~$ git status # show modified files + host:~$ git diff # show changed lines + host:~$ git commit -a -m "dummy commit for yocto" # This command is important! + +Try to compile your new changes. *Yocto* will automatically notice that the +source code was changed and fetches and configures everything from scratch. + +.. code-block:: console + + host:~$ bitbake barebox -c compile + +If the build fails, go back to the source directory, fix the problem, and +recommit your changes. If the build was successful, you can deploy *barebox* and +even create a new SD card image. + +.. code-block:: console + + host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox-phyflex-imx6-2.bin + host:~$ bitbake phytec-headless-image # new sd-card image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic + +If you want to make additional changes, just make another commit in the +repository and rebuild *barebox* again. + +Add Existing Software with "Sustainable Method" +............................................... + +Now that you have created your own layer, you have a second option to add +existing software to existing image definitions. Our standard image is defined +in meta-ampliphy + +.. code-block:: + + meta-ampliphy/recipes-images/images/phytec-headless-image.bb + +In your layer, you can now modify the recipe with a *bbappend* without modifying +any BSP code + +.. code-block:: + + meta-racer/recipes-images/images/phytec-headless-image.bbappend + +The append will be parsed together with the base recipe. As a result, you can +easily overwrite all variables set in the base recipe, which is not always what +you want. If we want to include additional software, we need to append it to the +IMAGE_INSTALL variable + +.. code-block:: kconfig + + IMAGE_INSTALL:append = " rsync" + +Add Linux Firmware Files to the Root Filesystem +............................................... + +It is a common task to add an extra firmware file to your root filesystem into +*/lib/firmware/*. For example, WiFi adapters or PCIe Ethernet cards might need +proprietary firmware. As a solution, we use a *bbappend* in our layer. To create +the necessary folders, *bbappend* and copy the firmware file type + +.. code-block:: console + + host:~$ cd meta-racer # go into your layer + host:~$ mkdir -p recipes-kernel/linux-firmware/linux-firmware/ + host:~$ touch recipes-kernel/linux-firmware/linux-firmware_%.bbappend + host:~$ cp ~/example-firmware.bin recipes-kernel/linux-firmware/linux-firmware/ # adapt filename + +Then add the following content to the *bbappend* file and replace every +occurrence of *example-firmware.bin* with your firmware file name. + +.. code-block:: kconfig + + # file recipes-kernel/linux-firmware/linux-firmware_%.bbappend + + FILESEXTRAPATHS:prepend := "${THISDIR}/linux-firmware:" + SRC_URI += "file://example-firmware.bin" + + do_install:append () { + install -m 0644 ${WORKDIR}/example-firmware.bin ${D}/lib/firmware/example-firmware.bin + } + + # NOTE: Use "=+" instead of "+=". Otherwise file is placed into the linux-firmware package. + PACKAGES =+ "${PN}-example" + FILES:${PN}-example = "/lib/firmware/example-firmware.bin" + +Now try to build the linux-firmware recipe + +.. code-block:: console + + host:~$ . sources/poky/oe-init-build-env + host:~$ bitbake linux-firmware + +This should generate a new package *deploy/ipk/all/linux-firmware-example*. + +As the final step, you have to install the firmware package to your image. You +can do that in your *local.conf* or image recipe via + +.. code-block:: kconfig + + # file local.conf or image recipe + IMAGE_INSTALL += "linux-firmware-example" + +.. warning:: + + Ensure that you have adapted the package name *linux-firmware-example* with + the name you assigned in *linux-firmware_%.bbappend*. + +Change the *u-boot* Environment via *bbappend* Files +.................................................... + +All i.MX8M\* products use the u-boot bootloader. The u-boot environment can be +modified using the Temporary Method. In the *u-boot-imx* sources modify the +header file corresponding to the processor located in +*include/configs/phycore_imx8m\**. New environment variables should be added at +the end of *CONFIG_EXTRA_ENV_SETTINGS* + +.. code-block:: kconfig + + #define CONFIG_EXTRA_ENV_SETTINGS \ + [...] + PHYCORE_FITIMAGE_ENV_BOOTLOGIC \ + "newvariable=1\0" + +Commit the changes and and create the file *u-boot-imx_%.bbappend* in your layer +at */recipes-bsp/u-boot/u-boot-imx_%.bbappend* + +.. code-block:: kconfig + + # contents of the file u-boot-imx_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://0001-environment-addition.patch \ + " + +Change the *barebox* Environment via *bbappend* Files +..................................................... + +Since *BSP-Yocto-AM335x-16.2.0* and *BSP-Yocto-i.MX6-PD16.1.0*, the *barebox* +environment handling in *meta-phytec* has changed. Now it is possible to add, +change, and remove files in the *barebox* environment via the *Python* bitbake +task *do_env*. There are two *Python* functions to change the environment. Their +signatures are: + +- *env_add(d, *\ **filename as string**\ *, *\ **file content as string**\ *)*: + to add a new file or overwrite an existing file +- *env_rm(d, *\ **filename as string**\ *)*: to remove a file + +The first example of a *bbappend* file in the custom layer *meta-racer* shows +how to add a new non-volatile variable *linux.bootargs.fb* in the *barebox* +environment folder */env/nv/* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_add(d, "nv/linux.bootargs.fb", "imxdrm.legacyfb_depth=32\n") + } + +The next example shows how to replace the network configuration file +*/env/network/eth0* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_add(d, "network/eth0", + """#!/bin/sh + + # ip setting (static/dhcp) + ip=static + global.dhcp.vendor_id=barebox-${global.hostname} + + # static setup used if ip=static + ipaddr=192.168.178.5 + netmask=255.255.255.0 + gateway=192.168.178.1 + serverip=192.168.178.1 + """) + } + +In the above example, the *Python* multiline string syntax **""" text """** is +used to avoid adding multiple newline characters *\\n* into the recipe *Python* +code. The *Python* function *env_add* can add and overwrite environment files. + +The next example shows how to remove an already added environment file, for +example *,* */env/boot/mmc* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_rm(d, "boot/mmc") + } + +Debugging the Environment +~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you want to see all environment files that are added in the build process, +you can enable a debug flag in the *local.conf* + +.. code-block:: kconfig + + # file local.conf + ENV_VERBOSE = "1" + +After that, you have to rebuild the *barebox* recipe to see the debugging +output + +.. code-block:: console + + host:~$ bitbake barebox -c clean + host:~$ bitbake barebox -c configure + +The output of the last command looks like this + +.. code-block:: + + [...] + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/allow_color' content "false" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.base' content "consoleblank=0" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.fb' content "imxdrm.legacyfb_depth=32" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.rootfs' content "rootwait ro fsck.repair=yes" + +Changing the Environment (depending on Machines) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you need to apply some *barebox* environment modifications only to a single +or only a few machines, you can use *Bitbake'* s machine overwrite syntax. For +the machine overwrite syntax, you append a machine name or SoC name (such as +*mx6* , *ti33x,* or *rk3288* ) with an underscore to a variable or task + +.. code-block:: kconfig + + DEPENDS:remove:mx6 = "virtual/libgl" or + python do_env_append_phyboard-mira-imx6-4(). + +The next example adds the environment variables only if the MACHINE is set to +*phyboard-mira-imx6-4* + +.. code-block:: kconfig + + # file meta-phytec/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append:phyboard-mira-imx6-4() { + env_add(d, "nv/linux.bootargs.cma", "cma=64M\n") + } + +*Bitbake's* override syntax for variables is explained in more detail at: +https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-metadata.html#conditional-metadata + +Upgrading the *barebox* Environment from Previous BSP Releases +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Prior to BSP version *BSP-Yocto-AM335x-16.2.0* and *BSP-Yocto-i.MX6-PD16.1.0* , +*barebox* environment changes via *bbappend* file were done differently. For +example, the directory structure in your meta layer (here *meta-skeleton* ) may +have looked like this + +.. code-block:: console + + host:~$ tree -a sources/meta-skeleton/recipes-bsp/barebox/ + sources/meta-skeleton/recipes-bsp/barebox + ├── barebox + │ └── phyboard-wega-am335x-3 + │ ├── boardenv + │ │ └── .gitignore + │ └── machineenv + │ └── nv + │ └── linux.bootargs.cma + └── barebox_%.bbappend + +and the file *barebox_%.bbappend* contained + +.. code-block:: kconfig + + # file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:" + +In this example, all environment changes from the directory *boardenv* in the +layer *meta-phytec* are ignored and the file *nv/linux.bootargs.cma* is added. +For the new handling of the *barebox* environment, you use the *Python* +functions *env_add* and *env_rm* in the *Python* task *do_env*. Now the above +example translates to a single *Python* function in the file +*barebox_%.bbappend* that looks like + +.. code-block:: kconfig + + # file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:" + python do_env:append() { + # Removing files (previously boardenv) + env_rm(d, "config-expansions") + # Adding new files (previously machineenv) + env_add(d, "nv/linux.bootargs.cma", "cma=64M\n") + } + +.. _scarthgap_changing-net-config: + +Changing the Network Configuration +.................................. + +To tweak IP addresses, routes, and gateways at runtime you can use the tools +*ifconfig* and *ip* . Some examples + +.. code-block:: console + + target:~$ ip addr # Show all network interfaces + target:~$ ip route # Show all routes + target:~$ ip addr add 192.168.178.11/24 dev eth0 # Add static ip and route to interface eth0 + target:~$ ip route add default via 192.168.178.1 dev eth0 # Add default gateway 192.168.178.1 + target:~$ ip addr del 192.168.178.11/24 dev eth0 # Remove static ip address from interface eth0 + +The network configuration is managed by *systemd-networkd* . To query the +current status use + +.. code-block:: console + + target:~$ networkctl status + target:~$ networkctl list + +The network daemon reads its configuration from the directories +*/etc/systemd/network/* , */run/systemd/network/* , and */lib/systemd/network/* +(from higher to lower priority). A sample configuration in +*/lib/systemd/network/10-eth0.network* looks like this + +.. code-block:: kconfig + + # file /lib/systemd/network/10-eth0.network + [Match] + Name=eth0 + + [Network] + Address=192.168.3.11/24 + Gateway=192.168.3.10 + +These files *\*.network* replace */etc/network/interfaces* from other +distributions. You can either edit the file *10-eth0.network* in-place or copy +it to */etc/systemd/network/* and make your changes there. After changing a file +you must restart the daemon to apply your changes + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +To see the syslog message of the network daemon, use + +.. code-block:: console + + target:~$ journalctl --unit=systemd-networkd.service + +To modify the network configuration at build time, look at the recipe +*sources/meta-ampliphy/recipes-core/systemd/systemd-machine-units.bb* +and the interface files in the folder +*meta-ampliphy/recipes-core/systemd/systemd-machine-units/* where the static IP +address configuration for *eth0* (and optionally *eth1*) is done. + +For more information, see https://wiki.archlinux.org/title/Systemd-networkd +and https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html. + +Changing the Wireless Network Configuration +........................................... + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- First set the correct regulatory domain for your country + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +- Set up the wireless interface + +.. code-block:: console + + target:~$ ip link # list all interfaces. Search for wlan* + target:~$ ip link set up dev wlan0 + +- Now you can scan for available networks + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for *WEP*, *WPA*, and +*WPA2* called *wpa_supplicant* for an encrypted connection. + +- To do so, add the network credentials to the file + */etc/wpa_supplicant.conf* + +.. code-block:: kconfig + + Confluence country=DE network={ ssid="" proto=WPA2 psk="" } + +- Now a connection can be established + +.. code-block:: console + + target:~$ wpa_supplicant -Dnl80211 -c/etc/wpa_supplicant.conf -iwlan0 -B + +This should result in the following output + +.. code-block:: kconfig + + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see the section :ref:`scarthgap_changing-net-config`. + +- First, create the directory + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +- Then add the following configuration snippet in + */etc/systemd/network/10-wlan0.network* + +.. code-block:: kconfig + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +- Now, restart the network daemon so that the configuration takes effect + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Creating a WLAN Access Point +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This section provides a basic access point (AP) configuration for a +secured *WPA2* network. + +Find the name of the WLAN interface with + +.. code-block:: console + + target:~$ ip link + +Edit the configuration in */etc/hostapd.conf*. It is strongly dependent on +the use case. The following shows an example + +.. code-block:: kconfig + + # file /etc/hostapd.conf + interface=wlan0 + driver=nl80211 + ieee80211d=1 + country_code=DE + hw_mode=g + ieee80211n=1 + ssid=Test-Wifi + channel=2 + wpa=2 + wpa_passphrase=12345678 + wpa_key_mgmt=WPA-PSK + wpa_pairwise=CCMP + +Set up and start the DHCP server for the network interface *wlan0* via +*systemd-networkd* + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + target:~$ vi /etc/systemd/network/10-wlan0.network + +Insert the following text into the file + +.. code-block:: kconfig + + [Match] + Name=wlan0 + + [Network] + Address=192.168.0.1/24 + DHCPServer=yes + + [DHCPServer] + EmitDNS=yes + target:~$ systemctl restart systemd-networkd + target:~$ systemctl status systemd-networkd -l # check status and see errors + +Start the userspace daemon *hostapd* + +.. code-block:: console + + target:~$ systemctl start hostapd + target:~$ systemctl status hostapd -l # check for errors + +Now, you should see the WLAN network *Test-Wifi* on your terminal device +(laptop, smartphone, etc.). + +If there are problems with the access point, you can either check the log +messages with + +.. code-block:: console + + target:~$ journalctl --unit=hostapd + +or start the daemon in debugging mode from the command line + +.. code-block:: console + + target:~$ systemctl stop hostapd + target:~$ hostapd -d /etc/hostapd.conf -P /var/run/hostapd.pid + +You should see + +.. code-block:: + + ... + wlan0: interface state UNINITIALIZED->ENABLED + wlan0: AP-ENABLED + +Further information about AP settings and the userspace daemon +*hostapd* can be found at + +.. code-block:: + + https://wireless.wiki.kernel.org/en/users/documentation/hostapd + https://w1.fi/hostapd/ + +phyCORE-i.MX 6UL/ULL Bluetooth +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Special consideration must be paid when working with any Bluetooth on a +phyCORE-i.MX 6UL/ULL. For further information, please check `L-844e.A5 i.MX +6UL/ULL BSP Manual - Bluetooth +`_. + +Add OpenCV Libraries and Examples +................................. + +*OpenCV* (Opensource Computer Vision https://opencv.org/) is an open-source +library for computer vision applications. + +To install the libraries and examples edit the file *conf/local.conf* in the +*Yocto* build system and add + +.. code-block:: kconfig + + # file conf/local.conf + # Installing OpenCV libraries and examples + LICENSE_FLAGS_ACCEPTED += "commercial_libav" + LICENSE_FLAGS_ACCEPTED += "commercial_x264" + IMAGE_INSTALL:append = " \ + opencv \ + opencv-samples \ + libopencv-calib3d2.4 \ + libopencv-contrib2.4 \ + libopencv-core2.4 \ + libopencv-flann2.4 \ + libopencv-gpu2.4 \ + libopencv-highgui2.4 \ + libopencv-imgproc2.4 \ + libopencv-legacy2.4 \ + libopencv-ml2.4 \ + libopencv-nonfree2.4 \ + libopencv-objdetect2.4 \ + libopencv-ocl2.4 \ + libopencv-photo2.4 \ + libopencv-stitching2.4 \ + libopencv-superres2.4 \ + libopencv-video2.4 \ + libopencv-videostab2.4 \ + " + +Then rebuild your image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +.. tip:: + + Most examples do not work out of the box, because they depend on the *GTK* + graphics library. The BSP only supports *Qt6* . + +Add Minimal PHP web runtime with *lightpd* +.......................................... + +This is one example of how to add a small runtime for PHP applications and a web +server on your target. Lighttpd can be used together with the PHP command line +tool over cgi. This solution weights only 5.5 MiB of disk storage. It is already +preconfigured in meta-ampliphy. Just modify the build configuration to install +it on the image + +.. code-block:: kconfig + + # file conf/local.conf + # install lighttpd with php cgi module + IMAGE_INSTALL:append = " lighttpd" + +After booting the image, you should find the example web content in */www/pages* +. For testing php, you can delete the *index.html* and replace it with a +*index.php* file + +.. code-block:: html + + + + PHP-Test + + + + + + +On your host, you can point your browser to the board's IP, (e.g. 192.168.3.11) +and the phpinfo should show up. + +Common Tasks +------------ + +Debugging a User Space Application +.................................. + +The phytec-qt6demo-image can be cross-debugged without any change. For +cross-debugging, you just have to match the host sysroot with the image in use. +So you need to create a toolchain for your image + +.. code-block:: console + + host:~$ bitbake -c populate_sdk phytec-qt6demo-image + +Additionally, if you want to have full debug and backtrace capabilities for all +programs and libraries in the image, you could add + +.. code-block:: kconfig + + DEBUG_BUILD = "1" + +to the ``conf/local.conf``. This is not necessary in all cases. The compiler +options will then be switched from FULL_OPTIMIZATION to DEBUG_OPTIMIZATION. Look +at the *Poky* source code for the default assignment of DEBUG_OPTIMIZATION. + +To start a cross debug session, install the SDK as mentioned previously, source +the SDK environment, and run *Qt Creator* in the same shell. If you do not use +*Qt Creator*, you can directly call the arm-<..>-gdb debugger instead which +should be in your path after sourcing the environment script. + +If you work with *Qt Creator*, have a look at the appropriate documentation +delivered with your product (either QuickStart or Application Guide) for +information on how to set up the toolchain. + +When starting the debugger with your userspace application you will get a +SIGILL, an illegal instruction from the *libcrypto*. *Openssl* probes for the +system capabilities by trapping illegal instructions, which will trigger *GDB*. +You can ignore this and hit **Continue** (c command). You can permanently ignore +this stop by adding + +.. code-block:: kconfig + + handle SIGILL nostop + +to your *GDB* startup script or in the *Qt Creator GDB* configuration panel. +Secondly, you might need to disable a security feature by adding + +.. code-block:: kconfig + + set auto-load safe-path / + +to the same startup script, which will enable the automatic loading of libraries +from any location. + +If you need to have native debugging, you might want to install the debug +symbols on the target. You can do this by adding the following line to your +*conf/local.conf* + +.. code-block:: kconfig + + EXTRA_IMAGE_FEATURES += "dbg-pkgs" + +For cross-debugging, this is not required as the debug symbols will be loaded +from the host side and the dbg-pkgs are included in the SDK of your image +anyway. + +.. _scarthgap_gen-source-mirrors: + +Generating Source Mirrors, working Offline +.......................................... + +Modify your *site.conf* (or *local.conf* if you do not use a *site.conf* ) as +follows + +.. code-block:: kconfig + + #DL_DIR ?= "" don't set it! It will default to a directory inside /build + SOURCE_MIRROR_URL = "file:///home/share/yocto_downloads/" + INHERIT += "own-mirrors" + BB_GENERATE_MIRROR_TARBALLS = "1" + +Now run + +.. code-block:: console + + host:~$ bitbake --runall=fetch + +for all images and for all machines you want to provide sources for. This will +create all the necessary *tar* archives. We can remove all SCM subfolders, as +they are duplicated with the tarballs + +.. code-block:: console + + host:~$ rm -rf build/download/git2/ + etc... + +Please consider that we used a local source mirror for generating the dl_dir. +Because of that, some archives will be linked locally. + +First, we need to copy all files, resolving symbolic links into the new mirror +directory + +.. code-block:: console + + host:~$ rsync -vaL ${TOPDIR}/../src_mirror/ + +Now we clean the */build* directory by deleting everything except */build/conf/* +but including */build/conf/sanity*. We change *site.conf* as follows + +.. code-block:: kconfig + + SOURCE_MIRROR_URL = "file://${TOPDIR}/../src_mirror" + INHERIT += "own-mirrors" + BB_NO_NETWORK = "1" + SCONF_VERSION = "1" + +The BSP directory can now be compressed with + +.. code-block:: console + + host:~$ tar cfJ .tar.xz + +where filename and folder should be the full BSP Name. + +Compiling on the Target +....................... + +To your *local.conf* add + +.. code-block:: kconfig + + IMAGE_FEATURES:append = " tools-sdk dev-pkgs" + +Different Toolchains +.................... + +There are several ways to create a toolchain installer in *Poky*. One option is +to run + +.. code-block:: console + + host:~$ bitbake meta-toolchain + +This will generate a toolchain installer in *build/deploy/sdk* which can be used +for cross-compiling of target applications. However, the installer does not +include libraries added to your image, so it is a bare *GCC* compiler only. This +is suited for bootloader and kernel development. + +Another you can run is + +.. code-block:: console + + host:~$ bitbake -c populate_sdk + +This will generate a toolchain installer containing all necessary development +packages of the software installed on the root filesystem of the target. This +installer can be handed over to the user space application development team and +includes all necessary parts to develop an application. If the image contains +the *QT* libraries, all of those will be available in the installer too. + +The third option is to create the ADT (Application Development Toolkit) +installer. It will contain the cross-toolchain and some tools to aid the +software developers, for example, an *Eclipse* plugin and a *QEMU* target +simulator. + +.. code-block:: console + + host:~$ bitbake adt-installer + +The ADT is untested for our BSP at the moment. + +Using the SDK +~~~~~~~~~~~~~ + +After generating the SDK with + +.. code-block:: console + + host:~$ source sources/poky/oe-init-build-env + host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image + +run the generated binary with + +.. code-block:: console + + host:~$ deploy/sdk/ampliphy-glibc-x86_64-phytec-qt6demo-image-cortexa9hf-vfp-neon-toolchain-i.MX6-PD15.3-rc.sh + Enter target directory for SDK (default: /opt/ampliphy/i.MX6-PD15.3-rc): + You are about to install the SDK to "/opt/ampliphy/i.MX6-PD15.3-rc". Proceed[Y/n]? + Extracting SDK...done + Setting it up...done + SDK has been successfully set up and is ready to be used. + +You can activate the toolchain for your shell by sourcing the file +*environment-setup* in the toolchain directory + +.. code-block:: console + + host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + +.. note:: + + To be able to build a Qt6 application with the SDK and the Meson Build system, the following has to be done, *after* the SDK has been sourced: + + .. code-block:: console + + host:~$ export PATH=$OECORE_NATIVE_SYSROOT/usr/libexec:$PATH + + +Then the necessary tools like the cross compiler and linker are in your PATH. To +compile a simple *C* program, use + +.. code-block:: console + + host:~$ $CC main.c -o main + +The environment variable $CC contains the path to the ARM cross compiler and +other compiler arguments needed like *-march* , *-sysroot* and *--mfloat-abi*. + +.. tip:: + + You cannot compile programs only with the compiler name like + + .. code-block:: console + + host:~$ arm-phytec-linux-gnueabi-gcc main.c -o main + + It will fail in many cases. Always use *CC*, CFLAGS, LDFLAGS, and so on. + +For convenience, the *environment-setup* exports other environment variables +like CXX, LD, SDKTARGETSYSROOT. + +A simple makefile compiling a *C* and *C++* program may look like this + +.. code-block:: kconfig + + # Makefile + TARGETS=c-program cpp-program + + all: $(TARGETS) + + c-program: c-program.c + $(CC) $(CFLAGS) $(LDFLAGS) $< -o $@ + + cpp-program: cpp-program.cpp + $(CXX) $(CXXFLAGS) $(LDFLAGS) $< -o $@ + + .PHONY: clean + clean: + rm -f $(TARGETS) + +To compile for the target, just source the toolchain in your shell before +executing make + +.. code-block:: console + + host:~$ make # Compiling with host CC, CXX for host architecture + host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + host:~$ make # Compiling with target CC, CXX for target architecture + +If you need to specify additionally included directories in the sysroot of the +toolchain, you can use an '=' sign in the *-I* argument like + +.. code-block:: kconfig + + -I=/usr/include/SDL + +*GCC* replaces it by the sysroot path (here +*/opt/ampliphy/i.MX6-PD15.3-rc/sysroots/cortexa9hf-vfp-neon-phytec-linux-gnueabi/*). +See the main page of *GCC* for more information. + +.. tip:: + + The variables $CFLAGS and $CXXFLAGS contain the compiler debug flag '-g' by + default. This includes debugging information in the binary and making it + bigger. Those should be removed from the production image. If you create a + *Bitbake* recipe, the default behavior is to turn on '-g' too. The debugging + symbols are used in the SDK rootfs to be able to get debugging information + when invoking *GDB* from the host. Before installing the package to the + target rootfs, *Bitbake* will invoke *strip* on the program which removes the + debugging symbols. By default, they are not found nor required on the target + root filesystem + +Using the SDK with GNU Autotools +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +*Yocto* SDK is a straightforward tool for a project that uses the *GNU +Autotools*. The traditional compile steps for the host are usually + +.. code-block:: console + + host:~$ ./autogen.sh # maybe not needed + host:~$ ./configure + host:~$ make + host:~$ make install DESTDIR=$PWD/build/ + +The commands to compile for the target machine with the *Yocto* SDK are quite +similar. The following commands assume that the SDK was unpacked to the +directory */opt/phytec-ampliphy/i.MX6-PD15.3.0/* (adapt the path as needed) + +.. code-block:: console + + host:~$ source /opt/phytec-ampliphy/i.MX6-PD15.3.0/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + host:~$ ./autogen.sh # maybe not needed + host:~$ ./configure ${CONFIGURE_FLAGS} + host:~$ make + host:~$ make install DESTDIR=$PWD/build/ + +Refer to the official *Yocto* documentation for more information: +https://docs.yoctoproject.org/dev/singleindex.html#autotools-based-projects + +Working with Kernel Modules +........................... + +You will come to the point where you either need to set some options for a +kernel module or you want to blacklist a module. Those things are handled by +*udev* and go into *\*.conf* files in + +.. code-block:: + + /etc/modprobe.d/\*.conf. + +If you want to specify an option at build time, there are three relevant +variables. If you just want to autoload a module that has no autoload +capabilities, add it to + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + +either in the kernel recipe or in the global variable scope. If you need to +specify options for a module, you can do so with + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + KERNEL_MODULE_PROBECONF += "your-module" + module_conf_your-module = "options your-module parametername=parametervalue" + +if you want to blacklist a module from autoloading, you can do it intuitively +with + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + KERNEL_MODULE_PROBECONF += "your-module" + module_conf_your-module = "blacklist your-module" + +Working with *udev* +................... + +Udev (Linux dynamic device management) is a system daemon that handles dynamic +device management in /dev. It is controlled by *udev* \ rules that are located +in */etc/udev/rules.d* (sysadmin configuration space) and\ */lib/udev/rules.d/* +(vendor-provided). Here is an example of an *udev* \ rule file + +.. code-block:: kconfig + + # file /etc/udev/rules.d/touchscreen.rules + # Create a symlink to any touchscreen input device + SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="input:*-e0*,3,*a0,1,*18,*", SYMLINK+="input/touchscreen0" + SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="ads7846", SYMLINK+="input/touchscreen0" + +See https://www.freedesktop.org/software/systemd/man/latest/udev.html for more details +about the syntax and usage. To get the list of attributes for a specific device +that can be used in an *udev* rule you can use the *udevadm info* tool. It +prints all existing attributes of the device node and its parents. The key-value +pairs from the output can be copied and pasted into a rule file. Some examples + +.. code-block:: console + + target:~$ udevadm info -a /dev/mmcblk0 + target:~$ udevadm info -a /dev/v4l-subdev25 + target:~$ udevadm info -a -p /sys/class/net/eth0 + +After changing an *udev* rule, you have to notify the daemon. Otherwise, your +changes are not reflected. Use the following command + +.. code-block:: console + + target:~$ udevadm control --reload-rules + +While developing *udev* rules you should monitor the events in order to see when +devices are attached or unattached to the system. Use + +.. code-block:: console + + target:~$ udevadm monitor + +Furthermore, it is very useful to monitor the system log in another shell, +especially if the rule executes external scripts. Execute + +.. code-block:: console + + target:~$ journalctl -f + +.. tip:: + + You cannot start daemons or heavy scripts in a *RUN* attribute. See + https://www.freedesktop.org/software/systemd/man/latest/udev.html#RUN%7Btype%7D . + + This can only be used for very short-running foreground tasks. Running an + event process for a long period of time may block all further events for this + or a dependent device. Starting daemons or other long-running processes is + not appropriate for *udev*; the forked processes, detached or not, will be + unconditionally killed after the event handling has finished. You can use the + special attribute *ENV{SYSTEMD_WANTS}="service-name.service"* and a + *systemd*\ service instead. + + See + https://unix.stackexchange.com/questions/63232/what-is-the-correct-way-to-write-a-udev-rule-to-stop-a-service-under-systemd. + +Troubleshooting +=============== + +Setscene Task Warning +--------------------- + +This warning occurs when the Yocto cache is in a dirty state. + +.. code-block:: + + WARNING: Setscene task X ([...]) failed with exit code '1' - real task + +You should avoid canceling the build process or if you have to, press Ctrl-C +once and wait until the build process has stopped. To remove all these warnings +just clean the sstate cache and remove the build folders. + +.. code-block:: console + + host:~$ bitbake phytec-headless-image -c cleansstate && rm -rf tmp deploy/ipk + +Yocto Documentation +=================== + +The most important piece of documentation for a BSP user is probably the +developer manual. +https://docs.yoctoproject.org/dev/dev-manual/index.html + +The chapter about common tasks is a good starting point. +https://docs.yoctoproject.org/dev/dev-manual/layers.html#understanding-and-creating-layers + +The complete documentation is available on one single HTML page, which is good +for searching for a feature or a variable name. +https://docs.yoctoproject.org/dev/singleindex.html diff --git a/previews/271/_static/_sphinx_javascript_frameworks_compat.js b/previews/271/_static/_sphinx_javascript_frameworks_compat.js new file mode 100644 index 000000000..81415803e --- /dev/null +++ b/previews/271/_static/_sphinx_javascript_frameworks_compat.js @@ -0,0 +1,123 @@ +/* Compatability shim for jQuery and underscores.js. + * + * Copyright Sphinx contributors + * Released under the two clause BSD licence + */ + +/** + * small helper function to urldecode strings + * + * See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/decodeURIComponent#Decoding_query_parameters_from_a_URL + */ +jQuery.urldecode = function(x) { + if (!x) { + return x + } + return decodeURIComponent(x.replace(/\+/g, ' ')); +}; + +/** + * small helper function to urlencode strings + */ +jQuery.urlencode = encodeURIComponent; + +/** + * This function returns the parsed url parameters of the + * current request. Multiple values per key are supported, + * it will always return arrays of strings for the value parts. + */ +jQuery.getQueryParameters = function(s) { + if (typeof s === 'undefined') + s = document.location.search; + var parts = s.substr(s.indexOf('?') + 1).split('&'); + var result = {}; + for (var i = 0; i < parts.length; i++) { + var tmp = parts[i].split('=', 2); + var key = jQuery.urldecode(tmp[0]); + var value = jQuery.urldecode(tmp[1]); + if (key in result) + result[key].push(value); + else + result[key] = [value]; + } + return result; +}; + +/** + * highlight a given string on a jquery object by wrapping it in + * span elements with the given class name. + */ +jQuery.fn.highlightText = function(text, className) { + function highlight(node, addItems) { + if (node.nodeType === 3) { + var val = node.nodeValue; + var pos = val.toLowerCase().indexOf(text); + if (pos >= 0 && + !jQuery(node.parentNode).hasClass(className) && + !jQuery(node.parentNode).hasClass("nohighlight")) { + var span; + var isInSVG = jQuery(node).closest("body, svg, foreignObject").is("svg"); + if (isInSVG) { + span = document.createElementNS("http://www.w3.org/2000/svg", "tspan"); + } else { + span = document.createElement("span"); + span.className = className; + } + span.appendChild(document.createTextNode(val.substr(pos, text.length))); + node.parentNode.insertBefore(span, node.parentNode.insertBefore( + document.createTextNode(val.substr(pos + text.length)), + node.nextSibling)); + node.nodeValue = val.substr(0, pos); + if (isInSVG) { + var rect = document.createElementNS("http://www.w3.org/2000/svg", "rect"); + var bbox = node.parentElement.getBBox(); + rect.x.baseVal.value = bbox.x; + rect.y.baseVal.value = bbox.y; + rect.width.baseVal.value = bbox.width; + rect.height.baseVal.value = bbox.height; + rect.setAttribute('class', className); + addItems.push({ + "parent": node.parentNode, + "target": rect}); + } + } + } + else if (!jQuery(node).is("button, select, textarea")) { + jQuery.each(node.childNodes, function() { + highlight(this, addItems); + }); + } + } + var addItems = []; + var result = this.each(function() { + highlight(this, addItems); + }); + for (var i = 0; i < addItems.length; ++i) { + jQuery(addItems[i].parent).before(addItems[i].target); + } + return result; +}; + +/* + * backward compatibility for jQuery.browser + * This will be supported until firefox bug is fixed. + */ +if (!jQuery.browser) { + jQuery.uaMatch = function(ua) { + ua = ua.toLowerCase(); + + var match = /(chrome)[ \/]([\w.]+)/.exec(ua) || + /(webkit)[ \/]([\w.]+)/.exec(ua) || + /(opera)(?:.*version|)[ \/]([\w.]+)/.exec(ua) || + /(msie) ([\w.]+)/.exec(ua) || + ua.indexOf("compatible") < 0 && /(mozilla)(?:.*? rv:([\w.]+)|)/.exec(ua) || + []; + + return { + browser: match[ 1 ] || "", + version: match[ 2 ] || "0" + }; + }; + jQuery.browser = {}; + jQuery.browser[jQuery.uaMatch(navigator.userAgent).browser] = true; +} diff --git a/previews/271/_static/basic.css b/previews/271/_static/basic.css new file mode 100644 index 000000000..7ebbd6d07 --- /dev/null +++ b/previews/271/_static/basic.css @@ -0,0 +1,914 @@ +/* + * Sphinx stylesheet -- basic theme. + */ + +/* -- main layout ----------------------------------------------------------- */ + +div.clearer { + clear: both; +} + +div.section::after { + display: block; + content: ''; + clear: left; +} + +/* -- relbar ---------------------------------------------------------------- */ + +div.related { + width: 100%; + font-size: 90%; +} + +div.related h3 { + display: none; +} + +div.related ul { + margin: 0; + padding: 0 0 0 10px; + list-style: none; +} + +div.related li { + display: inline; +} + +div.related li.right { + float: right; + margin-right: 5px; +} + +/* -- sidebar --------------------------------------------------------------- */ + +div.sphinxsidebarwrapper { + padding: 10px 5px 0 10px; +} + +div.sphinxsidebar { + float: left; + width: 230px; + margin-left: -100%; + font-size: 90%; + word-wrap: break-word; + overflow-wrap : break-word; +} + +div.sphinxsidebar ul { + list-style: none; +} + +div.sphinxsidebar ul ul, +div.sphinxsidebar ul.want-points { + margin-left: 20px; + list-style: square; +} + +div.sphinxsidebar ul ul { + margin-top: 0; + margin-bottom: 0; +} + +div.sphinxsidebar form { + margin-top: 10px; +} + +div.sphinxsidebar input { + border: 1px solid #98dbcc; + font-family: sans-serif; + font-size: 1em; +} + +div.sphinxsidebar #searchbox form.search { + overflow: hidden; +} + +div.sphinxsidebar #searchbox input[type="text"] { + float: left; + width: 80%; + padding: 0.25em; + box-sizing: border-box; +} + +div.sphinxsidebar #searchbox input[type="submit"] { + float: left; + width: 20%; + border-left: none; + padding: 0.25em; + box-sizing: border-box; +} + + +img { + border: 0; + max-width: 100%; +} + +/* -- search page ----------------------------------------------------------- */ + +ul.search { + margin-top: 10px; +} + +ul.search li { + padding: 5px 0; +} + +ul.search li a { + font-weight: bold; +} + +ul.search li p.context { + color: #888; + margin: 2px 0 0 30px; + text-align: left; +} + +ul.keywordmatches li.goodmatch a { + font-weight: bold; +} + +/* -- index page ------------------------------------------------------------ */ + +table.contentstable { + width: 90%; + margin-left: auto; + margin-right: auto; +} + +table.contentstable p.biglink { + line-height: 150%; +} + +a.biglink { + font-size: 1.3em; +} + +span.linkdescr { + font-style: italic; + padding-top: 5px; + font-size: 90%; +} + +/* -- general index --------------------------------------------------------- */ + +table.indextable { + width: 100%; +} + +table.indextable td { + text-align: left; + vertical-align: top; +} + +table.indextable ul { + margin-top: 0; + margin-bottom: 0; + list-style-type: none; +} + +table.indextable > tbody > tr > td > ul { + padding-left: 0em; +} + +table.indextable tr.pcap { + height: 10px; +} + +table.indextable tr.cap { + margin-top: 10px; + background-color: #f2f2f2; +} + +img.toggler { + margin-right: 3px; + margin-top: 3px; + cursor: pointer; +} + +div.modindex-jumpbox { + border-top: 1px solid #ddd; + border-bottom: 1px solid #ddd; + margin: 1em 0 1em 0; + padding: 0.4em; +} + +div.genindex-jumpbox { + border-top: 1px solid #ddd; + border-bottom: 1px solid #ddd; + margin: 1em 0 1em 0; + padding: 0.4em; +} + +/* -- domain module index --------------------------------------------------- */ + +table.modindextable td { + padding: 2px; + border-collapse: collapse; +} + +/* -- general body styles --------------------------------------------------- */ + +div.body { + min-width: 360px; + max-width: 800px; +} + +div.body p, div.body dd, div.body li, div.body blockquote { + -moz-hyphens: auto; + -ms-hyphens: auto; + -webkit-hyphens: auto; + hyphens: auto; +} + +a.headerlink { + visibility: hidden; +} + +a:visited { + color: #551A8B; +} + +h1:hover > a.headerlink, +h2:hover > a.headerlink, +h3:hover > a.headerlink, +h4:hover > a.headerlink, +h5:hover > a.headerlink, +h6:hover > a.headerlink, +dt:hover > a.headerlink, +caption:hover > a.headerlink, +p.caption:hover > a.headerlink, +div.code-block-caption:hover > a.headerlink { + visibility: visible; +} + +div.body p.caption { + text-align: inherit; +} + +div.body td { + text-align: left; +} + +.first { + margin-top: 0 !important; +} + +p.rubric { + margin-top: 30px; + font-weight: bold; +} + +img.align-left, figure.align-left, .figure.align-left, object.align-left { + clear: left; + float: left; + margin-right: 1em; +} + +img.align-right, figure.align-right, .figure.align-right, object.align-right { + clear: right; + float: right; + margin-left: 1em; +} + +img.align-center, figure.align-center, .figure.align-center, object.align-center { + display: block; + margin-left: auto; + margin-right: auto; +} + +img.align-default, figure.align-default, .figure.align-default { + display: block; + margin-left: auto; + margin-right: auto; +} + +.align-left { + text-align: left; +} + +.align-center { + text-align: center; +} + +.align-default { + text-align: center; +} + +.align-right { + text-align: right; +} + +/* -- sidebars -------------------------------------------------------------- */ + +div.sidebar, +aside.sidebar { + margin: 0 0 0.5em 1em; + border: 1px solid #ddb; + padding: 7px; + background-color: #ffe; + width: 40%; + float: right; + clear: right; + overflow-x: auto; +} + +p.sidebar-title { + font-weight: bold; +} + +nav.contents, +aside.topic, +div.admonition, div.topic, blockquote { + clear: left; +} + +/* -- topics ---------------------------------------------------------------- */ + +nav.contents, +aside.topic, +div.topic { + border: 1px solid #ccc; + padding: 7px; + margin: 10px 0 10px 0; +} + +p.topic-title { + font-size: 1.1em; + font-weight: bold; + margin-top: 10px; +} + +/* -- admonitions ----------------------------------------------------------- */ + +div.admonition { + margin-top: 10px; + margin-bottom: 10px; + padding: 7px; +} + +div.admonition dt { + font-weight: bold; +} + +p.admonition-title { + margin: 0px 10px 5px 0px; + font-weight: bold; +} + +div.body p.centered { + text-align: center; + margin-top: 25px; +} + +/* -- content of sidebars/topics/admonitions -------------------------------- */ + +div.sidebar > :last-child, +aside.sidebar > :last-child, +nav.contents > :last-child, +aside.topic > :last-child, +div.topic > :last-child, +div.admonition > :last-child { + margin-bottom: 0; +} + +div.sidebar::after, +aside.sidebar::after, +nav.contents::after, +aside.topic::after, +div.topic::after, +div.admonition::after, +blockquote::after { + display: block; + content: ''; + clear: both; +} + +/* -- tables ---------------------------------------------------------------- */ + +table.docutils { + margin-top: 10px; + margin-bottom: 10px; + border: 0; + border-collapse: collapse; +} + +table.align-center { + margin-left: auto; + margin-right: auto; +} + +table.align-default { + margin-left: auto; + margin-right: auto; +} + +table caption span.caption-number { + font-style: italic; +} + +table caption span.caption-text { +} + +table.docutils td, table.docutils th { + padding: 1px 8px 1px 5px; + border-top: 0; + border-left: 0; + border-right: 0; + border-bottom: 1px solid #aaa; +} + +th { + text-align: left; + padding-right: 5px; +} + +table.citation { + border-left: solid 1px gray; + margin-left: 1px; +} + +table.citation td { + border-bottom: none; +} + +th > :first-child, +td > :first-child { + margin-top: 0px; +} + +th > :last-child, +td > :last-child { + margin-bottom: 0px; +} + +/* -- figures --------------------------------------------------------------- */ + +div.figure, figure { + margin: 0.5em; + padding: 0.5em; +} + +div.figure p.caption, figcaption { + padding: 0.3em; +} + +div.figure p.caption span.caption-number, +figcaption span.caption-number { + font-style: italic; +} + +div.figure p.caption span.caption-text, +figcaption span.caption-text { +} + +/* -- field list styles ----------------------------------------------------- */ + +table.field-list td, table.field-list th { + border: 0 !important; +} + +.field-list ul { + margin: 0; + padding-left: 1em; +} + +.field-list p { + margin: 0; +} + +.field-name { + -moz-hyphens: manual; + -ms-hyphens: manual; + -webkit-hyphens: manual; + hyphens: manual; +} + +/* -- hlist styles ---------------------------------------------------------- */ + +table.hlist { + margin: 1em 0; +} + +table.hlist td { + vertical-align: top; +} + +/* -- object description styles --------------------------------------------- */ + +.sig { + font-family: 'Consolas', 'Menlo', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', monospace; +} + +.sig-name, code.descname { + background-color: transparent; + font-weight: bold; +} + +.sig-name { + font-size: 1.1em; +} + +code.descname { + font-size: 1.2em; +} + +.sig-prename, code.descclassname { + background-color: transparent; +} + +.optional { + font-size: 1.3em; +} + +.sig-paren { + font-size: larger; +} + +.sig-param.n { + font-style: italic; +} + +/* C++ specific styling */ + +.sig-inline.c-texpr, +.sig-inline.cpp-texpr { + font-family: unset; +} + +.sig.c .k, .sig.c .kt, +.sig.cpp .k, .sig.cpp .kt { + color: #0033B3; +} + +.sig.c .m, +.sig.cpp .m { + color: #1750EB; +} + +.sig.c .s, .sig.c .sc, +.sig.cpp .s, .sig.cpp .sc { + color: #067D17; +} + + +/* -- other body styles ----------------------------------------------------- */ + +ol.arabic { + list-style: decimal; +} + +ol.loweralpha { + list-style: lower-alpha; +} + +ol.upperalpha { + list-style: upper-alpha; +} + +ol.lowerroman { + list-style: lower-roman; +} + +ol.upperroman { + list-style: upper-roman; +} + +:not(li) > ol > li:first-child > :first-child, +:not(li) > ul > li:first-child > :first-child { + margin-top: 0px; +} + +:not(li) > ol > li:last-child > :last-child, +:not(li) > ul > li:last-child > :last-child { + margin-bottom: 0px; +} + +ol.simple ol p, +ol.simple ul p, +ul.simple ol p, +ul.simple ul p { + margin-top: 0; +} + +ol.simple > li:not(:first-child) > p, +ul.simple > li:not(:first-child) > p { + margin-top: 0; +} + +ol.simple p, +ul.simple p { + margin-bottom: 0; +} + +aside.footnote > span, +div.citation > span { + float: left; +} +aside.footnote > span:last-of-type, +div.citation > span:last-of-type { + padding-right: 0.5em; +} +aside.footnote > p { + margin-left: 2em; +} +div.citation > p { + margin-left: 4em; +} +aside.footnote > p:last-of-type, +div.citation > p:last-of-type { + margin-bottom: 0em; +} +aside.footnote > p:last-of-type:after, +div.citation > p:last-of-type:after { + content: ""; + clear: both; +} + +dl.field-list { + display: grid; + grid-template-columns: fit-content(30%) auto; +} + +dl.field-list > dt { + font-weight: bold; + word-break: break-word; + padding-left: 0.5em; + padding-right: 5px; +} + +dl.field-list > dd { + padding-left: 0.5em; + margin-top: 0em; + margin-left: 0em; + margin-bottom: 0em; +} + +dl { + margin-bottom: 15px; +} + +dd > :first-child { + margin-top: 0px; +} + +dd ul, dd table { + margin-bottom: 10px; +} + +dd { + margin-top: 3px; + margin-bottom: 10px; + margin-left: 30px; +} + +.sig dd { + margin-top: 0px; + margin-bottom: 0px; +} + +.sig dl { + margin-top: 0px; + margin-bottom: 0px; +} + +dl > dd:last-child, +dl > dd:last-child > :last-child { + margin-bottom: 0; +} + +dt:target, span.highlighted { + background-color: #fbe54e; +} + +rect.highlighted { + fill: #fbe54e; +} + +dl.glossary dt { + font-weight: bold; + font-size: 1.1em; +} + +.versionmodified { + font-style: italic; +} + +.system-message { + background-color: #fda; + padding: 5px; + border: 3px solid red; +} + +.footnote:target { + background-color: #ffa; +} + +.line-block { + display: block; + margin-top: 1em; + margin-bottom: 1em; +} + +.line-block .line-block { + margin-top: 0; + margin-bottom: 0; + margin-left: 1.5em; +} + +.guilabel, .menuselection { + font-family: sans-serif; +} + +.accelerator { + text-decoration: underline; +} + +.classifier { + font-style: oblique; +} + +.classifier:before { + font-style: normal; + margin: 0 0.5em; + content: ":"; + display: inline-block; +} + +abbr, acronym { + border-bottom: dotted 1px; + cursor: help; +} + +.translated { + background-color: rgba(207, 255, 207, 0.2) +} + +.untranslated { + background-color: rgba(255, 207, 207, 0.2) +} + +/* -- code displays --------------------------------------------------------- */ + +pre { + overflow: auto; + overflow-y: hidden; /* fixes display issues on Chrome browsers */ +} + +pre, div[class*="highlight-"] { + clear: both; +} + +span.pre { + -moz-hyphens: none; + -ms-hyphens: none; + -webkit-hyphens: none; + hyphens: none; + white-space: nowrap; +} + +div[class*="highlight-"] { + margin: 1em 0; +} + +td.linenos pre { + border: 0; + background-color: transparent; + color: #aaa; +} + +table.highlighttable { + display: block; +} + +table.highlighttable tbody { + display: block; +} + +table.highlighttable tr { + display: flex; +} + +table.highlighttable td { + margin: 0; + padding: 0; +} + +table.highlighttable td.linenos { + padding-right: 0.5em; +} + +table.highlighttable td.code { + flex: 1; + overflow: hidden; +} + +.highlight .hll { + display: block; +} + +div.highlight pre, +table.highlighttable pre { + margin: 0; +} + +div.code-block-caption + div { + margin-top: 0; +} + +div.code-block-caption { + margin-top: 1em; + padding: 2px 5px; + font-size: small; +} + +div.code-block-caption code { + background-color: transparent; +} + +table.highlighttable td.linenos, +span.linenos, +div.highlight span.gp { /* gp: Generic.Prompt */ + user-select: none; + -webkit-user-select: text; /* Safari fallback only */ + -webkit-user-select: none; /* Chrome/Safari */ + -moz-user-select: none; /* Firefox */ + -ms-user-select: none; /* IE10+ */ +} + +div.code-block-caption span.caption-number { + padding: 0.1em 0.3em; + font-style: italic; +} + +div.code-block-caption span.caption-text { +} + +div.literal-block-wrapper { + margin: 1em 0; +} + +code.xref, a code { + background-color: transparent; + font-weight: bold; +} + +h1 code, h2 code, h3 code, h4 code, h5 code, h6 code { + background-color: transparent; +} + +.viewcode-link { + float: right; +} + +.viewcode-back { + float: right; + font-family: sans-serif; +} + +div.viewcode-block:target { + margin: -1px -10px; + padding: 0 10px; +} + +/* -- math display ---------------------------------------------------------- */ + +img.math { + vertical-align: middle; +} + +div.body div.math p { + text-align: center; +} + +span.eqno { + float: right; +} + +span.eqno a.headerlink { + position: absolute; + z-index: 1; +} + +div.math:hover a.headerlink { + visibility: visible; +} + +/* -- printout stylesheet --------------------------------------------------- */ + +@media print { + div.document, + div.documentwrapper, + div.bodywrapper { + margin: 0 !important; + width: 100%; + } + + div.sphinxsidebar, + div.related, + div.footer, + #top-link { + display: none; + } +} \ No newline at end of file diff --git a/previews/271/_static/css/badge_only.css b/previews/271/_static/css/badge_only.css new file mode 100644 index 000000000..88ba55b96 --- /dev/null +++ b/previews/271/_static/css/badge_only.css @@ -0,0 +1 @@ +.clearfix{*zoom:1}.clearfix:after,.clearfix:before{display:table;content:""}.clearfix:after{clear:both}@font-face{font-family:FontAwesome;font-style:normal;font-weight:400;src:url(fonts/fontawesome-webfont.eot?674f50d287a8c48dc19ba404d20fe713?#iefix) format("embedded-opentype"),url(fonts/fontawesome-webfont.woff2?af7ae505a9eed503f8b8e6982036873e) format("woff2"),url(fonts/fontawesome-webfont.woff?fee66e712a8a08eef5805a46892932ad) format("woff"),url(fonts/fontawesome-webfont.ttf?b06871f281fee6b241d60582ae9369b9) format("truetype"),url(fonts/fontawesome-webfont.svg?912ec66d7572ff821749319396470bde#FontAwesome) format("svg")}.fa:before{font-family:FontAwesome;font-style:normal;font-weight:400;line-height:1}.fa:before,a .fa{text-decoration:inherit}.fa:before,a .fa,li .fa{display:inline-block}li .fa-large:before{width:1.875em}ul.fas{list-style-type:none;margin-left:2em;text-indent:-.8em}ul.fas li .fa{width:.8em}ul.fas li .fa-large:before{vertical-align:baseline}.fa-book:before,.icon-book:before{content:"\f02d"}.fa-caret-down:before,.icon-caret-down:before{content:"\f0d7"}.fa-caret-up:before,.icon-caret-up:before{content:"\f0d8"}.fa-caret-left:before,.icon-caret-left:before{content:"\f0d9"}.fa-caret-right:before,.icon-caret-right:before{content:"\f0da"}.rst-versions{position:fixed;bottom:0;left:0;width:300px;color:#fcfcfc;background:#1f1d1d;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;z-index:400}.rst-versions a{color:#2980b9;text-decoration:none}.rst-versions .rst-badge-small{display:none}.rst-versions .rst-current-version{padding:12px;background-color:#272525;display:block;text-align:right;font-size:90%;cursor:pointer;color:#27ae60}.rst-versions .rst-current-version:after{clear:both;content:"";display:block}.rst-versions .rst-current-version .fa{color:#fcfcfc}.rst-versions .rst-current-version .fa-book,.rst-versions .rst-current-version .icon-book{float:left}.rst-versions .rst-current-version.rst-out-of-date{background-color:#e74c3c;color:#fff}.rst-versions .rst-current-version.rst-active-old-version{background-color:#f1c40f;color:#000}.rst-versions.shift-up{height:auto;max-height:100%;overflow-y:scroll}.rst-versions.shift-up .rst-other-versions{display:block}.rst-versions .rst-other-versions{font-size:90%;padding:12px;color:grey;display:none}.rst-versions .rst-other-versions hr{display:block;height:1px;border:0;margin:20px 0;padding:0;border-top:1px solid #413d3d}.rst-versions .rst-other-versions dd{display:inline-block;margin:0}.rst-versions .rst-other-versions dd a{display:inline-block;padding:6px;color:#fcfcfc}.rst-versions .rst-other-versions .rtd-current-item{font-weight:700}.rst-versions.rst-badge{width:auto;bottom:20px;right:20px;left:auto;border:none;max-width:300px;max-height:90%}.rst-versions.rst-badge .fa-book,.rst-versions.rst-badge .icon-book{float:none;line-height:30px}.rst-versions.rst-badge.shift-up .rst-current-version{text-align:right}.rst-versions.rst-badge.shift-up .rst-current-version .fa-book,.rst-versions.rst-badge.shift-up .rst-current-version .icon-book{float:left}.rst-versions.rst-badge>.rst-current-version{width:auto;height:30px;line-height:30px;padding:0 6px;display:block;text-align:center}@media screen and (max-width:768px){.rst-versions{width:85%;display:none}.rst-versions.shift{display:block}}#flyout-search-form{padding:6px} \ No newline at end of file diff --git a/previews/271/_static/css/code-block.css b/previews/271/_static/css/code-block.css new file mode 100644 index 000000000..213d52d45 --- /dev/null +++ b/previews/271/_static/css/code-block.css @@ -0,0 +1,9 @@ +.rst-content .code-block-caption { + font-style: normal; + font-weight: bold; + padding: 10px 12px; + text-align: inherit; + border: 1px solid #e1e4e5; + border-bottom: 0px; + margin-bottom: -1px; +} diff --git a/previews/271/_static/css/fonts/Roboto-Slab-Bold.woff b/previews/271/_static/css/fonts/Roboto-Slab-Bold.woff new file mode 100644 index 000000000..6cb600001 Binary files /dev/null and b/previews/271/_static/css/fonts/Roboto-Slab-Bold.woff differ diff --git a/previews/271/_static/css/fonts/Roboto-Slab-Bold.woff2 b/previews/271/_static/css/fonts/Roboto-Slab-Bold.woff2 new file mode 100644 index 000000000..7059e2314 Binary files /dev/null and b/previews/271/_static/css/fonts/Roboto-Slab-Bold.woff2 differ diff --git a/previews/271/_static/css/fonts/Roboto-Slab-Regular.woff b/previews/271/_static/css/fonts/Roboto-Slab-Regular.woff new file mode 100644 index 000000000..f815f63f9 Binary files /dev/null and b/previews/271/_static/css/fonts/Roboto-Slab-Regular.woff differ diff --git a/previews/271/_static/css/fonts/Roboto-Slab-Regular.woff2 b/previews/271/_static/css/fonts/Roboto-Slab-Regular.woff2 new file mode 100644 index 000000000..f2c76e5bd Binary files /dev/null and b/previews/271/_static/css/fonts/Roboto-Slab-Regular.woff2 differ diff --git a/previews/271/_static/css/fonts/fontawesome-webfont.eot b/previews/271/_static/css/fonts/fontawesome-webfont.eot new file mode 100644 index 000000000..e9f60ca95 Binary files /dev/null and b/previews/271/_static/css/fonts/fontawesome-webfont.eot differ diff --git a/previews/271/_static/css/fonts/fontawesome-webfont.svg b/previews/271/_static/css/fonts/fontawesome-webfont.svg new file mode 100644 index 000000000..855c845e5 --- /dev/null +++ b/previews/271/_static/css/fonts/fontawesome-webfont.svg @@ -0,0 +1,2671 @@ + + + + +Created by FontForge 20120731 at Mon Oct 24 17:37:40 2016 + By ,,, +Copyright Dave Gandy 2016. All rights reserved. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/previews/271/_static/css/fonts/fontawesome-webfont.ttf b/previews/271/_static/css/fonts/fontawesome-webfont.ttf new file mode 100644 index 000000000..35acda2fa Binary files /dev/null and b/previews/271/_static/css/fonts/fontawesome-webfont.ttf differ diff --git a/previews/271/_static/css/fonts/fontawesome-webfont.woff b/previews/271/_static/css/fonts/fontawesome-webfont.woff new file mode 100644 index 000000000..400014a4b Binary files /dev/null and b/previews/271/_static/css/fonts/fontawesome-webfont.woff differ diff --git a/previews/271/_static/css/fonts/fontawesome-webfont.woff2 b/previews/271/_static/css/fonts/fontawesome-webfont.woff2 new file mode 100644 index 000000000..4d13fc604 Binary files /dev/null and b/previews/271/_static/css/fonts/fontawesome-webfont.woff2 differ diff --git a/previews/271/_static/css/fonts/lato-bold-italic.woff b/previews/271/_static/css/fonts/lato-bold-italic.woff new file mode 100644 index 000000000..88ad05b9f Binary files /dev/null and b/previews/271/_static/css/fonts/lato-bold-italic.woff differ diff --git a/previews/271/_static/css/fonts/lato-bold-italic.woff2 b/previews/271/_static/css/fonts/lato-bold-italic.woff2 new file mode 100644 index 000000000..c4e3d804b Binary files /dev/null and b/previews/271/_static/css/fonts/lato-bold-italic.woff2 differ diff --git a/previews/271/_static/css/fonts/lato-bold.woff b/previews/271/_static/css/fonts/lato-bold.woff new file mode 100644 index 000000000..c6dff51f0 Binary files /dev/null and b/previews/271/_static/css/fonts/lato-bold.woff differ diff --git a/previews/271/_static/css/fonts/lato-bold.woff2 b/previews/271/_static/css/fonts/lato-bold.woff2 new file mode 100644 index 000000000..bb195043c Binary files /dev/null and b/previews/271/_static/css/fonts/lato-bold.woff2 differ diff --git a/previews/271/_static/css/fonts/lato-normal-italic.woff b/previews/271/_static/css/fonts/lato-normal-italic.woff new file mode 100644 index 000000000..76114bc03 Binary files /dev/null and b/previews/271/_static/css/fonts/lato-normal-italic.woff differ diff --git a/previews/271/_static/css/fonts/lato-normal-italic.woff2 b/previews/271/_static/css/fonts/lato-normal-italic.woff2 new file mode 100644 index 000000000..3404f37e2 Binary files /dev/null and b/previews/271/_static/css/fonts/lato-normal-italic.woff2 differ diff --git a/previews/271/_static/css/fonts/lato-normal.woff b/previews/271/_static/css/fonts/lato-normal.woff new file mode 100644 index 000000000..ae1307ff5 Binary files /dev/null and b/previews/271/_static/css/fonts/lato-normal.woff differ diff --git a/previews/271/_static/css/fonts/lato-normal.woff2 b/previews/271/_static/css/fonts/lato-normal.woff2 new file mode 100644 index 000000000..3bf984332 Binary files /dev/null and b/previews/271/_static/css/fonts/lato-normal.woff2 differ diff --git a/previews/271/_static/css/phytec-theme.css b/previews/271/_static/css/phytec-theme.css new file mode 100644 index 000000000..c46cf7bca --- /dev/null +++ b/previews/271/_static/css/phytec-theme.css @@ -0,0 +1,45 @@ +/* Definitions for Colorscheme from the Phytec Website */ +:root { + --blue: #007bff; + --indigo: #6610f2; + --purple: #6f42c1; + --pink: #e83e8c; + --red: #dc3545; + --teal: #20c997; + --cyan: #17a2b8; + --gray: #6c757d; + --gray-dark: #343a40; + --primary: #006e73; + --secondary: #6c757d; + --success: #28a745; + --info: #17a2b8; + --warning: #ffc107; + --danger: #dc3545; + --light: #f8f9fa; + --dark: #343a40; + --black: #000; + --white: #fff; + --gray1: #f5f5f5; + --gray2: #d0d2d3; + --gray3: #95989a; + --gray4: #707070; + --teal1: #03c9d6; + --teal2: #02a6b1; + --teal3: #16969e; + --teal4: #006e73; + --orange: #ff9708; + --green: #c5d900; + --yellow: #f1bf00; +} + +.wy-menu-vertical header, +.wy-menu-vertical p.caption { + color: var(--teal4); + + /* Improves the appearance of uppercase text */ + letter-spacing: 0.75px; +} + +.wy-side-nav-search { + background-color: var(--teal4); +} diff --git a/previews/271/_static/css/theme.css b/previews/271/_static/css/theme.css new file mode 100644 index 000000000..0f14f1064 --- /dev/null +++ b/previews/271/_static/css/theme.css @@ -0,0 +1,4 @@ +html{box-sizing:border-box}*,:after,:before{box-sizing:inherit}article,aside,details,figcaption,figure,footer,header,hgroup,nav,section{display:block}audio,canvas,video{display:inline-block;*display:inline;*zoom:1}[hidden],audio:not([controls]){display:none}*{-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}html{font-size:100%;-webkit-text-size-adjust:100%;-ms-text-size-adjust:100%}body{margin:0}a:active,a:hover{outline:0}abbr[title]{border-bottom:1px dotted}b,strong{font-weight:700}blockquote{margin:0}dfn{font-style:italic}ins{background:#ff9;text-decoration:none}ins,mark{color:#000}mark{background:#ff0;font-style:italic;font-weight:700}.rst-content code,.rst-content tt,code,kbd,pre,samp{font-family:monospace,serif;_font-family:courier new,monospace;font-size:1em}pre{white-space:pre}q{quotes:none}q:after,q:before{content:"";content:none}small{font-size:85%}sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline}sup{top:-.5em}sub{bottom:-.25em}dl,ol,ul{margin:0;padding:0;list-style:none;list-style-image:none}li{list-style:none}dd{margin:0}img{border:0;-ms-interpolation-mode:bicubic;vertical-align:middle;max-width:100%}svg:not(:root){overflow:hidden}figure,form{margin:0}label{cursor:pointer}button,input,select,textarea{font-size:100%;margin:0;vertical-align:baseline;*vertical-align:middle}button,input{line-height:normal}button,input[type=button],input[type=reset],input[type=submit]{cursor:pointer;-webkit-appearance:button;*overflow:visible}button[disabled],input[disabled]{cursor:default}input[type=search]{-webkit-appearance:textfield;-moz-box-sizing:content-box;-webkit-box-sizing:content-box;box-sizing:content-box}textarea{resize:vertical}table{border-collapse:collapse;border-spacing:0}td{vertical-align:top}.chromeframe{margin:.2em 0;background:#ccc;color:#000;padding:.2em 0}.ir{display:block;border:0;text-indent:-999em;overflow:hidden;background-color:transparent;background-repeat:no-repeat;text-align:left;direction:ltr;*line-height:0}.ir br{display:none}.hidden{display:none!important;visibility:hidden}.visuallyhidden{border:0;clip:rect(0 0 0 0);height:1px;margin:-1px;overflow:hidden;padding:0;position:absolute;width:1px}.visuallyhidden.focusable:active,.visuallyhidden.focusable:focus{clip:auto;height:auto;margin:0;overflow:visible;position:static;width:auto}.invisible{visibility:hidden}.relative{position:relative}big,small{font-size:100%}@media print{body,html,section{background:none!important}*{box-shadow:none!important;text-shadow:none!important;filter:none!important;-ms-filter:none!important}a,a:visited{text-decoration:underline}.ir a:after,a[href^="#"]:after,a[href^="javascript:"]:after{content:""}blockquote,pre{page-break-inside:avoid}thead{display:table-header-group}img,tr{page-break-inside:avoid}img{max-width:100%!important}@page{margin:.5cm}.rst-content .toctree-wrapper>p.caption,h2,h3,p{orphans:3;widows:3}.rst-content .toctree-wrapper>p.caption,h2,h3{page-break-after:avoid}}.btn,.fa:before,.icon:before,.rst-content .admonition,.rst-content .admonition-title:before,.rst-content .admonition-todo,.rst-content .attention,.rst-content .caution,.rst-content .code-block-caption .headerlink:before,.rst-content .danger,.rst-content .eqno .headerlink:before,.rst-content .error,.rst-content .hint,.rst-content .important,.rst-content .note,.rst-content .seealso,.rst-content .tip,.rst-content .warning,.rst-content code.download span:first-child:before,.rst-content dl dt .headerlink:before,.rst-content h1 .headerlink:before,.rst-content h2 .headerlink:before,.rst-content h3 .headerlink:before,.rst-content h4 .headerlink:before,.rst-content h5 .headerlink:before,.rst-content h6 .headerlink:before,.rst-content p.caption .headerlink:before,.rst-content p .headerlink:before,.rst-content table>caption .headerlink:before,.rst-content tt.download span:first-child:before,.wy-alert,.wy-dropdown .caret:before,.wy-inline-validate.wy-inline-validate-danger .wy-input-context:before,.wy-inline-validate.wy-inline-validate-info .wy-input-context:before,.wy-inline-validate.wy-inline-validate-success .wy-input-context:before,.wy-inline-validate.wy-inline-validate-warning .wy-input-context:before,.wy-menu-vertical li.current>a button.toctree-expand:before,.wy-menu-vertical li.on a button.toctree-expand:before,.wy-menu-vertical li button.toctree-expand:before,input[type=color],input[type=date],input[type=datetime-local],input[type=datetime],input[type=email],input[type=month],input[type=number],input[type=password],input[type=search],input[type=tel],input[type=text],input[type=time],input[type=url],input[type=week],select,textarea{-webkit-font-smoothing:antialiased}.clearfix{*zoom:1}.clearfix:after,.clearfix:before{display:table;content:""}.clearfix:after{clear:both}/*! + * Font Awesome 4.7.0 by @davegandy - http://fontawesome.io - @fontawesome + * License - http://fontawesome.io/license (Font: SIL OFL 1.1, CSS: MIT License) + */@font-face{font-family:FontAwesome;src:url(fonts/fontawesome-webfont.eot?674f50d287a8c48dc19ba404d20fe713);src:url(fonts/fontawesome-webfont.eot?674f50d287a8c48dc19ba404d20fe713?#iefix&v=4.7.0) format("embedded-opentype"),url(fonts/fontawesome-webfont.woff2?af7ae505a9eed503f8b8e6982036873e) format("woff2"),url(fonts/fontawesome-webfont.woff?fee66e712a8a08eef5805a46892932ad) format("woff"),url(fonts/fontawesome-webfont.ttf?b06871f281fee6b241d60582ae9369b9) format("truetype"),url(fonts/fontawesome-webfont.svg?912ec66d7572ff821749319396470bde#fontawesomeregular) format("svg");font-weight:400;font-style:normal}.fa,.icon,.rst-content .admonition-title,.rst-content .code-block-caption .headerlink,.rst-content .eqno .headerlink,.rst-content code.download span:first-child,.rst-content dl dt .headerlink,.rst-content h1 .headerlink,.rst-content h2 .headerlink,.rst-content h3 .headerlink,.rst-content h4 .headerlink,.rst-content h5 .headerlink,.rst-content h6 .headerlink,.rst-content p.caption .headerlink,.rst-content p .headerlink,.rst-content table>caption .headerlink,.rst-content tt.download span:first-child,.wy-menu-vertical li.current>a button.toctree-expand,.wy-menu-vertical li.on a button.toctree-expand,.wy-menu-vertical li button.toctree-expand{display:inline-block;font:normal normal normal 14px/1 FontAwesome;font-size:inherit;text-rendering:auto;-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale}.fa-lg{font-size:1.33333em;line-height:.75em;vertical-align:-15%}.fa-2x{font-size:2em}.fa-3x{font-size:3em}.fa-4x{font-size:4em}.fa-5x{font-size:5em}.fa-fw{width:1.28571em;text-align:center}.fa-ul{padding-left:0;margin-left:2.14286em;list-style-type:none}.fa-ul>li{position:relative}.fa-li{position:absolute;left:-2.14286em;width:2.14286em;top:.14286em;text-align:center}.fa-li.fa-lg{left:-1.85714em}.fa-border{padding:.2em .25em .15em;border:.08em solid #eee;border-radius:.1em}.fa-pull-left{float:left}.fa-pull-right{float:right}.fa-pull-left.icon,.fa.fa-pull-left,.rst-content .code-block-caption .fa-pull-left.headerlink,.rst-content .eqno .fa-pull-left.headerlink,.rst-content .fa-pull-left.admonition-title,.rst-content code.download span.fa-pull-left:first-child,.rst-content dl dt .fa-pull-left.headerlink,.rst-content h1 .fa-pull-left.headerlink,.rst-content h2 .fa-pull-left.headerlink,.rst-content h3 .fa-pull-left.headerlink,.rst-content h4 .fa-pull-left.headerlink,.rst-content h5 .fa-pull-left.headerlink,.rst-content h6 .fa-pull-left.headerlink,.rst-content p .fa-pull-left.headerlink,.rst-content table>caption .fa-pull-left.headerlink,.rst-content tt.download span.fa-pull-left:first-child,.wy-menu-vertical li.current>a button.fa-pull-left.toctree-expand,.wy-menu-vertical li.on a button.fa-pull-left.toctree-expand,.wy-menu-vertical li button.fa-pull-left.toctree-expand{margin-right:.3em}.fa-pull-right.icon,.fa.fa-pull-right,.rst-content .code-block-caption .fa-pull-right.headerlink,.rst-content .eqno .fa-pull-right.headerlink,.rst-content .fa-pull-right.admonition-title,.rst-content code.download span.fa-pull-right:first-child,.rst-content dl dt .fa-pull-right.headerlink,.rst-content h1 .fa-pull-right.headerlink,.rst-content h2 .fa-pull-right.headerlink,.rst-content h3 .fa-pull-right.headerlink,.rst-content h4 .fa-pull-right.headerlink,.rst-content h5 .fa-pull-right.headerlink,.rst-content h6 .fa-pull-right.headerlink,.rst-content p .fa-pull-right.headerlink,.rst-content table>caption .fa-pull-right.headerlink,.rst-content tt.download span.fa-pull-right:first-child,.wy-menu-vertical li.current>a button.fa-pull-right.toctree-expand,.wy-menu-vertical li.on a button.fa-pull-right.toctree-expand,.wy-menu-vertical li button.fa-pull-right.toctree-expand{margin-left:.3em}.pull-right{float:right}.pull-left{float:left}.fa.pull-left,.pull-left.icon,.rst-content .code-block-caption .pull-left.headerlink,.rst-content .eqno .pull-left.headerlink,.rst-content .pull-left.admonition-title,.rst-content code.download span.pull-left:first-child,.rst-content dl dt .pull-left.headerlink,.rst-content h1 .pull-left.headerlink,.rst-content h2 .pull-left.headerlink,.rst-content h3 .pull-left.headerlink,.rst-content h4 .pull-left.headerlink,.rst-content h5 .pull-left.headerlink,.rst-content h6 .pull-left.headerlink,.rst-content p .pull-left.headerlink,.rst-content table>caption .pull-left.headerlink,.rst-content tt.download span.pull-left:first-child,.wy-menu-vertical li.current>a button.pull-left.toctree-expand,.wy-menu-vertical li.on a button.pull-left.toctree-expand,.wy-menu-vertical li button.pull-left.toctree-expand{margin-right:.3em}.fa.pull-right,.pull-right.icon,.rst-content .code-block-caption .pull-right.headerlink,.rst-content .eqno .pull-right.headerlink,.rst-content .pull-right.admonition-title,.rst-content code.download span.pull-right:first-child,.rst-content dl dt .pull-right.headerlink,.rst-content h1 .pull-right.headerlink,.rst-content h2 .pull-right.headerlink,.rst-content h3 .pull-right.headerlink,.rst-content h4 .pull-right.headerlink,.rst-content h5 .pull-right.headerlink,.rst-content h6 .pull-right.headerlink,.rst-content p .pull-right.headerlink,.rst-content table>caption .pull-right.headerlink,.rst-content tt.download span.pull-right:first-child,.wy-menu-vertical li.current>a button.pull-right.toctree-expand,.wy-menu-vertical li.on a button.pull-right.toctree-expand,.wy-menu-vertical li button.pull-right.toctree-expand{margin-left:.3em}.fa-spin{-webkit-animation:fa-spin 2s linear infinite;animation:fa-spin 2s linear infinite}.fa-pulse{-webkit-animation:fa-spin 1s steps(8) infinite;animation:fa-spin 1s steps(8) infinite}@-webkit-keyframes fa-spin{0%{-webkit-transform:rotate(0deg);transform:rotate(0deg)}to{-webkit-transform:rotate(359deg);transform:rotate(359deg)}}@keyframes fa-spin{0%{-webkit-transform:rotate(0deg);transform:rotate(0deg)}to{-webkit-transform:rotate(359deg);transform:rotate(359deg)}}.fa-rotate-90{-ms-filter:"progid:DXImageTransform.Microsoft.BasicImage(rotation=1)";-webkit-transform:rotate(90deg);-ms-transform:rotate(90deg);transform:rotate(90deg)}.fa-rotate-180{-ms-filter:"progid:DXImageTransform.Microsoft.BasicImage(rotation=2)";-webkit-transform:rotate(180deg);-ms-transform:rotate(180deg);transform:rotate(180deg)}.fa-rotate-270{-ms-filter:"progid:DXImageTransform.Microsoft.BasicImage(rotation=3)";-webkit-transform:rotate(270deg);-ms-transform:rotate(270deg);transform:rotate(270deg)}.fa-flip-horizontal{-ms-filter:"progid:DXImageTransform.Microsoft.BasicImage(rotation=0, mirror=1)";-webkit-transform:scaleX(-1);-ms-transform:scaleX(-1);transform:scaleX(-1)}.fa-flip-vertical{-ms-filter:"progid:DXImageTransform.Microsoft.BasicImage(rotation=2, mirror=1)";-webkit-transform:scaleY(-1);-ms-transform:scaleY(-1);transform:scaleY(-1)}:root .fa-flip-horizontal,:root .fa-flip-vertical,:root .fa-rotate-90,:root .fa-rotate-180,:root .fa-rotate-270{filter:none}.fa-stack{position:relative;display:inline-block;width:2em;height:2em;line-height:2em;vertical-align:middle}.fa-stack-1x,.fa-stack-2x{position:absolute;left:0;width:100%;text-align:center}.fa-stack-1x{line-height:inherit}.fa-stack-2x{font-size:2em}.fa-inverse{color:#fff}.fa-glass:before{content:""}.fa-music:before{content:""}.fa-search:before,.icon-search:before{content:""}.fa-envelope-o:before{content:""}.fa-heart:before{content:""}.fa-star:before{content:""}.fa-star-o:before{content:""}.fa-user:before{content:""}.fa-film:before{content:""}.fa-th-large:before{content:""}.fa-th:before{content:""}.fa-th-list:before{content:""}.fa-check:before{content:""}.fa-close:before,.fa-remove:before,.fa-times:before{content:""}.fa-search-plus:before{content:""}.fa-search-minus:before{content:""}.fa-power-off:before{content:""}.fa-signal:before{content:""}.fa-cog:before,.fa-gear:before{content:""}.fa-trash-o:before{content:""}.fa-home:before,.icon-home:before{content:""}.fa-file-o:before{content:""}.fa-clock-o:before{content:""}.fa-road:before{content:""}.fa-download:before,.rst-content code.download span:first-child:before,.rst-content tt.download span:first-child:before{content:""}.fa-arrow-circle-o-down:before{content:""}.fa-arrow-circle-o-up:before{content:""}.fa-inbox:before{content:""}.fa-play-circle-o:before{content:""}.fa-repeat:before,.fa-rotate-right:before{content:""}.fa-refresh:before{content:""}.fa-list-alt:before{content:""}.fa-lock:before{content:""}.fa-flag:before{content:""}.fa-headphones:before{content:""}.fa-volume-off:before{content:""}.fa-volume-down:before{content:""}.fa-volume-up:before{content:""}.fa-qrcode:before{content:""}.fa-barcode:before{content:""}.fa-tag:before{content:""}.fa-tags:before{content:""}.fa-book:before,.icon-book:before{content:""}.fa-bookmark:before{content:""}.fa-print:before{content:""}.fa-camera:before{content:""}.fa-font:before{content:""}.fa-bold:before{content:""}.fa-italic:before{content:""}.fa-text-height:before{content:""}.fa-text-width:before{content:""}.fa-align-left:before{content:""}.fa-align-center:before{content:""}.fa-align-right:before{content:""}.fa-align-justify:before{content:""}.fa-list:before{content:""}.fa-dedent:before,.fa-outdent:before{content:""}.fa-indent:before{content:""}.fa-video-camera:before{content:""}.fa-image:before,.fa-photo:before,.fa-picture-o:before{content:""}.fa-pencil:before{content:""}.fa-map-marker:before{content:""}.fa-adjust:before{content:""}.fa-tint:before{content:""}.fa-edit:before,.fa-pencil-square-o:before{content:""}.fa-share-square-o:before{content:""}.fa-check-square-o:before{content:""}.fa-arrows:before{content:""}.fa-step-backward:before{content:""}.fa-fast-backward:before{content:""}.fa-backward:before{content:""}.fa-play:before{content:""}.fa-pause:before{content:""}.fa-stop:before{content:""}.fa-forward:before{content:""}.fa-fast-forward:before{content:""}.fa-step-forward:before{content:""}.fa-eject:before{content:""}.fa-chevron-left:before{content:""}.fa-chevron-right:before{content:""}.fa-plus-circle:before{content:""}.fa-minus-circle:before{content:""}.fa-times-circle:before,.wy-inline-validate.wy-inline-validate-danger .wy-input-context:before{content:""}.fa-check-circle:before,.wy-inline-validate.wy-inline-validate-success .wy-input-context:before{content:""}.fa-question-circle:before{content:""}.fa-info-circle:before{content:""}.fa-crosshairs:before{content:""}.fa-times-circle-o:before{content:""}.fa-check-circle-o:before{content:""}.fa-ban:before{content:""}.fa-arrow-left:before{content:""}.fa-arrow-right:before{content:""}.fa-arrow-up:before{content:""}.fa-arrow-down:before{content:""}.fa-mail-forward:before,.fa-share:before{content:""}.fa-expand:before{content:""}.fa-compress:before{content:""}.fa-plus:before{content:""}.fa-minus:before{content:""}.fa-asterisk:before{content:""}.fa-exclamation-circle:before,.rst-content .admonition-title:before,.wy-inline-validate.wy-inline-validate-info .wy-input-context:before,.wy-inline-validate.wy-inline-validate-warning .wy-input-context:before{content:""}.fa-gift:before{content:""}.fa-leaf:before{content:""}.fa-fire:before,.icon-fire:before{content:""}.fa-eye:before{content:""}.fa-eye-slash:before{content:""}.fa-exclamation-triangle:before,.fa-warning:before{content:""}.fa-plane:before{content:""}.fa-calendar:before{content:""}.fa-random:before{content:""}.fa-comment:before{content:""}.fa-magnet:before{content:""}.fa-chevron-up:before{content:""}.fa-chevron-down:before{content:""}.fa-retweet:before{content:""}.fa-shopping-cart:before{content:""}.fa-folder:before{content:""}.fa-folder-open:before{content:""}.fa-arrows-v:before{content:""}.fa-arrows-h:before{content:""}.fa-bar-chart-o:before,.fa-bar-chart:before{content:""}.fa-twitter-square:before{content:""}.fa-facebook-square:before{content:""}.fa-camera-retro:before{content:""}.fa-key:before{content:""}.fa-cogs:before,.fa-gears:before{content:""}.fa-comments:before{content:""}.fa-thumbs-o-up:before{content:""}.fa-thumbs-o-down:before{content:""}.fa-star-half:before{content:""}.fa-heart-o:before{content:""}.fa-sign-out:before{content:""}.fa-linkedin-square:before{content:""}.fa-thumb-tack:before{content:""}.fa-external-link:before{content:""}.fa-sign-in:before{content:""}.fa-trophy:before{content:""}.fa-github-square:before{content:""}.fa-upload:before{content:""}.fa-lemon-o:before{content:""}.fa-phone:before{content:""}.fa-square-o:before{content:""}.fa-bookmark-o:before{content:""}.fa-phone-square:before{content:""}.fa-twitter:before{content:""}.fa-facebook-f:before,.fa-facebook:before{content:""}.fa-github:before,.icon-github:before{content:""}.fa-unlock:before{content:""}.fa-credit-card:before{content:""}.fa-feed:before,.fa-rss:before{content:""}.fa-hdd-o:before{content:""}.fa-bullhorn:before{content:""}.fa-bell:before{content:""}.fa-certificate:before{content:""}.fa-hand-o-right:before{content:""}.fa-hand-o-left:before{content:""}.fa-hand-o-up:before{content:""}.fa-hand-o-down:before{content:""}.fa-arrow-circle-left:before,.icon-circle-arrow-left:before{content:""}.fa-arrow-circle-right:before,.icon-circle-arrow-right:before{content:""}.fa-arrow-circle-up:before{content:""}.fa-arrow-circle-down:before{content:""}.fa-globe:before{content:""}.fa-wrench:before{content:""}.fa-tasks:before{content:""}.fa-filter:before{content:""}.fa-briefcase:before{content:""}.fa-arrows-alt:before{content:""}.fa-group:before,.fa-users:before{content:""}.fa-chain:before,.fa-link:before,.icon-link:before{content:""}.fa-cloud:before{content:""}.fa-flask:before{content:""}.fa-cut:before,.fa-scissors:before{content:""}.fa-copy:before,.fa-files-o:before{content:""}.fa-paperclip:before{content:""}.fa-floppy-o:before,.fa-save:before{content:""}.fa-square:before{content:""}.fa-bars:before,.fa-navicon:before,.fa-reorder:before{content:""}.fa-list-ul:before{content:""}.fa-list-ol:before{content:""}.fa-strikethrough:before{content:""}.fa-underline:before{content:""}.fa-table:before{content:""}.fa-magic:before{content:""}.fa-truck:before{content:""}.fa-pinterest:before{content:""}.fa-pinterest-square:before{content:""}.fa-google-plus-square:before{content:""}.fa-google-plus:before{content:""}.fa-money:before{content:""}.fa-caret-down:before,.icon-caret-down:before,.wy-dropdown .caret:before{content:""}.fa-caret-up:before{content:""}.fa-caret-left:before{content:""}.fa-caret-right:before{content:""}.fa-columns:before{content:""}.fa-sort:before,.fa-unsorted:before{content:""}.fa-sort-desc:before,.fa-sort-down:before{content:""}.fa-sort-asc:before,.fa-sort-up:before{content:""}.fa-envelope:before{content:""}.fa-linkedin:before{content:""}.fa-rotate-left:before,.fa-undo:before{content:""}.fa-gavel:before,.fa-legal:before{content:""}.fa-dashboard:before,.fa-tachometer:before{content:""}.fa-comment-o:before{content:""}.fa-comments-o:before{content:""}.fa-bolt:before,.fa-flash:before{content:""}.fa-sitemap:before{content:""}.fa-umbrella:before{content:""}.fa-clipboard:before,.fa-paste:before{content:""}.fa-lightbulb-o:before{content:""}.fa-exchange:before{content:""}.fa-cloud-download:before{content:""}.fa-cloud-upload:before{content:""}.fa-user-md:before{content:""}.fa-stethoscope:before{content:""}.fa-suitcase:before{content:""}.fa-bell-o:before{content:""}.fa-coffee:before{content:""}.fa-cutlery:before{content:""}.fa-file-text-o:before{content:""}.fa-building-o:before{content:""}.fa-hospital-o:before{content:""}.fa-ambulance:before{content:""}.fa-medkit:before{content:""}.fa-fighter-jet:before{content:""}.fa-beer:before{content:""}.fa-h-square:before{content:""}.fa-plus-square:before{content:""}.fa-angle-double-left:before{content:""}.fa-angle-double-right:before{content:""}.fa-angle-double-up:before{content:""}.fa-angle-double-down:before{content:""}.fa-angle-left:before{content:""}.fa-angle-right:before{content:""}.fa-angle-up:before{content:""}.fa-angle-down:before{content:""}.fa-desktop:before{content:""}.fa-laptop:before{content:""}.fa-tablet:before{content:""}.fa-mobile-phone:before,.fa-mobile:before{content:""}.fa-circle-o:before{content:""}.fa-quote-left:before{content:""}.fa-quote-right:before{content:""}.fa-spinner:before{content:""}.fa-circle:before{content:""}.fa-mail-reply:before,.fa-reply:before{content:""}.fa-github-alt:before{content:""}.fa-folder-o:before{content:""}.fa-folder-open-o:before{content:""}.fa-smile-o:before{content:""}.fa-frown-o:before{content:""}.fa-meh-o:before{content:""}.fa-gamepad:before{content:""}.fa-keyboard-o:before{content:""}.fa-flag-o:before{content:""}.fa-flag-checkered:before{content:""}.fa-terminal:before{content:""}.fa-code:before{content:""}.fa-mail-reply-all:before,.fa-reply-all:before{content:""}.fa-star-half-empty:before,.fa-star-half-full:before,.fa-star-half-o:before{content:""}.fa-location-arrow:before{content:""}.fa-crop:before{content:""}.fa-code-fork:before{content:""}.fa-chain-broken:before,.fa-unlink:before{content:""}.fa-question:before{content:""}.fa-info:before{content:""}.fa-exclamation:before{content:""}.fa-superscript:before{content:""}.fa-subscript:before{content:""}.fa-eraser:before{content:""}.fa-puzzle-piece:before{content:""}.fa-microphone:before{content:""}.fa-microphone-slash:before{content:""}.fa-shield:before{content:""}.fa-calendar-o:before{content:""}.fa-fire-extinguisher:before{content:""}.fa-rocket:before{content:""}.fa-maxcdn:before{content:""}.fa-chevron-circle-left:before{content:""}.fa-chevron-circle-right:before{content:""}.fa-chevron-circle-up:before{content:""}.fa-chevron-circle-down:before{content:""}.fa-html5:before{content:""}.fa-css3:before{content:""}.fa-anchor:before{content:""}.fa-unlock-alt:before{content:""}.fa-bullseye:before{content:""}.fa-ellipsis-h:before{content:""}.fa-ellipsis-v:before{content:""}.fa-rss-square:before{content:""}.fa-play-circle:before{content:""}.fa-ticket:before{content:""}.fa-minus-square:before{content:""}.fa-minus-square-o:before,.wy-menu-vertical li.current>a button.toctree-expand:before,.wy-menu-vertical li.on a button.toctree-expand:before{content:""}.fa-level-up:before{content:""}.fa-level-down:before{content:""}.fa-check-square:before{content:""}.fa-pencil-square:before{content:""}.fa-external-link-square:before{content:""}.fa-share-square:before{content:""}.fa-compass:before{content:""}.fa-caret-square-o-down:before,.fa-toggle-down:before{content:""}.fa-caret-square-o-up:before,.fa-toggle-up:before{content:""}.fa-caret-square-o-right:before,.fa-toggle-right:before{content:""}.fa-eur:before,.fa-euro:before{content:""}.fa-gbp:before{content:""}.fa-dollar:before,.fa-usd:before{content:""}.fa-inr:before,.fa-rupee:before{content:""}.fa-cny:before,.fa-jpy:before,.fa-rmb:before,.fa-yen:before{content:""}.fa-rouble:before,.fa-rub:before,.fa-ruble:before{content:""}.fa-krw:before,.fa-won:before{content:""}.fa-bitcoin:before,.fa-btc:before{content:""}.fa-file:before{content:""}.fa-file-text:before{content:""}.fa-sort-alpha-asc:before{content:""}.fa-sort-alpha-desc:before{content:""}.fa-sort-amount-asc:before{content:""}.fa-sort-amount-desc:before{content:""}.fa-sort-numeric-asc:before{content:""}.fa-sort-numeric-desc:before{content:""}.fa-thumbs-up:before{content:""}.fa-thumbs-down:before{content:""}.fa-youtube-square:before{content:""}.fa-youtube:before{content:""}.fa-xing:before{content:""}.fa-xing-square:before{content:""}.fa-youtube-play:before{content:""}.fa-dropbox:before{content:""}.fa-stack-overflow:before{content:""}.fa-instagram:before{content:""}.fa-flickr:before{content:""}.fa-adn:before{content:""}.fa-bitbucket:before,.icon-bitbucket:before{content:""}.fa-bitbucket-square:before{content:""}.fa-tumblr:before{content:""}.fa-tumblr-square:before{content:""}.fa-long-arrow-down:before{content:""}.fa-long-arrow-up:before{content:""}.fa-long-arrow-left:before{content:""}.fa-long-arrow-right:before{content:""}.fa-apple:before{content:""}.fa-windows:before{content:""}.fa-android:before{content:""}.fa-linux:before{content:""}.fa-dribbble:before{content:""}.fa-skype:before{content:""}.fa-foursquare:before{content:""}.fa-trello:before{content:""}.fa-female:before{content:""}.fa-male:before{content:""}.fa-gittip:before,.fa-gratipay:before{content:""}.fa-sun-o:before{content:""}.fa-moon-o:before{content:""}.fa-archive:before{content:""}.fa-bug:before{content:""}.fa-vk:before{content:""}.fa-weibo:before{content:""}.fa-renren:before{content:""}.fa-pagelines:before{content:""}.fa-stack-exchange:before{content:""}.fa-arrow-circle-o-right:before{content:""}.fa-arrow-circle-o-left:before{content:""}.fa-caret-square-o-left:before,.fa-toggle-left:before{content:""}.fa-dot-circle-o:before{content:""}.fa-wheelchair:before{content:""}.fa-vimeo-square:before{content:""}.fa-try:before,.fa-turkish-lira:before{content:""}.fa-plus-square-o:before,.wy-menu-vertical li button.toctree-expand:before{content:""}.fa-space-shuttle:before{content:""}.fa-slack:before{content:""}.fa-envelope-square:before{content:""}.fa-wordpress:before{content:""}.fa-openid:before{content:""}.fa-bank:before,.fa-institution:before,.fa-university:before{content:""}.fa-graduation-cap:before,.fa-mortar-board:before{content:""}.fa-yahoo:before{content:""}.fa-google:before{content:""}.fa-reddit:before{content:""}.fa-reddit-square:before{content:""}.fa-stumbleupon-circle:before{content:""}.fa-stumbleupon:before{content:""}.fa-delicious:before{content:""}.fa-digg:before{content:""}.fa-pied-piper-pp:before{content:""}.fa-pied-piper-alt:before{content:""}.fa-drupal:before{content:""}.fa-joomla:before{content:""}.fa-language:before{content:""}.fa-fax:before{content:""}.fa-building:before{content:""}.fa-child:before{content:""}.fa-paw:before{content:""}.fa-spoon:before{content:""}.fa-cube:before{content:""}.fa-cubes:before{content:""}.fa-behance:before{content:""}.fa-behance-square:before{content:""}.fa-steam:before{content:""}.fa-steam-square:before{content:""}.fa-recycle:before{content:""}.fa-automobile:before,.fa-car:before{content:""}.fa-cab:before,.fa-taxi:before{content:""}.fa-tree:before{content:""}.fa-spotify:before{content:""}.fa-deviantart:before{content:""}.fa-soundcloud:before{content:""}.fa-database:before{content:""}.fa-file-pdf-o:before{content:""}.fa-file-word-o:before{content:""}.fa-file-excel-o:before{content:""}.fa-file-powerpoint-o:before{content:""}.fa-file-image-o:before,.fa-file-photo-o:before,.fa-file-picture-o:before{content:""}.fa-file-archive-o:before,.fa-file-zip-o:before{content:""}.fa-file-audio-o:before,.fa-file-sound-o:before{content:""}.fa-file-movie-o:before,.fa-file-video-o:before{content:""}.fa-file-code-o:before{content:""}.fa-vine:before{content:""}.fa-codepen:before{content:""}.fa-jsfiddle:before{content:""}.fa-life-bouy:before,.fa-life-buoy:before,.fa-life-ring:before,.fa-life-saver:before,.fa-support:before{content:""}.fa-circle-o-notch:before{content:""}.fa-ra:before,.fa-rebel:before,.fa-resistance:before{content:""}.fa-empire:before,.fa-ge:before{content:""}.fa-git-square:before{content:""}.fa-git:before{content:""}.fa-hacker-news:before,.fa-y-combinator-square:before,.fa-yc-square:before{content:""}.fa-tencent-weibo:before{content:""}.fa-qq:before{content:""}.fa-wechat:before,.fa-weixin:before{content:""}.fa-paper-plane:before,.fa-send:before{content:""}.fa-paper-plane-o:before,.fa-send-o:before{content:""}.fa-history:before{content:""}.fa-circle-thin:before{content:""}.fa-header:before{content:""}.fa-paragraph:before{content:""}.fa-sliders:before{content:""}.fa-share-alt:before{content:""}.fa-share-alt-square:before{content:""}.fa-bomb:before{content:""}.fa-futbol-o:before,.fa-soccer-ball-o:before{content:""}.fa-tty:before{content:""}.fa-binoculars:before{content:""}.fa-plug:before{content:""}.fa-slideshare:before{content:""}.fa-twitch:before{content:""}.fa-yelp:before{content:""}.fa-newspaper-o:before{content:""}.fa-wifi:before{content:""}.fa-calculator:before{content:""}.fa-paypal:before{content:""}.fa-google-wallet:before{content:""}.fa-cc-visa:before{content:""}.fa-cc-mastercard:before{content:""}.fa-cc-discover:before{content:""}.fa-cc-amex:before{content:""}.fa-cc-paypal:before{content:""}.fa-cc-stripe:before{content:""}.fa-bell-slash:before{content:""}.fa-bell-slash-o:before{content:""}.fa-trash:before{content:""}.fa-copyright:before{content:""}.fa-at:before{content:""}.fa-eyedropper:before{content:""}.fa-paint-brush:before{content:""}.fa-birthday-cake:before{content:""}.fa-area-chart:before{content:""}.fa-pie-chart:before{content:""}.fa-line-chart:before{content:""}.fa-lastfm:before{content:""}.fa-lastfm-square:before{content:""}.fa-toggle-off:before{content:""}.fa-toggle-on:before{content:""}.fa-bicycle:before{content:""}.fa-bus:before{content:""}.fa-ioxhost:before{content:""}.fa-angellist:before{content:""}.fa-cc:before{content:""}.fa-ils:before,.fa-shekel:before,.fa-sheqel:before{content:""}.fa-meanpath:before{content:""}.fa-buysellads:before{content:""}.fa-connectdevelop:before{content:""}.fa-dashcube:before{content:""}.fa-forumbee:before{content:""}.fa-leanpub:before{content:""}.fa-sellsy:before{content:""}.fa-shirtsinbulk:before{content:""}.fa-simplybuilt:before{content:""}.fa-skyatlas:before{content:""}.fa-cart-plus:before{content:""}.fa-cart-arrow-down:before{content:""}.fa-diamond:before{content:""}.fa-ship:before{content:""}.fa-user-secret:before{content:""}.fa-motorcycle:before{content:""}.fa-street-view:before{content:""}.fa-heartbeat:before{content:""}.fa-venus:before{content:""}.fa-mars:before{content:""}.fa-mercury:before{content:""}.fa-intersex:before,.fa-transgender:before{content:""}.fa-transgender-alt:before{content:""}.fa-venus-double:before{content:""}.fa-mars-double:before{content:""}.fa-venus-mars:before{content:""}.fa-mars-stroke:before{content:""}.fa-mars-stroke-v:before{content:""}.fa-mars-stroke-h:before{content:""}.fa-neuter:before{content:""}.fa-genderless:before{content:""}.fa-facebook-official:before{content:""}.fa-pinterest-p:before{content:""}.fa-whatsapp:before{content:""}.fa-server:before{content:""}.fa-user-plus:before{content:""}.fa-user-times:before{content:""}.fa-bed:before,.fa-hotel:before{content:""}.fa-viacoin:before{content:""}.fa-train:before{content:""}.fa-subway:before{content:""}.fa-medium:before{content:""}.fa-y-combinator:before,.fa-yc:before{content:""}.fa-optin-monster:before{content:""}.fa-opencart:before{content:""}.fa-expeditedssl:before{content:""}.fa-battery-4:before,.fa-battery-full:before,.fa-battery:before{content:""}.fa-battery-3:before,.fa-battery-three-quarters:before{content:""}.fa-battery-2:before,.fa-battery-half:before{content:""}.fa-battery-1:before,.fa-battery-quarter:before{content:""}.fa-battery-0:before,.fa-battery-empty:before{content:""}.fa-mouse-pointer:before{content:""}.fa-i-cursor:before{content:""}.fa-object-group:before{content:""}.fa-object-ungroup:before{content:""}.fa-sticky-note:before{content:""}.fa-sticky-note-o:before{content:""}.fa-cc-jcb:before{content:""}.fa-cc-diners-club:before{content:""}.fa-clone:before{content:""}.fa-balance-scale:before{content:""}.fa-hourglass-o:before{content:""}.fa-hourglass-1:before,.fa-hourglass-start:before{content:""}.fa-hourglass-2:before,.fa-hourglass-half:before{content:""}.fa-hourglass-3:before,.fa-hourglass-end:before{content:""}.fa-hourglass:before{content:""}.fa-hand-grab-o:before,.fa-hand-rock-o:before{content:""}.fa-hand-paper-o:before,.fa-hand-stop-o:before{content:""}.fa-hand-scissors-o:before{content:""}.fa-hand-lizard-o:before{content:""}.fa-hand-spock-o:before{content:""}.fa-hand-pointer-o:before{content:""}.fa-hand-peace-o:before{content:""}.fa-trademark:before{content:""}.fa-registered:before{content:""}.fa-creative-commons:before{content:""}.fa-gg:before{content:""}.fa-gg-circle:before{content:""}.fa-tripadvisor:before{content:""}.fa-odnoklassniki:before{content:""}.fa-odnoklassniki-square:before{content:""}.fa-get-pocket:before{content:""}.fa-wikipedia-w:before{content:""}.fa-safari:before{content:""}.fa-chrome:before{content:""}.fa-firefox:before{content:""}.fa-opera:before{content:""}.fa-internet-explorer:before{content:""}.fa-television:before,.fa-tv:before{content:""}.fa-contao:before{content:""}.fa-500px:before{content:""}.fa-amazon:before{content:""}.fa-calendar-plus-o:before{content:""}.fa-calendar-minus-o:before{content:""}.fa-calendar-times-o:before{content:""}.fa-calendar-check-o:before{content:""}.fa-industry:before{content:""}.fa-map-pin:before{content:""}.fa-map-signs:before{content:""}.fa-map-o:before{content:""}.fa-map:before{content:""}.fa-commenting:before{content:""}.fa-commenting-o:before{content:""}.fa-houzz:before{content:""}.fa-vimeo:before{content:""}.fa-black-tie:before{content:""}.fa-fonticons:before{content:""}.fa-reddit-alien:before{content:""}.fa-edge:before{content:""}.fa-credit-card-alt:before{content:""}.fa-codiepie:before{content:""}.fa-modx:before{content:""}.fa-fort-awesome:before{content:""}.fa-usb:before{content:""}.fa-product-hunt:before{content:""}.fa-mixcloud:before{content:""}.fa-scribd:before{content:""}.fa-pause-circle:before{content:""}.fa-pause-circle-o:before{content:""}.fa-stop-circle:before{content:""}.fa-stop-circle-o:before{content:""}.fa-shopping-bag:before{content:""}.fa-shopping-basket:before{content:""}.fa-hashtag:before{content:""}.fa-bluetooth:before{content:""}.fa-bluetooth-b:before{content:""}.fa-percent:before{content:""}.fa-gitlab:before,.icon-gitlab:before{content:""}.fa-wpbeginner:before{content:""}.fa-wpforms:before{content:""}.fa-envira:before{content:""}.fa-universal-access:before{content:""}.fa-wheelchair-alt:before{content:""}.fa-question-circle-o:before{content:""}.fa-blind:before{content:""}.fa-audio-description:before{content:""}.fa-volume-control-phone:before{content:""}.fa-braille:before{content:""}.fa-assistive-listening-systems:before{content:""}.fa-american-sign-language-interpreting:before,.fa-asl-interpreting:before{content:""}.fa-deaf:before,.fa-deafness:before,.fa-hard-of-hearing:before{content:""}.fa-glide:before{content:""}.fa-glide-g:before{content:""}.fa-sign-language:before,.fa-signing:before{content:""}.fa-low-vision:before{content:""}.fa-viadeo:before{content:""}.fa-viadeo-square:before{content:""}.fa-snapchat:before{content:""}.fa-snapchat-ghost:before{content:""}.fa-snapchat-square:before{content:""}.fa-pied-piper:before{content:""}.fa-first-order:before{content:""}.fa-yoast:before{content:""}.fa-themeisle:before{content:""}.fa-google-plus-circle:before,.fa-google-plus-official:before{content:""}.fa-fa:before,.fa-font-awesome:before{content:""}.fa-handshake-o:before{content:""}.fa-envelope-open:before{content:""}.fa-envelope-open-o:before{content:""}.fa-linode:before{content:""}.fa-address-book:before{content:""}.fa-address-book-o:before{content:""}.fa-address-card:before,.fa-vcard:before{content:""}.fa-address-card-o:before,.fa-vcard-o:before{content:""}.fa-user-circle:before{content:""}.fa-user-circle-o:before{content:""}.fa-user-o:before{content:""}.fa-id-badge:before{content:""}.fa-drivers-license:before,.fa-id-card:before{content:""}.fa-drivers-license-o:before,.fa-id-card-o:before{content:""}.fa-quora:before{content:""}.fa-free-code-camp:before{content:""}.fa-telegram:before{content:""}.fa-thermometer-4:before,.fa-thermometer-full:before,.fa-thermometer:before{content:""}.fa-thermometer-3:before,.fa-thermometer-three-quarters:before{content:""}.fa-thermometer-2:before,.fa-thermometer-half:before{content:""}.fa-thermometer-1:before,.fa-thermometer-quarter:before{content:""}.fa-thermometer-0:before,.fa-thermometer-empty:before{content:""}.fa-shower:before{content:""}.fa-bath:before,.fa-bathtub:before,.fa-s15:before{content:""}.fa-podcast:before{content:""}.fa-window-maximize:before{content:""}.fa-window-minimize:before{content:""}.fa-window-restore:before{content:""}.fa-times-rectangle:before,.fa-window-close:before{content:""}.fa-times-rectangle-o:before,.fa-window-close-o:before{content:""}.fa-bandcamp:before{content:""}.fa-grav:before{content:""}.fa-etsy:before{content:""}.fa-imdb:before{content:""}.fa-ravelry:before{content:""}.fa-eercast:before{content:""}.fa-microchip:before{content:""}.fa-snowflake-o:before{content:""}.fa-superpowers:before{content:""}.fa-wpexplorer:before{content:""}.fa-meetup:before{content:""}.sr-only{position:absolute;width:1px;height:1px;padding:0;margin:-1px;overflow:hidden;clip:rect(0,0,0,0);border:0}.sr-only-focusable:active,.sr-only-focusable:focus{position:static;width:auto;height:auto;margin:0;overflow:visible;clip:auto}.fa,.icon,.rst-content .admonition-title,.rst-content .code-block-caption .headerlink,.rst-content .eqno .headerlink,.rst-content code.download span:first-child,.rst-content dl dt .headerlink,.rst-content h1 .headerlink,.rst-content h2 .headerlink,.rst-content h3 .headerlink,.rst-content h4 .headerlink,.rst-content h5 .headerlink,.rst-content h6 .headerlink,.rst-content p.caption .headerlink,.rst-content p .headerlink,.rst-content table>caption .headerlink,.rst-content tt.download span:first-child,.wy-dropdown .caret,.wy-inline-validate.wy-inline-validate-danger .wy-input-context,.wy-inline-validate.wy-inline-validate-info .wy-input-context,.wy-inline-validate.wy-inline-validate-success .wy-input-context,.wy-inline-validate.wy-inline-validate-warning .wy-input-context,.wy-menu-vertical li.current>a button.toctree-expand,.wy-menu-vertical li.on a button.toctree-expand,.wy-menu-vertical li button.toctree-expand{font-family:inherit}.fa:before,.icon:before,.rst-content .admonition-title:before,.rst-content .code-block-caption .headerlink:before,.rst-content .eqno .headerlink:before,.rst-content code.download span:first-child:before,.rst-content dl dt .headerlink:before,.rst-content h1 .headerlink:before,.rst-content h2 .headerlink:before,.rst-content h3 .headerlink:before,.rst-content h4 .headerlink:before,.rst-content h5 .headerlink:before,.rst-content h6 .headerlink:before,.rst-content p.caption .headerlink:before,.rst-content p .headerlink:before,.rst-content table>caption .headerlink:before,.rst-content tt.download span:first-child:before,.wy-dropdown .caret:before,.wy-inline-validate.wy-inline-validate-danger .wy-input-context:before,.wy-inline-validate.wy-inline-validate-info .wy-input-context:before,.wy-inline-validate.wy-inline-validate-success .wy-input-context:before,.wy-inline-validate.wy-inline-validate-warning .wy-input-context:before,.wy-menu-vertical li.current>a button.toctree-expand:before,.wy-menu-vertical li.on a button.toctree-expand:before,.wy-menu-vertical li button.toctree-expand:before{font-family:FontAwesome;display:inline-block;font-style:normal;font-weight:400;line-height:1;text-decoration:inherit}.rst-content .code-block-caption a .headerlink,.rst-content .eqno a .headerlink,.rst-content a .admonition-title,.rst-content code.download a span:first-child,.rst-content dl dt a .headerlink,.rst-content h1 a .headerlink,.rst-content h2 a .headerlink,.rst-content h3 a .headerlink,.rst-content h4 a .headerlink,.rst-content h5 a .headerlink,.rst-content h6 a .headerlink,.rst-content p.caption a .headerlink,.rst-content p a .headerlink,.rst-content table>caption a .headerlink,.rst-content tt.download a span:first-child,.wy-menu-vertical li.current>a button.toctree-expand,.wy-menu-vertical li.on a button.toctree-expand,.wy-menu-vertical li a button.toctree-expand,a .fa,a .icon,a .rst-content .admonition-title,a .rst-content .code-block-caption .headerlink,a .rst-content .eqno .headerlink,a .rst-content code.download span:first-child,a .rst-content dl dt .headerlink,a .rst-content h1 .headerlink,a .rst-content h2 .headerlink,a .rst-content h3 .headerlink,a .rst-content h4 .headerlink,a .rst-content h5 .headerlink,a .rst-content h6 .headerlink,a .rst-content p.caption .headerlink,a .rst-content p .headerlink,a .rst-content table>caption .headerlink,a .rst-content tt.download span:first-child,a .wy-menu-vertical li button.toctree-expand{display:inline-block;text-decoration:inherit}.btn .fa,.btn .icon,.btn .rst-content .admonition-title,.btn .rst-content .code-block-caption .headerlink,.btn .rst-content .eqno .headerlink,.btn .rst-content code.download span:first-child,.btn .rst-content dl dt .headerlink,.btn .rst-content h1 .headerlink,.btn .rst-content h2 .headerlink,.btn .rst-content h3 .headerlink,.btn .rst-content h4 .headerlink,.btn .rst-content h5 .headerlink,.btn .rst-content h6 .headerlink,.btn .rst-content p .headerlink,.btn .rst-content table>caption .headerlink,.btn .rst-content tt.download span:first-child,.btn .wy-menu-vertical li.current>a button.toctree-expand,.btn .wy-menu-vertical li.on a button.toctree-expand,.btn .wy-menu-vertical li button.toctree-expand,.nav .fa,.nav .icon,.nav .rst-content .admonition-title,.nav .rst-content .code-block-caption .headerlink,.nav .rst-content .eqno .headerlink,.nav .rst-content code.download span:first-child,.nav .rst-content dl dt .headerlink,.nav .rst-content h1 .headerlink,.nav .rst-content h2 .headerlink,.nav .rst-content h3 .headerlink,.nav .rst-content h4 .headerlink,.nav .rst-content h5 .headerlink,.nav .rst-content h6 .headerlink,.nav .rst-content p .headerlink,.nav .rst-content table>caption .headerlink,.nav .rst-content tt.download span:first-child,.nav .wy-menu-vertical li.current>a button.toctree-expand,.nav .wy-menu-vertical li.on a button.toctree-expand,.nav .wy-menu-vertical li button.toctree-expand,.rst-content .btn .admonition-title,.rst-content .code-block-caption .btn .headerlink,.rst-content .code-block-caption .nav .headerlink,.rst-content .eqno .btn .headerlink,.rst-content .eqno .nav .headerlink,.rst-content .nav .admonition-title,.rst-content code.download .btn span:first-child,.rst-content code.download .nav span:first-child,.rst-content dl dt .btn .headerlink,.rst-content dl dt .nav .headerlink,.rst-content h1 .btn .headerlink,.rst-content h1 .nav .headerlink,.rst-content h2 .btn .headerlink,.rst-content h2 .nav .headerlink,.rst-content h3 .btn .headerlink,.rst-content h3 .nav .headerlink,.rst-content h4 .btn .headerlink,.rst-content h4 .nav .headerlink,.rst-content h5 .btn .headerlink,.rst-content h5 .nav .headerlink,.rst-content h6 .btn .headerlink,.rst-content h6 .nav .headerlink,.rst-content p .btn .headerlink,.rst-content p .nav .headerlink,.rst-content table>caption .btn .headerlink,.rst-content table>caption .nav .headerlink,.rst-content tt.download .btn span:first-child,.rst-content tt.download .nav span:first-child,.wy-menu-vertical li .btn button.toctree-expand,.wy-menu-vertical li.current>a .btn button.toctree-expand,.wy-menu-vertical li.current>a .nav button.toctree-expand,.wy-menu-vertical li .nav button.toctree-expand,.wy-menu-vertical li.on a .btn button.toctree-expand,.wy-menu-vertical li.on a .nav button.toctree-expand{display:inline}.btn .fa-large.icon,.btn .fa.fa-large,.btn .rst-content .code-block-caption .fa-large.headerlink,.btn .rst-content .eqno .fa-large.headerlink,.btn .rst-content .fa-large.admonition-title,.btn .rst-content code.download span.fa-large:first-child,.btn .rst-content dl dt .fa-large.headerlink,.btn .rst-content h1 .fa-large.headerlink,.btn .rst-content h2 .fa-large.headerlink,.btn .rst-content h3 .fa-large.headerlink,.btn .rst-content h4 .fa-large.headerlink,.btn .rst-content h5 .fa-large.headerlink,.btn .rst-content h6 .fa-large.headerlink,.btn .rst-content p .fa-large.headerlink,.btn .rst-content table>caption .fa-large.headerlink,.btn .rst-content tt.download span.fa-large:first-child,.btn .wy-menu-vertical li button.fa-large.toctree-expand,.nav .fa-large.icon,.nav .fa.fa-large,.nav .rst-content .code-block-caption .fa-large.headerlink,.nav .rst-content .eqno .fa-large.headerlink,.nav .rst-content .fa-large.admonition-title,.nav .rst-content code.download span.fa-large:first-child,.nav .rst-content dl dt .fa-large.headerlink,.nav .rst-content h1 .fa-large.headerlink,.nav .rst-content h2 .fa-large.headerlink,.nav .rst-content h3 .fa-large.headerlink,.nav .rst-content h4 .fa-large.headerlink,.nav .rst-content h5 .fa-large.headerlink,.nav .rst-content h6 .fa-large.headerlink,.nav .rst-content p .fa-large.headerlink,.nav .rst-content table>caption .fa-large.headerlink,.nav .rst-content tt.download span.fa-large:first-child,.nav .wy-menu-vertical li button.fa-large.toctree-expand,.rst-content .btn .fa-large.admonition-title,.rst-content .code-block-caption .btn .fa-large.headerlink,.rst-content .code-block-caption .nav .fa-large.headerlink,.rst-content .eqno .btn .fa-large.headerlink,.rst-content .eqno .nav .fa-large.headerlink,.rst-content .nav .fa-large.admonition-title,.rst-content code.download .btn span.fa-large:first-child,.rst-content code.download .nav span.fa-large:first-child,.rst-content dl dt .btn .fa-large.headerlink,.rst-content dl dt .nav .fa-large.headerlink,.rst-content h1 .btn .fa-large.headerlink,.rst-content h1 .nav .fa-large.headerlink,.rst-content h2 .btn .fa-large.headerlink,.rst-content h2 .nav .fa-large.headerlink,.rst-content h3 .btn .fa-large.headerlink,.rst-content h3 .nav .fa-large.headerlink,.rst-content h4 .btn .fa-large.headerlink,.rst-content h4 .nav .fa-large.headerlink,.rst-content h5 .btn .fa-large.headerlink,.rst-content h5 .nav .fa-large.headerlink,.rst-content h6 .btn .fa-large.headerlink,.rst-content h6 .nav .fa-large.headerlink,.rst-content p .btn .fa-large.headerlink,.rst-content p .nav .fa-large.headerlink,.rst-content table>caption .btn .fa-large.headerlink,.rst-content table>caption .nav .fa-large.headerlink,.rst-content tt.download .btn span.fa-large:first-child,.rst-content tt.download .nav span.fa-large:first-child,.wy-menu-vertical li .btn button.fa-large.toctree-expand,.wy-menu-vertical li .nav button.fa-large.toctree-expand{line-height:.9em}.btn .fa-spin.icon,.btn .fa.fa-spin,.btn .rst-content .code-block-caption .fa-spin.headerlink,.btn .rst-content .eqno .fa-spin.headerlink,.btn .rst-content .fa-spin.admonition-title,.btn .rst-content code.download span.fa-spin:first-child,.btn .rst-content dl dt .fa-spin.headerlink,.btn .rst-content h1 .fa-spin.headerlink,.btn .rst-content h2 .fa-spin.headerlink,.btn .rst-content h3 .fa-spin.headerlink,.btn .rst-content h4 .fa-spin.headerlink,.btn .rst-content h5 .fa-spin.headerlink,.btn .rst-content h6 .fa-spin.headerlink,.btn .rst-content p .fa-spin.headerlink,.btn .rst-content table>caption .fa-spin.headerlink,.btn .rst-content tt.download span.fa-spin:first-child,.btn .wy-menu-vertical li button.fa-spin.toctree-expand,.nav .fa-spin.icon,.nav .fa.fa-spin,.nav .rst-content .code-block-caption .fa-spin.headerlink,.nav .rst-content .eqno .fa-spin.headerlink,.nav .rst-content .fa-spin.admonition-title,.nav .rst-content code.download span.fa-spin:first-child,.nav .rst-content dl dt .fa-spin.headerlink,.nav .rst-content h1 .fa-spin.headerlink,.nav .rst-content h2 .fa-spin.headerlink,.nav .rst-content h3 .fa-spin.headerlink,.nav .rst-content h4 .fa-spin.headerlink,.nav .rst-content h5 .fa-spin.headerlink,.nav .rst-content h6 .fa-spin.headerlink,.nav .rst-content p .fa-spin.headerlink,.nav .rst-content table>caption .fa-spin.headerlink,.nav .rst-content tt.download span.fa-spin:first-child,.nav .wy-menu-vertical li button.fa-spin.toctree-expand,.rst-content .btn .fa-spin.admonition-title,.rst-content .code-block-caption .btn .fa-spin.headerlink,.rst-content .code-block-caption .nav .fa-spin.headerlink,.rst-content .eqno .btn .fa-spin.headerlink,.rst-content .eqno .nav .fa-spin.headerlink,.rst-content .nav .fa-spin.admonition-title,.rst-content code.download .btn span.fa-spin:first-child,.rst-content code.download .nav span.fa-spin:first-child,.rst-content dl dt .btn .fa-spin.headerlink,.rst-content dl dt .nav .fa-spin.headerlink,.rst-content h1 .btn .fa-spin.headerlink,.rst-content h1 .nav .fa-spin.headerlink,.rst-content h2 .btn .fa-spin.headerlink,.rst-content h2 .nav .fa-spin.headerlink,.rst-content h3 .btn .fa-spin.headerlink,.rst-content h3 .nav .fa-spin.headerlink,.rst-content h4 .btn .fa-spin.headerlink,.rst-content h4 .nav .fa-spin.headerlink,.rst-content h5 .btn .fa-spin.headerlink,.rst-content h5 .nav .fa-spin.headerlink,.rst-content h6 .btn .fa-spin.headerlink,.rst-content h6 .nav .fa-spin.headerlink,.rst-content p .btn .fa-spin.headerlink,.rst-content p .nav .fa-spin.headerlink,.rst-content table>caption .btn .fa-spin.headerlink,.rst-content table>caption .nav .fa-spin.headerlink,.rst-content tt.download .btn span.fa-spin:first-child,.rst-content tt.download .nav span.fa-spin:first-child,.wy-menu-vertical li .btn button.fa-spin.toctree-expand,.wy-menu-vertical li .nav button.fa-spin.toctree-expand{display:inline-block}.btn.fa:before,.btn.icon:before,.rst-content .btn.admonition-title:before,.rst-content .code-block-caption .btn.headerlink:before,.rst-content .eqno .btn.headerlink:before,.rst-content code.download span.btn:first-child:before,.rst-content dl dt .btn.headerlink:before,.rst-content h1 .btn.headerlink:before,.rst-content h2 .btn.headerlink:before,.rst-content h3 .btn.headerlink:before,.rst-content h4 .btn.headerlink:before,.rst-content h5 .btn.headerlink:before,.rst-content h6 .btn.headerlink:before,.rst-content p .btn.headerlink:before,.rst-content table>caption .btn.headerlink:before,.rst-content tt.download span.btn:first-child:before,.wy-menu-vertical li button.btn.toctree-expand:before{opacity:.5;-webkit-transition:opacity .05s ease-in;-moz-transition:opacity .05s ease-in;transition:opacity .05s ease-in}.btn.fa:hover:before,.btn.icon:hover:before,.rst-content .btn.admonition-title:hover:before,.rst-content .code-block-caption .btn.headerlink:hover:before,.rst-content .eqno .btn.headerlink:hover:before,.rst-content code.download span.btn:first-child:hover:before,.rst-content dl dt .btn.headerlink:hover:before,.rst-content h1 .btn.headerlink:hover:before,.rst-content h2 .btn.headerlink:hover:before,.rst-content h3 .btn.headerlink:hover:before,.rst-content h4 .btn.headerlink:hover:before,.rst-content h5 .btn.headerlink:hover:before,.rst-content h6 .btn.headerlink:hover:before,.rst-content p .btn.headerlink:hover:before,.rst-content table>caption .btn.headerlink:hover:before,.rst-content tt.download span.btn:first-child:hover:before,.wy-menu-vertical li button.btn.toctree-expand:hover:before{opacity:1}.btn-mini .fa:before,.btn-mini .icon:before,.btn-mini .rst-content .admonition-title:before,.btn-mini .rst-content .code-block-caption .headerlink:before,.btn-mini .rst-content .eqno .headerlink:before,.btn-mini .rst-content code.download span:first-child:before,.btn-mini .rst-content dl dt .headerlink:before,.btn-mini .rst-content h1 .headerlink:before,.btn-mini .rst-content h2 .headerlink:before,.btn-mini .rst-content h3 .headerlink:before,.btn-mini .rst-content h4 .headerlink:before,.btn-mini .rst-content h5 .headerlink:before,.btn-mini .rst-content h6 .headerlink:before,.btn-mini .rst-content p .headerlink:before,.btn-mini .rst-content table>caption .headerlink:before,.btn-mini .rst-content tt.download span:first-child:before,.btn-mini .wy-menu-vertical li button.toctree-expand:before,.rst-content .btn-mini .admonition-title:before,.rst-content .code-block-caption .btn-mini .headerlink:before,.rst-content .eqno .btn-mini .headerlink:before,.rst-content code.download .btn-mini span:first-child:before,.rst-content dl dt .btn-mini .headerlink:before,.rst-content h1 .btn-mini .headerlink:before,.rst-content h2 .btn-mini .headerlink:before,.rst-content h3 .btn-mini .headerlink:before,.rst-content h4 .btn-mini .headerlink:before,.rst-content h5 .btn-mini .headerlink:before,.rst-content h6 .btn-mini .headerlink:before,.rst-content p .btn-mini .headerlink:before,.rst-content table>caption .btn-mini .headerlink:before,.rst-content tt.download .btn-mini span:first-child:before,.wy-menu-vertical li .btn-mini button.toctree-expand:before{font-size:14px;vertical-align:-15%}.rst-content .admonition,.rst-content .admonition-todo,.rst-content .attention,.rst-content .caution,.rst-content .danger,.rst-content .error,.rst-content .hint,.rst-content .important,.rst-content .note,.rst-content .seealso,.rst-content .tip,.rst-content .warning,.wy-alert{padding:12px;line-height:24px;margin-bottom:24px;background:#e7f2fa}.rst-content .admonition-title,.wy-alert-title{font-weight:700;display:block;color:#fff;background:#6ab0de;padding:6px 12px;margin:-12px -12px 12px}.rst-content .danger,.rst-content .error,.rst-content .wy-alert-danger.admonition,.rst-content .wy-alert-danger.admonition-todo,.rst-content .wy-alert-danger.attention,.rst-content .wy-alert-danger.caution,.rst-content .wy-alert-danger.hint,.rst-content .wy-alert-danger.important,.rst-content .wy-alert-danger.note,.rst-content .wy-alert-danger.seealso,.rst-content .wy-alert-danger.tip,.rst-content .wy-alert-danger.warning,.wy-alert.wy-alert-danger{background:#fdf3f2}.rst-content .danger .admonition-title,.rst-content .danger .wy-alert-title,.rst-content .error .admonition-title,.rst-content .error .wy-alert-title,.rst-content .wy-alert-danger.admonition-todo .admonition-title,.rst-content .wy-alert-danger.admonition-todo .wy-alert-title,.rst-content .wy-alert-danger.admonition .admonition-title,.rst-content .wy-alert-danger.admonition .wy-alert-title,.rst-content .wy-alert-danger.attention .admonition-title,.rst-content .wy-alert-danger.attention .wy-alert-title,.rst-content .wy-alert-danger.caution .admonition-title,.rst-content .wy-alert-danger.caution .wy-alert-title,.rst-content .wy-alert-danger.hint .admonition-title,.rst-content .wy-alert-danger.hint .wy-alert-title,.rst-content .wy-alert-danger.important .admonition-title,.rst-content .wy-alert-danger.important .wy-alert-title,.rst-content .wy-alert-danger.note .admonition-title,.rst-content .wy-alert-danger.note .wy-alert-title,.rst-content .wy-alert-danger.seealso .admonition-title,.rst-content .wy-alert-danger.seealso .wy-alert-title,.rst-content .wy-alert-danger.tip .admonition-title,.rst-content .wy-alert-danger.tip .wy-alert-title,.rst-content .wy-alert-danger.warning .admonition-title,.rst-content .wy-alert-danger.warning .wy-alert-title,.rst-content .wy-alert.wy-alert-danger .admonition-title,.wy-alert.wy-alert-danger .rst-content .admonition-title,.wy-alert.wy-alert-danger .wy-alert-title{background:#f29f97}.rst-content .admonition-todo,.rst-content .attention,.rst-content .caution,.rst-content .warning,.rst-content .wy-alert-warning.admonition,.rst-content .wy-alert-warning.danger,.rst-content .wy-alert-warning.error,.rst-content .wy-alert-warning.hint,.rst-content .wy-alert-warning.important,.rst-content .wy-alert-warning.note,.rst-content .wy-alert-warning.seealso,.rst-content .wy-alert-warning.tip,.wy-alert.wy-alert-warning{background:#ffedcc}.rst-content .admonition-todo .admonition-title,.rst-content .admonition-todo .wy-alert-title,.rst-content .attention .admonition-title,.rst-content .attention .wy-alert-title,.rst-content .caution .admonition-title,.rst-content .caution .wy-alert-title,.rst-content .warning .admonition-title,.rst-content .warning .wy-alert-title,.rst-content .wy-alert-warning.admonition .admonition-title,.rst-content .wy-alert-warning.admonition .wy-alert-title,.rst-content .wy-alert-warning.danger .admonition-title,.rst-content .wy-alert-warning.danger .wy-alert-title,.rst-content .wy-alert-warning.error .admonition-title,.rst-content .wy-alert-warning.error .wy-alert-title,.rst-content .wy-alert-warning.hint .admonition-title,.rst-content .wy-alert-warning.hint .wy-alert-title,.rst-content .wy-alert-warning.important .admonition-title,.rst-content .wy-alert-warning.important .wy-alert-title,.rst-content .wy-alert-warning.note .admonition-title,.rst-content .wy-alert-warning.note .wy-alert-title,.rst-content .wy-alert-warning.seealso .admonition-title,.rst-content .wy-alert-warning.seealso .wy-alert-title,.rst-content .wy-alert-warning.tip .admonition-title,.rst-content .wy-alert-warning.tip .wy-alert-title,.rst-content .wy-alert.wy-alert-warning .admonition-title,.wy-alert.wy-alert-warning .rst-content .admonition-title,.wy-alert.wy-alert-warning .wy-alert-title{background:#f0b37e}.rst-content .note,.rst-content .seealso,.rst-content .wy-alert-info.admonition,.rst-content .wy-alert-info.admonition-todo,.rst-content .wy-alert-info.attention,.rst-content .wy-alert-info.caution,.rst-content .wy-alert-info.danger,.rst-content .wy-alert-info.error,.rst-content .wy-alert-info.hint,.rst-content .wy-alert-info.important,.rst-content .wy-alert-info.tip,.rst-content .wy-alert-info.warning,.wy-alert.wy-alert-info{background:#e7f2fa}.rst-content .note .admonition-title,.rst-content .note .wy-alert-title,.rst-content .seealso .admonition-title,.rst-content .seealso .wy-alert-title,.rst-content .wy-alert-info.admonition-todo .admonition-title,.rst-content .wy-alert-info.admonition-todo .wy-alert-title,.rst-content .wy-alert-info.admonition .admonition-title,.rst-content .wy-alert-info.admonition .wy-alert-title,.rst-content .wy-alert-info.attention .admonition-title,.rst-content .wy-alert-info.attention .wy-alert-title,.rst-content .wy-alert-info.caution .admonition-title,.rst-content .wy-alert-info.caution .wy-alert-title,.rst-content .wy-alert-info.danger .admonition-title,.rst-content .wy-alert-info.danger .wy-alert-title,.rst-content .wy-alert-info.error .admonition-title,.rst-content .wy-alert-info.error .wy-alert-title,.rst-content .wy-alert-info.hint .admonition-title,.rst-content .wy-alert-info.hint .wy-alert-title,.rst-content .wy-alert-info.important .admonition-title,.rst-content .wy-alert-info.important .wy-alert-title,.rst-content .wy-alert-info.tip .admonition-title,.rst-content .wy-alert-info.tip .wy-alert-title,.rst-content .wy-alert-info.warning .admonition-title,.rst-content .wy-alert-info.warning .wy-alert-title,.rst-content .wy-alert.wy-alert-info .admonition-title,.wy-alert.wy-alert-info .rst-content .admonition-title,.wy-alert.wy-alert-info .wy-alert-title{background:#6ab0de}.rst-content .hint,.rst-content .important,.rst-content .tip,.rst-content .wy-alert-success.admonition,.rst-content .wy-alert-success.admonition-todo,.rst-content .wy-alert-success.attention,.rst-content .wy-alert-success.caution,.rst-content .wy-alert-success.danger,.rst-content .wy-alert-success.error,.rst-content .wy-alert-success.note,.rst-content .wy-alert-success.seealso,.rst-content .wy-alert-success.warning,.wy-alert.wy-alert-success{background:#dbfaf4}.rst-content .hint .admonition-title,.rst-content .hint .wy-alert-title,.rst-content .important .admonition-title,.rst-content .important .wy-alert-title,.rst-content .tip .admonition-title,.rst-content .tip .wy-alert-title,.rst-content .wy-alert-success.admonition-todo .admonition-title,.rst-content .wy-alert-success.admonition-todo .wy-alert-title,.rst-content .wy-alert-success.admonition .admonition-title,.rst-content .wy-alert-success.admonition .wy-alert-title,.rst-content .wy-alert-success.attention .admonition-title,.rst-content .wy-alert-success.attention .wy-alert-title,.rst-content .wy-alert-success.caution .admonition-title,.rst-content .wy-alert-success.caution .wy-alert-title,.rst-content .wy-alert-success.danger .admonition-title,.rst-content .wy-alert-success.danger .wy-alert-title,.rst-content .wy-alert-success.error .admonition-title,.rst-content .wy-alert-success.error .wy-alert-title,.rst-content .wy-alert-success.note .admonition-title,.rst-content .wy-alert-success.note .wy-alert-title,.rst-content .wy-alert-success.seealso .admonition-title,.rst-content .wy-alert-success.seealso .wy-alert-title,.rst-content .wy-alert-success.warning .admonition-title,.rst-content .wy-alert-success.warning .wy-alert-title,.rst-content .wy-alert.wy-alert-success .admonition-title,.wy-alert.wy-alert-success .rst-content .admonition-title,.wy-alert.wy-alert-success .wy-alert-title{background:#1abc9c}.rst-content .wy-alert-neutral.admonition,.rst-content .wy-alert-neutral.admonition-todo,.rst-content .wy-alert-neutral.attention,.rst-content .wy-alert-neutral.caution,.rst-content .wy-alert-neutral.danger,.rst-content .wy-alert-neutral.error,.rst-content .wy-alert-neutral.hint,.rst-content .wy-alert-neutral.important,.rst-content .wy-alert-neutral.note,.rst-content .wy-alert-neutral.seealso,.rst-content .wy-alert-neutral.tip,.rst-content .wy-alert-neutral.warning,.wy-alert.wy-alert-neutral{background:#f3f6f6}.rst-content .wy-alert-neutral.admonition-todo .admonition-title,.rst-content .wy-alert-neutral.admonition-todo .wy-alert-title,.rst-content .wy-alert-neutral.admonition .admonition-title,.rst-content .wy-alert-neutral.admonition .wy-alert-title,.rst-content .wy-alert-neutral.attention .admonition-title,.rst-content .wy-alert-neutral.attention .wy-alert-title,.rst-content .wy-alert-neutral.caution .admonition-title,.rst-content .wy-alert-neutral.caution .wy-alert-title,.rst-content .wy-alert-neutral.danger .admonition-title,.rst-content .wy-alert-neutral.danger .wy-alert-title,.rst-content .wy-alert-neutral.error .admonition-title,.rst-content .wy-alert-neutral.error .wy-alert-title,.rst-content .wy-alert-neutral.hint .admonition-title,.rst-content .wy-alert-neutral.hint .wy-alert-title,.rst-content .wy-alert-neutral.important .admonition-title,.rst-content .wy-alert-neutral.important .wy-alert-title,.rst-content .wy-alert-neutral.note .admonition-title,.rst-content .wy-alert-neutral.note .wy-alert-title,.rst-content .wy-alert-neutral.seealso .admonition-title,.rst-content .wy-alert-neutral.seealso .wy-alert-title,.rst-content .wy-alert-neutral.tip .admonition-title,.rst-content .wy-alert-neutral.tip .wy-alert-title,.rst-content .wy-alert-neutral.warning .admonition-title,.rst-content .wy-alert-neutral.warning .wy-alert-title,.rst-content .wy-alert.wy-alert-neutral .admonition-title,.wy-alert.wy-alert-neutral .rst-content .admonition-title,.wy-alert.wy-alert-neutral .wy-alert-title{color:#404040;background:#e1e4e5}.rst-content .wy-alert-neutral.admonition-todo a,.rst-content .wy-alert-neutral.admonition a,.rst-content .wy-alert-neutral.attention a,.rst-content .wy-alert-neutral.caution a,.rst-content .wy-alert-neutral.danger a,.rst-content .wy-alert-neutral.error a,.rst-content .wy-alert-neutral.hint a,.rst-content .wy-alert-neutral.important a,.rst-content .wy-alert-neutral.note a,.rst-content .wy-alert-neutral.seealso a,.rst-content .wy-alert-neutral.tip a,.rst-content .wy-alert-neutral.warning a,.wy-alert.wy-alert-neutral a{color:#2980b9}.rst-content .admonition-todo p:last-child,.rst-content .admonition p:last-child,.rst-content .attention p:last-child,.rst-content .caution p:last-child,.rst-content .danger p:last-child,.rst-content .error p:last-child,.rst-content .hint p:last-child,.rst-content .important p:last-child,.rst-content .note p:last-child,.rst-content .seealso p:last-child,.rst-content .tip p:last-child,.rst-content .warning p:last-child,.wy-alert p:last-child{margin-bottom:0}.wy-tray-container{position:fixed;bottom:0;left:0;z-index:600}.wy-tray-container li{display:block;width:300px;background:transparent;color:#fff;text-align:center;box-shadow:0 5px 5px 0 rgba(0,0,0,.1);padding:0 24px;min-width:20%;opacity:0;height:0;line-height:56px;overflow:hidden;-webkit-transition:all .3s ease-in;-moz-transition:all .3s ease-in;transition:all .3s ease-in}.wy-tray-container li.wy-tray-item-success{background:#27ae60}.wy-tray-container li.wy-tray-item-info{background:#2980b9}.wy-tray-container li.wy-tray-item-warning{background:#e67e22}.wy-tray-container li.wy-tray-item-danger{background:#e74c3c}.wy-tray-container li.on{opacity:1;height:56px}@media screen and (max-width:768px){.wy-tray-container{bottom:auto;top:0;width:100%}.wy-tray-container li{width:100%}}button{font-size:100%;margin:0;vertical-align:baseline;*vertical-align:middle;cursor:pointer;line-height:normal;-webkit-appearance:button;*overflow:visible}button::-moz-focus-inner,input::-moz-focus-inner{border:0;padding:0}button[disabled]{cursor:default}.btn{display:inline-block;border-radius:2px;line-height:normal;white-space:nowrap;text-align:center;cursor:pointer;font-size:100%;padding:6px 12px 8px;color:#fff;border:1px solid rgba(0,0,0,.1);background-color:#27ae60;text-decoration:none;font-weight:400;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;box-shadow:inset 0 1px 2px -1px hsla(0,0%,100%,.5),inset 0 -2px 0 0 rgba(0,0,0,.1);outline-none:false;vertical-align:middle;*display:inline;zoom:1;-webkit-user-drag:none;-webkit-user-select:none;-moz-user-select:none;-ms-user-select:none;user-select:none;-webkit-transition:all .1s linear;-moz-transition:all .1s linear;transition:all .1s linear}.btn-hover{background:#2e8ece;color:#fff}.btn:hover{background:#2cc36b;color:#fff}.btn:focus{background:#2cc36b;outline:0}.btn:active{box-shadow:inset 0 -1px 0 0 rgba(0,0,0,.05),inset 0 2px 0 0 rgba(0,0,0,.1);padding:8px 12px 6px}.btn:visited{color:#fff}.btn-disabled,.btn-disabled:active,.btn-disabled:focus,.btn-disabled:hover,.btn:disabled{background-image:none;filter:progid:DXImageTransform.Microsoft.gradient(enabled = false);filter:alpha(opacity=40);opacity:.4;cursor:not-allowed;box-shadow:none}.btn::-moz-focus-inner{padding:0;border:0}.btn-small{font-size:80%}.btn-info{background-color:#2980b9!important}.btn-info:hover{background-color:#2e8ece!important}.btn-neutral{background-color:#f3f6f6!important;color:#404040!important}.btn-neutral:hover{background-color:#e5ebeb!important;color:#404040}.btn-neutral:visited{color:#404040!important}.btn-success{background-color:#27ae60!important}.btn-success:hover{background-color:#295!important}.btn-danger{background-color:#e74c3c!important}.btn-danger:hover{background-color:#ea6153!important}.btn-warning{background-color:#e67e22!important}.btn-warning:hover{background-color:#e98b39!important}.btn-invert{background-color:#222}.btn-invert:hover{background-color:#2f2f2f!important}.btn-link{background-color:transparent!important;color:#2980b9;box-shadow:none;border-color:transparent!important}.btn-link:active,.btn-link:hover{background-color:transparent!important;color:#409ad5!important;box-shadow:none}.btn-link:visited{color:#9b59b6}.wy-btn-group .btn,.wy-control .btn{vertical-align:middle}.wy-btn-group{margin-bottom:24px;*zoom:1}.wy-btn-group:after,.wy-btn-group:before{display:table;content:""}.wy-btn-group:after{clear:both}.wy-dropdown{position:relative;display:inline-block}.wy-dropdown-active .wy-dropdown-menu{display:block}.wy-dropdown-menu{position:absolute;left:0;display:none;float:left;top:100%;min-width:100%;background:#fcfcfc;z-index:100;border:1px solid #cfd7dd;box-shadow:0 2px 2px 0 rgba(0,0,0,.1);padding:12px}.wy-dropdown-menu>dd>a{display:block;clear:both;color:#404040;white-space:nowrap;font-size:90%;padding:0 12px;cursor:pointer}.wy-dropdown-menu>dd>a:hover{background:#2980b9;color:#fff}.wy-dropdown-menu>dd.divider{border-top:1px solid #cfd7dd;margin:6px 0}.wy-dropdown-menu>dd.search{padding-bottom:12px}.wy-dropdown-menu>dd.search input[type=search]{width:100%}.wy-dropdown-menu>dd.call-to-action{background:#e3e3e3;text-transform:uppercase;font-weight:500;font-size:80%}.wy-dropdown-menu>dd.call-to-action:hover{background:#e3e3e3}.wy-dropdown-menu>dd.call-to-action .btn{color:#fff}.wy-dropdown.wy-dropdown-up .wy-dropdown-menu{bottom:100%;top:auto;left:auto;right:0}.wy-dropdown.wy-dropdown-bubble .wy-dropdown-menu{background:#fcfcfc;margin-top:2px}.wy-dropdown.wy-dropdown-bubble .wy-dropdown-menu a{padding:6px 12px}.wy-dropdown.wy-dropdown-bubble .wy-dropdown-menu a:hover{background:#2980b9;color:#fff}.wy-dropdown.wy-dropdown-left .wy-dropdown-menu{right:0;left:auto;text-align:right}.wy-dropdown-arrow:before{content:" ";border-bottom:5px solid #f5f5f5;border-left:5px solid transparent;border-right:5px solid transparent;position:absolute;display:block;top:-4px;left:50%;margin-left:-3px}.wy-dropdown-arrow.wy-dropdown-arrow-left:before{left:11px}.wy-form-stacked select{display:block}.wy-form-aligned .wy-help-inline,.wy-form-aligned input,.wy-form-aligned label,.wy-form-aligned select,.wy-form-aligned textarea{display:inline-block;*display:inline;*zoom:1;vertical-align:middle}.wy-form-aligned .wy-control-group>label{display:inline-block;vertical-align:middle;width:10em;margin:6px 12px 0 0;float:left}.wy-form-aligned .wy-control{float:left}.wy-form-aligned .wy-control label{display:block}.wy-form-aligned .wy-control select{margin-top:6px}fieldset{margin:0}fieldset,legend{border:0;padding:0}legend{width:100%;white-space:normal;margin-bottom:24px;font-size:150%;*margin-left:-7px}label,legend{display:block}label{margin:0 0 .3125em;color:#333;font-size:90%}input,select,textarea{font-size:100%;margin:0;vertical-align:baseline;*vertical-align:middle}.wy-control-group{margin-bottom:24px;max-width:1200px;margin-left:auto;margin-right:auto;*zoom:1}.wy-control-group:after,.wy-control-group:before{display:table;content:""}.wy-control-group:after{clear:both}.wy-control-group.wy-control-group-required>label:after{content:" *";color:#e74c3c}.wy-control-group .wy-form-full,.wy-control-group .wy-form-halves,.wy-control-group .wy-form-thirds{padding-bottom:12px}.wy-control-group .wy-form-full input[type=color],.wy-control-group .wy-form-full input[type=date],.wy-control-group .wy-form-full input[type=datetime-local],.wy-control-group .wy-form-full input[type=datetime],.wy-control-group .wy-form-full input[type=email],.wy-control-group .wy-form-full input[type=month],.wy-control-group .wy-form-full input[type=number],.wy-control-group .wy-form-full input[type=password],.wy-control-group .wy-form-full input[type=search],.wy-control-group .wy-form-full input[type=tel],.wy-control-group .wy-form-full input[type=text],.wy-control-group .wy-form-full input[type=time],.wy-control-group .wy-form-full input[type=url],.wy-control-group .wy-form-full input[type=week],.wy-control-group .wy-form-full select,.wy-control-group .wy-form-halves input[type=color],.wy-control-group .wy-form-halves input[type=date],.wy-control-group .wy-form-halves input[type=datetime-local],.wy-control-group .wy-form-halves input[type=datetime],.wy-control-group .wy-form-halves input[type=email],.wy-control-group .wy-form-halves input[type=month],.wy-control-group .wy-form-halves input[type=number],.wy-control-group .wy-form-halves input[type=password],.wy-control-group .wy-form-halves input[type=search],.wy-control-group .wy-form-halves input[type=tel],.wy-control-group .wy-form-halves input[type=text],.wy-control-group .wy-form-halves input[type=time],.wy-control-group .wy-form-halves input[type=url],.wy-control-group .wy-form-halves input[type=week],.wy-control-group .wy-form-halves select,.wy-control-group .wy-form-thirds input[type=color],.wy-control-group .wy-form-thirds input[type=date],.wy-control-group .wy-form-thirds input[type=datetime-local],.wy-control-group .wy-form-thirds input[type=datetime],.wy-control-group .wy-form-thirds input[type=email],.wy-control-group .wy-form-thirds input[type=month],.wy-control-group .wy-form-thirds input[type=number],.wy-control-group .wy-form-thirds input[type=password],.wy-control-group .wy-form-thirds input[type=search],.wy-control-group .wy-form-thirds input[type=tel],.wy-control-group .wy-form-thirds input[type=text],.wy-control-group .wy-form-thirds input[type=time],.wy-control-group .wy-form-thirds input[type=url],.wy-control-group .wy-form-thirds input[type=week],.wy-control-group .wy-form-thirds select{width:100%}.wy-control-group .wy-form-full{float:left;display:block;width:100%;margin-right:0}.wy-control-group .wy-form-full:last-child{margin-right:0}.wy-control-group .wy-form-halves{float:left;display:block;margin-right:2.35765%;width:48.82117%}.wy-control-group .wy-form-halves:last-child,.wy-control-group .wy-form-halves:nth-of-type(2n){margin-right:0}.wy-control-group .wy-form-halves:nth-of-type(odd){clear:left}.wy-control-group .wy-form-thirds{float:left;display:block;margin-right:2.35765%;width:31.76157%}.wy-control-group .wy-form-thirds:last-child,.wy-control-group .wy-form-thirds:nth-of-type(3n){margin-right:0}.wy-control-group .wy-form-thirds:nth-of-type(3n+1){clear:left}.wy-control-group.wy-control-group-no-input .wy-control,.wy-control-no-input{margin:6px 0 0;font-size:90%}.wy-control-no-input{display:inline-block}.wy-control-group.fluid-input input[type=color],.wy-control-group.fluid-input input[type=date],.wy-control-group.fluid-input input[type=datetime-local],.wy-control-group.fluid-input input[type=datetime],.wy-control-group.fluid-input input[type=email],.wy-control-group.fluid-input input[type=month],.wy-control-group.fluid-input input[type=number],.wy-control-group.fluid-input input[type=password],.wy-control-group.fluid-input input[type=search],.wy-control-group.fluid-input input[type=tel],.wy-control-group.fluid-input input[type=text],.wy-control-group.fluid-input input[type=time],.wy-control-group.fluid-input input[type=url],.wy-control-group.fluid-input input[type=week]{width:100%}.wy-form-message-inline{padding-left:.3em;color:#666;font-size:90%}.wy-form-message{display:block;color:#999;font-size:70%;margin-top:.3125em;font-style:italic}.wy-form-message p{font-size:inherit;font-style:italic;margin-bottom:6px}.wy-form-message p:last-child{margin-bottom:0}input{line-height:normal}input[type=button],input[type=reset],input[type=submit]{-webkit-appearance:button;cursor:pointer;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;*overflow:visible}input[type=color],input[type=date],input[type=datetime-local],input[type=datetime],input[type=email],input[type=month],input[type=number],input[type=password],input[type=search],input[type=tel],input[type=text],input[type=time],input[type=url],input[type=week]{-webkit-appearance:none;padding:6px;display:inline-block;border:1px solid #ccc;font-size:80%;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;box-shadow:inset 0 1px 3px #ddd;border-radius:0;-webkit-transition:border .3s linear;-moz-transition:border .3s linear;transition:border .3s linear}input[type=datetime-local]{padding:.34375em .625em}input[disabled]{cursor:default}input[type=checkbox],input[type=radio]{padding:0;margin-right:.3125em;*height:13px;*width:13px}input[type=checkbox],input[type=radio],input[type=search]{-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}input[type=search]::-webkit-search-cancel-button,input[type=search]::-webkit-search-decoration{-webkit-appearance:none}input[type=color]:focus,input[type=date]:focus,input[type=datetime-local]:focus,input[type=datetime]:focus,input[type=email]:focus,input[type=month]:focus,input[type=number]:focus,input[type=password]:focus,input[type=search]:focus,input[type=tel]:focus,input[type=text]:focus,input[type=time]:focus,input[type=url]:focus,input[type=week]:focus{outline:0;outline:thin dotted\9;border-color:#333}input.no-focus:focus{border-color:#ccc!important}input[type=checkbox]:focus,input[type=file]:focus,input[type=radio]:focus{outline:thin dotted #333;outline:1px auto #129fea}input[type=color][disabled],input[type=date][disabled],input[type=datetime-local][disabled],input[type=datetime][disabled],input[type=email][disabled],input[type=month][disabled],input[type=number][disabled],input[type=password][disabled],input[type=search][disabled],input[type=tel][disabled],input[type=text][disabled],input[type=time][disabled],input[type=url][disabled],input[type=week][disabled]{cursor:not-allowed;background-color:#fafafa}input:focus:invalid,select:focus:invalid,textarea:focus:invalid{color:#e74c3c;border:1px solid #e74c3c}input:focus:invalid:focus,select:focus:invalid:focus,textarea:focus:invalid:focus{border-color:#e74c3c}input[type=checkbox]:focus:invalid:focus,input[type=file]:focus:invalid:focus,input[type=radio]:focus:invalid:focus{outline-color:#e74c3c}input.wy-input-large{padding:12px;font-size:100%}textarea{overflow:auto;vertical-align:top;width:100%;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif}select,textarea{padding:.5em .625em;display:inline-block;border:1px solid #ccc;font-size:80%;box-shadow:inset 0 1px 3px #ddd;-webkit-transition:border .3s linear;-moz-transition:border .3s linear;transition:border .3s linear}select{border:1px solid #ccc;background-color:#fff}select[multiple]{height:auto}select:focus,textarea:focus{outline:0}input[readonly],select[disabled],select[readonly],textarea[disabled],textarea[readonly]{cursor:not-allowed;background-color:#fafafa}input[type=checkbox][disabled],input[type=radio][disabled]{cursor:not-allowed}.wy-checkbox,.wy-radio{margin:6px 0;color:#404040;display:block}.wy-checkbox input,.wy-radio input{vertical-align:baseline}.wy-form-message-inline{display:inline-block;*display:inline;*zoom:1;vertical-align:middle}.wy-input-prefix,.wy-input-suffix{white-space:nowrap;padding:6px}.wy-input-prefix .wy-input-context,.wy-input-suffix .wy-input-context{line-height:27px;padding:0 8px;display:inline-block;font-size:80%;background-color:#f3f6f6;border:1px solid #ccc;color:#999}.wy-input-suffix .wy-input-context{border-left:0}.wy-input-prefix .wy-input-context{border-right:0}.wy-switch{position:relative;display:block;height:24px;margin-top:12px;cursor:pointer}.wy-switch:before{left:0;top:0;width:36px;height:12px;background:#ccc}.wy-switch:after,.wy-switch:before{position:absolute;content:"";display:block;border-radius:4px;-webkit-transition:all .2s ease-in-out;-moz-transition:all .2s ease-in-out;transition:all .2s ease-in-out}.wy-switch:after{width:18px;height:18px;background:#999;left:-3px;top:-3px}.wy-switch span{position:absolute;left:48px;display:block;font-size:12px;color:#ccc;line-height:1}.wy-switch.active:before{background:#1e8449}.wy-switch.active:after{left:24px;background:#27ae60}.wy-switch.disabled{cursor:not-allowed;opacity:.8}.wy-control-group.wy-control-group-error .wy-form-message,.wy-control-group.wy-control-group-error>label{color:#e74c3c}.wy-control-group.wy-control-group-error input[type=color],.wy-control-group.wy-control-group-error input[type=date],.wy-control-group.wy-control-group-error input[type=datetime-local],.wy-control-group.wy-control-group-error input[type=datetime],.wy-control-group.wy-control-group-error input[type=email],.wy-control-group.wy-control-group-error input[type=month],.wy-control-group.wy-control-group-error input[type=number],.wy-control-group.wy-control-group-error input[type=password],.wy-control-group.wy-control-group-error input[type=search],.wy-control-group.wy-control-group-error input[type=tel],.wy-control-group.wy-control-group-error input[type=text],.wy-control-group.wy-control-group-error input[type=time],.wy-control-group.wy-control-group-error input[type=url],.wy-control-group.wy-control-group-error input[type=week],.wy-control-group.wy-control-group-error textarea{border:1px solid #e74c3c}.wy-inline-validate{white-space:nowrap}.wy-inline-validate .wy-input-context{padding:.5em .625em;display:inline-block;font-size:80%}.wy-inline-validate.wy-inline-validate-success .wy-input-context{color:#27ae60}.wy-inline-validate.wy-inline-validate-danger .wy-input-context{color:#e74c3c}.wy-inline-validate.wy-inline-validate-warning .wy-input-context{color:#e67e22}.wy-inline-validate.wy-inline-validate-info .wy-input-context{color:#2980b9}.rotate-90{-webkit-transform:rotate(90deg);-moz-transform:rotate(90deg);-ms-transform:rotate(90deg);-o-transform:rotate(90deg);transform:rotate(90deg)}.rotate-180{-webkit-transform:rotate(180deg);-moz-transform:rotate(180deg);-ms-transform:rotate(180deg);-o-transform:rotate(180deg);transform:rotate(180deg)}.rotate-270{-webkit-transform:rotate(270deg);-moz-transform:rotate(270deg);-ms-transform:rotate(270deg);-o-transform:rotate(270deg);transform:rotate(270deg)}.mirror{-webkit-transform:scaleX(-1);-moz-transform:scaleX(-1);-ms-transform:scaleX(-1);-o-transform:scaleX(-1);transform:scaleX(-1)}.mirror.rotate-90{-webkit-transform:scaleX(-1) rotate(90deg);-moz-transform:scaleX(-1) rotate(90deg);-ms-transform:scaleX(-1) rotate(90deg);-o-transform:scaleX(-1) rotate(90deg);transform:scaleX(-1) rotate(90deg)}.mirror.rotate-180{-webkit-transform:scaleX(-1) rotate(180deg);-moz-transform:scaleX(-1) rotate(180deg);-ms-transform:scaleX(-1) rotate(180deg);-o-transform:scaleX(-1) rotate(180deg);transform:scaleX(-1) rotate(180deg)}.mirror.rotate-270{-webkit-transform:scaleX(-1) rotate(270deg);-moz-transform:scaleX(-1) rotate(270deg);-ms-transform:scaleX(-1) rotate(270deg);-o-transform:scaleX(-1) rotate(270deg);transform:scaleX(-1) rotate(270deg)}@media only screen and (max-width:480px){.wy-form button[type=submit]{margin:.7em 0 0}.wy-form input[type=color],.wy-form input[type=date],.wy-form input[type=datetime-local],.wy-form input[type=datetime],.wy-form input[type=email],.wy-form input[type=month],.wy-form input[type=number],.wy-form input[type=password],.wy-form input[type=search],.wy-form input[type=tel],.wy-form input[type=text],.wy-form input[type=time],.wy-form input[type=url],.wy-form input[type=week],.wy-form label{margin-bottom:.3em;display:block}.wy-form input[type=color],.wy-form input[type=date],.wy-form input[type=datetime-local],.wy-form input[type=datetime],.wy-form input[type=email],.wy-form input[type=month],.wy-form input[type=number],.wy-form input[type=password],.wy-form input[type=search],.wy-form input[type=tel],.wy-form input[type=time],.wy-form input[type=url],.wy-form input[type=week]{margin-bottom:0}.wy-form-aligned .wy-control-group label{margin-bottom:.3em;text-align:left;display:block;width:100%}.wy-form-aligned .wy-control{margin:1.5em 0 0}.wy-form-message,.wy-form-message-inline,.wy-form .wy-help-inline{display:block;font-size:80%;padding:6px 0}}@media screen and (max-width:768px){.tablet-hide{display:none}}@media screen and (max-width:480px){.mobile-hide{display:none}}.float-left{float:left}.float-right{float:right}.full-width{width:100%}.rst-content table.docutils,.rst-content table.field-list,.wy-table{border-collapse:collapse;border-spacing:0;empty-cells:show;margin-bottom:24px}.rst-content table.docutils caption,.rst-content table.field-list caption,.wy-table caption{color:#000;font:italic 85%/1 arial,sans-serif;padding:1em 0;text-align:center}.rst-content table.docutils td,.rst-content table.docutils th,.rst-content table.field-list td,.rst-content table.field-list th,.wy-table td,.wy-table th{font-size:90%;margin:0;overflow:visible;padding:8px 16px}.rst-content table.docutils td:first-child,.rst-content table.docutils th:first-child,.rst-content table.field-list td:first-child,.rst-content table.field-list th:first-child,.wy-table td:first-child,.wy-table th:first-child{border-left-width:0}.rst-content table.docutils thead,.rst-content table.field-list thead,.wy-table thead{color:#000;text-align:left;vertical-align:bottom;white-space:nowrap}.rst-content table.docutils thead th,.rst-content table.field-list thead th,.wy-table thead th{font-weight:700;border-bottom:2px solid #e1e4e5}.rst-content table.docutils td,.rst-content table.field-list td,.wy-table td{background-color:transparent;vertical-align:middle}.rst-content table.docutils td p,.rst-content table.field-list td p,.wy-table td p{line-height:18px}.rst-content table.docutils td p:last-child,.rst-content table.field-list td p:last-child,.wy-table td p:last-child{margin-bottom:0}.rst-content table.docutils .wy-table-cell-min,.rst-content table.field-list .wy-table-cell-min,.wy-table .wy-table-cell-min{width:1%;padding-right:0}.rst-content table.docutils .wy-table-cell-min input[type=checkbox],.rst-content table.field-list .wy-table-cell-min input[type=checkbox],.wy-table .wy-table-cell-min input[type=checkbox]{margin:0}.wy-table-secondary{color:grey;font-size:90%}.wy-table-tertiary{color:grey;font-size:80%}.rst-content table.docutils:not(.field-list) tr:nth-child(2n-1) td,.wy-table-backed,.wy-table-odd td,.wy-table-striped tr:nth-child(2n-1) td{background-color:#f3f6f6}.rst-content table.docutils,.wy-table-bordered-all{border:1px solid #e1e4e5}.rst-content table.docutils td,.wy-table-bordered-all td{border-bottom:1px solid #e1e4e5;border-left:1px solid #e1e4e5}.rst-content table.docutils tbody>tr:last-child td,.wy-table-bordered-all tbody>tr:last-child td{border-bottom-width:0}.wy-table-bordered{border:1px solid #e1e4e5}.wy-table-bordered-rows td{border-bottom:1px solid #e1e4e5}.wy-table-bordered-rows tbody>tr:last-child td{border-bottom-width:0}.wy-table-horizontal td,.wy-table-horizontal th{border-width:0 0 1px;border-bottom:1px solid #e1e4e5}.wy-table-horizontal tbody>tr:last-child td{border-bottom-width:0}.wy-table-responsive{margin-bottom:24px;max-width:100%;overflow:auto}.wy-table-responsive table{margin-bottom:0!important}.wy-table-responsive table td,.wy-table-responsive table th{white-space:nowrap}a{color:#2980b9;text-decoration:none;cursor:pointer}a:hover{color:#3091d1}a:visited{color:#9b59b6}html{height:100%}body,html{overflow-x:hidden}body{font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;font-weight:400;color:#404040;min-height:100%;background:#edf0f2}.wy-text-left{text-align:left}.wy-text-center{text-align:center}.wy-text-right{text-align:right}.wy-text-large{font-size:120%}.wy-text-normal{font-size:100%}.wy-text-small,small{font-size:80%}.wy-text-strike{text-decoration:line-through}.wy-text-warning{color:#e67e22!important}a.wy-text-warning:hover{color:#eb9950!important}.wy-text-info{color:#2980b9!important}a.wy-text-info:hover{color:#409ad5!important}.wy-text-success{color:#27ae60!important}a.wy-text-success:hover{color:#36d278!important}.wy-text-danger{color:#e74c3c!important}a.wy-text-danger:hover{color:#ed7669!important}.wy-text-neutral{color:#404040!important}a.wy-text-neutral:hover{color:#595959!important}.rst-content .toctree-wrapper>p.caption,h1,h2,h3,h4,h5,h6,legend{margin-top:0;font-weight:700;font-family:Roboto Slab,ff-tisa-web-pro,Georgia,Arial,sans-serif}p{line-height:24px;font-size:16px;margin:0 0 24px}h1{font-size:175%}.rst-content .toctree-wrapper>p.caption,h2{font-size:150%}h3{font-size:125%}h4{font-size:115%}h5{font-size:110%}h6{font-size:100%}hr{display:block;height:1px;border:0;border-top:1px solid #e1e4e5;margin:24px 0;padding:0}.rst-content code,.rst-content tt,code{white-space:nowrap;max-width:100%;background:#fff;border:1px solid #e1e4e5;font-size:75%;padding:0 5px;font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;color:#e74c3c;overflow-x:auto}.rst-content tt.code-large,code.code-large{font-size:90%}.rst-content .section ul,.rst-content .toctree-wrapper ul,.rst-content section ul,.wy-plain-list-disc,article ul{list-style:disc;line-height:24px;margin-bottom:24px}.rst-content .section ul li,.rst-content .toctree-wrapper ul li,.rst-content section ul li,.wy-plain-list-disc li,article ul li{list-style:disc;margin-left:24px}.rst-content .section ul li p:last-child,.rst-content .section ul li ul,.rst-content .toctree-wrapper ul li p:last-child,.rst-content .toctree-wrapper ul li ul,.rst-content section ul li p:last-child,.rst-content section ul li ul,.wy-plain-list-disc li p:last-child,.wy-plain-list-disc li ul,article ul li p:last-child,article ul li ul{margin-bottom:0}.rst-content .section ul li li,.rst-content .toctree-wrapper ul li li,.rst-content section ul li li,.wy-plain-list-disc li li,article ul li li{list-style:circle}.rst-content .section ul li li li,.rst-content .toctree-wrapper ul li li li,.rst-content section ul li li li,.wy-plain-list-disc li li li,article ul li li li{list-style:square}.rst-content .section ul li ol li,.rst-content .toctree-wrapper ul li ol li,.rst-content section ul li ol li,.wy-plain-list-disc li ol li,article ul li ol li{list-style:decimal}.rst-content .section ol,.rst-content .section ol.arabic,.rst-content .toctree-wrapper ol,.rst-content .toctree-wrapper ol.arabic,.rst-content section ol,.rst-content section ol.arabic,.wy-plain-list-decimal,article ol{list-style:decimal;line-height:24px;margin-bottom:24px}.rst-content .section ol.arabic li,.rst-content .section ol li,.rst-content .toctree-wrapper ol.arabic li,.rst-content .toctree-wrapper ol li,.rst-content section ol.arabic li,.rst-content section ol li,.wy-plain-list-decimal li,article ol li{list-style:decimal;margin-left:24px}.rst-content .section ol.arabic li ul,.rst-content .section ol li p:last-child,.rst-content .section ol li ul,.rst-content .toctree-wrapper ol.arabic li ul,.rst-content .toctree-wrapper ol li p:last-child,.rst-content .toctree-wrapper ol li ul,.rst-content section ol.arabic li ul,.rst-content section ol li p:last-child,.rst-content section ol li ul,.wy-plain-list-decimal li p:last-child,.wy-plain-list-decimal li ul,article ol li p:last-child,article ol li ul{margin-bottom:0}.rst-content .section ol.arabic li ul li,.rst-content .section ol li ul li,.rst-content .toctree-wrapper ol.arabic li ul li,.rst-content .toctree-wrapper ol li ul li,.rst-content section ol.arabic li ul li,.rst-content section ol li ul li,.wy-plain-list-decimal li ul li,article ol li ul li{list-style:disc}.wy-breadcrumbs{*zoom:1}.wy-breadcrumbs:after,.wy-breadcrumbs:before{display:table;content:""}.wy-breadcrumbs:after{clear:both}.wy-breadcrumbs>li{display:inline-block;padding-top:5px}.wy-breadcrumbs>li.wy-breadcrumbs-aside{float:right}.rst-content .wy-breadcrumbs>li code,.rst-content .wy-breadcrumbs>li tt,.wy-breadcrumbs>li .rst-content tt,.wy-breadcrumbs>li code{all:inherit;color:inherit}.breadcrumb-item:before{content:"/";color:#bbb;font-size:13px;padding:0 6px 0 3px}.wy-breadcrumbs-extra{margin-bottom:0;color:#b3b3b3;font-size:80%;display:inline-block}@media screen and (max-width:480px){.wy-breadcrumbs-extra,.wy-breadcrumbs li.wy-breadcrumbs-aside{display:none}}@media print{.wy-breadcrumbs li.wy-breadcrumbs-aside{display:none}}html{font-size:16px}.wy-affix{position:fixed;top:1.618em}.wy-menu a:hover{text-decoration:none}.wy-menu-horiz{*zoom:1}.wy-menu-horiz:after,.wy-menu-horiz:before{display:table;content:""}.wy-menu-horiz:after{clear:both}.wy-menu-horiz li,.wy-menu-horiz ul{display:inline-block}.wy-menu-horiz li:hover{background:hsla(0,0%,100%,.1)}.wy-menu-horiz li.divide-left{border-left:1px solid #404040}.wy-menu-horiz li.divide-right{border-right:1px solid #404040}.wy-menu-horiz a{height:32px;display:inline-block;line-height:32px;padding:0 16px}.wy-menu-vertical{width:300px}.wy-menu-vertical header,.wy-menu-vertical p.caption{color:#55a5d9;height:32px;line-height:32px;padding:0 1.618em;margin:12px 0 0;display:block;font-weight:700;text-transform:uppercase;font-size:85%;white-space:nowrap}.wy-menu-vertical ul{margin-bottom:0}.wy-menu-vertical li.divide-top{border-top:1px solid #404040}.wy-menu-vertical li.divide-bottom{border-bottom:1px solid #404040}.wy-menu-vertical li.current{background:#e3e3e3}.wy-menu-vertical li.current a{color:grey;border-right:1px solid #c9c9c9;padding:.4045em 2.427em}.wy-menu-vertical li.current a:hover{background:#d6d6d6}.rst-content .wy-menu-vertical li tt,.wy-menu-vertical li .rst-content tt,.wy-menu-vertical li code{border:none;background:inherit;color:inherit;padding-left:0;padding-right:0}.wy-menu-vertical li button.toctree-expand{display:block;float:left;margin-left:-1.2em;line-height:18px;color:#4d4d4d;border:none;background:none;padding:0}.wy-menu-vertical li.current>a,.wy-menu-vertical li.on a{color:#404040;font-weight:700;position:relative;background:#fcfcfc;border:none;padding:.4045em 1.618em}.wy-menu-vertical li.current>a:hover,.wy-menu-vertical li.on a:hover{background:#fcfcfc}.wy-menu-vertical li.current>a:hover button.toctree-expand,.wy-menu-vertical li.on a:hover button.toctree-expand{color:grey}.wy-menu-vertical li.current>a button.toctree-expand,.wy-menu-vertical li.on a button.toctree-expand{display:block;line-height:18px;color:#333}.wy-menu-vertical li.toctree-l1.current>a{border-bottom:1px solid #c9c9c9;border-top:1px solid #c9c9c9}.wy-menu-vertical .toctree-l1.current .toctree-l2>ul,.wy-menu-vertical .toctree-l2.current .toctree-l3>ul,.wy-menu-vertical .toctree-l3.current .toctree-l4>ul,.wy-menu-vertical .toctree-l4.current .toctree-l5>ul,.wy-menu-vertical .toctree-l5.current .toctree-l6>ul,.wy-menu-vertical .toctree-l6.current .toctree-l7>ul,.wy-menu-vertical .toctree-l7.current .toctree-l8>ul,.wy-menu-vertical .toctree-l8.current .toctree-l9>ul,.wy-menu-vertical .toctree-l9.current .toctree-l10>ul,.wy-menu-vertical .toctree-l10.current .toctree-l11>ul{display:none}.wy-menu-vertical .toctree-l1.current .current.toctree-l2>ul,.wy-menu-vertical .toctree-l2.current .current.toctree-l3>ul,.wy-menu-vertical .toctree-l3.current .current.toctree-l4>ul,.wy-menu-vertical .toctree-l4.current .current.toctree-l5>ul,.wy-menu-vertical .toctree-l5.current .current.toctree-l6>ul,.wy-menu-vertical .toctree-l6.current .current.toctree-l7>ul,.wy-menu-vertical .toctree-l7.current .current.toctree-l8>ul,.wy-menu-vertical .toctree-l8.current .current.toctree-l9>ul,.wy-menu-vertical .toctree-l9.current .current.toctree-l10>ul,.wy-menu-vertical .toctree-l10.current .current.toctree-l11>ul{display:block}.wy-menu-vertical li.toctree-l3,.wy-menu-vertical li.toctree-l4{font-size:.9em}.wy-menu-vertical li.toctree-l2 a,.wy-menu-vertical li.toctree-l3 a,.wy-menu-vertical li.toctree-l4 a,.wy-menu-vertical li.toctree-l5 a,.wy-menu-vertical li.toctree-l6 a,.wy-menu-vertical li.toctree-l7 a,.wy-menu-vertical li.toctree-l8 a,.wy-menu-vertical li.toctree-l9 a,.wy-menu-vertical li.toctree-l10 a{color:#404040}.wy-menu-vertical li.toctree-l2 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l3 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l4 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l5 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l6 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l7 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l8 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l9 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l10 a:hover button.toctree-expand{color:grey}.wy-menu-vertical li.toctree-l2.current li.toctree-l3>a,.wy-menu-vertical li.toctree-l3.current li.toctree-l4>a,.wy-menu-vertical li.toctree-l4.current li.toctree-l5>a,.wy-menu-vertical li.toctree-l5.current li.toctree-l6>a,.wy-menu-vertical li.toctree-l6.current li.toctree-l7>a,.wy-menu-vertical li.toctree-l7.current li.toctree-l8>a,.wy-menu-vertical li.toctree-l8.current li.toctree-l9>a,.wy-menu-vertical li.toctree-l9.current li.toctree-l10>a,.wy-menu-vertical li.toctree-l10.current li.toctree-l11>a{display:block}.wy-menu-vertical li.toctree-l2.current>a{padding:.4045em 2.427em}.wy-menu-vertical li.toctree-l2.current li.toctree-l3>a{padding:.4045em 1.618em .4045em 4.045em}.wy-menu-vertical li.toctree-l3.current>a{padding:.4045em 4.045em}.wy-menu-vertical li.toctree-l3.current li.toctree-l4>a{padding:.4045em 1.618em .4045em 5.663em}.wy-menu-vertical li.toctree-l4.current>a{padding:.4045em 5.663em}.wy-menu-vertical li.toctree-l4.current li.toctree-l5>a{padding:.4045em 1.618em .4045em 7.281em}.wy-menu-vertical li.toctree-l5.current>a{padding:.4045em 7.281em}.wy-menu-vertical li.toctree-l5.current li.toctree-l6>a{padding:.4045em 1.618em .4045em 8.899em}.wy-menu-vertical li.toctree-l6.current>a{padding:.4045em 8.899em}.wy-menu-vertical li.toctree-l6.current li.toctree-l7>a{padding:.4045em 1.618em .4045em 10.517em}.wy-menu-vertical li.toctree-l7.current>a{padding:.4045em 10.517em}.wy-menu-vertical li.toctree-l7.current li.toctree-l8>a{padding:.4045em 1.618em .4045em 12.135em}.wy-menu-vertical li.toctree-l8.current>a{padding:.4045em 12.135em}.wy-menu-vertical li.toctree-l8.current li.toctree-l9>a{padding:.4045em 1.618em .4045em 13.753em}.wy-menu-vertical li.toctree-l9.current>a{padding:.4045em 13.753em}.wy-menu-vertical li.toctree-l9.current li.toctree-l10>a{padding:.4045em 1.618em .4045em 15.371em}.wy-menu-vertical li.toctree-l10.current>a{padding:.4045em 15.371em}.wy-menu-vertical li.toctree-l10.current li.toctree-l11>a{padding:.4045em 1.618em .4045em 16.989em}.wy-menu-vertical li.toctree-l2.current>a,.wy-menu-vertical li.toctree-l2.current li.toctree-l3>a{background:#c9c9c9}.wy-menu-vertical li.toctree-l2 button.toctree-expand{color:#a3a3a3}.wy-menu-vertical li.toctree-l3.current>a,.wy-menu-vertical li.toctree-l3.current li.toctree-l4>a{background:#bdbdbd}.wy-menu-vertical li.toctree-l3 button.toctree-expand{color:#969696}.wy-menu-vertical li.current ul{display:block}.wy-menu-vertical li ul{margin-bottom:0;display:none}.wy-menu-vertical li ul li a{margin-bottom:0;color:#d9d9d9;font-weight:400}.wy-menu-vertical a{line-height:18px;padding:.4045em 1.618em;display:block;position:relative;font-size:90%;color:#d9d9d9}.wy-menu-vertical a:hover{background-color:#4e4a4a;cursor:pointer}.wy-menu-vertical a:hover button.toctree-expand{color:#d9d9d9}.wy-menu-vertical a:active{background-color:#2980b9;cursor:pointer;color:#fff}.wy-menu-vertical a:active button.toctree-expand{color:#fff}.wy-side-nav-search{display:block;width:300px;padding:.809em;margin-bottom:.809em;z-index:200;background-color:#2980b9;text-align:center;color:#fcfcfc}.wy-side-nav-search input[type=text]{width:100%;border-radius:50px;padding:6px 12px;border-color:#2472a4}.wy-side-nav-search img{display:block;margin:auto auto .809em;height:45px;width:45px;background-color:#2980b9;padding:5px;border-radius:100%}.wy-side-nav-search .wy-dropdown>a,.wy-side-nav-search>a{color:#fcfcfc;font-size:100%;font-weight:700;display:inline-block;padding:4px 6px;margin-bottom:.809em;max-width:100%}.wy-side-nav-search .wy-dropdown>a:hover,.wy-side-nav-search .wy-dropdown>aactive,.wy-side-nav-search .wy-dropdown>afocus,.wy-side-nav-search>a:hover,.wy-side-nav-search>aactive,.wy-side-nav-search>afocus{background:hsla(0,0%,100%,.1)}.wy-side-nav-search .wy-dropdown>a img.logo,.wy-side-nav-search>a img.logo{display:block;margin:0 auto;height:auto;width:auto;border-radius:0;max-width:100%;background:transparent}.wy-side-nav-search .wy-dropdown>a.icon,.wy-side-nav-search>a.icon{display:block}.wy-side-nav-search .wy-dropdown>a.icon img.logo,.wy-side-nav-search>a.icon img.logo{margin-top:.85em}.wy-side-nav-search>div.switch-menus{position:relative;display:block;margin-top:-.4045em;margin-bottom:.809em;font-weight:400;color:hsla(0,0%,100%,.3)}.wy-side-nav-search>div.switch-menus>div.language-switch,.wy-side-nav-search>div.switch-menus>div.version-switch{display:inline-block;padding:.2em}.wy-side-nav-search>div.switch-menus>div.language-switch select,.wy-side-nav-search>div.switch-menus>div.version-switch select{display:inline-block;margin-right:-2rem;padding-right:2rem;max-width:240px;text-align-last:center;background:none;border:none;border-radius:0;box-shadow:none;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;font-size:1em;font-weight:400;color:hsla(0,0%,100%,.3);cursor:pointer;appearance:none;-webkit-appearance:none;-moz-appearance:none}.wy-side-nav-search>div.switch-menus>div.language-switch select:active,.wy-side-nav-search>div.switch-menus>div.language-switch select:focus,.wy-side-nav-search>div.switch-menus>div.language-switch select:hover,.wy-side-nav-search>div.switch-menus>div.version-switch select:active,.wy-side-nav-search>div.switch-menus>div.version-switch select:focus,.wy-side-nav-search>div.switch-menus>div.version-switch select:hover{background:hsla(0,0%,100%,.1);color:hsla(0,0%,100%,.5)}.wy-side-nav-search>div.switch-menus>div.language-switch select option,.wy-side-nav-search>div.switch-menus>div.version-switch select option{color:#000}.wy-side-nav-search>div.switch-menus>div.language-switch:has(>select):after,.wy-side-nav-search>div.switch-menus>div.version-switch:has(>select):after{display:inline-block;width:1.5em;height:100%;padding:.1em;content:"\f0d7";font-size:1em;line-height:1.2em;font-family:FontAwesome;text-align:center;pointer-events:none;box-sizing:border-box}.wy-nav .wy-menu-vertical header{color:#2980b9}.wy-nav .wy-menu-vertical a{color:#b3b3b3}.wy-nav .wy-menu-vertical a:hover{background-color:#2980b9;color:#fff}[data-menu-wrap]{-webkit-transition:all .2s ease-in;-moz-transition:all .2s ease-in;transition:all .2s ease-in;position:absolute;opacity:1;width:100%;opacity:0}[data-menu-wrap].move-center{left:0;right:auto;opacity:1}[data-menu-wrap].move-left{right:auto;left:-100%;opacity:0}[data-menu-wrap].move-right{right:-100%;left:auto;opacity:0}.wy-body-for-nav{background:#fcfcfc}.wy-grid-for-nav{position:absolute;width:100%;height:100%}.wy-nav-side{position:fixed;top:0;bottom:0;left:0;padding-bottom:2em;width:300px;overflow-x:hidden;overflow-y:hidden;min-height:100%;color:#9b9b9b;background:#343131;z-index:200}.wy-side-scroll{width:320px;position:relative;overflow-x:hidden;overflow-y:scroll;height:100%}.wy-nav-top{display:none;background:#2980b9;color:#fff;padding:.4045em .809em;position:relative;line-height:50px;text-align:center;font-size:100%;*zoom:1}.wy-nav-top:after,.wy-nav-top:before{display:table;content:""}.wy-nav-top:after{clear:both}.wy-nav-top a{color:#fff;font-weight:700}.wy-nav-top img{margin-right:12px;height:45px;width:45px;background-color:#2980b9;padding:5px;border-radius:100%}.wy-nav-top i{font-size:30px;float:left;cursor:pointer;padding-top:inherit}.wy-nav-content-wrap{margin-left:300px;background:#fcfcfc;min-height:100%}.wy-nav-content{padding:1.618em 3.236em;height:100%;max-width:800px;margin:auto}.wy-body-mask{position:fixed;width:100%;height:100%;background:rgba(0,0,0,.2);display:none;z-index:499}.wy-body-mask.on{display:block}footer{color:grey}footer p{margin-bottom:12px}.rst-content footer span.commit tt,footer span.commit .rst-content tt,footer span.commit code{padding:0;font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;font-size:1em;background:none;border:none;color:grey}.rst-footer-buttons{*zoom:1}.rst-footer-buttons:after,.rst-footer-buttons:before{width:100%;display:table;content:""}.rst-footer-buttons:after{clear:both}.rst-breadcrumbs-buttons{margin-top:12px;*zoom:1}.rst-breadcrumbs-buttons:after,.rst-breadcrumbs-buttons:before{display:table;content:""}.rst-breadcrumbs-buttons:after{clear:both}#search-results .search li{margin-bottom:24px;border-bottom:1px solid #e1e4e5;padding-bottom:24px}#search-results .search li:first-child{border-top:1px solid #e1e4e5;padding-top:24px}#search-results .search li a{font-size:120%;margin-bottom:12px;display:inline-block}#search-results .context{color:grey;font-size:90%}.genindextable li>ul{margin-left:24px}@media screen and (max-width:768px){.wy-body-for-nav{background:#fcfcfc}.wy-nav-top{display:block}.wy-nav-side{left:-300px}.wy-nav-side.shift{width:85%;left:0}.wy-menu.wy-menu-vertical,.wy-side-nav-search,.wy-side-scroll{width:auto}.wy-nav-content-wrap{margin-left:0}.wy-nav-content-wrap .wy-nav-content{padding:1.618em}.wy-nav-content-wrap.shift{position:fixed;min-width:100%;left:85%;top:0;height:100%;overflow:hidden}}@media screen and (min-width:1100px){.wy-nav-content-wrap{background:rgba(0,0,0,.05)}.wy-nav-content{margin:0;background:#fcfcfc}}@media print{.rst-versions,.wy-nav-side,footer{display:none}.wy-nav-content-wrap{margin-left:0}}.rst-versions{position:fixed;bottom:0;left:0;width:300px;color:#fcfcfc;background:#1f1d1d;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;z-index:400}.rst-versions a{color:#2980b9;text-decoration:none}.rst-versions .rst-badge-small{display:none}.rst-versions .rst-current-version{padding:12px;background-color:#272525;display:block;text-align:right;font-size:90%;cursor:pointer;color:#27ae60;*zoom:1}.rst-versions .rst-current-version:after,.rst-versions .rst-current-version:before{display:table;content:""}.rst-versions .rst-current-version:after{clear:both}.rst-content .code-block-caption .rst-versions .rst-current-version .headerlink,.rst-content .eqno .rst-versions .rst-current-version .headerlink,.rst-content .rst-versions .rst-current-version .admonition-title,.rst-content code.download .rst-versions .rst-current-version span:first-child,.rst-content dl dt .rst-versions .rst-current-version .headerlink,.rst-content h1 .rst-versions .rst-current-version .headerlink,.rst-content h2 .rst-versions .rst-current-version .headerlink,.rst-content h3 .rst-versions .rst-current-version .headerlink,.rst-content h4 .rst-versions .rst-current-version .headerlink,.rst-content h5 .rst-versions .rst-current-version .headerlink,.rst-content h6 .rst-versions .rst-current-version .headerlink,.rst-content p .rst-versions .rst-current-version .headerlink,.rst-content table>caption .rst-versions .rst-current-version .headerlink,.rst-content tt.download .rst-versions .rst-current-version span:first-child,.rst-versions .rst-current-version .fa,.rst-versions .rst-current-version .icon,.rst-versions .rst-current-version .rst-content .admonition-title,.rst-versions .rst-current-version .rst-content .code-block-caption .headerlink,.rst-versions .rst-current-version .rst-content .eqno .headerlink,.rst-versions .rst-current-version .rst-content code.download span:first-child,.rst-versions .rst-current-version .rst-content dl dt .headerlink,.rst-versions .rst-current-version .rst-content h1 .headerlink,.rst-versions .rst-current-version .rst-content h2 .headerlink,.rst-versions .rst-current-version .rst-content h3 .headerlink,.rst-versions .rst-current-version .rst-content h4 .headerlink,.rst-versions .rst-current-version .rst-content h5 .headerlink,.rst-versions .rst-current-version .rst-content h6 .headerlink,.rst-versions .rst-current-version .rst-content p .headerlink,.rst-versions .rst-current-version .rst-content table>caption .headerlink,.rst-versions .rst-current-version .rst-content tt.download span:first-child,.rst-versions .rst-current-version .wy-menu-vertical li button.toctree-expand,.wy-menu-vertical li .rst-versions .rst-current-version button.toctree-expand{color:#fcfcfc}.rst-versions .rst-current-version .fa-book,.rst-versions .rst-current-version .icon-book{float:left}.rst-versions .rst-current-version.rst-out-of-date{background-color:#e74c3c;color:#fff}.rst-versions .rst-current-version.rst-active-old-version{background-color:#f1c40f;color:#000}.rst-versions.shift-up{height:auto;max-height:100%;overflow-y:scroll}.rst-versions.shift-up .rst-other-versions{display:block}.rst-versions .rst-other-versions{font-size:90%;padding:12px;color:grey;display:none}.rst-versions .rst-other-versions hr{display:block;height:1px;border:0;margin:20px 0;padding:0;border-top:1px solid #413d3d}.rst-versions .rst-other-versions dd{display:inline-block;margin:0}.rst-versions .rst-other-versions dd a{display:inline-block;padding:6px;color:#fcfcfc}.rst-versions .rst-other-versions .rtd-current-item{font-weight:700}.rst-versions.rst-badge{width:auto;bottom:20px;right:20px;left:auto;border:none;max-width:300px;max-height:90%}.rst-versions.rst-badge .fa-book,.rst-versions.rst-badge .icon-book{float:none;line-height:30px}.rst-versions.rst-badge.shift-up .rst-current-version{text-align:right}.rst-versions.rst-badge.shift-up .rst-current-version .fa-book,.rst-versions.rst-badge.shift-up .rst-current-version .icon-book{float:left}.rst-versions.rst-badge>.rst-current-version{width:auto;height:30px;line-height:30px;padding:0 6px;display:block;text-align:center}@media screen and (max-width:768px){.rst-versions{width:85%;display:none}.rst-versions.shift{display:block}}#flyout-search-form{padding:6px}.rst-content .toctree-wrapper>p.caption,.rst-content h1,.rst-content h2,.rst-content h3,.rst-content h4,.rst-content h5,.rst-content h6{margin-bottom:24px}.rst-content img{max-width:100%;height:auto}.rst-content div.figure,.rst-content figure{margin-bottom:24px}.rst-content div.figure .caption-text,.rst-content figure .caption-text{font-style:italic}.rst-content div.figure p:last-child.caption,.rst-content figure p:last-child.caption{margin-bottom:0}.rst-content div.figure.align-center,.rst-content figure.align-center{text-align:center}.rst-content .section>a>img,.rst-content .section>img,.rst-content section>a>img,.rst-content section>img{margin-bottom:24px}.rst-content abbr[title]{text-decoration:none}.rst-content.style-external-links a.reference.external:after{font-family:FontAwesome;content:"\f08e";color:#b3b3b3;vertical-align:super;font-size:60%;margin:0 .2em}.rst-content blockquote{margin-left:24px;line-height:24px;margin-bottom:24px}.rst-content pre.literal-block{white-space:pre;margin:0;padding:12px;font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;display:block;overflow:auto}.rst-content div[class^=highlight],.rst-content pre.literal-block{border:1px solid #e1e4e5;overflow-x:auto;margin:1px 0 24px}.rst-content div[class^=highlight] div[class^=highlight],.rst-content pre.literal-block div[class^=highlight]{padding:0;border:none;margin:0}.rst-content div[class^=highlight] td.code{width:100%}.rst-content .linenodiv pre{border-right:1px solid #e6e9ea;margin:0;padding:12px;font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;user-select:none;pointer-events:none}.rst-content div[class^=highlight] pre{white-space:pre;margin:0;padding:12px;display:block;overflow:auto}.rst-content div[class^=highlight] pre .hll{display:block;margin:0 -12px;padding:0 12px}.rst-content .linenodiv pre,.rst-content div[class^=highlight] pre,.rst-content pre.literal-block{font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;font-size:12px;line-height:1.4}.rst-content div.highlight .gp,.rst-content div.highlight span.linenos{user-select:none;pointer-events:none}.rst-content div.highlight span.linenos{display:inline-block;padding-left:0;padding-right:12px;margin-right:12px;border-right:1px solid #e6e9ea}.rst-content .code-block-caption{font-style:italic;font-size:85%;line-height:1;padding:1em 0;text-align:center}@media print{.rst-content .codeblock,.rst-content div[class^=highlight],.rst-content div[class^=highlight] pre{white-space:pre-wrap}}.rst-content .admonition,.rst-content .admonition-todo,.rst-content .attention,.rst-content .caution,.rst-content .danger,.rst-content .error,.rst-content .hint,.rst-content .important,.rst-content .note,.rst-content .seealso,.rst-content .tip,.rst-content .warning{clear:both}.rst-content .admonition-todo .last,.rst-content .admonition-todo>:last-child,.rst-content .admonition .last,.rst-content .admonition>:last-child,.rst-content .attention .last,.rst-content .attention>:last-child,.rst-content .caution .last,.rst-content .caution>:last-child,.rst-content .danger .last,.rst-content .danger>:last-child,.rst-content .error .last,.rst-content .error>:last-child,.rst-content .hint .last,.rst-content .hint>:last-child,.rst-content .important .last,.rst-content .important>:last-child,.rst-content .note .last,.rst-content .note>:last-child,.rst-content .seealso .last,.rst-content .seealso>:last-child,.rst-content .tip .last,.rst-content .tip>:last-child,.rst-content .warning .last,.rst-content .warning>:last-child{margin-bottom:0}.rst-content .admonition-title:before{margin-right:4px}.rst-content .admonition table{border-color:rgba(0,0,0,.1)}.rst-content .admonition table td,.rst-content .admonition table th{background:transparent!important;border-color:rgba(0,0,0,.1)!important}.rst-content .section ol.loweralpha,.rst-content .section ol.loweralpha>li,.rst-content .toctree-wrapper ol.loweralpha,.rst-content .toctree-wrapper ol.loweralpha>li,.rst-content section ol.loweralpha,.rst-content section ol.loweralpha>li{list-style:lower-alpha}.rst-content .section ol.upperalpha,.rst-content .section ol.upperalpha>li,.rst-content .toctree-wrapper ol.upperalpha,.rst-content .toctree-wrapper ol.upperalpha>li,.rst-content section ol.upperalpha,.rst-content section ol.upperalpha>li{list-style:upper-alpha}.rst-content .section ol li>*,.rst-content .section ul li>*,.rst-content .toctree-wrapper ol li>*,.rst-content .toctree-wrapper ul li>*,.rst-content section ol li>*,.rst-content section ul li>*{margin-top:12px;margin-bottom:12px}.rst-content .section ol li>:first-child,.rst-content .section ul li>:first-child,.rst-content .toctree-wrapper ol li>:first-child,.rst-content .toctree-wrapper ul li>:first-child,.rst-content section ol li>:first-child,.rst-content section ul li>:first-child{margin-top:0}.rst-content .section ol li>p,.rst-content .section ol li>p:last-child,.rst-content .section ul li>p,.rst-content .section ul li>p:last-child,.rst-content .toctree-wrapper ol li>p,.rst-content .toctree-wrapper ol li>p:last-child,.rst-content .toctree-wrapper ul li>p,.rst-content .toctree-wrapper ul li>p:last-child,.rst-content section ol li>p,.rst-content section ol li>p:last-child,.rst-content section ul li>p,.rst-content section ul li>p:last-child{margin-bottom:12px}.rst-content .section ol li>p:only-child,.rst-content .section ol li>p:only-child:last-child,.rst-content .section ul li>p:only-child,.rst-content .section ul li>p:only-child:last-child,.rst-content .toctree-wrapper ol li>p:only-child,.rst-content .toctree-wrapper ol li>p:only-child:last-child,.rst-content .toctree-wrapper ul li>p:only-child,.rst-content .toctree-wrapper ul li>p:only-child:last-child,.rst-content section ol li>p:only-child,.rst-content section ol li>p:only-child:last-child,.rst-content section ul li>p:only-child,.rst-content section ul li>p:only-child:last-child{margin-bottom:0}.rst-content .section ol li>ol,.rst-content .section ol li>ul,.rst-content .section ul li>ol,.rst-content .section ul li>ul,.rst-content .toctree-wrapper ol li>ol,.rst-content .toctree-wrapper ol li>ul,.rst-content .toctree-wrapper ul li>ol,.rst-content .toctree-wrapper ul li>ul,.rst-content section ol li>ol,.rst-content section ol li>ul,.rst-content section ul li>ol,.rst-content section ul li>ul{margin-bottom:12px}.rst-content .section ol.simple li>*,.rst-content .section ol.simple li ol,.rst-content .section ol.simple li ul,.rst-content .section ul.simple li>*,.rst-content .section ul.simple li ol,.rst-content .section ul.simple li ul,.rst-content .toctree-wrapper ol.simple li>*,.rst-content .toctree-wrapper ol.simple li ol,.rst-content .toctree-wrapper ol.simple li ul,.rst-content .toctree-wrapper ul.simple li>*,.rst-content .toctree-wrapper ul.simple li ol,.rst-content .toctree-wrapper ul.simple li ul,.rst-content section ol.simple li>*,.rst-content section ol.simple li ol,.rst-content section ol.simple li ul,.rst-content section ul.simple li>*,.rst-content section ul.simple li ol,.rst-content section ul.simple li ul{margin-top:0;margin-bottom:0}.rst-content .line-block{margin-left:0;margin-bottom:24px;line-height:24px}.rst-content .line-block .line-block{margin-left:24px;margin-bottom:0}.rst-content .topic-title{font-weight:700;margin-bottom:12px}.rst-content .toc-backref{color:#404040}.rst-content .align-right{float:right;margin:0 0 24px 24px}.rst-content .align-left{float:left;margin:0 24px 24px 0}.rst-content .align-center{margin:auto}.rst-content .align-center:not(table){display:block}.rst-content .code-block-caption .headerlink,.rst-content .eqno .headerlink,.rst-content .toctree-wrapper>p.caption .headerlink,.rst-content dl dt .headerlink,.rst-content h1 .headerlink,.rst-content h2 .headerlink,.rst-content h3 .headerlink,.rst-content h4 .headerlink,.rst-content h5 .headerlink,.rst-content h6 .headerlink,.rst-content p.caption .headerlink,.rst-content p .headerlink,.rst-content table>caption .headerlink{opacity:0;font-size:14px;font-family:FontAwesome;margin-left:.5em}.rst-content .code-block-caption .headerlink:focus,.rst-content .code-block-caption:hover .headerlink,.rst-content .eqno .headerlink:focus,.rst-content .eqno:hover .headerlink,.rst-content .toctree-wrapper>p.caption .headerlink:focus,.rst-content .toctree-wrapper>p.caption:hover .headerlink,.rst-content dl dt .headerlink:focus,.rst-content dl dt:hover .headerlink,.rst-content h1 .headerlink:focus,.rst-content h1:hover .headerlink,.rst-content h2 .headerlink:focus,.rst-content h2:hover .headerlink,.rst-content h3 .headerlink:focus,.rst-content h3:hover .headerlink,.rst-content h4 .headerlink:focus,.rst-content h4:hover .headerlink,.rst-content h5 .headerlink:focus,.rst-content h5:hover .headerlink,.rst-content h6 .headerlink:focus,.rst-content h6:hover .headerlink,.rst-content p.caption .headerlink:focus,.rst-content p.caption:hover .headerlink,.rst-content p .headerlink:focus,.rst-content p:hover .headerlink,.rst-content table>caption .headerlink:focus,.rst-content table>caption:hover .headerlink{opacity:1}.rst-content p a{overflow-wrap:anywhere}.rst-content .wy-table td p,.rst-content .wy-table td ul,.rst-content .wy-table th p,.rst-content .wy-table th ul,.rst-content table.docutils td p,.rst-content table.docutils td ul,.rst-content table.docutils th p,.rst-content table.docutils th ul,.rst-content table.field-list td p,.rst-content table.field-list td ul,.rst-content table.field-list th p,.rst-content table.field-list th ul{font-size:inherit}.rst-content .btn:focus{outline:2px solid}.rst-content table>caption .headerlink:after{font-size:12px}.rst-content .centered{text-align:center}.rst-content .sidebar{float:right;width:40%;display:block;margin:0 0 24px 24px;padding:24px;background:#f3f6f6;border:1px solid #e1e4e5}.rst-content .sidebar dl,.rst-content .sidebar p,.rst-content .sidebar ul{font-size:90%}.rst-content .sidebar .last,.rst-content .sidebar>:last-child{margin-bottom:0}.rst-content .sidebar .sidebar-title{display:block;font-family:Roboto Slab,ff-tisa-web-pro,Georgia,Arial,sans-serif;font-weight:700;background:#e1e4e5;padding:6px 12px;margin:-24px -24px 24px;font-size:100%}.rst-content .highlighted{background:#f1c40f;box-shadow:0 0 0 2px #f1c40f;display:inline;font-weight:700}.rst-content .citation-reference,.rst-content .footnote-reference{vertical-align:baseline;position:relative;top:-.4em;line-height:0;font-size:90%}.rst-content .citation-reference>span.fn-bracket,.rst-content .footnote-reference>span.fn-bracket{display:none}.rst-content .hlist{width:100%}.rst-content dl dt span.classifier:before{content:" : "}.rst-content dl dt span.classifier-delimiter{display:none!important}html.writer-html4 .rst-content table.docutils.citation,html.writer-html4 .rst-content table.docutils.footnote{background:none;border:none}html.writer-html4 .rst-content table.docutils.citation td,html.writer-html4 .rst-content table.docutils.citation tr,html.writer-html4 .rst-content table.docutils.footnote td,html.writer-html4 .rst-content table.docutils.footnote tr{border:none;background-color:transparent!important;white-space:normal}html.writer-html4 .rst-content table.docutils.citation td.label,html.writer-html4 .rst-content table.docutils.footnote td.label{padding-left:0;padding-right:0;vertical-align:top}html.writer-html5 .rst-content dl.citation,html.writer-html5 .rst-content dl.field-list,html.writer-html5 .rst-content dl.footnote{display:grid;grid-template-columns:auto minmax(80%,95%)}html.writer-html5 .rst-content dl.citation>dt,html.writer-html5 .rst-content dl.field-list>dt,html.writer-html5 .rst-content dl.footnote>dt{display:inline-grid;grid-template-columns:max-content auto}html.writer-html5 .rst-content aside.citation,html.writer-html5 .rst-content aside.footnote,html.writer-html5 .rst-content div.citation{display:grid;grid-template-columns:auto auto minmax(.65rem,auto) minmax(40%,95%)}html.writer-html5 .rst-content aside.citation>span.label,html.writer-html5 .rst-content aside.footnote>span.label,html.writer-html5 .rst-content div.citation>span.label{grid-column-start:1;grid-column-end:2}html.writer-html5 .rst-content aside.citation>span.backrefs,html.writer-html5 .rst-content aside.footnote>span.backrefs,html.writer-html5 .rst-content div.citation>span.backrefs{grid-column-start:2;grid-column-end:3;grid-row-start:1;grid-row-end:3}html.writer-html5 .rst-content aside.citation>p,html.writer-html5 .rst-content aside.footnote>p,html.writer-html5 .rst-content div.citation>p{grid-column-start:4;grid-column-end:5}html.writer-html5 .rst-content dl.citation,html.writer-html5 .rst-content dl.field-list,html.writer-html5 .rst-content dl.footnote{margin-bottom:24px}html.writer-html5 .rst-content dl.citation>dt,html.writer-html5 .rst-content dl.field-list>dt,html.writer-html5 .rst-content dl.footnote>dt{padding-left:1rem}html.writer-html5 .rst-content dl.citation>dd,html.writer-html5 .rst-content dl.citation>dt,html.writer-html5 .rst-content dl.field-list>dd,html.writer-html5 .rst-content dl.field-list>dt,html.writer-html5 .rst-content dl.footnote>dd,html.writer-html5 .rst-content dl.footnote>dt{margin-bottom:0}html.writer-html5 .rst-content dl.citation,html.writer-html5 .rst-content dl.footnote{font-size:.9rem}html.writer-html5 .rst-content dl.citation>dt,html.writer-html5 .rst-content dl.footnote>dt{margin:0 .5rem .5rem 0;line-height:1.2rem;word-break:break-all;font-weight:400}html.writer-html5 .rst-content dl.citation>dt>span.brackets:before,html.writer-html5 .rst-content dl.footnote>dt>span.brackets:before{content:"["}html.writer-html5 .rst-content dl.citation>dt>span.brackets:after,html.writer-html5 .rst-content dl.footnote>dt>span.brackets:after{content:"]"}html.writer-html5 .rst-content dl.citation>dt>span.fn-backref,html.writer-html5 .rst-content dl.footnote>dt>span.fn-backref{text-align:left;font-style:italic;margin-left:.65rem;word-break:break-word;word-spacing:-.1rem;max-width:5rem}html.writer-html5 .rst-content dl.citation>dt>span.fn-backref>a,html.writer-html5 .rst-content dl.footnote>dt>span.fn-backref>a{word-break:keep-all}html.writer-html5 .rst-content dl.citation>dt>span.fn-backref>a:not(:first-child):before,html.writer-html5 .rst-content dl.footnote>dt>span.fn-backref>a:not(:first-child):before{content:" "}html.writer-html5 .rst-content dl.citation>dd,html.writer-html5 .rst-content dl.footnote>dd{margin:0 0 .5rem;line-height:1.2rem}html.writer-html5 .rst-content dl.citation>dd p,html.writer-html5 .rst-content dl.footnote>dd p{font-size:.9rem}html.writer-html5 .rst-content aside.citation,html.writer-html5 .rst-content aside.footnote,html.writer-html5 .rst-content div.citation{padding-left:1rem;padding-right:1rem;font-size:.9rem;line-height:1.2rem}html.writer-html5 .rst-content aside.citation p,html.writer-html5 .rst-content aside.footnote p,html.writer-html5 .rst-content div.citation p{font-size:.9rem;line-height:1.2rem;margin-bottom:12px}html.writer-html5 .rst-content aside.citation span.backrefs,html.writer-html5 .rst-content aside.footnote span.backrefs,html.writer-html5 .rst-content div.citation span.backrefs{text-align:left;font-style:italic;margin-left:.65rem;word-break:break-word;word-spacing:-.1rem;max-width:5rem}html.writer-html5 .rst-content aside.citation span.backrefs>a,html.writer-html5 .rst-content aside.footnote span.backrefs>a,html.writer-html5 .rst-content div.citation span.backrefs>a{word-break:keep-all}html.writer-html5 .rst-content aside.citation span.backrefs>a:not(:first-child):before,html.writer-html5 .rst-content aside.footnote span.backrefs>a:not(:first-child):before,html.writer-html5 .rst-content div.citation span.backrefs>a:not(:first-child):before{content:" "}html.writer-html5 .rst-content aside.citation span.label,html.writer-html5 .rst-content aside.footnote span.label,html.writer-html5 .rst-content div.citation span.label{line-height:1.2rem}html.writer-html5 .rst-content aside.citation-list,html.writer-html5 .rst-content aside.footnote-list,html.writer-html5 .rst-content div.citation-list{margin-bottom:24px}html.writer-html5 .rst-content dl.option-list kbd{font-size:.9rem}.rst-content table.docutils.footnote,html.writer-html4 .rst-content table.docutils.citation,html.writer-html5 .rst-content aside.footnote,html.writer-html5 .rst-content aside.footnote-list aside.footnote,html.writer-html5 .rst-content div.citation-list>div.citation,html.writer-html5 .rst-content dl.citation,html.writer-html5 .rst-content dl.footnote{color:grey}.rst-content table.docutils.footnote code,.rst-content table.docutils.footnote tt,html.writer-html4 .rst-content table.docutils.citation code,html.writer-html4 .rst-content table.docutils.citation tt,html.writer-html5 .rst-content aside.footnote-list aside.footnote code,html.writer-html5 .rst-content aside.footnote-list aside.footnote tt,html.writer-html5 .rst-content aside.footnote code,html.writer-html5 .rst-content aside.footnote tt,html.writer-html5 .rst-content div.citation-list>div.citation code,html.writer-html5 .rst-content div.citation-list>div.citation tt,html.writer-html5 .rst-content dl.citation code,html.writer-html5 .rst-content dl.citation tt,html.writer-html5 .rst-content dl.footnote code,html.writer-html5 .rst-content dl.footnote tt{color:#555}.rst-content .wy-table-responsive.citation,.rst-content .wy-table-responsive.footnote{margin-bottom:0}.rst-content .wy-table-responsive.citation+:not(.citation),.rst-content .wy-table-responsive.footnote+:not(.footnote){margin-top:24px}.rst-content .wy-table-responsive.citation:last-child,.rst-content .wy-table-responsive.footnote:last-child{margin-bottom:24px}.rst-content table.docutils th{border-color:#e1e4e5}html.writer-html5 .rst-content table.docutils th{border:1px solid #e1e4e5}html.writer-html5 .rst-content table.docutils td>p,html.writer-html5 .rst-content table.docutils th>p{line-height:1rem;margin-bottom:0;font-size:.9rem}.rst-content table.docutils td .last,.rst-content table.docutils td .last>:last-child{margin-bottom:0}.rst-content table.field-list,.rst-content table.field-list td{border:none}.rst-content table.field-list td p{line-height:inherit}.rst-content table.field-list td>strong{display:inline-block}.rst-content table.field-list .field-name{padding-right:10px;text-align:left;white-space:nowrap}.rst-content table.field-list .field-body{text-align:left}.rst-content code,.rst-content tt{color:#000;font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;padding:2px 5px}.rst-content code big,.rst-content code em,.rst-content tt big,.rst-content tt em{font-size:100%!important;line-height:normal}.rst-content code.literal,.rst-content tt.literal{color:#e74c3c;white-space:normal}.rst-content code.xref,.rst-content tt.xref,a .rst-content code,a .rst-content tt{font-weight:700;color:#404040;overflow-wrap:normal}.rst-content kbd,.rst-content pre,.rst-content samp{font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace}.rst-content a code,.rst-content a tt{color:#2980b9}.rst-content dl{margin-bottom:24px}.rst-content dl dt{font-weight:700;margin-bottom:12px}.rst-content dl ol,.rst-content dl p,.rst-content dl table,.rst-content dl ul{margin-bottom:12px}.rst-content dl dd{margin:0 0 12px 24px;line-height:24px}.rst-content dl dd>ol:last-child,.rst-content dl dd>p:last-child,.rst-content dl dd>table:last-child,.rst-content dl dd>ul:last-child{margin-bottom:0}html.writer-html4 .rst-content dl:not(.docutils),html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple){margin-bottom:24px}html.writer-html4 .rst-content dl:not(.docutils)>dt,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt{display:table;margin:6px 0;font-size:90%;line-height:normal;background:#e7f2fa;color:#2980b9;border-top:3px solid #6ab0de;padding:6px;position:relative}html.writer-html4 .rst-content dl:not(.docutils)>dt:before,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt:before{color:#6ab0de}html.writer-html4 .rst-content dl:not(.docutils)>dt .headerlink,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt .headerlink{color:#404040;font-size:100%!important}html.writer-html4 .rst-content dl:not(.docutils) dl:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) dl:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt{margin-bottom:6px;border:none;border-left:3px solid #ccc;background:#f0f0f0;color:#555}html.writer-html4 .rst-content dl:not(.docutils) dl:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt .headerlink,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) dl:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt .headerlink{color:#404040;font-size:100%!important}html.writer-html4 .rst-content dl:not(.docutils)>dt:first-child,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt:first-child{margin-top:0}html.writer-html4 .rst-content dl:not(.docutils) code.descclassname,html.writer-html4 .rst-content dl:not(.docutils) code.descname,html.writer-html4 .rst-content dl:not(.docutils) tt.descclassname,html.writer-html4 .rst-content dl:not(.docutils) tt.descname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) code.descclassname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) code.descname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) tt.descclassname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) tt.descname{background-color:transparent;border:none;padding:0;font-size:100%!important}html.writer-html4 .rst-content dl:not(.docutils) code.descname,html.writer-html4 .rst-content dl:not(.docutils) tt.descname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) code.descname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) tt.descname{font-weight:700}html.writer-html4 .rst-content dl:not(.docutils) .optional,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .optional{display:inline-block;padding:0 4px;color:#000;font-weight:700}html.writer-html4 .rst-content dl:not(.docutils) .property,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .property{display:inline-block;padding-right:8px;max-width:100%}html.writer-html4 .rst-content dl:not(.docutils) .k,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .k{font-style:italic}html.writer-html4 .rst-content dl:not(.docutils) .descclassname,html.writer-html4 .rst-content dl:not(.docutils) .descname,html.writer-html4 .rst-content dl:not(.docutils) .sig-name,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .descclassname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .descname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .sig-name{font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;color:#000}.rst-content .viewcode-back,.rst-content .viewcode-link{display:inline-block;color:#27ae60;font-size:80%;padding-left:24px}.rst-content .viewcode-back{display:block;float:right}.rst-content p.rubric{margin-bottom:12px;font-weight:700}.rst-content code.download,.rst-content tt.download{background:inherit;padding:inherit;font-weight:400;font-family:inherit;font-size:inherit;color:inherit;border:inherit;white-space:inherit}.rst-content code.download span:first-child,.rst-content tt.download span:first-child{-webkit-font-smoothing:subpixel-antialiased}.rst-content code.download span:first-child:before,.rst-content tt.download span:first-child:before{margin-right:4px}.rst-content .guilabel,.rst-content .menuselection{font-size:80%;font-weight:700;border-radius:4px;padding:2.4px 6px;margin:auto 2px}.rst-content .guilabel,.rst-content .menuselection{border:1px solid #7fbbe3;background:#e7f2fa}.rst-content :not(dl.option-list)>:not(dt):not(kbd):not(.kbd)>.kbd,.rst-content :not(dl.option-list)>:not(dt):not(kbd):not(.kbd)>kbd{color:inherit;font-size:80%;background-color:#fff;border:1px solid #a6a6a6;border-radius:4px;box-shadow:0 2px grey;padding:2.4px 6px;margin:auto 0}.rst-content .versionmodified{font-style:italic}@media screen and (max-width:480px){.rst-content .sidebar{width:100%}}span[id*=MathJax-Span]{color:#404040}.math{text-align:center}@font-face{font-family:Lato;src:url(fonts/lato-normal.woff2?bd03a2cc277bbbc338d464e679fe9942) format("woff2"),url(fonts/lato-normal.woff?27bd77b9162d388cb8d4c4217c7c5e2a) format("woff");font-weight:400;font-style:normal;font-display:block}@font-face{font-family:Lato;src:url(fonts/lato-bold.woff2?cccb897485813c7c256901dbca54ecf2) format("woff2"),url(fonts/lato-bold.woff?d878b6c29b10beca227e9eef4246111b) format("woff");font-weight:700;font-style:normal;font-display:block}@font-face{font-family:Lato;src:url(fonts/lato-bold-italic.woff2?0b6bb6725576b072c5d0b02ecdd1900d) format("woff2"),url(fonts/lato-bold-italic.woff?9c7e4e9eb485b4a121c760e61bc3707c) format("woff");font-weight:700;font-style:italic;font-display:block}@font-face{font-family:Lato;src:url(fonts/lato-normal-italic.woff2?4eb103b4d12be57cb1d040ed5e162e9d) format("woff2"),url(fonts/lato-normal-italic.woff?f28f2d6482446544ef1ea1ccc6dd5892) format("woff");font-weight:400;font-style:italic;font-display:block}@font-face{font-family:Roboto Slab;font-style:normal;font-weight:400;src:url(fonts/Roboto-Slab-Regular.woff2?7abf5b8d04d26a2cafea937019bca958) format("woff2"),url(fonts/Roboto-Slab-Regular.woff?c1be9284088d487c5e3ff0a10a92e58c) format("woff");font-display:block}@font-face{font-family:Roboto Slab;font-style:normal;font-weight:700;src:url(fonts/Roboto-Slab-Bold.woff2?9984f4a9bda09be08e83f2506954adbe) format("woff2"),url(fonts/Roboto-Slab-Bold.woff?bed5564a116b05148e3b3bea6fb1162a) format("woff");font-display:block} \ No newline at end of file diff --git a/previews/271/_static/doctools.js b/previews/271/_static/doctools.js new file mode 100644 index 000000000..0398ebb9f --- /dev/null +++ b/previews/271/_static/doctools.js @@ -0,0 +1,149 @@ +/* + * Base JavaScript utilities for all Sphinx HTML documentation. + */ +"use strict"; + +const BLACKLISTED_KEY_CONTROL_ELEMENTS = new Set([ + "TEXTAREA", + "INPUT", + "SELECT", + "BUTTON", +]); + +const _ready = (callback) => { + if (document.readyState !== "loading") { + callback(); + } else { + document.addEventListener("DOMContentLoaded", callback); + } +}; + +/** + * Small JavaScript module for the documentation. + */ +const Documentation = { + init: () => { + Documentation.initDomainIndexTable(); + Documentation.initOnKeyListeners(); + }, + + /** + * i18n support + */ + TRANSLATIONS: {}, + PLURAL_EXPR: (n) => (n === 1 ? 0 : 1), + LOCALE: "unknown", + + // gettext and ngettext don't access this so that the functions + // can safely bound to a different name (_ = Documentation.gettext) + gettext: (string) => { + const translated = Documentation.TRANSLATIONS[string]; + switch (typeof translated) { + case "undefined": + return string; // no translation + case "string": + return translated; // translation exists + default: + return translated[0]; // (singular, plural) translation tuple exists + } + }, + + ngettext: (singular, plural, n) => { + const translated = Documentation.TRANSLATIONS[singular]; + if (typeof translated !== "undefined") + return translated[Documentation.PLURAL_EXPR(n)]; + return n === 1 ? singular : plural; + }, + + addTranslations: (catalog) => { + Object.assign(Documentation.TRANSLATIONS, catalog.messages); + Documentation.PLURAL_EXPR = new Function( + "n", + `return (${catalog.plural_expr})` + ); + Documentation.LOCALE = catalog.locale; + }, + + /** + * helper function to focus on search bar + */ + focusSearchBar: () => { + document.querySelectorAll("input[name=q]")[0]?.focus(); + }, + + /** + * Initialise the domain index toggle buttons + */ + initDomainIndexTable: () => { + const toggler = (el) => { + const idNumber = el.id.substr(7); + const toggledRows = document.querySelectorAll(`tr.cg-${idNumber}`); + if (el.src.substr(-9) === "minus.png") { + el.src = `${el.src.substr(0, el.src.length - 9)}plus.png`; + toggledRows.forEach((el) => (el.style.display = "none")); + } else { + el.src = `${el.src.substr(0, el.src.length - 8)}minus.png`; + toggledRows.forEach((el) => (el.style.display = "")); + } + }; + + const togglerElements = document.querySelectorAll("img.toggler"); + togglerElements.forEach((el) => + el.addEventListener("click", (event) => toggler(event.currentTarget)) + ); + togglerElements.forEach((el) => (el.style.display = "")); + if (DOCUMENTATION_OPTIONS.COLLAPSE_INDEX) togglerElements.forEach(toggler); + }, + + initOnKeyListeners: () => { + // only install a listener if it is really needed + if ( + !DOCUMENTATION_OPTIONS.NAVIGATION_WITH_KEYS && + !DOCUMENTATION_OPTIONS.ENABLE_SEARCH_SHORTCUTS + ) + return; + + document.addEventListener("keydown", (event) => { + // bail for input elements + if (BLACKLISTED_KEY_CONTROL_ELEMENTS.has(document.activeElement.tagName)) return; + // bail with special keys + if (event.altKey || event.ctrlKey || event.metaKey) return; + + if (!event.shiftKey) { + switch (event.key) { + case "ArrowLeft": + if (!DOCUMENTATION_OPTIONS.NAVIGATION_WITH_KEYS) break; + + const prevLink = document.querySelector('link[rel="prev"]'); + if (prevLink && prevLink.href) { + window.location.href = prevLink.href; + event.preventDefault(); + } + break; + case "ArrowRight": + if (!DOCUMENTATION_OPTIONS.NAVIGATION_WITH_KEYS) break; + + const nextLink = document.querySelector('link[rel="next"]'); + if (nextLink && nextLink.href) { + window.location.href = nextLink.href; + event.preventDefault(); + } + break; + } + } + + // some keyboard layouts may need Shift to get / + switch (event.key) { + case "/": + if (!DOCUMENTATION_OPTIONS.ENABLE_SEARCH_SHORTCUTS) break; + Documentation.focusSearchBar(); + event.preventDefault(); + } + }); + }, +}; + +// quick alias for translations +const _ = Documentation.gettext; + +_ready(Documentation.init); diff --git a/previews/271/_static/documentation_options.js b/previews/271/_static/documentation_options.js new file mode 100644 index 000000000..7e4c114f2 --- /dev/null +++ b/previews/271/_static/documentation_options.js @@ -0,0 +1,13 @@ +const DOCUMENTATION_OPTIONS = { + VERSION: '', + LANGUAGE: 'en', + COLLAPSE_INDEX: false, + BUILDER: 'html', + FILE_SUFFIX: '.html', + LINK_SUFFIX: '.html', + HAS_SOURCE: true, + SOURCELINK_SUFFIX: '.txt', + NAVIGATION_WITH_KEYS: false, + SHOW_SEARCH_SUMMARY: true, + ENABLE_SEARCH_SHORTCUTS: true, +}; \ No newline at end of file diff --git a/previews/271/_static/favicon.ico b/previews/271/_static/favicon.ico new file mode 100644 index 000000000..a817310c8 Binary files /dev/null and b/previews/271/_static/favicon.ico differ diff --git a/previews/271/_static/file.png b/previews/271/_static/file.png new file mode 100644 index 000000000..a858a410e Binary files /dev/null and b/previews/271/_static/file.png differ diff --git a/previews/271/_static/fonts/Lato/lato-bold.eot b/previews/271/_static/fonts/Lato/lato-bold.eot new file mode 100644 index 000000000..3361183a4 Binary files /dev/null and b/previews/271/_static/fonts/Lato/lato-bold.eot differ diff --git a/previews/271/_static/fonts/Lato/lato-bold.ttf b/previews/271/_static/fonts/Lato/lato-bold.ttf new file mode 100644 index 000000000..29f691d5e Binary files /dev/null and b/previews/271/_static/fonts/Lato/lato-bold.ttf differ diff --git a/previews/271/_static/fonts/Lato/lato-bold.woff b/previews/271/_static/fonts/Lato/lato-bold.woff new file mode 100644 index 000000000..c6dff51f0 Binary files /dev/null and b/previews/271/_static/fonts/Lato/lato-bold.woff differ diff --git a/previews/271/_static/fonts/Lato/lato-bold.woff2 b/previews/271/_static/fonts/Lato/lato-bold.woff2 new file mode 100644 index 000000000..bb195043c Binary files /dev/null and b/previews/271/_static/fonts/Lato/lato-bold.woff2 differ diff --git a/previews/271/_static/fonts/Lato/lato-bolditalic.eot b/previews/271/_static/fonts/Lato/lato-bolditalic.eot new file mode 100644 index 000000000..3d4154936 Binary files /dev/null and b/previews/271/_static/fonts/Lato/lato-bolditalic.eot differ diff --git a/previews/271/_static/fonts/Lato/lato-bolditalic.ttf b/previews/271/_static/fonts/Lato/lato-bolditalic.ttf new file mode 100644 index 000000000..f402040b3 Binary files /dev/null and b/previews/271/_static/fonts/Lato/lato-bolditalic.ttf differ diff --git a/previews/271/_static/fonts/Lato/lato-bolditalic.woff b/previews/271/_static/fonts/Lato/lato-bolditalic.woff new file mode 100644 index 000000000..88ad05b9f Binary files /dev/null and b/previews/271/_static/fonts/Lato/lato-bolditalic.woff differ diff --git a/previews/271/_static/fonts/Lato/lato-bolditalic.woff2 b/previews/271/_static/fonts/Lato/lato-bolditalic.woff2 new file mode 100644 index 000000000..c4e3d804b Binary files /dev/null and b/previews/271/_static/fonts/Lato/lato-bolditalic.woff2 differ diff --git a/previews/271/_static/fonts/Lato/lato-italic.eot b/previews/271/_static/fonts/Lato/lato-italic.eot new file mode 100644 index 000000000..3f826421a Binary files /dev/null and b/previews/271/_static/fonts/Lato/lato-italic.eot differ diff --git a/previews/271/_static/fonts/Lato/lato-italic.ttf b/previews/271/_static/fonts/Lato/lato-italic.ttf new file mode 100644 index 000000000..b4bfc9b24 Binary files /dev/null and b/previews/271/_static/fonts/Lato/lato-italic.ttf differ diff --git a/previews/271/_static/fonts/Lato/lato-italic.woff b/previews/271/_static/fonts/Lato/lato-italic.woff new file mode 100644 index 000000000..76114bc03 Binary files /dev/null and b/previews/271/_static/fonts/Lato/lato-italic.woff differ diff --git a/previews/271/_static/fonts/Lato/lato-italic.woff2 b/previews/271/_static/fonts/Lato/lato-italic.woff2 new file mode 100644 index 000000000..3404f37e2 Binary files /dev/null and b/previews/271/_static/fonts/Lato/lato-italic.woff2 differ diff --git a/previews/271/_static/fonts/Lato/lato-regular.eot b/previews/271/_static/fonts/Lato/lato-regular.eot new file mode 100644 index 000000000..11e3f2a5f Binary files /dev/null and b/previews/271/_static/fonts/Lato/lato-regular.eot differ diff --git a/previews/271/_static/fonts/Lato/lato-regular.ttf b/previews/271/_static/fonts/Lato/lato-regular.ttf new file mode 100644 index 000000000..74decd9eb Binary files /dev/null and b/previews/271/_static/fonts/Lato/lato-regular.ttf differ diff --git a/previews/271/_static/fonts/Lato/lato-regular.woff b/previews/271/_static/fonts/Lato/lato-regular.woff new file mode 100644 index 000000000..ae1307ff5 Binary files /dev/null and b/previews/271/_static/fonts/Lato/lato-regular.woff differ diff --git a/previews/271/_static/fonts/Lato/lato-regular.woff2 b/previews/271/_static/fonts/Lato/lato-regular.woff2 new file mode 100644 index 000000000..3bf984332 Binary files /dev/null and b/previews/271/_static/fonts/Lato/lato-regular.woff2 differ diff --git a/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-bold.eot b/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-bold.eot new file mode 100644 index 000000000..79dc8efed Binary files /dev/null and b/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-bold.eot differ diff --git a/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-bold.ttf b/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-bold.ttf new file mode 100644 index 000000000..df5d1df27 Binary files /dev/null and b/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-bold.ttf differ diff --git a/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-bold.woff b/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-bold.woff new file mode 100644 index 000000000..6cb600001 Binary files /dev/null and b/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-bold.woff differ diff --git a/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-bold.woff2 b/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-bold.woff2 new file mode 100644 index 000000000..7059e2314 Binary files /dev/null and b/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-bold.woff2 differ diff --git a/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-regular.eot b/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-regular.eot new file mode 100644 index 000000000..2f7ca78a1 Binary files /dev/null and b/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-regular.eot differ diff --git a/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-regular.ttf b/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-regular.ttf new file mode 100644 index 000000000..eb52a7907 Binary files /dev/null and b/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-regular.ttf differ diff --git a/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-regular.woff b/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-regular.woff new file mode 100644 index 000000000..f815f63f9 Binary files /dev/null and b/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-regular.woff differ diff --git a/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-regular.woff2 b/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-regular.woff2 new file mode 100644 index 000000000..f2c76e5bd Binary files /dev/null and b/previews/271/_static/fonts/RobotoSlab/roboto-slab-v7-regular.woff2 differ diff --git a/previews/271/_static/googledd12f2e41658d61e.html b/previews/271/_static/googledd12f2e41658d61e.html new file mode 100644 index 000000000..cb695ae9f --- /dev/null +++ b/previews/271/_static/googledd12f2e41658d61e.html @@ -0,0 +1 @@ +google-site-verification: googledd12f2e41658d61e.html \ No newline at end of file diff --git a/previews/271/_static/imx8mm-head.pdf b/previews/271/_static/imx8mm-head.pdf new file mode 100644 index 000000000..6b8fe6be0 Binary files /dev/null and b/previews/271/_static/imx8mm-head.pdf differ diff --git a/previews/271/_static/imx8mm-pd22.1.1.pdf b/previews/271/_static/imx8mm-pd22.1.1.pdf new file mode 100644 index 000000000..2ba47bfe4 Binary files /dev/null and b/previews/271/_static/imx8mm-pd22.1.1.pdf differ diff --git a/previews/271/_static/imx8mm-pd23.1.0.pdf b/previews/271/_static/imx8mm-pd23.1.0.pdf new file mode 100644 index 000000000..e16b9bed9 Binary files /dev/null and b/previews/271/_static/imx8mm-pd23.1.0.pdf differ diff --git a/previews/271/_static/imx8mn-head.pdf b/previews/271/_static/imx8mn-head.pdf new file mode 100644 index 000000000..33beb890e Binary files /dev/null and b/previews/271/_static/imx8mn-head.pdf differ diff --git a/previews/271/_static/imx8mn-pd22.1.1.pdf b/previews/271/_static/imx8mn-pd22.1.1.pdf new file mode 100644 index 000000000..5f0160b62 Binary files /dev/null and b/previews/271/_static/imx8mn-pd22.1.1.pdf differ diff --git a/previews/271/_static/imx8mn-pd23.1.0.pdf b/previews/271/_static/imx8mn-pd23.1.0.pdf new file mode 100644 index 000000000..811aed5b1 Binary files /dev/null and b/previews/271/_static/imx8mn-pd23.1.0.pdf differ diff --git a/previews/271/_static/imx8mp-head.pdf b/previews/271/_static/imx8mp-head.pdf new file mode 100644 index 000000000..84ad42be2 Binary files /dev/null and b/previews/271/_static/imx8mp-head.pdf differ diff --git a/previews/271/_static/imx8mp-libra-fpsc-head.pdf b/previews/271/_static/imx8mp-libra-fpsc-head.pdf new file mode 100644 index 000000000..679b3cc50 Binary files /dev/null and b/previews/271/_static/imx8mp-libra-fpsc-head.pdf differ diff --git a/previews/271/_static/imx8mp-mainline-head.pdf b/previews/271/_static/imx8mp-mainline-head.pdf new file mode 100644 index 000000000..b59b8bc1d Binary files /dev/null and b/previews/271/_static/imx8mp-mainline-head.pdf differ diff --git a/previews/271/_static/imx8mp-pd22.1.1.pdf b/previews/271/_static/imx8mp-pd22.1.1.pdf new file mode 100644 index 000000000..8930921b2 Binary files /dev/null and b/previews/271/_static/imx8mp-pd22.1.1.pdf differ diff --git a/previews/271/_static/imx8mp-pd22.1.2.pdf b/previews/271/_static/imx8mp-pd22.1.2.pdf new file mode 100644 index 000000000..48faba425 Binary files /dev/null and b/previews/271/_static/imx8mp-pd22.1.2.pdf differ diff --git a/previews/271/_static/imx8mp-pd23.1.0.pdf b/previews/271/_static/imx8mp-pd23.1.0.pdf new file mode 100644 index 000000000..fb7e95fcf Binary files /dev/null and b/previews/271/_static/imx8mp-pd23.1.0.pdf differ diff --git a/previews/271/_static/imx8mp-pd24.1.0_nxp.pdf b/previews/271/_static/imx8mp-pd24.1.0_nxp.pdf new file mode 100644 index 000000000..84f31c6b8 Binary files /dev/null and b/previews/271/_static/imx8mp-pd24.1.0_nxp.pdf differ diff --git a/previews/271/_static/imx8mp-pd24.1.1.pdf b/previews/271/_static/imx8mp-pd24.1.1.pdf new file mode 100644 index 000000000..bbf053ab6 Binary files /dev/null and b/previews/271/_static/imx8mp-pd24.1.1.pdf differ diff --git a/previews/271/_static/imx8mp-pd24.1.2.pdf b/previews/271/_static/imx8mp-pd24.1.2.pdf new file mode 100644 index 000000000..221b02711 Binary files /dev/null and b/previews/271/_static/imx8mp-pd24.1.2.pdf differ diff --git a/previews/271/_static/imx93-pd24.1.0.pdf b/previews/271/_static/imx93-pd24.1.0.pdf new file mode 100644 index 000000000..bd9602dae Binary files /dev/null and b/previews/271/_static/imx93-pd24.1.0.pdf differ diff --git a/previews/271/_static/imx93-pd24.1.1.pdf b/previews/271/_static/imx93-pd24.1.1.pdf new file mode 100644 index 000000000..88361f618 Binary files /dev/null and b/previews/271/_static/imx93-pd24.1.1.pdf differ diff --git a/previews/271/_static/imx93-pd24.2.0.pdf b/previews/271/_static/imx93-pd24.2.0.pdf new file mode 100644 index 000000000..0bf5a9972 Binary files /dev/null and b/previews/271/_static/imx93-pd24.2.0.pdf differ diff --git a/previews/271/_static/jquery.js b/previews/271/_static/jquery.js new file mode 100644 index 000000000..c4c6022f2 --- /dev/null +++ b/previews/271/_static/jquery.js @@ -0,0 +1,2 @@ +/*! jQuery v3.6.0 | (c) OpenJS Foundation and other contributors | jquery.org/license */ +!function(e,t){"use strict";"object"==typeof module&&"object"==typeof module.exports?module.exports=e.document?t(e,!0):function(e){if(!e.document)throw new Error("jQuery requires a window with a document");return t(e)}:t(e)}("undefined"!=typeof window?window:this,function(C,e){"use strict";var t=[],r=Object.getPrototypeOf,s=t.slice,g=t.flat?function(e){return t.flat.call(e)}:function(e){return t.concat.apply([],e)},u=t.push,i=t.indexOf,n={},o=n.toString,v=n.hasOwnProperty,a=v.toString,l=a.call(Object),y={},m=function(e){return"function"==typeof e&&"number"!=typeof e.nodeType&&"function"!=typeof e.item},x=function(e){return null!=e&&e===e.window},E=C.document,c={type:!0,src:!0,nonce:!0,noModule:!0};function b(e,t,n){var r,i,o=(n=n||E).createElement("script");if(o.text=e,t)for(r in c)(i=t[r]||t.getAttribute&&t.getAttribute(r))&&o.setAttribute(r,i);n.head.appendChild(o).parentNode.removeChild(o)}function w(e){return null==e?e+"":"object"==typeof e||"function"==typeof e?n[o.call(e)]||"object":typeof e}var f="3.6.0",S=function(e,t){return new S.fn.init(e,t)};function p(e){var t=!!e&&"length"in e&&e.length,n=w(e);return!m(e)&&!x(e)&&("array"===n||0===t||"number"==typeof t&&0+~]|"+M+")"+M+"*"),U=new RegExp(M+"|>"),X=new RegExp(F),V=new RegExp("^"+I+"$"),G={ID:new RegExp("^#("+I+")"),CLASS:new RegExp("^\\.("+I+")"),TAG:new RegExp("^("+I+"|[*])"),ATTR:new RegExp("^"+W),PSEUDO:new RegExp("^"+F),CHILD:new RegExp("^:(only|first|last|nth|nth-last)-(child|of-type)(?:\\("+M+"*(even|odd|(([+-]|)(\\d*)n|)"+M+"*(?:([+-]|)"+M+"*(\\d+)|))"+M+"*\\)|)","i"),bool:new RegExp("^(?:"+R+")$","i"),needsContext:new RegExp("^"+M+"*[>+~]|:(even|odd|eq|gt|lt|nth|first|last)(?:\\("+M+"*((?:-\\d)?\\d*)"+M+"*\\)|)(?=[^-]|$)","i")},Y=/HTML$/i,Q=/^(?:input|select|textarea|button)$/i,J=/^h\d$/i,K=/^[^{]+\{\s*\[native \w/,Z=/^(?:#([\w-]+)|(\w+)|\.([\w-]+))$/,ee=/[+~]/,te=new RegExp("\\\\[\\da-fA-F]{1,6}"+M+"?|\\\\([^\\r\\n\\f])","g"),ne=function(e,t){var n="0x"+e.slice(1)-65536;return t||(n<0?String.fromCharCode(n+65536):String.fromCharCode(n>>10|55296,1023&n|56320))},re=/([\0-\x1f\x7f]|^-?\d)|^-$|[^\0-\x1f\x7f-\uFFFF\w-]/g,ie=function(e,t){return t?"\0"===e?"\ufffd":e.slice(0,-1)+"\\"+e.charCodeAt(e.length-1).toString(16)+" ":"\\"+e},oe=function(){T()},ae=be(function(e){return!0===e.disabled&&"fieldset"===e.nodeName.toLowerCase()},{dir:"parentNode",next:"legend"});try{H.apply(t=O.call(p.childNodes),p.childNodes),t[p.childNodes.length].nodeType}catch(e){H={apply:t.length?function(e,t){L.apply(e,O.call(t))}:function(e,t){var n=e.length,r=0;while(e[n++]=t[r++]);e.length=n-1}}}function se(t,e,n,r){var i,o,a,s,u,l,c,f=e&&e.ownerDocument,p=e?e.nodeType:9;if(n=n||[],"string"!=typeof t||!t||1!==p&&9!==p&&11!==p)return n;if(!r&&(T(e),e=e||C,E)){if(11!==p&&(u=Z.exec(t)))if(i=u[1]){if(9===p){if(!(a=e.getElementById(i)))return n;if(a.id===i)return n.push(a),n}else if(f&&(a=f.getElementById(i))&&y(e,a)&&a.id===i)return n.push(a),n}else{if(u[2])return H.apply(n,e.getElementsByTagName(t)),n;if((i=u[3])&&d.getElementsByClassName&&e.getElementsByClassName)return H.apply(n,e.getElementsByClassName(i)),n}if(d.qsa&&!N[t+" "]&&(!v||!v.test(t))&&(1!==p||"object"!==e.nodeName.toLowerCase())){if(c=t,f=e,1===p&&(U.test(t)||z.test(t))){(f=ee.test(t)&&ye(e.parentNode)||e)===e&&d.scope||((s=e.getAttribute("id"))?s=s.replace(re,ie):e.setAttribute("id",s=S)),o=(l=h(t)).length;while(o--)l[o]=(s?"#"+s:":scope")+" "+xe(l[o]);c=l.join(",")}try{return H.apply(n,f.querySelectorAll(c)),n}catch(e){N(t,!0)}finally{s===S&&e.removeAttribute("id")}}}return g(t.replace($,"$1"),e,n,r)}function ue(){var r=[];return function e(t,n){return r.push(t+" ")>b.cacheLength&&delete e[r.shift()],e[t+" "]=n}}function le(e){return e[S]=!0,e}function ce(e){var t=C.createElement("fieldset");try{return!!e(t)}catch(e){return!1}finally{t.parentNode&&t.parentNode.removeChild(t),t=null}}function fe(e,t){var n=e.split("|"),r=n.length;while(r--)b.attrHandle[n[r]]=t}function pe(e,t){var n=t&&e,r=n&&1===e.nodeType&&1===t.nodeType&&e.sourceIndex-t.sourceIndex;if(r)return r;if(n)while(n=n.nextSibling)if(n===t)return-1;return e?1:-1}function de(t){return function(e){return"input"===e.nodeName.toLowerCase()&&e.type===t}}function he(n){return function(e){var t=e.nodeName.toLowerCase();return("input"===t||"button"===t)&&e.type===n}}function ge(t){return function(e){return"form"in e?e.parentNode&&!1===e.disabled?"label"in e?"label"in e.parentNode?e.parentNode.disabled===t:e.disabled===t:e.isDisabled===t||e.isDisabled!==!t&&ae(e)===t:e.disabled===t:"label"in e&&e.disabled===t}}function ve(a){return le(function(o){return o=+o,le(function(e,t){var n,r=a([],e.length,o),i=r.length;while(i--)e[n=r[i]]&&(e[n]=!(t[n]=e[n]))})})}function ye(e){return e&&"undefined"!=typeof e.getElementsByTagName&&e}for(e in d=se.support={},i=se.isXML=function(e){var t=e&&e.namespaceURI,n=e&&(e.ownerDocument||e).documentElement;return!Y.test(t||n&&n.nodeName||"HTML")},T=se.setDocument=function(e){var t,n,r=e?e.ownerDocument||e:p;return r!=C&&9===r.nodeType&&r.documentElement&&(a=(C=r).documentElement,E=!i(C),p!=C&&(n=C.defaultView)&&n.top!==n&&(n.addEventListener?n.addEventListener("unload",oe,!1):n.attachEvent&&n.attachEvent("onunload",oe)),d.scope=ce(function(e){return a.appendChild(e).appendChild(C.createElement("div")),"undefined"!=typeof e.querySelectorAll&&!e.querySelectorAll(":scope fieldset div").length}),d.attributes=ce(function(e){return e.className="i",!e.getAttribute("className")}),d.getElementsByTagName=ce(function(e){return e.appendChild(C.createComment("")),!e.getElementsByTagName("*").length}),d.getElementsByClassName=K.test(C.getElementsByClassName),d.getById=ce(function(e){return a.appendChild(e).id=S,!C.getElementsByName||!C.getElementsByName(S).length}),d.getById?(b.filter.ID=function(e){var t=e.replace(te,ne);return function(e){return e.getAttribute("id")===t}},b.find.ID=function(e,t){if("undefined"!=typeof t.getElementById&&E){var n=t.getElementById(e);return n?[n]:[]}}):(b.filter.ID=function(e){var n=e.replace(te,ne);return function(e){var t="undefined"!=typeof e.getAttributeNode&&e.getAttributeNode("id");return t&&t.value===n}},b.find.ID=function(e,t){if("undefined"!=typeof t.getElementById&&E){var n,r,i,o=t.getElementById(e);if(o){if((n=o.getAttributeNode("id"))&&n.value===e)return[o];i=t.getElementsByName(e),r=0;while(o=i[r++])if((n=o.getAttributeNode("id"))&&n.value===e)return[o]}return[]}}),b.find.TAG=d.getElementsByTagName?function(e,t){return"undefined"!=typeof t.getElementsByTagName?t.getElementsByTagName(e):d.qsa?t.querySelectorAll(e):void 0}:function(e,t){var n,r=[],i=0,o=t.getElementsByTagName(e);if("*"===e){while(n=o[i++])1===n.nodeType&&r.push(n);return r}return o},b.find.CLASS=d.getElementsByClassName&&function(e,t){if("undefined"!=typeof t.getElementsByClassName&&E)return t.getElementsByClassName(e)},s=[],v=[],(d.qsa=K.test(C.querySelectorAll))&&(ce(function(e){var t;a.appendChild(e).innerHTML="",e.querySelectorAll("[msallowcapture^='']").length&&v.push("[*^$]="+M+"*(?:''|\"\")"),e.querySelectorAll("[selected]").length||v.push("\\["+M+"*(?:value|"+R+")"),e.querySelectorAll("[id~="+S+"-]").length||v.push("~="),(t=C.createElement("input")).setAttribute("name",""),e.appendChild(t),e.querySelectorAll("[name='']").length||v.push("\\["+M+"*name"+M+"*="+M+"*(?:''|\"\")"),e.querySelectorAll(":checked").length||v.push(":checked"),e.querySelectorAll("a#"+S+"+*").length||v.push(".#.+[+~]"),e.querySelectorAll("\\\f"),v.push("[\\r\\n\\f]")}),ce(function(e){e.innerHTML="";var t=C.createElement("input");t.setAttribute("type","hidden"),e.appendChild(t).setAttribute("name","D"),e.querySelectorAll("[name=d]").length&&v.push("name"+M+"*[*^$|!~]?="),2!==e.querySelectorAll(":enabled").length&&v.push(":enabled",":disabled"),a.appendChild(e).disabled=!0,2!==e.querySelectorAll(":disabled").length&&v.push(":enabled",":disabled"),e.querySelectorAll("*,:x"),v.push(",.*:")})),(d.matchesSelector=K.test(c=a.matches||a.webkitMatchesSelector||a.mozMatchesSelector||a.oMatchesSelector||a.msMatchesSelector))&&ce(function(e){d.disconnectedMatch=c.call(e,"*"),c.call(e,"[s!='']:x"),s.push("!=",F)}),v=v.length&&new RegExp(v.join("|")),s=s.length&&new RegExp(s.join("|")),t=K.test(a.compareDocumentPosition),y=t||K.test(a.contains)?function(e,t){var n=9===e.nodeType?e.documentElement:e,r=t&&t.parentNode;return e===r||!(!r||1!==r.nodeType||!(n.contains?n.contains(r):e.compareDocumentPosition&&16&e.compareDocumentPosition(r)))}:function(e,t){if(t)while(t=t.parentNode)if(t===e)return!0;return!1},j=t?function(e,t){if(e===t)return l=!0,0;var n=!e.compareDocumentPosition-!t.compareDocumentPosition;return n||(1&(n=(e.ownerDocument||e)==(t.ownerDocument||t)?e.compareDocumentPosition(t):1)||!d.sortDetached&&t.compareDocumentPosition(e)===n?e==C||e.ownerDocument==p&&y(p,e)?-1:t==C||t.ownerDocument==p&&y(p,t)?1:u?P(u,e)-P(u,t):0:4&n?-1:1)}:function(e,t){if(e===t)return l=!0,0;var n,r=0,i=e.parentNode,o=t.parentNode,a=[e],s=[t];if(!i||!o)return e==C?-1:t==C?1:i?-1:o?1:u?P(u,e)-P(u,t):0;if(i===o)return pe(e,t);n=e;while(n=n.parentNode)a.unshift(n);n=t;while(n=n.parentNode)s.unshift(n);while(a[r]===s[r])r++;return r?pe(a[r],s[r]):a[r]==p?-1:s[r]==p?1:0}),C},se.matches=function(e,t){return se(e,null,null,t)},se.matchesSelector=function(e,t){if(T(e),d.matchesSelector&&E&&!N[t+" "]&&(!s||!s.test(t))&&(!v||!v.test(t)))try{var n=c.call(e,t);if(n||d.disconnectedMatch||e.document&&11!==e.document.nodeType)return n}catch(e){N(t,!0)}return 0":{dir:"parentNode",first:!0}," ":{dir:"parentNode"},"+":{dir:"previousSibling",first:!0},"~":{dir:"previousSibling"}},preFilter:{ATTR:function(e){return e[1]=e[1].replace(te,ne),e[3]=(e[3]||e[4]||e[5]||"").replace(te,ne),"~="===e[2]&&(e[3]=" "+e[3]+" "),e.slice(0,4)},CHILD:function(e){return e[1]=e[1].toLowerCase(),"nth"===e[1].slice(0,3)?(e[3]||se.error(e[0]),e[4]=+(e[4]?e[5]+(e[6]||1):2*("even"===e[3]||"odd"===e[3])),e[5]=+(e[7]+e[8]||"odd"===e[3])):e[3]&&se.error(e[0]),e},PSEUDO:function(e){var t,n=!e[6]&&e[2];return G.CHILD.test(e[0])?null:(e[3]?e[2]=e[4]||e[5]||"":n&&X.test(n)&&(t=h(n,!0))&&(t=n.indexOf(")",n.length-t)-n.length)&&(e[0]=e[0].slice(0,t),e[2]=n.slice(0,t)),e.slice(0,3))}},filter:{TAG:function(e){var t=e.replace(te,ne).toLowerCase();return"*"===e?function(){return!0}:function(e){return e.nodeName&&e.nodeName.toLowerCase()===t}},CLASS:function(e){var t=m[e+" "];return t||(t=new RegExp("(^|"+M+")"+e+"("+M+"|$)"))&&m(e,function(e){return t.test("string"==typeof e.className&&e.className||"undefined"!=typeof e.getAttribute&&e.getAttribute("class")||"")})},ATTR:function(n,r,i){return function(e){var t=se.attr(e,n);return null==t?"!="===r:!r||(t+="","="===r?t===i:"!="===r?t!==i:"^="===r?i&&0===t.indexOf(i):"*="===r?i&&-1:\x20\t\r\n\f]*)[\x20\t\r\n\f]*\/?>(?:<\/\1>|)$/i;function j(e,n,r){return m(n)?S.grep(e,function(e,t){return!!n.call(e,t,e)!==r}):n.nodeType?S.grep(e,function(e){return e===n!==r}):"string"!=typeof n?S.grep(e,function(e){return-1)[^>]*|#([\w-]+))$/;(S.fn.init=function(e,t,n){var r,i;if(!e)return this;if(n=n||D,"string"==typeof e){if(!(r="<"===e[0]&&">"===e[e.length-1]&&3<=e.length?[null,e,null]:q.exec(e))||!r[1]&&t)return!t||t.jquery?(t||n).find(e):this.constructor(t).find(e);if(r[1]){if(t=t instanceof S?t[0]:t,S.merge(this,S.parseHTML(r[1],t&&t.nodeType?t.ownerDocument||t:E,!0)),N.test(r[1])&&S.isPlainObject(t))for(r in t)m(this[r])?this[r](t[r]):this.attr(r,t[r]);return this}return(i=E.getElementById(r[2]))&&(this[0]=i,this.length=1),this}return e.nodeType?(this[0]=e,this.length=1,this):m(e)?void 0!==n.ready?n.ready(e):e(S):S.makeArray(e,this)}).prototype=S.fn,D=S(E);var L=/^(?:parents|prev(?:Until|All))/,H={children:!0,contents:!0,next:!0,prev:!0};function O(e,t){while((e=e[t])&&1!==e.nodeType);return e}S.fn.extend({has:function(e){var t=S(e,this),n=t.length;return this.filter(function(){for(var e=0;e\x20\t\r\n\f]*)/i,he=/^$|^module$|\/(?:java|ecma)script/i;ce=E.createDocumentFragment().appendChild(E.createElement("div")),(fe=E.createElement("input")).setAttribute("type","radio"),fe.setAttribute("checked","checked"),fe.setAttribute("name","t"),ce.appendChild(fe),y.checkClone=ce.cloneNode(!0).cloneNode(!0).lastChild.checked,ce.innerHTML="",y.noCloneChecked=!!ce.cloneNode(!0).lastChild.defaultValue,ce.innerHTML="",y.option=!!ce.lastChild;var ge={thead:[1,"","
"],col:[2,"","
"],tr:[2,"","
"],td:[3,"","
"],_default:[0,"",""]};function ve(e,t){var n;return n="undefined"!=typeof e.getElementsByTagName?e.getElementsByTagName(t||"*"):"undefined"!=typeof e.querySelectorAll?e.querySelectorAll(t||"*"):[],void 0===t||t&&A(e,t)?S.merge([e],n):n}function ye(e,t){for(var n=0,r=e.length;n",""]);var me=/<|&#?\w+;/;function xe(e,t,n,r,i){for(var o,a,s,u,l,c,f=t.createDocumentFragment(),p=[],d=0,h=e.length;d\s*$/g;function je(e,t){return A(e,"table")&&A(11!==t.nodeType?t:t.firstChild,"tr")&&S(e).children("tbody")[0]||e}function De(e){return e.type=(null!==e.getAttribute("type"))+"/"+e.type,e}function qe(e){return"true/"===(e.type||"").slice(0,5)?e.type=e.type.slice(5):e.removeAttribute("type"),e}function Le(e,t){var n,r,i,o,a,s;if(1===t.nodeType){if(Y.hasData(e)&&(s=Y.get(e).events))for(i in Y.remove(t,"handle events"),s)for(n=0,r=s[i].length;n").attr(n.scriptAttrs||{}).prop({charset:n.scriptCharset,src:n.url}).on("load error",i=function(e){r.remove(),i=null,e&&t("error"===e.type?404:200,e.type)}),E.head.appendChild(r[0])},abort:function(){i&&i()}}});var _t,zt=[],Ut=/(=)\?(?=&|$)|\?\?/;S.ajaxSetup({jsonp:"callback",jsonpCallback:function(){var e=zt.pop()||S.expando+"_"+wt.guid++;return this[e]=!0,e}}),S.ajaxPrefilter("json jsonp",function(e,t,n){var r,i,o,a=!1!==e.jsonp&&(Ut.test(e.url)?"url":"string"==typeof e.data&&0===(e.contentType||"").indexOf("application/x-www-form-urlencoded")&&Ut.test(e.data)&&"data");if(a||"jsonp"===e.dataTypes[0])return r=e.jsonpCallback=m(e.jsonpCallback)?e.jsonpCallback():e.jsonpCallback,a?e[a]=e[a].replace(Ut,"$1"+r):!1!==e.jsonp&&(e.url+=(Tt.test(e.url)?"&":"?")+e.jsonp+"="+r),e.converters["script json"]=function(){return o||S.error(r+" was not called"),o[0]},e.dataTypes[0]="json",i=C[r],C[r]=function(){o=arguments},n.always(function(){void 0===i?S(C).removeProp(r):C[r]=i,e[r]&&(e.jsonpCallback=t.jsonpCallback,zt.push(r)),o&&m(i)&&i(o[0]),o=i=void 0}),"script"}),y.createHTMLDocument=((_t=E.implementation.createHTMLDocument("").body).innerHTML="
",2===_t.childNodes.length),S.parseHTML=function(e,t,n){return"string"!=typeof e?[]:("boolean"==typeof t&&(n=t,t=!1),t||(y.createHTMLDocument?((r=(t=E.implementation.createHTMLDocument("")).createElement("base")).href=E.location.href,t.head.appendChild(r)):t=E),o=!n&&[],(i=N.exec(e))?[t.createElement(i[1])]:(i=xe([e],t,o),o&&o.length&&S(o).remove(),S.merge([],i.childNodes)));var r,i,o},S.fn.load=function(e,t,n){var r,i,o,a=this,s=e.indexOf(" ");return-1").append(S.parseHTML(e)).find(r):e)}).always(n&&function(e,t){a.each(function(){n.apply(this,o||[e.responseText,t,e])})}),this},S.expr.pseudos.animated=function(t){return S.grep(S.timers,function(e){return t===e.elem}).length},S.offset={setOffset:function(e,t,n){var r,i,o,a,s,u,l=S.css(e,"position"),c=S(e),f={};"static"===l&&(e.style.position="relative"),s=c.offset(),o=S.css(e,"top"),u=S.css(e,"left"),("absolute"===l||"fixed"===l)&&-1<(o+u).indexOf("auto")?(a=(r=c.position()).top,i=r.left):(a=parseFloat(o)||0,i=parseFloat(u)||0),m(t)&&(t=t.call(e,n,S.extend({},s))),null!=t.top&&(f.top=t.top-s.top+a),null!=t.left&&(f.left=t.left-s.left+i),"using"in t?t.using.call(e,f):c.css(f)}},S.fn.extend({offset:function(t){if(arguments.length)return void 0===t?this:this.each(function(e){S.offset.setOffset(this,t,e)});var e,n,r=this[0];return r?r.getClientRects().length?(e=r.getBoundingClientRect(),n=r.ownerDocument.defaultView,{top:e.top+n.pageYOffset,left:e.left+n.pageXOffset}):{top:0,left:0}:void 0},position:function(){if(this[0]){var e,t,n,r=this[0],i={top:0,left:0};if("fixed"===S.css(r,"position"))t=r.getBoundingClientRect();else{t=this.offset(),n=r.ownerDocument,e=r.offsetParent||n.documentElement;while(e&&(e===n.body||e===n.documentElement)&&"static"===S.css(e,"position"))e=e.parentNode;e&&e!==r&&1===e.nodeType&&((i=S(e).offset()).top+=S.css(e,"borderTopWidth",!0),i.left+=S.css(e,"borderLeftWidth",!0))}return{top:t.top-i.top-S.css(r,"marginTop",!0),left:t.left-i.left-S.css(r,"marginLeft",!0)}}},offsetParent:function(){return this.map(function(){var e=this.offsetParent;while(e&&"static"===S.css(e,"position"))e=e.offsetParent;return e||re})}}),S.each({scrollLeft:"pageXOffset",scrollTop:"pageYOffset"},function(t,i){var o="pageYOffset"===i;S.fn[t]=function(e){return $(this,function(e,t,n){var r;if(x(e)?r=e:9===e.nodeType&&(r=e.defaultView),void 0===n)return r?r[i]:e[t];r?r.scrollTo(o?r.pageXOffset:n,o?n:r.pageYOffset):e[t]=n},t,e,arguments.length)}}),S.each(["top","left"],function(e,n){S.cssHooks[n]=Fe(y.pixelPosition,function(e,t){if(t)return t=We(e,n),Pe.test(t)?S(e).position()[n]+"px":t})}),S.each({Height:"height",Width:"width"},function(a,s){S.each({padding:"inner"+a,content:s,"":"outer"+a},function(r,o){S.fn[o]=function(e,t){var n=arguments.length&&(r||"boolean"!=typeof e),i=r||(!0===e||!0===t?"margin":"border");return $(this,function(e,t,n){var r;return x(e)?0===o.indexOf("outer")?e["inner"+a]:e.document.documentElement["client"+a]:9===e.nodeType?(r=e.documentElement,Math.max(e.body["scroll"+a],r["scroll"+a],e.body["offset"+a],r["offset"+a],r["client"+a])):void 0===n?S.css(e,t,i):S.style(e,t,n,i)},s,n?e:void 0,n)}})}),S.each(["ajaxStart","ajaxStop","ajaxComplete","ajaxError","ajaxSuccess","ajaxSend"],function(e,t){S.fn[t]=function(e){return this.on(t,e)}}),S.fn.extend({bind:function(e,t,n){return this.on(e,null,t,n)},unbind:function(e,t){return this.off(e,null,t)},delegate:function(e,t,n,r){return this.on(t,e,n,r)},undelegate:function(e,t,n){return 1===arguments.length?this.off(e,"**"):this.off(t,e||"**",n)},hover:function(e,t){return this.mouseenter(e).mouseleave(t||e)}}),S.each("blur focus focusin focusout resize scroll click dblclick mousedown mouseup mousemove mouseover mouseout mouseenter mouseleave change select submit keydown keypress keyup contextmenu".split(" "),function(e,n){S.fn[n]=function(e,t){return 0"),n("table.docutils.footnote").wrap("
"),n("table.docutils.citation").wrap("
"),n(".wy-menu-vertical ul").not(".simple").siblings("a").each((function(){var t=n(this);expand=n(''),expand.on("click",(function(n){return e.toggleCurrent(t),n.stopPropagation(),!1})),t.prepend(expand)}))},reset:function(){var n=encodeURI(window.location.hash)||"#";try{var e=$(".wy-menu-vertical"),t=e.find('[href="'+n+'"]');if(0===t.length){var i=$('.document [id="'+n.substring(1)+'"]').closest("div.section");0===(t=e.find('[href="#'+i.attr("id")+'"]')).length&&(t=e.find('[href="#"]'))}if(t.length>0){$(".wy-menu-vertical .current").removeClass("current").attr("aria-expanded","false"),t.addClass("current").attr("aria-expanded","true"),t.closest("li.toctree-l1").parent().addClass("current").attr("aria-expanded","true");for(let n=1;n<=10;n++)t.closest("li.toctree-l"+n).addClass("current").attr("aria-expanded","true");t[0].scrollIntoView()}}catch(n){console.log("Error expanding nav for anchor",n)}},onScroll:function(){this.winScroll=!1;var n=this.win.scrollTop(),e=n+this.winHeight,t=this.navBar.scrollTop()+(n-this.winPosition);n<0||e>this.docHeight||(this.navBar.scrollTop(t),this.winPosition=n)},onResize:function(){this.winResize=!1,this.winHeight=this.win.height(),this.docHeight=$(document).height()},hashChange:function(){this.linkScroll=!0,this.win.one("hashchange",(function(){this.linkScroll=!1}))},toggleCurrent:function(n){var e=n.closest("li");e.siblings("li.current").removeClass("current").attr("aria-expanded","false"),e.siblings().find("li.current").removeClass("current").attr("aria-expanded","false");var t=e.find("> ul li");t.length&&(t.removeClass("current").attr("aria-expanded","false"),e.toggleClass("current").attr("aria-expanded",(function(n,e){return"true"==e?"false":"true"})))}},"undefined"!=typeof window&&(window.SphinxRtdTheme={Navigation:n.exports.ThemeNav,StickyNav:n.exports.ThemeNav}),function(){for(var n=0,e=["ms","moz","webkit","o"],t=0;t +
Languages
+ ${config.projects.translations + .map( + (translation) => ` +
+ ${translation.language.code} +
+ `, + ) + .join("\n")} + + `; + return languagesHTML; + } + + function renderVersions(config) { + if (!config.versions.active.length) { + return ""; + } + const versionsHTML = ` +
+
Versions
+ ${config.versions.active + .map( + (version) => ` +
+ ${version.slug} +
+ `, + ) + .join("\n")} +
+ `; + return versionsHTML; + } + + function renderDownloads(config) { + if (!Object.keys(config.versions.current.downloads).length) { + return ""; + } + const downloadsNameDisplay = { + pdf: "PDF", + epub: "Epub", + htmlzip: "HTML", + }; + + const downloadsHTML = ` +
+
Downloads
+ ${Object.entries(config.versions.current.downloads) + .map( + ([name, url]) => ` +
+ ${downloadsNameDisplay[name]} +
+ `, + ) + .join("\n")} +
+ `; + return downloadsHTML; + } + + document.addEventListener("readthedocs-addons-data-ready", function (event) { + const config = event.detail.data(); + + const flyout = ` +
+ + Read the Docs + v: ${config.versions.current.slug} + + +
+
+ ${renderLanguages(config)} + ${renderVersions(config)} + ${renderDownloads(config)} +
+
On Read the Docs
+
+ Project Home +
+
+ Builds +
+
+ Downloads +
+
+
+
Search
+
+
+ +
+
+
+
+ + Hosted by Read the Docs + +
+
+ `; + + // Inject the generated flyout into the body HTML element. + document.body.insertAdjacentHTML("beforeend", flyout); + + // Trigger the Read the Docs Addons Search modal when clicking on the "Search docs" input from inside the flyout. + document + .querySelector("#flyout-search-form") + .addEventListener("focusin", () => { + const event = new CustomEvent("readthedocs-search-show"); + document.dispatchEvent(event); + }); + }) +} + +if (themeLanguageSelector || themeVersionSelector) { + function onSelectorSwitch(event) { + const option = event.target.selectedIndex; + const item = event.target.options[option]; + window.location.href = item.dataset.url; + } + + document.addEventListener("readthedocs-addons-data-ready", function (event) { + const config = event.detail.data(); + + const versionSwitch = document.querySelector( + "div.switch-menus > div.version-switch", + ); + if (themeVersionSelector) { + let versions = config.versions.active; + if (config.versions.current.hidden || config.versions.current.type === "external") { + versions.unshift(config.versions.current); + } + const versionSelect = ` + + `; + + versionSwitch.innerHTML = versionSelect; + versionSwitch.firstElementChild.addEventListener("change", onSelectorSwitch); + } + + const languageSwitch = document.querySelector( + "div.switch-menus > div.language-switch", + ); + + if (themeLanguageSelector) { + if (config.projects.translations.length) { + // Add the current language to the options on the selector + let languages = config.projects.translations.concat( + config.projects.current, + ); + languages = languages.sort((a, b) => + a.language.name.localeCompare(b.language.name), + ); + + const languageSelect = ` + + `; + + languageSwitch.innerHTML = languageSelect; + languageSwitch.firstElementChild.addEventListener("change", onSelectorSwitch); + } + else { + languageSwitch.remove(); + } + } + }); +} + +document.addEventListener("readthedocs-addons-data-ready", function (event) { + // Trigger the Read the Docs Addons Search modal when clicking on "Search docs" input from the topnav. + document + .querySelector("[role='search'] input") + .addEventListener("focusin", () => { + const event = new CustomEvent("readthedocs-search-show"); + document.dispatchEvent(event); + }); +}); \ No newline at end of file diff --git a/previews/271/_static/kirkstone.pdf b/previews/271/_static/kirkstone.pdf new file mode 100644 index 000000000..9d03d4be6 Binary files /dev/null and b/previews/271/_static/kirkstone.pdf differ diff --git a/previews/271/_static/language_data.js b/previews/271/_static/language_data.js new file mode 100644 index 000000000..c7fe6c6fa --- /dev/null +++ b/previews/271/_static/language_data.js @@ -0,0 +1,192 @@ +/* + * This script contains the language-specific data used by searchtools.js, + * namely the list of stopwords, stemmer, scorer and splitter. + */ + +var stopwords = ["a", "and", "are", "as", "at", "be", "but", "by", "for", "if", "in", "into", "is", "it", "near", "no", "not", "of", "on", "or", "such", "that", "the", "their", "then", "there", "these", "they", "this", "to", "was", "will", "with"]; + + +/* Non-minified version is copied as a separate JS file, if available */ + +/** + * Porter Stemmer + */ +var Stemmer = function() { + + var step2list = { + ational: 'ate', + tional: 'tion', + enci: 'ence', + anci: 'ance', + izer: 'ize', + bli: 'ble', + alli: 'al', + entli: 'ent', + eli: 'e', + ousli: 'ous', + ization: 'ize', + ation: 'ate', + ator: 'ate', + alism: 'al', + iveness: 'ive', + fulness: 'ful', + ousness: 'ous', + aliti: 'al', + iviti: 'ive', + biliti: 'ble', + logi: 'log' + }; + + var step3list = { + icate: 'ic', + ative: '', + alize: 'al', + iciti: 'ic', + ical: 'ic', + ful: '', + ness: '' + }; + + var c = "[^aeiou]"; // consonant + var v = "[aeiouy]"; // vowel + var C = c + "[^aeiouy]*"; // consonant sequence + var V = v + "[aeiou]*"; // vowel sequence + + var mgr0 = "^(" + C + ")?" + V + C; // [C]VC... is m>0 + var meq1 = "^(" + C + ")?" + V + C + "(" + V + ")?$"; // [C]VC[V] is m=1 + var mgr1 = "^(" + C + ")?" + V + C + V + C; // [C]VCVC... is m>1 + var s_v = "^(" + C + ")?" + v; // vowel in stem + + this.stemWord = function (w) { + var stem; + var suffix; + var firstch; + var origword = w; + + if (w.length < 3) + return w; + + var re; + var re2; + var re3; + var re4; + + firstch = w.substr(0,1); + if (firstch == "y") + w = firstch.toUpperCase() + w.substr(1); + + // Step 1a + re = /^(.+?)(ss|i)es$/; + re2 = /^(.+?)([^s])s$/; + + if (re.test(w)) + w = w.replace(re,"$1$2"); + else if (re2.test(w)) + w = w.replace(re2,"$1$2"); + + // Step 1b + re = /^(.+?)eed$/; + re2 = /^(.+?)(ed|ing)$/; + if (re.test(w)) { + var fp = re.exec(w); + re = new RegExp(mgr0); + if (re.test(fp[1])) { + re = /.$/; + w = w.replace(re,""); + } + } + else if (re2.test(w)) { + var fp = re2.exec(w); + stem = fp[1]; + re2 = new RegExp(s_v); + if (re2.test(stem)) { + w = stem; + re2 = /(at|bl|iz)$/; + re3 = new RegExp("([^aeiouylsz])\\1$"); + re4 = new RegExp("^" + C + v + "[^aeiouwxy]$"); + if (re2.test(w)) + w = w + "e"; + else if (re3.test(w)) { + re = /.$/; + w = w.replace(re,""); + } + else if (re4.test(w)) + w = w + "e"; + } + } + + // Step 1c + re = /^(.+?)y$/; + if (re.test(w)) { + var fp = re.exec(w); + stem = fp[1]; + re = new RegExp(s_v); + if (re.test(stem)) + w = stem + "i"; + } + + // Step 2 + re = /^(.+?)(ational|tional|enci|anci|izer|bli|alli|entli|eli|ousli|ization|ation|ator|alism|iveness|fulness|ousness|aliti|iviti|biliti|logi)$/; + if (re.test(w)) { + var fp = re.exec(w); + stem = fp[1]; + suffix = fp[2]; + re = new RegExp(mgr0); + if (re.test(stem)) + w = stem + step2list[suffix]; + } + + // Step 3 + re = /^(.+?)(icate|ative|alize|iciti|ical|ful|ness)$/; + if (re.test(w)) { + var fp = re.exec(w); + stem = fp[1]; + suffix = fp[2]; + re = new RegExp(mgr0); + if (re.test(stem)) + w = stem + step3list[suffix]; + } + + // Step 4 + re = /^(.+?)(al|ance|ence|er|ic|able|ible|ant|ement|ment|ent|ou|ism|ate|iti|ous|ive|ize)$/; + re2 = /^(.+?)(s|t)(ion)$/; + if (re.test(w)) { + var fp = re.exec(w); + stem = fp[1]; + re = new RegExp(mgr1); + if (re.test(stem)) + w = stem; + } + else if (re2.test(w)) { + var fp = re2.exec(w); + stem = fp[1] + fp[2]; + re2 = new RegExp(mgr1); + if (re2.test(stem)) + w = stem; + } + + // Step 5 + re = /^(.+?)e$/; + if (re.test(w)) { + var fp = re.exec(w); + stem = fp[1]; + re = new RegExp(mgr1); + re2 = new RegExp(meq1); + re3 = new RegExp("^" + C + v + "[^aeiouwxy]$"); + if (re.test(stem) || (re2.test(stem) && !(re3.test(stem)))) + w = stem; + } + re = /ll$/; + re2 = new RegExp(mgr1); + if (re.test(w) && re2.test(w)) { + re = /.$/; + w = w.replace(re,""); + } + + // and turn initial Y back to y + if (firstch == "y") + w = firstch.toLowerCase() + w.substr(1); + return w; + } +} + diff --git a/previews/271/_static/logo-phytec.svg b/previews/271/_static/logo-phytec.svg new file mode 100644 index 000000000..b385926a7 --- /dev/null +++ b/previews/271/_static/logo-phytec.svg @@ -0,0 +1,9 @@ + + + + + + + + + diff --git a/previews/271/_static/mickledore.pdf b/previews/271/_static/mickledore.pdf new file mode 100644 index 000000000..a60827093 Binary files /dev/null and b/previews/271/_static/mickledore.pdf differ diff --git a/previews/271/_static/minus.png b/previews/271/_static/minus.png new file mode 100644 index 000000000..d96755fda Binary files /dev/null and b/previews/271/_static/minus.png differ diff --git a/previews/271/_static/plus.png b/previews/271/_static/plus.png new file mode 100644 index 000000000..7107cec93 Binary files /dev/null and b/previews/271/_static/plus.png differ diff --git a/previews/271/_static/pygments.css b/previews/271/_static/pygments.css new file mode 100644 index 000000000..6f8b210a1 --- /dev/null +++ b/previews/271/_static/pygments.css @@ -0,0 +1,75 @@ +pre { line-height: 125%; } +td.linenos .normal { color: inherit; background-color: transparent; padding-left: 5px; padding-right: 5px; } +span.linenos { color: inherit; background-color: transparent; padding-left: 5px; padding-right: 5px; } +td.linenos .special { color: #000000; background-color: #ffffc0; padding-left: 5px; padding-right: 5px; } +span.linenos.special { color: #000000; background-color: #ffffc0; padding-left: 5px; padding-right: 5px; } +.highlight .hll { background-color: #ffffcc } +.highlight { background: #f8f8f8; } +.highlight .c { color: #3D7B7B; font-style: italic } /* Comment */ +.highlight .err { border: 1px solid #F00 } /* Error */ +.highlight .k { color: #008000; font-weight: bold } /* Keyword */ +.highlight .o { color: #666 } /* Operator */ +.highlight .ch { color: #3D7B7B; font-style: italic } /* Comment.Hashbang */ +.highlight .cm { color: #3D7B7B; font-style: italic } /* Comment.Multiline */ +.highlight .cp { color: #9C6500 } /* Comment.Preproc */ +.highlight .cpf { color: #3D7B7B; font-style: italic } /* Comment.PreprocFile */ +.highlight .c1 { color: #3D7B7B; font-style: italic } /* Comment.Single */ +.highlight .cs { color: #3D7B7B; font-style: italic } /* Comment.Special */ +.highlight .gd { color: #A00000 } /* Generic.Deleted */ +.highlight .ge { font-style: italic } /* Generic.Emph */ +.highlight .ges { font-weight: bold; font-style: italic } /* Generic.EmphStrong */ +.highlight .gr { color: #E40000 } /* Generic.Error */ +.highlight .gh { color: #000080; font-weight: bold } /* Generic.Heading */ +.highlight .gi { color: #008400 } /* Generic.Inserted */ +.highlight .go { color: #717171 } /* Generic.Output */ +.highlight .gp { color: #000080; font-weight: bold } /* Generic.Prompt */ +.highlight .gs { font-weight: bold } /* Generic.Strong */ +.highlight .gu { color: #800080; font-weight: bold } /* Generic.Subheading */ +.highlight .gt { color: #04D } /* Generic.Traceback */ +.highlight .kc { color: #008000; font-weight: bold } /* Keyword.Constant */ +.highlight .kd { color: #008000; font-weight: bold } /* Keyword.Declaration */ +.highlight .kn { color: #008000; font-weight: bold } /* Keyword.Namespace */ +.highlight .kp { color: #008000 } /* Keyword.Pseudo */ +.highlight .kr { color: #008000; font-weight: bold } /* Keyword.Reserved */ +.highlight .kt { color: #B00040 } /* Keyword.Type */ +.highlight .m { color: #666 } /* Literal.Number */ +.highlight .s { color: #BA2121 } /* Literal.String */ +.highlight .na { color: #687822 } /* Name.Attribute */ +.highlight .nb { color: #008000 } /* Name.Builtin */ +.highlight .nc { color: #00F; font-weight: bold } /* Name.Class */ +.highlight .no { color: #800 } /* Name.Constant */ +.highlight .nd { color: #A2F } /* Name.Decorator */ +.highlight .ni { color: #717171; font-weight: bold } /* Name.Entity */ +.highlight .ne { color: #CB3F38; font-weight: bold } /* Name.Exception */ +.highlight .nf { color: #00F } /* Name.Function */ +.highlight .nl { color: #767600 } /* Name.Label */ +.highlight .nn { color: #00F; font-weight: bold } /* Name.Namespace */ +.highlight .nt { color: #008000; font-weight: bold } /* Name.Tag */ +.highlight .nv { color: #19177C } /* Name.Variable */ +.highlight .ow { color: #A2F; font-weight: bold } /* Operator.Word */ +.highlight .w { color: #BBB } /* Text.Whitespace */ +.highlight .mb { color: #666 } /* Literal.Number.Bin */ +.highlight .mf { color: #666 } /* Literal.Number.Float */ +.highlight .mh { color: #666 } /* Literal.Number.Hex */ +.highlight .mi { color: #666 } /* Literal.Number.Integer */ +.highlight .mo { color: #666 } /* Literal.Number.Oct */ +.highlight .sa { color: #BA2121 } /* Literal.String.Affix */ +.highlight .sb { color: #BA2121 } /* Literal.String.Backtick */ +.highlight .sc { color: #BA2121 } /* Literal.String.Char */ +.highlight .dl { color: #BA2121 } /* Literal.String.Delimiter */ +.highlight .sd { color: #BA2121; font-style: italic } /* Literal.String.Doc */ +.highlight .s2 { color: #BA2121 } /* Literal.String.Double */ +.highlight .se { color: #AA5D1F; font-weight: bold } /* Literal.String.Escape */ +.highlight .sh { color: #BA2121 } /* Literal.String.Heredoc */ +.highlight .si { color: #A45A77; font-weight: bold } /* Literal.String.Interpol */ +.highlight .sx { color: #008000 } /* Literal.String.Other */ +.highlight .sr { color: #A45A77 } /* Literal.String.Regex */ +.highlight .s1 { color: #BA2121 } /* Literal.String.Single */ +.highlight .ss { color: #19177C } /* Literal.String.Symbol */ +.highlight .bp { color: #008000 } /* Name.Builtin.Pseudo */ +.highlight .fm { color: #00F } /* Name.Function.Magic */ +.highlight .vc { color: #19177C } /* Name.Variable.Class */ +.highlight .vg { color: #19177C } /* Name.Variable.Global */ +.highlight .vi { color: #19177C } /* Name.Variable.Instance */ +.highlight .vm { color: #19177C } /* Name.Variable.Magic */ +.highlight .il { color: #666 } /* Literal.Number.Integer.Long */ \ No newline at end of file diff --git a/previews/271/_static/rauc-kirkstone.pdf b/previews/271/_static/rauc-kirkstone.pdf new file mode 100644 index 000000000..f1c1d68bb Binary files /dev/null and b/previews/271/_static/rauc-kirkstone.pdf differ diff --git a/previews/271/_static/rauc-mickledore.pdf b/previews/271/_static/rauc-mickledore.pdf new file mode 100644 index 000000000..739590c03 Binary files /dev/null and b/previews/271/_static/rauc-mickledore.pdf differ diff --git a/previews/271/_static/rauc-scarthgap.pdf b/previews/271/_static/rauc-scarthgap.pdf new file mode 100644 index 000000000..e7829c34c Binary files /dev/null and b/previews/271/_static/rauc-scarthgap.pdf differ diff --git a/previews/271/_static/robots.txt b/previews/271/_static/robots.txt new file mode 100644 index 000000000..ea27bb96d --- /dev/null +++ b/previews/271/_static/robots.txt @@ -0,0 +1,3 @@ +User-agent: * + +Sitemap: https://phytec.github.io/doc-bsp-yocto/sitemap.xml diff --git a/previews/271/_static/scarthgap.pdf b/previews/271/_static/scarthgap.pdf new file mode 100644 index 000000000..db3d90648 Binary files /dev/null and b/previews/271/_static/scarthgap.pdf differ diff --git a/previews/271/_static/searchtools.js b/previews/271/_static/searchtools.js new file mode 100644 index 000000000..2c774d17a --- /dev/null +++ b/previews/271/_static/searchtools.js @@ -0,0 +1,632 @@ +/* + * Sphinx JavaScript utilities for the full-text search. + */ +"use strict"; + +/** + * Simple result scoring code. + */ +if (typeof Scorer === "undefined") { + var Scorer = { + // Implement the following function to further tweak the score for each result + // The function takes a result array [docname, title, anchor, descr, score, filename] + // and returns the new score. + /* + score: result => { + const [docname, title, anchor, descr, score, filename, kind] = result + return score + }, + */ + + // query matches the full name of an object + objNameMatch: 11, + // or matches in the last dotted part of the object name + objPartialMatch: 6, + // Additive scores depending on the priority of the object + objPrio: { + 0: 15, // used to be importantResults + 1: 5, // used to be objectResults + 2: -5, // used to be unimportantResults + }, + // Used when the priority is not in the mapping. + objPrioDefault: 0, + + // query found in title + title: 15, + partialTitle: 7, + // query found in terms + term: 5, + partialTerm: 2, + }; +} + +// Global search result kind enum, used by themes to style search results. +class SearchResultKind { + static get index() { return "index"; } + static get object() { return "object"; } + static get text() { return "text"; } + static get title() { return "title"; } +} + +const _removeChildren = (element) => { + while (element && element.lastChild) element.removeChild(element.lastChild); +}; + +/** + * See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions#escaping + */ +const _escapeRegExp = (string) => + string.replace(/[.*+\-?^${}()|[\]\\]/g, "\\$&"); // $& means the whole matched string + +const _displayItem = (item, searchTerms, highlightTerms) => { + const docBuilder = DOCUMENTATION_OPTIONS.BUILDER; + const docFileSuffix = DOCUMENTATION_OPTIONS.FILE_SUFFIX; + const docLinkSuffix = DOCUMENTATION_OPTIONS.LINK_SUFFIX; + const showSearchSummary = DOCUMENTATION_OPTIONS.SHOW_SEARCH_SUMMARY; + const contentRoot = document.documentElement.dataset.content_root; + + const [docName, title, anchor, descr, score, _filename, kind] = item; + + let listItem = document.createElement("li"); + // Add a class representing the item's type: + // can be used by a theme's CSS selector for styling + // See SearchResultKind for the class names. + listItem.classList.add(`kind-${kind}`); + let requestUrl; + let linkUrl; + if (docBuilder === "dirhtml") { + // dirhtml builder + let dirname = docName + "/"; + if (dirname.match(/\/index\/$/)) + dirname = dirname.substring(0, dirname.length - 6); + else if (dirname === "index/") dirname = ""; + requestUrl = contentRoot + dirname; + linkUrl = requestUrl; + } else { + // normal html builders + requestUrl = contentRoot + docName + docFileSuffix; + linkUrl = docName + docLinkSuffix; + } + let linkEl = listItem.appendChild(document.createElement("a")); + linkEl.href = linkUrl + anchor; + linkEl.dataset.score = score; + linkEl.innerHTML = title; + if (descr) { + listItem.appendChild(document.createElement("span")).innerHTML = + " (" + descr + ")"; + // highlight search terms in the description + if (SPHINX_HIGHLIGHT_ENABLED) // set in sphinx_highlight.js + highlightTerms.forEach((term) => _highlightText(listItem, term, "highlighted")); + } + else if (showSearchSummary) + fetch(requestUrl) + .then((responseData) => responseData.text()) + .then((data) => { + if (data) + listItem.appendChild( + Search.makeSearchSummary(data, searchTerms, anchor) + ); + // highlight search terms in the summary + if (SPHINX_HIGHLIGHT_ENABLED) // set in sphinx_highlight.js + highlightTerms.forEach((term) => _highlightText(listItem, term, "highlighted")); + }); + Search.output.appendChild(listItem); +}; +const _finishSearch = (resultCount) => { + Search.stopPulse(); + Search.title.innerText = _("Search Results"); + if (!resultCount) + Search.status.innerText = Documentation.gettext( + "Your search did not match any documents. Please make sure that all words are spelled correctly and that you've selected enough categories." + ); + else + Search.status.innerText = Documentation.ngettext( + "Search finished, found one page matching the search query.", + "Search finished, found ${resultCount} pages matching the search query.", + resultCount, + ).replace('${resultCount}', resultCount); +}; +const _displayNextItem = ( + results, + resultCount, + searchTerms, + highlightTerms, +) => { + // results left, load the summary and display it + // this is intended to be dynamic (don't sub resultsCount) + if (results.length) { + _displayItem(results.pop(), searchTerms, highlightTerms); + setTimeout( + () => _displayNextItem(results, resultCount, searchTerms, highlightTerms), + 5 + ); + } + // search finished, update title and status message + else _finishSearch(resultCount); +}; +// Helper function used by query() to order search results. +// Each input is an array of [docname, title, anchor, descr, score, filename, kind]. +// Order the results by score (in opposite order of appearance, since the +// `_displayNextItem` function uses pop() to retrieve items) and then alphabetically. +const _orderResultsByScoreThenName = (a, b) => { + const leftScore = a[4]; + const rightScore = b[4]; + if (leftScore === rightScore) { + // same score: sort alphabetically + const leftTitle = a[1].toLowerCase(); + const rightTitle = b[1].toLowerCase(); + if (leftTitle === rightTitle) return 0; + return leftTitle > rightTitle ? -1 : 1; // inverted is intentional + } + return leftScore > rightScore ? 1 : -1; +}; + +/** + * Default splitQuery function. Can be overridden in ``sphinx.search`` with a + * custom function per language. + * + * The regular expression works by splitting the string on consecutive characters + * that are not Unicode letters, numbers, underscores, or emoji characters. + * This is the same as ``\W+`` in Python, preserving the surrogate pair area. + */ +if (typeof splitQuery === "undefined") { + var splitQuery = (query) => query + .split(/[^\p{Letter}\p{Number}_\p{Emoji_Presentation}]+/gu) + .filter(term => term) // remove remaining empty strings +} + +/** + * Search Module + */ +const Search = { + _index: null, + _queued_query: null, + _pulse_status: -1, + + htmlToText: (htmlString, anchor) => { + const htmlElement = new DOMParser().parseFromString(htmlString, 'text/html'); + for (const removalQuery of [".headerlink", "script", "style"]) { + htmlElement.querySelectorAll(removalQuery).forEach((el) => { el.remove() }); + } + if (anchor) { + const anchorContent = htmlElement.querySelector(`[role="main"] ${anchor}`); + if (anchorContent) return anchorContent.textContent; + + console.warn( + `Anchored content block not found. Sphinx search tries to obtain it via DOM query '[role=main] ${anchor}'. Check your theme or template.` + ); + } + + // if anchor not specified or not found, fall back to main content + const docContent = htmlElement.querySelector('[role="main"]'); + if (docContent) return docContent.textContent; + + console.warn( + "Content block not found. Sphinx search tries to obtain it via DOM query '[role=main]'. Check your theme or template." + ); + return ""; + }, + + init: () => { + const query = new URLSearchParams(window.location.search).get("q"); + document + .querySelectorAll('input[name="q"]') + .forEach((el) => (el.value = query)); + if (query) Search.performSearch(query); + }, + + loadIndex: (url) => + (document.body.appendChild(document.createElement("script")).src = url), + + setIndex: (index) => { + Search._index = index; + if (Search._queued_query !== null) { + const query = Search._queued_query; + Search._queued_query = null; + Search.query(query); + } + }, + + hasIndex: () => Search._index !== null, + + deferQuery: (query) => (Search._queued_query = query), + + stopPulse: () => (Search._pulse_status = -1), + + startPulse: () => { + if (Search._pulse_status >= 0) return; + + const pulse = () => { + Search._pulse_status = (Search._pulse_status + 1) % 4; + Search.dots.innerText = ".".repeat(Search._pulse_status); + if (Search._pulse_status >= 0) window.setTimeout(pulse, 500); + }; + pulse(); + }, + + /** + * perform a search for something (or wait until index is loaded) + */ + performSearch: (query) => { + // create the required interface elements + const searchText = document.createElement("h2"); + searchText.textContent = _("Searching"); + const searchSummary = document.createElement("p"); + searchSummary.classList.add("search-summary"); + searchSummary.innerText = ""; + const searchList = document.createElement("ul"); + searchList.setAttribute("role", "list"); + searchList.classList.add("search"); + + const out = document.getElementById("search-results"); + Search.title = out.appendChild(searchText); + Search.dots = Search.title.appendChild(document.createElement("span")); + Search.status = out.appendChild(searchSummary); + Search.output = out.appendChild(searchList); + + const searchProgress = document.getElementById("search-progress"); + // Some themes don't use the search progress node + if (searchProgress) { + searchProgress.innerText = _("Preparing search..."); + } + Search.startPulse(); + + // index already loaded, the browser was quick! + if (Search.hasIndex()) Search.query(query); + else Search.deferQuery(query); + }, + + _parseQuery: (query) => { + // stem the search terms and add them to the correct list + const stemmer = new Stemmer(); + const searchTerms = new Set(); + const excludedTerms = new Set(); + const highlightTerms = new Set(); + const objectTerms = new Set(splitQuery(query.toLowerCase().trim())); + splitQuery(query.trim()).forEach((queryTerm) => { + const queryTermLower = queryTerm.toLowerCase(); + + // maybe skip this "word" + // stopwords array is from language_data.js + if ( + stopwords.indexOf(queryTermLower) !== -1 || + queryTerm.match(/^\d+$/) + ) + return; + + // stem the word + let word = stemmer.stemWord(queryTermLower); + // select the correct list + if (word[0] === "-") excludedTerms.add(word.substr(1)); + else { + searchTerms.add(word); + highlightTerms.add(queryTermLower); + } + }); + + if (SPHINX_HIGHLIGHT_ENABLED) { // set in sphinx_highlight.js + localStorage.setItem("sphinx_highlight_terms", [...highlightTerms].join(" ")) + } + + // console.debug("SEARCH: searching for:"); + // console.info("required: ", [...searchTerms]); + // console.info("excluded: ", [...excludedTerms]); + + return [query, searchTerms, excludedTerms, highlightTerms, objectTerms]; + }, + + /** + * execute search (requires search index to be loaded) + */ + _performSearch: (query, searchTerms, excludedTerms, highlightTerms, objectTerms) => { + const filenames = Search._index.filenames; + const docNames = Search._index.docnames; + const titles = Search._index.titles; + const allTitles = Search._index.alltitles; + const indexEntries = Search._index.indexentries; + + // Collect multiple result groups to be sorted separately and then ordered. + // Each is an array of [docname, title, anchor, descr, score, filename, kind]. + const normalResults = []; + const nonMainIndexResults = []; + + _removeChildren(document.getElementById("search-progress")); + + const queryLower = query.toLowerCase().trim(); + for (const [title, foundTitles] of Object.entries(allTitles)) { + if (title.toLowerCase().trim().includes(queryLower) && (queryLower.length >= title.length/2)) { + for (const [file, id] of foundTitles) { + const score = Math.round(Scorer.title * queryLower.length / title.length); + const boost = titles[file] === title ? 1 : 0; // add a boost for document titles + normalResults.push([ + docNames[file], + titles[file] !== title ? `${titles[file]} > ${title}` : title, + id !== null ? "#" + id : "", + null, + score + boost, + filenames[file], + SearchResultKind.title, + ]); + } + } + } + + // search for explicit entries in index directives + for (const [entry, foundEntries] of Object.entries(indexEntries)) { + if (entry.includes(queryLower) && (queryLower.length >= entry.length/2)) { + for (const [file, id, isMain] of foundEntries) { + const score = Math.round(100 * queryLower.length / entry.length); + const result = [ + docNames[file], + titles[file], + id ? "#" + id : "", + null, + score, + filenames[file], + SearchResultKind.index, + ]; + if (isMain) { + normalResults.push(result); + } else { + nonMainIndexResults.push(result); + } + } + } + } + + // lookup as object + objectTerms.forEach((term) => + normalResults.push(...Search.performObjectSearch(term, objectTerms)) + ); + + // lookup as search terms in fulltext + normalResults.push(...Search.performTermsSearch(searchTerms, excludedTerms)); + + // let the scorer override scores with a custom scoring function + if (Scorer.score) { + normalResults.forEach((item) => (item[4] = Scorer.score(item))); + nonMainIndexResults.forEach((item) => (item[4] = Scorer.score(item))); + } + + // Sort each group of results by score and then alphabetically by name. + normalResults.sort(_orderResultsByScoreThenName); + nonMainIndexResults.sort(_orderResultsByScoreThenName); + + // Combine the result groups in (reverse) order. + // Non-main index entries are typically arbitrary cross-references, + // so display them after other results. + let results = [...nonMainIndexResults, ...normalResults]; + + // remove duplicate search results + // note the reversing of results, so that in the case of duplicates, the highest-scoring entry is kept + let seen = new Set(); + results = results.reverse().reduce((acc, result) => { + let resultStr = result.slice(0, 4).concat([result[5]]).map(v => String(v)).join(','); + if (!seen.has(resultStr)) { + acc.push(result); + seen.add(resultStr); + } + return acc; + }, []); + + return results.reverse(); + }, + + query: (query) => { + const [searchQuery, searchTerms, excludedTerms, highlightTerms, objectTerms] = Search._parseQuery(query); + const results = Search._performSearch(searchQuery, searchTerms, excludedTerms, highlightTerms, objectTerms); + + // for debugging + //Search.lastresults = results.slice(); // a copy + // console.info("search results:", Search.lastresults); + + // print the results + _displayNextItem(results, results.length, searchTerms, highlightTerms); + }, + + /** + * search for object names + */ + performObjectSearch: (object, objectTerms) => { + const filenames = Search._index.filenames; + const docNames = Search._index.docnames; + const objects = Search._index.objects; + const objNames = Search._index.objnames; + const titles = Search._index.titles; + + const results = []; + + const objectSearchCallback = (prefix, match) => { + const name = match[4] + const fullname = (prefix ? prefix + "." : "") + name; + const fullnameLower = fullname.toLowerCase(); + if (fullnameLower.indexOf(object) < 0) return; + + let score = 0; + const parts = fullnameLower.split("."); + + // check for different match types: exact matches of full name or + // "last name" (i.e. last dotted part) + if (fullnameLower === object || parts.slice(-1)[0] === object) + score += Scorer.objNameMatch; + else if (parts.slice(-1)[0].indexOf(object) > -1) + score += Scorer.objPartialMatch; // matches in last name + + const objName = objNames[match[1]][2]; + const title = titles[match[0]]; + + // If more than one term searched for, we require other words to be + // found in the name/title/description + const otherTerms = new Set(objectTerms); + otherTerms.delete(object); + if (otherTerms.size > 0) { + const haystack = `${prefix} ${name} ${objName} ${title}`.toLowerCase(); + if ( + [...otherTerms].some((otherTerm) => haystack.indexOf(otherTerm) < 0) + ) + return; + } + + let anchor = match[3]; + if (anchor === "") anchor = fullname; + else if (anchor === "-") anchor = objNames[match[1]][1] + "-" + fullname; + + const descr = objName + _(", in ") + title; + + // add custom score for some objects according to scorer + if (Scorer.objPrio.hasOwnProperty(match[2])) + score += Scorer.objPrio[match[2]]; + else score += Scorer.objPrioDefault; + + results.push([ + docNames[match[0]], + fullname, + "#" + anchor, + descr, + score, + filenames[match[0]], + SearchResultKind.object, + ]); + }; + Object.keys(objects).forEach((prefix) => + objects[prefix].forEach((array) => + objectSearchCallback(prefix, array) + ) + ); + return results; + }, + + /** + * search for full-text terms in the index + */ + performTermsSearch: (searchTerms, excludedTerms) => { + // prepare search + const terms = Search._index.terms; + const titleTerms = Search._index.titleterms; + const filenames = Search._index.filenames; + const docNames = Search._index.docnames; + const titles = Search._index.titles; + + const scoreMap = new Map(); + const fileMap = new Map(); + + // perform the search on the required terms + searchTerms.forEach((word) => { + const files = []; + const arr = [ + { files: terms[word], score: Scorer.term }, + { files: titleTerms[word], score: Scorer.title }, + ]; + // add support for partial matches + if (word.length > 2) { + const escapedWord = _escapeRegExp(word); + if (!terms.hasOwnProperty(word)) { + Object.keys(terms).forEach((term) => { + if (term.match(escapedWord)) + arr.push({ files: terms[term], score: Scorer.partialTerm }); + }); + } + if (!titleTerms.hasOwnProperty(word)) { + Object.keys(titleTerms).forEach((term) => { + if (term.match(escapedWord)) + arr.push({ files: titleTerms[term], score: Scorer.partialTitle }); + }); + } + } + + // no match but word was a required one + if (arr.every((record) => record.files === undefined)) return; + + // found search word in contents + arr.forEach((record) => { + if (record.files === undefined) return; + + let recordFiles = record.files; + if (recordFiles.length === undefined) recordFiles = [recordFiles]; + files.push(...recordFiles); + + // set score for the word in each file + recordFiles.forEach((file) => { + if (!scoreMap.has(file)) scoreMap.set(file, {}); + scoreMap.get(file)[word] = record.score; + }); + }); + + // create the mapping + files.forEach((file) => { + if (!fileMap.has(file)) fileMap.set(file, [word]); + else if (fileMap.get(file).indexOf(word) === -1) fileMap.get(file).push(word); + }); + }); + + // now check if the files don't contain excluded terms + const results = []; + for (const [file, wordList] of fileMap) { + // check if all requirements are matched + + // as search terms with length < 3 are discarded + const filteredTermCount = [...searchTerms].filter( + (term) => term.length > 2 + ).length; + if ( + wordList.length !== searchTerms.size && + wordList.length !== filteredTermCount + ) + continue; + + // ensure that none of the excluded terms is in the search result + if ( + [...excludedTerms].some( + (term) => + terms[term] === file || + titleTerms[term] === file || + (terms[term] || []).includes(file) || + (titleTerms[term] || []).includes(file) + ) + ) + break; + + // select one (max) score for the file. + const score = Math.max(...wordList.map((w) => scoreMap.get(file)[w])); + // add result to the result list + results.push([ + docNames[file], + titles[file], + "", + null, + score, + filenames[file], + SearchResultKind.text, + ]); + } + return results; + }, + + /** + * helper function to return a node containing the + * search summary for a given text. keywords is a list + * of stemmed words. + */ + makeSearchSummary: (htmlText, keywords, anchor) => { + const text = Search.htmlToText(htmlText, anchor); + if (text === "") return null; + + const textLower = text.toLowerCase(); + const actualStartPosition = [...keywords] + .map((k) => textLower.indexOf(k.toLowerCase())) + .filter((i) => i > -1) + .slice(-1)[0]; + const startWithContext = Math.max(actualStartPosition - 120, 0); + + const top = startWithContext === 0 ? "" : "..."; + const tail = startWithContext + 240 < text.length ? "..." : ""; + + let summary = document.createElement("p"); + summary.classList.add("context"); + summary.textContent = top + text.substr(startWithContext, 240).trim() + tail; + + return summary; + }, +}; + +_ready(Search.init); diff --git a/previews/271/_static/sphinx_highlight.js b/previews/271/_static/sphinx_highlight.js new file mode 100644 index 000000000..8a96c69a1 --- /dev/null +++ b/previews/271/_static/sphinx_highlight.js @@ -0,0 +1,154 @@ +/* Highlighting utilities for Sphinx HTML documentation. */ +"use strict"; + +const SPHINX_HIGHLIGHT_ENABLED = true + +/** + * highlight a given string on a node by wrapping it in + * span elements with the given class name. + */ +const _highlight = (node, addItems, text, className) => { + if (node.nodeType === Node.TEXT_NODE) { + const val = node.nodeValue; + const parent = node.parentNode; + const pos = val.toLowerCase().indexOf(text); + if ( + pos >= 0 && + !parent.classList.contains(className) && + !parent.classList.contains("nohighlight") + ) { + let span; + + const closestNode = parent.closest("body, svg, foreignObject"); + const isInSVG = closestNode && closestNode.matches("svg"); + if (isInSVG) { + span = document.createElementNS("http://www.w3.org/2000/svg", "tspan"); + } else { + span = document.createElement("span"); + span.classList.add(className); + } + + span.appendChild(document.createTextNode(val.substr(pos, text.length))); + const rest = document.createTextNode(val.substr(pos + text.length)); + parent.insertBefore( + span, + parent.insertBefore( + rest, + node.nextSibling + ) + ); + node.nodeValue = val.substr(0, pos); + /* There may be more occurrences of search term in this node. So call this + * function recursively on the remaining fragment. + */ + _highlight(rest, addItems, text, className); + + if (isInSVG) { + const rect = document.createElementNS( + "http://www.w3.org/2000/svg", + "rect" + ); + const bbox = parent.getBBox(); + rect.x.baseVal.value = bbox.x; + rect.y.baseVal.value = bbox.y; + rect.width.baseVal.value = bbox.width; + rect.height.baseVal.value = bbox.height; + rect.setAttribute("class", className); + addItems.push({ parent: parent, target: rect }); + } + } + } else if (node.matches && !node.matches("button, select, textarea")) { + node.childNodes.forEach((el) => _highlight(el, addItems, text, className)); + } +}; +const _highlightText = (thisNode, text, className) => { + let addItems = []; + _highlight(thisNode, addItems, text, className); + addItems.forEach((obj) => + obj.parent.insertAdjacentElement("beforebegin", obj.target) + ); +}; + +/** + * Small JavaScript module for the documentation. + */ +const SphinxHighlight = { + + /** + * highlight the search words provided in localstorage in the text + */ + highlightSearchWords: () => { + if (!SPHINX_HIGHLIGHT_ENABLED) return; // bail if no highlight + + // get and clear terms from localstorage + const url = new URL(window.location); + const highlight = + localStorage.getItem("sphinx_highlight_terms") + || url.searchParams.get("highlight") + || ""; + localStorage.removeItem("sphinx_highlight_terms") + url.searchParams.delete("highlight"); + window.history.replaceState({}, "", url); + + // get individual terms from highlight string + const terms = highlight.toLowerCase().split(/\s+/).filter(x => x); + if (terms.length === 0) return; // nothing to do + + // There should never be more than one element matching "div.body" + const divBody = document.querySelectorAll("div.body"); + const body = divBody.length ? divBody[0] : document.querySelector("body"); + window.setTimeout(() => { + terms.forEach((term) => _highlightText(body, term, "highlighted")); + }, 10); + + const searchBox = document.getElementById("searchbox"); + if (searchBox === null) return; + searchBox.appendChild( + document + .createRange() + .createContextualFragment( + '

' + + '' + + _("Hide Search Matches") + + "

" + ) + ); + }, + + /** + * helper function to hide the search marks again + */ + hideSearchWords: () => { + document + .querySelectorAll("#searchbox .highlight-link") + .forEach((el) => el.remove()); + document + .querySelectorAll("span.highlighted") + .forEach((el) => el.classList.remove("highlighted")); + localStorage.removeItem("sphinx_highlight_terms") + }, + + initEscapeListener: () => { + // only install a listener if it is really needed + if (!DOCUMENTATION_OPTIONS.ENABLE_SEARCH_SHORTCUTS) return; + + document.addEventListener("keydown", (event) => { + // bail for input elements + if (BLACKLISTED_KEY_CONTROL_ELEMENTS.has(document.activeElement.tagName)) return; + // bail with special keys + if (event.shiftKey || event.altKey || event.ctrlKey || event.metaKey) return; + if (DOCUMENTATION_OPTIONS.ENABLE_SEARCH_SHORTCUTS && (event.key === "Escape")) { + SphinxHighlight.hideSearchWords(); + event.preventDefault(); + } + }); + }, +}; + +_ready(() => { + /* Do not call highlightSearchWords() when we are on the search page. + * It will highlight words from the *previous* search query. + */ + if (typeof Search === "undefined") SphinxHighlight.highlightSearchWords(); + SphinxHighlight.initEscapeListener(); +}); diff --git a/previews/271/bsp/imx8/imx8.html b/previews/271/bsp/imx8/imx8.html new file mode 100644 index 000000000..03a3b0438 --- /dev/null +++ b/previews/271/bsp/imx8/imx8.html @@ -0,0 +1,179 @@ + + + + + + + + + i.MX 8 Manuals — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+ +
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mm/head.html b/previews/271/bsp/imx8/imx8mm/head.html new file mode 100644 index 000000000..51304ff63 --- /dev/null +++ b/previews/271/bsp/imx8/imx8mm/head.html @@ -0,0 +1,4840 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + + + + +

L-1002e.Ax i.MX 8M Mini BSP +Manual Head

Document Title

L-1002e.Ax i.MX 8M Mini BSP +Manual Head

Document Type

BSP Manual

Article Number

L-1002e.Ax

Yocto Manual

Release Date

XXXX/XX/XX

Is Branch of

L-1002e.Ax i.MX 8M Mini BSP +Manual Head

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +phyCORE-i.MX8M Mini Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads of our product.

+
+

1.1. Supported Hardware

+

The phyBOARD-Polis populated with either the i.MX 8M Mini SoC or i.MX 8M Nano SoC, is +supported.

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-NXP-i.MX8MM-PD24.1.0 download. +If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware

+
+

1.1.1. phyBOARD-Polis Components

+ + + + + + +
+../../../_images/polis-front.jpg +
+

phyBOARD-Polis Components (top)

+
+
+
+../../../_images/polis-back.jpg + +
+

phyBOARD-Polis Components (bottom)

+
+
+
+
+
+
+
+

2. Getting Started

+

The phyCORE-i.MX8M Mini Kit is shipped with a pre-flashed SD card. It contains the +phytec-qt6demo-image and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+

There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool dd. An +alternative way is to use PHYTEC’s system initialization program called +partup, which makes it especially easy to +format more complex systems. You can get prebuilt Linux binaries of partup from its release page. Also read +partup’s README for installation +instructions.

+
+

2.1. Get the Image

+

The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using dd, can be downloaded from the PHYTEC download server.

+

Get either the partup package or the WIC image from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt6demo-image-phyboard-polis-imx8mm-5.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+
+
+
+

Note

+

For eMMC, more complex partitioning schemes or even just large images, we +recommend using the partup package, as it is faster in writing than dd +and allows for a more flexible configuration of the target flash device.

+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card, you must have root privileges on your Linux +host PC. Be very careful when specifying the destination device! All files +on the selected device will be erased immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system on your host PC!

+
+
+

2.2.1. Finding the Correct Device

+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+

Unmount all those partitions, e.g.:

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

Now, the SD card is ready to be flashed with an image, using either partup, +dd or bmap-tools.

+
+
+

2.2.2. Using bmap-tools

+

One way to prepare an SD card is using +bmap-tools. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host:~$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-polis-imx8mm-5?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

Replace <your_device> with your actual SD card’s device name found previously, +and make sure to place the file <IMAGENAME>-<MACHINE>.wic.bmap alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip.

+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.2.3. Using partup

+

Writing to an SD card with partup is done in a single command:

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-polis-imx8mm-5?(.rootfs).partup /dev/<your_device>
+
+
+

Make sure to replace <your_device> with your actual device name found previously.

+

Further usage of partup is explained at its official documentation website.

+
+

Warning

+

Host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to write partup packages created with Yocto Mickledore +or newer to SD-Card. This is due to a new default option in resize2fs which causes an +incompatibility. See release notes.

+
+
+

Note

+

partup has the advantage of allowing to clear specific raw areas in the +MMC user area, which is used in our provided partup packages to erase any +existing U-Boot environments. This is a known issue bmaptool does not +solve, as mentioned in the previous chapter.

+

Another key advantage of partup over other flashing tools is that it allows +configuring MMC specific parts, like writing to eMMC boot partitions, without +the need to call multiple other commands when writing.

+
+
+
+

2.2.4. Using dd

+

After having unmounted all SD card’s partitions, you can create your bootable SD card.

+

Some PHYTEC BSPs produce uncompressed images (with filename-extension *.wic), +and some others produce compressed images (with filename-extension *.wic.xz).

+

To flash an uncompressed images (*.wic) use command below:

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-polis-imx8mm-5?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Or to flash a compressed images (*.wic.xz) use that command:

+
host:~$ xzcat phytec-qt6demo-image-phyboard-polis-imx8mm-5?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Again, make sure to replace <your_device> with your actual device name found +previously.

+

The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

+
+
+
+

2.3. First Start-up

+ + + + + + + +
Bootmode Selection
+../../../_images/SD_Card_Boot.jpg +
+

Mini

+
+
+
+
    +

  • Insert the SD card

    • +

  • Connect the target and the host with mirco USB on (X30) +debug USB

    • +

  • Power up the board

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 8M Mini BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (scarthgap).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (scarthgap).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-IMX8MM; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-vendor MACHINE=phyboard-polis-imx8mm-5 ./phyLinux init -p imx8mm -r BSP-Yocto-NXP-i.MX8MM-PD24.1.0
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the phyboard-polis-imx8mm-5 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx8mm.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, +lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY firmware images

    • +

  • imx-boot: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM +Trusted Firmware and DDR firmware. This is the final bootloader image which is +bootable.

    • +

  • fitImage: Linux kernel FIT image

    • +

  • fitImage-its*.its: FIT image configuration file

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx8mm-phyboard-polis-rdk*.dtb: Kernel device tree file

    • +

  • imx8mm-phy*.dtbo: Kernel device tree overlay files

    • +

  • phytec-qt6demo-image*.tar.gz: Root file system

    • +

  • phytec-qt6demo-image*.rootfs.wic.xz: SD card image

    • +
+
+
+
+
+

4. Installing the OS

+
+

4.1. Bootmode Switch (S1)

+

The phyBOARD-Polis features a boot switch with six individually switchable ports to +select the phyCORE-i.MX 8M Mini default bootsource.

+
+

4.1.1. Mini

+ + + + + + + + + + +
Bootmode Selection
+../../../_images/eMMC.jpg +
+

eMMC (Default SoM boot)

+
+
+
+../../../_images/SPI_NOR.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download1.png +
+

USB Serial Download

+
+
+
+../../../_images/SD_Card_Boot.jpg +
+

SD Card

+
+
+
+ + + + + + + +
Switch between UART1 RS485/RS232
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+
+
+

4.2. Flash eMMC

+

For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see Setup Network Host.

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S1) is set to eMMC.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk2p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from Network

+

i.MX 8M Mini boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

4.2.1.1. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Show your available image files on the host:

+
host:~$ ls /srv/tftp
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.bmap
+
+
+

Send the image with the bmaptool command combined with ssh through the network +to the eMMC of your device:

+
host:~$ scp /srv/tftp/phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.xz /dev/mmcblk2"
+
+
+
+
+

4.2.1.2. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Take a compressed or decompressed image with the accompanying block map file +*.bmap on the host and send it with ssh through the network to the eMMC of +the target with a one-line command:

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.* /tmp && bmaptool copy /tmp/phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.xz /dev/mmcblk2
+
+
+
+
+

4.2.1.3. Flash eMMC from Network in U-Boot on Target

+

These steps will show how to update the eMMC via a network.

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE.

+
+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Uncompress your image

+
host:~$ unxz /srv/tftp/phytec-headless-image-phyboard-polis-imx8mm-5.rootfs.wic.xz
+
+
+

Load your image via network to RAM:

+
    +

  • when using dhcp

    +
    u-boot=> dhcp phytec-headless-image-phyboard-polis-imx8mm-5.rootfs.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.1 (1 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.1
+Filename 'phytec-headless-image-phyboard-polis-imx8mm-5.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • when using a static ip address (serverip and ipaddr must be set +additionally).

    +
    u-boot=> tftp ${loadaddr} phytec-headless-image-phyboard-polis-imx8mm-5.rootfs.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-phyboard-polis-imx8mm-5.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
+
+
+
+
+

4.2.2. Flash eMMC U-Boot image via Network from running U-Boot

+

Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x42 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.3. Flash eMMC from USB stick

+
+

4.2.3.1. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-qt6demo-image-phyboard-polis-imx8mm-5.|yocto-imageext|). Set the bootmode switch (S1) to SD Card.

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ ls /mnt
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Mini eMMC (MMC device 2 without partition):

    +
    target:~$ bmaptool copy /mnt/phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.xz /dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Tip

    +

    Before this will work, you need to configure the bootmode switch (S1) to +eMMC.

    +
    +
    • +
+
+
+

4.2.3.2. Flash eMMC from USB stick in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE.

+
+

These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch (S1) to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied uncompressed WIC image to +the USB slot.

+

Load your image from the USB device to RAM:

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 0x58000000 phytec-headless-image-|yocto-machinename|.rootfs.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write 0x58000000 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+
+

4.2.4. Flash eMMC from SD Card

+

Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (*.wic) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see Resizing ext4 Root Filesystem.

+

Alternatively, flash a partup package to the SD card, as described in +Getting Started. This will ensure the full space of the SD card is used.

+
+

4.2.4.1. Flash eMMC from SD card in Linux on Target

+

You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card.

+
    +

  • Show your saved partup package or WIC image files on the SD card:

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.partup
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Mini eMMC (MMC device 2 without +partition) using partup:

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.partup /dev/mmcblk2
+
    +
    +

    Flashing the partup package has the advantage of using the full capacity of +the eMMC device, adjusting partitions accordingly.

    +
    +

    Note

    +

    Alternatively, bmaptool may be used instead:

    +
    target:~$ bmaptool copy phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.xz /dev/mmcblk2
+
    +
    +

    Keep in mind that the root partition does not make use of the full space when +flashing with bmaptool.

    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Warning

    +

    Before this will work, you need to configure the bootmode switch (S1) to eMMC.

    +
    +
    • +
+
+
+

4.2.4.2. Flash eMMC from SD card in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE. If the +image file is too large use the Updating eMMC from SD card in +Linux on Target subsection.

+
+
    +

  • Flash an SD card with a working image and create a third ext4 partition. Copy +the WIC image (for example phytec-qt6demo-image.rootfs.wic) to this +partition.

    • +

  • Configure the bootmode switch (S1) to SD Card and insert the SD Card.

    • +

  • Power on the board and stop in U-Boot.

    • +

  • Load the image:

    +
    u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-phyboard-polis-imx8mm-5.rootfs.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • Switch the mmc dev to eMMC:

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • Flash your WIC image (for example phytec-qt6demo-image.rootfs.wic) +from the SD card to eMMC. This will partition the card and copy imx-boot, +Image, dtb, dtbo, and root file system to eMMC.

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • Power off the board and change the bootmode switch (S1) to eMMC.

    • +
+
+
+
+
+

4.3. Flash SPI NOR Flash

+

The phyCORE-i.MX8MM modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set bootmode switch (S1) to SPI NOR. The SPI Flash is usually quite small. +The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash populated. Only the +bootloader and the environment can be stored. The kernel, device tree, and file +system are taken from eMMC by default.

+

The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with:

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. Flash SPI NOR Flash from Network

+

The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-i.MX 8M Mini.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+
+

4.3.1.1. Flash SPI NOR from Network in kernel on Target

+
    +

  • Copy the image from the host to the target:

    +
    host:~$ scp imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • Find the number of blocks to erase of the U-boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the U-Boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.1.2. Flash SPI NOR from Network in U-Boot on Target

+

Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI NOR flash needs to be probed:

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • A specially formatted U-Boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image over tftp, erase and write the +bootloader to the flash:

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+

4.3.2. Flash SPI NOR Flash from SD Card

+

The bootloader on SPI NOR flash can be also flashed with SD Card.

+
+

4.3.2.1. Flash SPI NOR from SD Card in kernel on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi to the first partition +on the SD Card.

    • +

  • Mount the SD Card:

    +
    target:~$ mount /dev/mmcblk1p1 /mnt
+
    +
    +
    • +

  • Find the number of blocks to erase of the U-Boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the u-boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.2.2. Flash SPI NOR from SD Card in U-Boot on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi to the first partition +on the SD Card.

    • +

  • Before reading and writing are possible, the SPI-NOR flash +needs to be probed:

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • A specially formatted U-boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image from the SD Card, erase and write +the bootloader to the flash:

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A6 RAUC Update & Device Management Manual.

+
+
+

4.5. EFI Boot

+

Standardboot in U-Boot also supports booting distros over efi. By default the +U-Boot will search for a bootscript first, which is used to boot our Ampliphy +distro. If it does not find any bootscript, it will search for bootable efi +applications. So for booting over efi just make sure you don’t have our distro +installed.

+
+

4.5.1. Disable booting with efi

+

To disable booting with efi you have to set the doefiboot variable to 0. +Also make sure you do not have efi or efi_mgr specified in the +bootmeths environment variable.

+
u-boot=> setenv doefiboot 0
+u-boot=> env save; env save;
+
+
+
+
+

4.5.2. Switch to only efi boot

+

If you want to only boot with efi, you can set the bootmeths environment +variable to efi. Also make sure you have the doefiboot environment variable +set to 1.

+
u-boot=> setenv bootmeths efi
+u-boot=> env save; env save;
+
+
+
+
+

4.5.3. Installing a distro

+

With efi you can install and boot different distros like openSUSE, Fedora or +Debian. First you have to get the iso Image from their website. For example:

+

https://cdimage.debian.org/debian-cd/current/arm64/iso-dvd/

+

Then copy the .iso file to a usb stick for example. Make sure you select the +correct device:

+
sudo dd if=file.iso of=/dev/sdx bs=1M conv=fsync status=progress
+
+
+

Insert the USB stick into the board and boot it. GRUB will then prompt you with +a menu where you can select what to do. Here select install. Then you have to +click through the installation menu. This is relatively straightforward and +differs a bit for every distro. You can install the distro for example to emmc +(mmc 2) or sdcard (mmc 1). Make sure you do not overwrite +your U-Boot during the install. Best to choose a different medium to install to +than the U-Boot is stored on. Otherwise manual partitioning will be required. +The automatic partitioning will start at the beginning of the disk. To not +overwrite the U-Boot, use an offset of 4MiB at the beginning of the disk.

+

During the Installation of Debian you will be asked, if you want to Force the +GRUB installation to the EFI removable media path. Select no. Also select no, +when you will be asked if you want to update the NVRAM variables. Otherwise the +grub-dummy installation step will fail and you will be sent back to the +“Force GRUB installation” prompt.

+

After the installation is complete, reboot the board and remove the +installation medium (USB-stick). The board should then boot the distro you +installed.

+

If that does not happen, check if there is a boot option set for the distro. +The easiest way is with the eficonfig command.

+
u-boot=> eficonfig
+
+
+

That will open a menu. Then you can select Edit Boot Option. It will show +you the current boot options. If this is empty or you don’t find your distro, +select Add Boot Option to add a new one. For debian for example you only +need to set the description and the file. You can enter whatever you want into +the description field. When you select the file field, you can select the disc +you installed the distro on and partition number one. For example +“mmc 2:1” for emmc, or “mmc 1:1” for sdcard. The file you +need to select is at EFI/debian/grubaa64.efi. After that save, quit and +reset the board. The board should then boot into debian.

+
+
+
+
+

5. Development

+

Starting with this release, the boot behaviour in U-Boot changes. Before, kernel +and device tree came as separate blobs. Now, both will be included in a single +FIT image blob. Further, the logic for booting the PHYTEC ampliphy distributions +is moved to a boot script which itself is part of a separate FIT image blob. +To revert to the old style of booting, you may do

+
u-boot=> run legacyboot
+
+
+
+

Note

+

This way of booting is deprecated and will be removed in the next release. +By default, booting via this command will return an error as kernel and +device tree are missing in the boot partition.

+
+
+

5.1. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone git://git.phytec.de/u-boot-imx)

+
+
+

5.1.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-imx and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    https://github.com/phytec/linux-phytec-imx
+
    +
    +
    • +

  • Our i.MX 8M Mini kernel is based on the linux-phytec-imx kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.1.2. Get the SDK

+

You can download the SDK here, or build it yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

After a successful build the SDK installer is deployed to build/deploy*/sdk.

+
+
+

5.1.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-vendor-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.x.sh
+host:~$ ./phytec-ampliphy-vendor-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.x.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor/5.0.x):
+You are about to install the SDK to "/opt/ampliphy-vendor/5.0.x". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.1.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-vendor/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.1.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.2. U-Boot standalone build

+
+

5.2.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag used in this release is called v2022.04_2.2.2-phy5

    • +

  • Check out the needed U-Boot tag:

    +
    host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2022.04_2.2.2-phy5
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.2.2. Get the needed binaries

+

To build the bootloader, you need to copy these files to your u-boot-imx +build directory and rename them to fit with mkimage script:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx8mm.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +
+

If you already built our BSP with Yocto, you can get the +bl31-imx8mm.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: BSP Images

+

Or you can download the files here: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/imx-boot-tools/

+
+

Warning

+

Make sure you rename the files you need so that they are compatible with the +mkimage tool.

+
+
+
+

5.2.3. Build the bootloader

+
    +

  • build flash.bin (imx-boot):

    +
    host:~/u-boot-imx$ make phycore-imx8mm_defconfig
+host:~/u-boot-imx$ make flash.bin
+
    +
    +
    • +
+
+
+

5.2.4. Flash the bootloader to a block device

+

The flash.bin can be found at u-boot-imx/ directory and now can be +flashed. A chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 8M Mini

33 kiB

33 kiB

/dev/mmcblk2

+

E.g. flash SD card:

+
host:~/u-boot-imx$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=33 conv=sync
+
+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables +“BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+

5.2.5. Build U-Boot With a Fixed RAM Size

+

If you cannot boot your system anymore because the hardware introspection in the +EEPROM is damaged or deleted, you can create a flash.bin with a fixed ram size. +You should still contact support and flash the correct EEPROM data, as this +could lead to unexpected behavior.

+

Follow the steps to get the U-boot sources and check the correct branch in the +Build U-Boot section.

+

Edit the file configs/phycore-imx8mm_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MM=y
+CONFIG_PHYCORE_IMX8MM_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_4GB=y
+
+
+

Choose the correct RAM size as populated on the board and uncomment the line for +this ram size. +After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+
+

5.3. Kernel standalone build

+

The kernel is packaged in a FIT image together with the device tree. U-Boot has +been adapted to be able to load a FIT image and boot the kernel contained in it. +As a result, the kernel Image has to packaged in a FIT image.

+
+

5.3.1. Setup sources

+
    +

  • The used linux-phytec-imx branch can be found in the release notes

    • +

  • The tag needed for this release is called v5.15.71_2.2.2-phy3

    • +

  • Check out the needed linux-phytec-imx tag:

    +
    host:~$ git clone https://github.com/phytec/linux-phytec-imx
+host:~$ cd ~/linux-phytec-imx/
+host:~/linux-phytec-imx$ git fetch --all --tags
+host:~/linux-phytec-imx$ git checkout tags/v5.15.71_2.2.2-phy3
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-phytec-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-phytec-imx$ source /opt/ampliphy-vendor/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.3.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-phytec-imx$ make imx8_phytec_defconfig
+host:~/linux-phytec-imx$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-phytec-imx/arch/arm64/boot/Image.gz

    • +

  • The dtb can be found at +~/linux-phytec-imx/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-phytec-imx$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.3.3. Package the kernel in a FIT image

+

To simply replace the kernel, you will need an image tree source (.its) +file. If you already built our BSP with Yocto, you can get the its file from the +directory mentioned here: BSP Images Or you can download the file here: +https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/

+

Copy the .its file to the current working directory, create a link to the kernel +image and create the final fitImage with mkimage.

+
host:~/linux-phytec-imx$ cp /path/to/yocto/deploydir/fitimage-its*.its .
+                  && ln -s arch/arm64/boot/Image.gz linux.bin
+                  && uboot-mkimage -f fitImage-its*.its fitImage
+
+
+
+
+

5.3.4. Copy FIT image and kernel modules to SD Card

+

When one-time boot via netboot is not sufficient, the FIT image along with the +kernel modules may be copied directly to a mounted SD card.

+
host:~/linux-phytec-imx$ cp fitImage /path/to/sdcard/boot/
+host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.4. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.4.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.4.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy-ampliphy-vendor/images/phyboard-polis-imx8mm-5/. For flashing a wic image to eMMC, +you will also need phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.

+
+
+

5.4.3. Prepare Target

+

Set the bootmode switch (S1) to USB Serial Download. Also, connect USB port +X2 to your host.

+
+
+

5.4.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via (X30), as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.4.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.4.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic
+
+
+
+
+

5.4.7. Flashing SPI NOR Flash via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b qspi imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi
+
+
+

This will update the U-Boot on SPI NOR Flash but not the environment. You may need to erase the old +environment so the default environment of the new U-Boot gets loaded:

+
u-boot=> env erase
+u-boot=> reset
+
+
+
+
+
+

5.5. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.5.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.5.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.5.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.6. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.6.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel fitimage to your tftp directory:

    +
    host:~$ cp fitImage /srv/tftp
+
    +
    +
    • +

  • Copy the bootscript to your tftp directory:

    +
    host:~$ cp boot.scr.uimg /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.6.2. Set the bootenv.txt for Netboot

+

Create a bootenv.txt file in your tftp directory and write the following variables into it.

+
nfsroot=/srv/nfs
+overlays=<overlayconfignames>
+
+
+

<overlayconfignames> has to be replaced with the devicetree overlay config names that you want to use. +Separate the config names by hashtag. For example:

+
overlays=conf-example-overlay1.dtbo#conf-example-overlay2.dtbo
+
+
+
+

Tip

+

All supported devicetree overlays are in the device tree chapter. Or can be printed with:

+
host:~$ dumpimage -l fitImage
+
+
+
+
+
+

5.6.3. Network Settings on Target

+

To customize the targets ethernet configuration, please follow the description +here: Network Environment Customization

+
+
+

5.6.4. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> setenv boot_targets ethernet
+u-boot=> bootflow scan -lb
+
    +
    +
    • +
+
+
+
+

5.7. Accessing the Development states

+
+

5.7.1. Development state of current release

+

These release manifests exist to give you access to the development states +of the Yocto BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line:

+
host:~$ ./phyLinux init -p imx8mm -r BSP-Yocto-NXP-i.MX8MM-PD24.1.y
+
+
+

This will initialize a BSP that will track the latest development state of the +current release (BSP-Yocto-NXP-i.MX8MM-PD24.1.0). From now on repo sync in this folder +will pull all the latest changes from our Git repositories:

+
host:~$ repo sync
+
+
+
+
+

5.7.2. Development state of upcoming release

+

Also development states of upcoming releases can be accessed this way. +For this execute the following command and look for a release with a higher +PDXX.Y number than the latest one (BSP-Yocto-NXP-i.MX8MM-PD24.1.0) and .y at the +end:

+
host:~$ ./phyLinux init -p imx8mm
+
+
+
+
+
+

5.8. Accessing the Latest Upstream Support

+

We have a vanilla manifest that makes use of the Yocto master branches (not an +NXP release), Linux, and U-Boot. This can be used to test the latest upstream +kernel/U-Boot.

+
+

Note

+

The master manifest reflects the latest state of development. This tends to +be broken from time to time. We try to fix the master on a regular basis.

+
+
host:~$ ./phyLinux init -p imx8mm -r BSP-Yocto-Ampliphy-i.MX8MM-master
+
+
+
+
+

5.9. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.9.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+

5.10. Switch back to legacyboot

+
+

Warning

+

As we switched to standardboot with fitimage as default, legacyboot is +deprecated. We kept the option to switch back to legacyboot for this +release, but it will be removed in the future.

+
+
+

5.10.1. Changes in Yocto

+

By default, the fitImage and bootscript will be deployed into the wic.xz Image. +To switch back to legacyboot, you need to replace the fitImage and bootscript +for the kernel image and the devicetrees. They are still in the deploy +folder from the Yocto build, so you can manually copy them to the boot +partition on your device. Otherwise you can do the following changes in Yocto +to get the kernel and devicetrees deployed in the Image again.

+

First create the variable KERNEL_DEVICETREE_DEPLOY. This can be done for +example in the local.conf file in your build directory conf/local.conf. +The variable is basically a copy of the KERNEL_DEVICETREE variable that is +set in conf/machine/phyboard-polis-imx8mm-5.conf in meta-phytec but the freescale +at the beginning needs to be removed, so that only the devicetree filename are +left. In the end it should look something like this:

+
KERNEL_DEVICETREE_DEPLOY = " \
+     imx8mp-phyboard-pollux-rdk.dtb \
+     imx8mp-phyboard-pollux-isp-csi1.dtbo \
+     imx8mp-phyboard-pollux-isp-csi2.dtbo \
+     imx8mp-phyboard-pollux-isi-csi1.dtbo \
+     imx8mp-phyboard-pollux-isi-csi2.dtbo \
+     imx8mp-phyboard-pollux-peb-av-10.dtbo \
+     imx8mp-phyboard-pollux-peb-wlbt-05.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2-fpdlink-port1.dtbo \
+     imx8mp-phycore-no-eth.dtbo \
+     imx8mp-phycore-no-rtc.dtbo \
+     imx8mp-phycore-no-spiflash.dtbo \
+     imx8mp-phycore-rpmsg.dtbo \
+"
+
+
+

Then add this line:

+
IMAGE_BOOT_FILES:mx8m-nxp-bsp:append = " Image oftree ${KERNEL_DEVICETREE_DEPLOY}"
+
+
+
+

Note

+

A clean might be required for this to work.

+
bitbake -c cleanall phytec-qt6demo-image
+
+
+
+

Then start the build:

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

5.10.2. Changes in U-Boot environment

+

To re-enable legacyboot set the following variable:

+
uboot=> setenv dolegacyboot 1
+uboot=> env save; env save;
+uboot=> boot
+
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 8M Mini BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 8M Mini SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Board.dts - include the module dtsi file. Devices that come from the i.MX 8M Mini +SoC but are just routed down to the carrier board and used there are included +in this dts.

    • +

  • Overlay.dtso - enable/disable features depending on optional hardware that +may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10)

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 8 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the folder arch/arm64/boot/dts/freescale/.

+

Available overlays for phyboard-polis-imx8mm-5.conf are:

+
imx8mm-phyboard-polis-peb-eval-01.dtbo
+|dtbo-peb-av-10|
+imx8mm-phycore-rpmsg.dtbo
+imx8mm-phycore-no-eth.dtbo
+imx8mm-phycore-no-spiflash.dtbo
+imx8mm-vm016.dtbo
+imx8mm-vm016-fpdlink.dtbo
+imx8mm-vm017.dtbo
+imx8mm-vm017-fpdlink.dtbo
+imx8mm-dual-vm017-fpdlink.dtbo
+
+
+

Otherwise you can show the content of a FIT image including all overlay +configs in the FIT image with this command in Linux:

+
host:~$ dumpimage -l /boot/fitImage
+
+
+

or in U-Boot:

+
u-boot=> load mmc ${mmcdev}:1 ${loadaddr} fitImage
+u-boot=> iminfo
+
+
+

The usage of overlays can be configured during runtime in Linux or U-Boot. +Overlays are applied during the boot process in the bootloader after the +boot command is called and before the kernel is loaded. The next sections +explain the configuration in more detail.

+
+

6.2.2.1. Set ${overlays} variable

+

The ${overlays} U-Boot environment variable contains a number-sign (#) +separated list of overlays that will be applied during boot. The overlays +listed in the overlays variable must be included in the FIT image. Overlays set +in the $KERNEL_DEVICETREE Yocto machine variable will automatically be added to +the FIT image.

+

The ${overlays} variable can either be set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +When desired to use the overlays variable as set manually in the U-Boot +environment, disable bootenv by setting env set no_bootenv 1 as the overlays +variable may be overwritten during the execution of the boot script. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=conf-imx8mm-phyboard-polis-rdk-peb-eval-01.dtbo#conf-imx8mm-phyboard-polis-peb-av-10.dtbo
+
+
+

Changes will take effect after the next reboot. If no bootenv.txt file is +available the overlays variable can be set directly in the U-Boot environment.

+
u-boot=> setenv overlays conf-imx8mm-phyboard-polis-peb-av-10.dtbo
+u-boot=> printenv overlays
+overlays=conf-imx8mm-phyboard-polis-peb-av-10.dtbo
+u-boot=> boot
+
+
+

If a user defined ${overlays} variable should be directly loaded from U-Boot +environment but there is still an external bootenv.txt available, the ${no_bootenv} +variable needs to be set as a flag:

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays conf-imx8mm-phyboard-polis-peb-av-10.dtbo
+u-boot=> boot
+
+
+

More information about the external environment can be found in +U-boot External Environment subsection of the +device tree overlay section.

+

We use the ${overlays} variable for overlays describing expansion boards and +cameras that can not be detected during run time. To prevent applying overlays +unset the overlays variable and set no_bootenv to anything other than 0.

+
u-boot=> env delete overlays
+u-boot=> env set no_bootenv 1
+
+
+

If desired to use the bootenv.txt file for setting U-Boot variables other than +overlays and having overlays disabled, remove the overlays definition line from +the bootenv.txt file instead of setting no_bootenv.

+
+
+

6.2.2.2. SoM Variants

+

Additional overlays are applied automatically to disable components that are not +populated on the SoM. The detection is done with the EEPROM data (EEPROM SoM +Detection) found on the SoM i2c EEPROM.

+

It depends on the SoM variant if any device tree overlays will be applied. To check +if an overlay will be applied on the running SoM in U-Boot, run:

+
u-boot=> env print fit_extensions
+
+
+

If the EEPROM data is not available, no device tree overlays are applied.

+

To prevent application of the SoM variant related overlays the +${no_extensions} variable can be set to 1 in the bootloader environment:

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot External Environment

+

During the start of the Linux Kernel the external environment bootenv.txt +text file will be loaded from the boot partition of an MMC device or via TFTP. +The main intention of this file is to store the ${overlays} variable. This makes +it easy to pre-define the overlays in Yocto depending on the used machine. The +content from the file is defined in the Yocto recipe bootenv found in +meta-phytec: +https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=scarthgap

+

Other variables can be set in this file, too. They will overwrite the existing +settings in the environment. But only variables evaluated after issuing the boot +command can be overwritten, such as ${nfsroot} or ${mmcargs}. Changing other +variables in that file will not have an effect. See the usage during netboot as +an example.

+

If the external environment can not be loaded the boot process will be anyway +continued with the values of the existing environment settings.

+
+
+

6.2.4. Change U-boot Environment from Linux on Target

+

Libubootenv is a tool included in our images to modify the U-Boot environment of +Linux on the target machine.

+

Print the U-Boot environment using the following command:

+
target:~$ fw_printenv
+
+
+

Modify a U-Boot environment variable using the following command:

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

Caution

+

Libubootenv takes the environment selected in a configuration file. The +environment to use is inserted there, and by default it is configured to use +the eMMC environment (known as the default used environment).

+

If the eMMC is not flashed or the eMMC environment is deleted, libubootenv +will not work. You should modify the /etc/fw_env.config file to match the +environment source that you want to use.

+
+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 8M Mini BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 8M Mini BSP Device Tree Concept to get an understanding +of our i.MX 8 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 8 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 8M Mini Pin Muxing

+

The i.MX 8M Mini SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 8M Mini terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 8M Mini Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx8mm-phyboard-polis-rdk.dts:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX     0x00
+                MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX      0x00
+                MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B  0x00
+                MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B  0x00
+        >;
+};
+
+
+

The first part of the string MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad (in this example +SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the desired muxing option for this pad. +The pad setting value (hex value on the right) defines different modes of the pad, for example, if +internal pull resistors are activated or not. In this case, the internal resistors are disabled.

+
+
+

7.2. RS232/RS485

+

The i.MX 8M Mini SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +bootmode switch (S1) needs to be set correctly:

+ + + + + + + +
Switch between UART1 RS485/RS232
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+

7.2.1. RS232

+
    +

  • Display the current settings of a terminal in a human-readable format:

    +
    target:~$ stty -a
+
    +
    +
    • +

  • Configuration of the UART interface can be done with stty. For example:

    +
    target:~$ stty -F /dev/ttymxc0 115200 crtscts raw -echo
+
    +
    +
    • +

  • With a simple echo and cat, basic communication can be tested. Example:

    +
    target:~$ echo 123 > /dev/ttymxc0
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

The host should print out “123”.

+
+
+

7.2.2. RS485

+
+

Hint

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

For easy testing, look at the linux-serial-test. This tool is called the IOCTL +for RS485 and sends a constant stream of data.

+
target:~$ linux-serial-test -p /dev/ttymxc0 -b 115200 --rs485 0
+
+
+

More information about the linux-serial-test tool and its parameters can be +found here: linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Documentation for calling the IOCTL within c-code is described in the Linux +kernel documentation: +https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see “test” printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final “count for this session”. There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+

The device tree representation for RS232 and RS485: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n291

+
+
+
+
+

7.3. Network

+

phyBOARD-Polis-i.MX 8M Mini provides one Gigabit Ethernet interface.

+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n59.

+

+
+

7.3.1. Network Environment Customization

+
+

7.3.1.1. U-boot network-environment

+
    +

  • To find the Ethernet settings in the target bootloader:

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • With your development host set to IP 192.168.3.10 and netmask 255.255.255.0, +the target should return:

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • If you need to make any changes:

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> should be one of ipaddr, netmask, gatewayip or serverip. +<value> will be the actual value of the chosen parameter.

    +
    • +

  • The changes you made are temporary for now. To save these:

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

Here you can also change the IP address to DHCP instead of using a static one.

+
    +

  • Configure:

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • Set up paths for TFTP and NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+

Tip

+

Variables like nfsroot and netargs can be overwritten by the U-boot External +Environment. For netboot, the external environment will be loaded from tftp. +For example, to locally set the nfsroot variable in a bootenv.txt file, +locate the tftproot directory:

+
nfsroot=/home/user/nfssrc
+
+
+

There is no need to store the info on the target. Please note that this does +not work for variables like ipaddr or serveraddr as they need to be already +set when the external environment is being loaded.

+
+
+
+

7.3.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. WLAN

+

For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. Connecting to a WLAN Network

+

First set the correct regulatory domain for your country:

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

You will see:

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

Set up the wireless interface:

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

Now you can scan for available networks:

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection.

+

To do so, add the network-credentials to the file /etc/wpa_supplicant.conf:

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

Now a connection can be established:

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

This should result in the following output:

+
Successfully initialized wpa_supplicant
+
+
+

The ip address is automatically configured over DHCP. For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (scarthgap).

+
+
+
+

7.3.3. Bluetooth

+

Bluetooth is connected to UART2 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup.

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. Visibility

+

To activate visibility:

+
target:~$ hciconfig hci0 piscan
+
+
+

To disable visibility:

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. Connect

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

Note

+

If the connection fails with the error message: “Failed to connect: +org.bluez.Error.Failed” try restarting PulseAudio with:

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC Card

+

The i.MX 8M Mini supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n383

+

DT configuration for the eMMC interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n335

+
+
+

7.5. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 8M Mini is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw Multi-Level Cells (MLC) or Triple-Level +Cells (TLC) combined with a memory controller that handles ECC and wear +leveling. They are connected via an SD/MMC interface to the i.MX 8M Mini and are +represented as block devices in the Linux kernel like SD cards, flash drives, or +hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.5.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +or TLC. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background Operations +(BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • Enabling can be done with this command:

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.5.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 8M Mini SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.5.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
+
+

7.5.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC or TLC +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC used in NAND Flash, MLC or TLC have lower reliability and a higher +error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC or TLC +or mark these blocks as discard. The data on the device is lost and +will be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.5.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 8M Mini uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.5.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

The following table is for the offset of the i.MX 8M Mini SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 8M Mini

33 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.6. SPI Master

+

The i.MX 8M Mini controller has a FlexSPI and an ECSPI IP core included. The FlexSPI +host controller supports two SPI channels with up to 4 devices. Each channel +supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data +lines). The ECSPI controller supports 3 SPI interfaces with one dedicated chip +selected for each interface. As chip selects should be realized with GPIOs, more +than one device on each channel is possible.

+
+

7.6.1. SPI NOR Flash

+

phyCORE-i.MX 8M Mini is equipped with a QSPI NOR Flash which connects to the i.MX 8M Mini’s +FlexSPI interface. The QSPI NOR Flash is suitable for booting. Please see +different sections for flashing and bootmode setup. Due to limited space on the +SPI NOR Flash, only the bootloader is stored inside. By default, the kernel, +device tree, and rootfs are taken from eMMC.

+

The Bootloader does detect with the help of the EEPROM Introspection data if an +SPI flash is mounted or not. If no SPI flash is mounted a device tree overlay is +applied with the expansion command to disable the SPI flash device tree node +during boot. If no introspection data is available the SPI NOR flash node is +always enabled. Find more information in the device tree overlay section.

+

The bootloader also passes the SPI MTD partition table to Linux by fixing up the +device tree based on the mtdparts boot parameter. The default partition layout +in the BSP is set to:

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

This is a bootloader environment variable that is defined here and can be +changed during runtime. From Linux userspace, the NOR Flash partitions are +accessible via /dev/mtd<N> devices where <N> is the MTD device number associated +with the NOR flash partition to access. To find the correct MTD device number +for a partition, run on the target:

+
root@phyboard-polis-imx8mm-5:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

It lists all MTD devices and the corresponding partition names. The flash node +is defined inside of the SPI master node in the module DTS. The SPI node +contains all devices connected to this SPI bus which is in this case only the +SPI NOR Flash.

+

The definition of the SPI master node in the device tree can be found here:

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n87

+
+
+
+

7.7. GPIOs

+

The phyBOARD-Polis has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to i.MX 8M Mini pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal i.MX 8M Mini GPIO banks GPIO1 – GPIO5.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO5_07). <X> identifies the GPIO +bank and counts from 1 to 5, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo -c gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 20 from chip0):

    +
    target:~$ gpioget -c gpiochip0 20
+
    +
    +
    • +

  • Set the value of GPIO 20 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset -z -c gpiochip0 20=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <line=value>...
+
+Set values of GPIO lines.
+
+Lines are specified by name, or optionally by offset if the chip option
+is provided.
+Values may be '1' or '0', or equivalently 'active'/'inactive' or 'on'/'off'.
+
+The line output state is maintained until the process exits, but after that
+is not guaranteed.
+
+Options:
+      --banner            display a banner on successful startup
+  -b, --bias <bias>       specify the line bias
+                  Possible values: 'pull-down', 'pull-up', 'disabled'.
+                  (default is to leave bias unchanged)
+      --by-name           treat lines as names even if they would parse as an offset
+  -c, --chip <chip>       restrict scope to a particular chip
+  -C, --consumer <name>   consumer name applied to requested lines (default is 'gpioset')
+  -d, --drive <drive>     specify the line drive mode
+                  Possible values: 'push-pull', 'open-drain', 'open-source'.
+                  (default is 'push-pull')
+  -h, --help              display this help and exit
+  -l, --active-low        treat the line as active low
+  -p, --hold-period <period>
+                  the minimum time period to hold lines at the requested values
+  -s, --strict            abort if requested line names are not unique
+  -t, --toggle <period>[,period]...
+                  toggle the line(s) after the specified period(s)
+                  If the last period is non-zero then the sequence repeats.
+      --unquoted  don't quote line names
+  -v, --version           output version information and exit
+  -z, --daemonize set values then detach from the controlling terminal
+
+Chips:
+    A GPIO chip may be identified by number, name, or path.
+    e.g. '0', 'gpiochip0', and '/dev/gpiochip0' all refer to the same chip.
+
+Periods:
+    Periods are taken as milliseconds unless units are specified. e.g. 10us.
+    Supported units are 's', 'ms', and 'us'.
+
+*Note*
+    The state of a GPIO line controlled over the character device reverts to default
+    when the last process referencing the file descriptor representing the device file exits.
+    This means that it's wrong to run gpioset, have it exit and expect the line to continue
+    being driven high or low. It may happen if given pin is floating but it must be interpreted
+    as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.7.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the defconfig you use in +arch/arm64/configs/ in the linux kernel sources. For our NXP based releases, +this could be for example imx8_phytec_distro.config:

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+

Pinmuxing of some GPIO pins in the device tree imx8mm-phyboard-polis-rdk.dts:

+
pinctrl_leds: leds1grp {
+        fsl,pins = <
+                MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1       0x16
+                MX8MM_IOMUXC_GPIO1_IO14_GPIO1_IO14      0x16
+                MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x16
+        >;
+};
+
+
+
+
+
+

7.8. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the phyBOARD-Polis.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n36

+
+
+

7.9. I²C Bus

+

The i.MX 8M Mini contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 8M Mini. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our phyBOARD-Polis.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C1 bus configuration (e.g. imx8mm-phycore-som.dtsi): +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n119

+

General I²C4 bus configuration (e.g. imx8mm-phyboard-polis-rdk.dts): +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n244

+
+
+

7.10. EEPROM

+

On the phyCORE-i.MX8MM there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues.

+
+

Note

+

If you deleted reserved EEPROM spaces, please contact our support!

+
+
+

7.10.1. I2C EEPROM on phyCORE-i.MX8MM

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

The I2C EEPROM on the phyCORE-i.MX8MM SoM is connected to I2C address 0x51 on the I2C-0 +bus. It is possible to read and write directly to the device populated:

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the 4KiB EEPROM (bus: I2C-0 addr: 0x51) with zeros leaving out the EEPROM data use:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM Detection

+

The I2C EEPROM, populated on the phyCORE-i.MX8MM, has a separate ID page that is +addressable over I2C address 0x59 on bus 0 and a normal area that is addressable +over I2C address 0x51 on bus 0. PHYTEC uses this data area of 32 Bytes to store +information about the SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the EEPROM ID page data and the first 256 bytes of the normal area are +deleted, the bootloader will fall back to the phyCORE-i.MX8MM Kit RAM setup, which +is 2GiB RAM.

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

SoMs that are flashed with data format API revision 2 will print out information +about the module in the early stage.

+

DT representation, e.g. in phyCORE-i.MX 8M Mini file imx8mm-phycore-som.dtsi can be +found in our PHYTEC git: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n311

+
+
+
+

7.11. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC Wakealarm

+

It is possible to issue an interrupt from the RTC to wake up the system. The +format uses the Unix epoch time, which is the number of seconds since UTC +midnight on 1 January 1970. To wake up the system after 4 minutes from suspend +to ram state, type:

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

Note

+

Internally the wake alarm time will be rounded up to the next minute since +the alarm function doesn’t support seconds.

+
+
+
+

7.11.2. RTC Parameters

+

RTCs have a few abilities which can be read/set with the help of hwclock +tool.

+
    +

  • We can check RTC supported features with:

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    What this value means is encoded in kernel, each set bit translates to:

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • We can check RTC BSM (Backup Switchover Mode) with:

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • We can set RTC BSM with:

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    What BSM values mean translates to these values:

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    Tip

    +

    You should set BSM mode to DSM or LSM for RTC to switch to backup power +source when the initial power source is not available. Check RV-3028 RTC +datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching +Mode) actually mean.

    +
    +
    • +
+

DT representation for I²C RTCs: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n319

+
+
+
+

7.12. USB Host Controller

+

The USB controller of the i.MX 8M Mini SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +‘HS’). The USB subsystem has two independent USB controller cores. Both cores +are On-The-Go (OTG) controller cores and are capable of acting as a USB +peripheral device or a USB host. Each is connected to a USB 2.0 PHY.

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+

User USB2 (host) configuration is in the kernel device tree +imx8mm-phyboard-polis-rdk.dts:

+
&usbotg2 {
+        dr_mode = "host";
+        picophy,pre-emp-curr-control = <3>;
+        picophy,dc-vol-level-adjust = <7>;
+        status = "okay";
+};
+
+
+

DT representation for USB Host: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n347

+
+
+

7.13. USB OTG

+

Most PHYTEC boards provide a USB OTG interface. USB OTG ports automatically act +as a USB device or USB host. The mode depends on the USB hardware attached to +the USB OTG port. If, for example, a USB mass storage device is attached to the +USB OTG port, the device will show up as /dev/sda.

+
+

7.13.1. USB Device

+

In order to connect the board’s USB device to a USB host port (for example a +PC), you need to configure the appropriate USB gadget. With USB configfs you can +define the parameters and functions of the USB gadget. The BSP includes +USB configfs support as a kernel module.

+
target:~$ modprobe libcomposite
+
+
+

Example:

+
    +

  • First, define the parameters such as the USB vendor and product IDs, and set +the information strings for the English (0x409) language:

    • +
+
+

Hint

+

To save time, copy these commands and execute them in a script

+
+
cd /sys/kernel/config/usb_gadget/
+mkdir g1
+cd g1/
+echo "0x1d6b" > idVendor
+echo "0x0104" > idProduct
+mkdir strings/0x409
+echo "0123456789" > strings/0x409/serialnumber
+echo "Foo Inc." > strings/0x409/manufacturer
+echo "Bar Gadget" > strings/0x409/product
+
+
+
    +

  • Next, create a file for the mass storage gadget:

    • +
+
target:~$ dd if=/dev/zero of=/tmp/file.img bs=1M count=64
+
+
+
    +

  • Now you should create the functions you want to use:

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir functions/acm.GS0
+mkdir functions/ecm.usb0
+mkdir functions/mass_storage.0
+echo /tmp/file.img > functions/mass_storage.0/lun.0/file
+
+
+
    +

  • acm: Serial gadget, creates serial interface like /dev/ttyGS0.

    • +

  • ecm: Ethernet gadget, creates ethernet interface, e.g. usb0

    • +

  • mass_storage: The host can partition, format, and mount the gadget mass +storage the same way as any other USB mass storage.

    • +
+
    +

  • Bind the defined functions to a configuration:

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir configs/c.1
+mkdir configs/c.1/strings/0x409
+echo "CDC ACM+ECM+MS" > configs/c.1/strings/0x409/configuration
+ln -s functions/acm.GS0 configs/c.1/
+ln -s functions/ecm.usb0 configs/c.1/
+ln -s functions/mass_storage.0 configs/c.1/
+
+
+
    +

  • Finally, start the USB gadget with the following commands:

    • +
+
target:~$ cd /sys/kernel/config/usb_gadget/g1
+target:~$ ls /sys/class/udc/
+ci_hdrc.0
+target:~$ echo "ci_hdrc.0" >UDC
+
+
+

If your system has more than one USB Device or OTG port, you can pass the right +one to the USB Device Controller (UDC).

+
    +

  • To stop the USB gadget and unbind the used functions, execute:

    • +
+
target:~$ echo "" > /sys/kernel/config/usb_gadget/g1/UDC
+
+
+

Both USB interfaces are configured as host in the kernel device tree +imx8mm-phyboard-polis-rdk.dts. See: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n335

+
+
+
+

7.14. CAN FD

+

The phyBOARD-Polis has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
+

Hint

+

phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. +There are different interfaces involved, which limits the datarate +capabilities of CANFD.

+
+
+

Hint

+

On phyBOARD-Polis-i.MX8MM a terminating resistor can be enabled by setting +S5 to ON if required.

+
+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The two CAN interfaces should show up as +can0 and can1.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    The information for can0 will look like:

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+
+

Warning

+

The mcp2518fd SPI to CANfd supports only baudrates starting from 125kB/s. +Slower rates can be selected but may not work correctly.

+
+

Device Tree CAN configuration of imx8mm-phyboard-polis-rdk.dts: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n175

+
+
+

7.15. PCIe

+

The phyCORE-i.MX 8M Mini has one Mini-PCIe slot. In general, PCIe autodetects new +devices on the bus. After connecting the device and booting up the system, you +can use the command lspci to see all PCIe devices recognized.

+
    +

  • Type:

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • You will receive:

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

In this example, the PCIe device is the Intel Corporation WiFi Link 5100.

+

For PCIe devices, you have to enable the correct driver in the kernel +configuration. This WLAN card, for example, is manufactured by Intel. The +option for the driver, which must be enabled, is named CONFIG_IWLWIFI and can be +found under Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimat in +the kernel configuration.

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • The linux-imx is represented by: virtual/kernel

      • +
    +
    • +
+

For some devices like the WLAN card, additional binary firmware blobs are +needed. These firmware blobs have to be placed in /lib/firmware/ before the +device can be used.

+
    +

  • Type:

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • For example, if you try to bring up the network interface:

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • You will get the following output on the serial console:

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

Tip

+

Some PCIe devices, e.g. the Ethernet card, may function properly even if no +firmware blob is loaded from /lib/firmware/ and you received an error message +as shown in the first line of the output above. This is because some +manufacturers provide the firmware as a fallback on the card itself. In this +case, the behavior and output depend strongly on the manufacturer’s firmware.

+
+

Device Tree PCIe configuration of imx8mm-phyboard-polis-rdk.dts: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n257

+
+
+

7.16. Audio

+

The PEB-AV-10-Connector exists in two versions and the 1531.1 version is +populated with a TI TLV320AIC3007 audio codec. Audio support is done via the I2S +interface and controlled via I2C.

+

There is a 3.5mm headset jack with OMTP standard and an 8-pin header to connect +audio devices with the AV-Connector. The 8-pin header contains a mono speaker, +headphones, and line-in signals.

+

To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices:

+
target:~$ aplay -L
+
+
+

Or type for recording devices:

+
target:~$ arecord -L
+
+
+
+

7.16.1. Alsamixer

+

To inspect the capabilities of your soundcard, call:

+
target:~$ alsamixer
+
+
+

You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. “MM” means the feature is muted +(both output, left & right), which can be toggled by hitting ‘m’. You can also +toggle by hitting ‘<’ for left and ‘>’ for right output. With the tab +key, you can switch between controls for playback and recording.

+
+
+

7.16.2. Restore default volumes

+

There are some default settings stored in /var/lib/alsa/asound.state. +You can save your current alsa settings with:

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

You can restore saved alsa settings with:

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.16.3. ALSA configuration

+

Our BSP comes with a ALSA configuration file /etc/asound.conf.

+

The ALSA configuration file can be edited as desired or deleted since it is not +required for ALSA to work properly.

+
target:~$ vi /etc/asound.conf
+
+
+

To set PEB-AV-10 as output, set playback.pcm from “dummy” to “pebav10”:

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

If the sound is not audible change playback devices to the software volume control +playback devices, set playback.pcm to the respective softvol playback device e.g. +“softvol_pebav10”. Use alsamixer controls to vary the volume levels.

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.16.4. Pulseaudio Configuration

+

For applications using Pulseaudio, check for available sinks:

+
target:~$ pactl list short sinks
+
+
+

To select the output device, type:

+
target:~$ pactl set-default-sink <sink_number>
+
+
+
+
+

7.16.5. Playback

+

Run speaker-test to check playback availability:

+
target:~$ speaker-test -c 2 -t wav
+
+
+

To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds:

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

To playback other formats like mp3 for example, you can use Gstreamer:

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.16.6. Capture

+

arecord is a command-line tool for capturing audio streams which use Line In as +the default input source. To select a different audio source you can +use alsamixer. For example, switch on Right PGA Mixer Mic3R and Left PGA Mixer +Mic3R in order to capture the audio from the microphone input of the +TLV320-Codec using the 3.5mm jack.

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

Hint

+

Since playback and capture share hardware interfaces, it is not possible to +use different sampling rates and formats for simultaneous playback and +capture operations.

+
+

Device Tree Audio configuration: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mm-phyboard-polis-peb-av-010.dtsi?h=v5.15.71_2.2.2-phy3#n54

+
+
+
+

7.17. Video

+
+

7.17.1. Videos with Gstreamer

+

One example video is installed by default in the BSP at /usr/share/qtphy/videos/. +Start the video playback with one of these commands:

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.18. Display

+

The 10” Display is always active. If the PEB-AV-Connector is not connected, an +error message may occur at boot.

+
+

7.18.1. Qt Demo

+

With the phytec-qt6demo-image, Weston starts during boot. Our Qt6 demo application named +“qtphy” can be stopped with:

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • To start the demo again, run:

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • To disable autostart of the demo, run:

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • To enable autostart of the demo, run:

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston can be stopped with:

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

Note

+

The Qt demo must be closed before Weston can be closed.

+
+
+
+

7.18.2. Backlight Control

+

If a display is connected to the PHYTEC board, you can control its backlight +with the Linux kernel sysfs interface. All available backlight devices in the +system can be found in the folder /sys/class/backlight. Reading the appropriate +files and writing to them allows you to control the backlight.

+
+

Note

+

Some boards with multiple display connectors might have multiple backlight +controls in /sys/class/backlight. For example: backlight0 and backlight1

+
+
    +

  • To get, for example, the maximum brightness level (max_brightness) execute:

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    Valid brightness values are 0 to <max_brightness>.

    +
    • +

  • To obtain the current brightness level, type:

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • Write to the file brightness to change the brightness:

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    turns the backlight off for example.

    +

    For documentation of all files, see +https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight.

    +
    • +
+

The device tree of PEB-AV-10 can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mm-phyboard-polis-peb-av-010.dtsi?h=v5.15.71_2.2.2-phy3

+
+
+
+

7.19. Power Management

+
+

7.19.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 8M Mini SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as ‘Dynamic Voltage and +Frequency Scaling’ (DVFS). The i.MX 8M Mini BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the i.MX 8 +variant used, several different frequencies are supported.

+
+

Tip

+

Although the DVFS framework provides frequency settings for each CPU core, a +change in the frequency settings of one CPU core always affects all other CPU +cores too. So all CPU cores always share the same DVFS setting. An individual +DVFS setting for each core is not possible.

+
+
    +

  • To get a complete list type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately +1,6 GHz, the result will be:

    +
    1200000 1600000
+
    +
    +
    • +

  • To ask for the current frequency type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

So-called governors are automatically selecting one of these frequencies in +accordance with their goals.

+
    +

  • List all governors available with the following command:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    The result will be:

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative is much like the ondemand governor. It differs in behavior in +that it gracefully increases and decreases the CPU speed rather than jumping +to max speed the moment there is any load on the CPU.

    • +

  • ondemand (default) switches between possible CPU core frequencies in +reference to the current system load. When the system load increases above a +specific limit, it increases the CPU core frequency immediately.

    • +

  • powersave always selects the lowest possible CPU core frequency.

    • +

  • performance always selects the highest possible CPU core frequency.

    • +

  • userspace allows the user or userspace program running as root to set a +specific frequency (e.g. to 1600000). Type:

    • +

  • In order to ask for the current governor, type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    You will normally get:

    +
    ondemand
+
    +
    +
    • +

  • Switching over to another governor (e.g. userspace) is done with:

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • Now you can set the speed:

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +Documentation/admin-guide/pm/cpufreq.rst.

+
+
+

7.19.2. CPU Core Management

+

The i.MX 8M Mini SoC can have multiple processor cores on the die. The i.MX 8M Mini, for +example, has 4 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    Here the system has four processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.19.3. Suspend to RAM

+

The phyCORE-i.MX8MM supports basic suspend and resume. Different wake-up sources can be +used. Suspend/resume is possible with:

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

To wake up with serial console run

+
target:~$ echo enabled > /sys/class/tty/ttymxc2/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.20. Thermal Management

+
+

7.20.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.20.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 8M Mini SoC platform. The i.MX 8 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Industrial +and Commercial.

+ + + + + + + + + + + + + + + + + +

Commercial

Industrial

passive (warning)

85°C

95°C

critical (shutdown)

90°C

100°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise, Fair Share, Bang Bang, and +Userspace. The default policy used in the BSP is step_wise. If the value of the +SoC temperature in the sysfs file temp is above trip_point_0, the CPU frequency +is set to the lowest CPU frequency. When the SoC temperature drops below +trip_point_0 again, the throttling is released.

+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+

7.20.3. GPIO Fan

+
+

Note

+

Only GPIO fan supported.

+
+

A GPIO fan can be connected to the phyBOARD-Polis-i.MX 8M Mini. The SoC only contains one +temperature sensor which is already used by the thermal frequency scaling. The +fan can not be controlled by the kernel. We use lmsensors with hwmon for this +instead. lmsensors reads the temperature periodically and enables or disables +the fan at a configurable threshold. For the phyBOARD-Polis-i.MX 8M Mini, this is 60°C.

+

The settings can be configured in the configuration file:

+
/etc/fancontrol
+
+
+

Fan control is started by a systemd service during boot. This can be disabled +with:

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.21. Watchdog

+

The PHYTEC i.MX 8M Mini modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.21.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.22. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 8M Mini provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 8M Mini Reference Manual). The following list is +an abstract from the i.MX 8M Mini Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x30350000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x30350000

Description

OCOTP_MAC_ADDR0

9

0

0x640

contains lower 32 bits +of ENET0 MAC address

OCOTP_MAC_ADDR1

9

1

0x650

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

OCOTP_MAC_ADDR2

9

2

0x660

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 8M Mini Security Reference Manual.

+
+

7.22.1. Reading Fuse Values in uBoot

+

You can read the content of a fuse using memory-mapped shadow registers. To +calculate the memory address, use the fuse Bank and Word in the following +formula:

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.22.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+
+

8. i.MX 8M Mini M4 Core

+

In addition to the Cortex-A53 cores, there is a Cortex-M4 Core as MCU +integrated into the i.MX 8M Mini SoC. Our Yocto-Linux-BSP runs on the A53-Cores and +the M4 Core can be used as a secondary core for additional tasks using +bare-metal or RTOS firmware. +Both cores have access to the same peripherals and thus peripheral +usage needs to be limited either in the M4 Core’s firmware or the devicetree +for the Linux operating system. This section describes how to build firmware +examples and how to run them on phyBOARD-Polis.

+

The phyBOARD-Polis is currently supported by the NXP MCUXpresso SDK and by +The Zephyr Project. This section only describes the NXP MCUXpresso SDK because +the MCUXpresso SDK has more supported features at the moment.

+

If you want to use the M4 Core with The Zephyr Project, please refer to the +The Zephyr Project documentation:

+ +
+

8.1. Getting the Firmware Examples

+

The firmware can be built using the NXP MCUxpresso SDK with a compatible +compiler toolchain using command-line tools.

+
+

8.1.1. Getting the Sources

+

The MCUX SDK and the examples for the i.MX 8M Mini can be obtained from PHYTEC’s GitHub +page:

+ +
    +

  1. Initialize the MCUX SDK via west:

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    This will create a mcuxsdk directory with the mcux-sdk repository in it. +The mcux-sdk-phytec-examples repository will be automatically cloned into +the mcuxsdk directory. +The given argument <VERSION> is a the branch name of the mcux-sdk repository +that represents the MCUX SDK version. For the newest tested version +you can use 2.13.0.

    +
    +

    Note

    +

    west is a repository management tool and a part of the Zephyr +Project. +To install west, you can use pip. In this example west is installed in +a python virtual environment:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. Update the dependencies:

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    The directory examples-phytec contains all examples ported and tested +for phyBOARD-Polis with version 2.13.0 of MCUX.

    +

    To build the firmware, a compiler toolchain and make/cmake are required. +The GNU Arm Embedded Toolchain may be available in your distribution’s +repositories, e.g. for Ubuntu.

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    The compiler toolchain can also be obtained directly from +https://developer.arm.com/. After the archive has been extracted, +the ARMGCC_DIR has to be added to the environment, e.g. for the +ARM toolchain 10-2020-q4-major release located in the home directory:

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. Building the Firmware

+

To build the PHYTEC samples an environment has to be sourced

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

The scripts to build the firmware are located in +<sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc. +There are scripts for each memory location the firmware is supposed to run in, +e.g.

+
host:~$ ./build_release.sh
+
+
+

to build the firmware for the M4 Core’s TCM. The output will be placed under +release/ in the armgcc directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+

To build the firmware for the DRAM, run the script build_ddr_release. +The script of the firmware that is supposed to run, e.g.

+
host:~$ ./build_ddr_release.sh
+
+
+

The output will be placed under ddr_release/ in the armgcc +directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+
+
+
+

8.2. Running M4 Core Examples

+

There are two ways to run the M4 Core with the built firmware, U-Boot and +Remoteproc within a running Linux.

+

To receive debug messages start your favorite terminal software (e.g. Minicom, +Tio, or Tera Term) on your host PC and configure it for 115200 baud, 8 data +bits, no parity, and 1 stop bit (8n1) with no handshake.

+

Once a micro-USB cable is connected to the USB-debug port on the phyBOARD-Polis, two +ttyUSB devices are registered. One prints messages from A53-Core’s debug UART +and the other one from the M4 Core’s debug UART.

+
+

8.2.1. Running Examples from U-Boot

+

To load firmware using the bootloader U-Boot, the bootaux command can be used:

+
    +

  1. Prepare an SD Card with our Yocto-BSP

    2. +

  2. Copy the generated .bin file to the SD Cards first partition

    3. +

  3. Stop the autoboot by pressing any key

    4. +

  4. Type the command depending on the type of firmware:

    5. +
+

For firmware built to run in the M4 Core’s TCM:

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

For firmware built to run in the DRAM:

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

The program’s output should appear on the M4 Core’s debug UART.

+
+
+

8.2.2. Running Examples from Linux using Remoteproc

+

Remoteproc is a module that allows you to control the M4 Core from Linux +during runtime. Firmware built for TCM can be loaded and the execution started +or stopped. To use Remoteproc a devicetree overlay needs to be set:

+

Edit the bootenv.txt file located in the /boot directory on the target by +adding imx8mm-phycore-rpmsg.dtbo:

+
overlays=imx8mm-phycore-rpmsg.dtbo
+
+
+

Restart the target and execute in U-Boot:

+
u-boot=> run prepare_mcore
+
+
+

Firmware .elf files for the M4 Core can be found under /lib/firmware. +To load the firmware, type:

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

To load a different firmware, the M4 Core needs to be stopped:

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

Note

+

The samples found in /lib/firmware on the target come from NXP’s +Yocto layer meta-imx. +To use the samples you built yourself through MCUX SDK, please copy them +to /lib/firmware on the target after building them.

+
+
+ +
+
+
+

9. BSP Extensions

+
+

9.1. Chromium

+

Our BSP for the phyBOARD-Polis-i.MX 8M Mini supports Chromium. You can include it in the +phytec-qt6demo-image with only a few steps.

+
+

9.1.1. Adding Chromium to Your local.conf

+

To include Chromium you have to add the following line into your local.conf. You +can find it in <yocto_dir>/build/conf/local.conf. This adds Chromium to your +next image build.

+
IMAGE_INSTALL:append = " chromium-ozone-wayland"
+
+
+
+

Note

+

Compiling Chromium takes a long time.

+
+
+
+

9.1.2. Get Chromium Running on the Target

+

To run Chromium, it needs a few arguments to use the hardware graphics +acceleration:

+
target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox
+
+
+

If you want to start Chromium via SSH, you must first define the display on +which Chromium will run. For example:

+
target$ DISPLAY=:0
+
+
+

After you have defined this, you can start it via virtual terminal on Weston as +shown above.

+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mm/imx8mm.html b/previews/271/bsp/imx8/imx8mm/imx8mm.html new file mode 100644 index 000000000..4f2f8ac45 --- /dev/null +++ b/previews/271/bsp/imx8/imx8mm/imx8mm.html @@ -0,0 +1,431 @@ + + + + + + + + + i.MX 8M Mini Manuals — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

i.MX 8M Mini Manuals

+ +
+

BSP-Yocto-NXP-i.MX8MM-PD23.1.0

+
+

Table of Contents

+ +
+
+
+

BSP-Yocto-NXP-i.MX8MM-PD22.1.1

+
+

Table of Contents

+ +
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mm/pd22.1.1.html b/previews/271/bsp/imx8/imx8mm/pd22.1.1.html new file mode 100644 index 000000000..619835253 --- /dev/null +++ b/previews/271/bsp/imx8/imx8mm/pd22.1.1.html @@ -0,0 +1,4515 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 8M Mini BSP Manual

Document Title

i.MX 8M Mini BSP Manual

Document Type

BSP Manual

Yocto Manual

Release Date

2023/05/25

Is Branch of

i.MX 8M Mini BSP Manual

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-NXP-i.MX8MM-PD22.1.1

Minor

2023/05/23

Released

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +phyCORE-i.MX8M Mini Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads of our product.

+
+

1.1. Supported Hardware

+

The phyBOARD-Polis populated with either the i.MX 8M Mini SoC or i.MX 8M Nano SoC, is +supported.

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-NXP-i.MX8MM-PD22.1.1 download. +If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware

+
+

1.1.1. phyBOARD-Polis Components

+ + + + + + +
+../../../_images/polis-front.jpg +
+

phyBOARD-Polis Components (top)

+
+
+
+../../../_images/polis-back.jpg + +
+

phyBOARD-Polis Components (bottom)

+
+
+
+
+
+
+
+

2. Getting Started

+

The phyCORE-i.MX8M Mini Kit is shipped with a pre-flashed SD card. It contains the +phytec-qt5demo-image and can be used directly as a boot source. The eMMC is +programmed with only a U-boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+
+

2.1. Get the Image

+

The WIC image contains all BSP files in several, correctly pre-formatted +partitions and can be copied to an SD card easily using the single Linux +command dd. It can be built by Yocto or downloaded from the PHYTEC download +server.

+

Get the WIC file from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic
+
+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card with the dd command, you must have root +privileges. Be very careful when specifying the destination device with +dd! All files on the selected destination device will be erased +immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system!

+
+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. Unmount any mounted partitions before +you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+
    +

  • Unmount all partitions, e.g.:

    +
    host$ sudo umount /dev/sde1
+
    +
    +
    • +

  • After having unmounted all partitions, you can create your bootable SD card:

    +
    host$ sudo dd if=<IMAGENAME>-<MACHINE>.wic of=/dev/sdX bs=1M conv=fsync status=progress
+
    +
    +

    Again, make sure to replace /dev/sdX with your actual device name found +previously.

    +

    The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

    +
    • +
+

An alternative and much faster way to prepare an SD card can be done by using +bmap-tools from Intel. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host$ bmaptool copy <IMAGENAME>-<MACHINE>.wic /dev/<your_device>
+
+
+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.3. First Start-up

+ + + + + + + +
Bootmode Selection
+../../../_images/SD_Card_Boot.jpg +
+

Mini

+
+
+
+
    +

  • Insert the SD card

    • +

  • Connect the target and the host with mirco USB on (X30) +debug USB

    • +

  • Power up the board

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 8M Mini BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: L-813e.A13 Yocto Reference Manual (hardknott).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +L-813e.A13 Yocto Reference Manual (hardknott).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-IMX8MM; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-xwayland MACHINE=phyboard-polis-imx8mm-5 ./phyLinux init -p imx8mm -r BSP-Yocto-NXP-i.MX8MM-PD22.1.1
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-qt5demo-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the phyboard-polis-imx8mm-5 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx8mm.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, +lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY firmware images

    • +

  • imx-boot: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM +Trusted Firmware and DDR firmware. This is the final bootloader image which is +bootable.

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx8mm-phyboard-polis-rdk*.dtb: Kernel device tree file

    • +

  • imx8mm-phy*.dtbo: Kernel device tree overlay files

    • +

  • phytec-qt5demo-image*.tar.gz: Root file system

    • +

  • phytec-qt5demo-image*.wic: SD card image

    • +
+
+
+
+
+

4. Installing the OS

+
+

4.1. Bootmode Switch (S1)

+

The phyBOARD-Polis features a boot switch with six individually switchable ports to +select the phyCORE-i.MX 8M Mini default bootsource.

+
+

4.1.1. Mini

+ + + + + + + + + + +
Bootmode Selection
+../../../_images/eMMC.jpg +
+

eMMC (Default SoM boot)

+
+
+
+../../../_images/SPI_NOR.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download1.png +
+

USB Serial Download

+
+
+
+../../../_images/SD_Card_Boot.jpg +
+

SD Card

+
+
+
+ + + + + + + +
Switch between UART1 RS485/RS232
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+
+
+

4.2. Flash eMMC

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S1) is set to Default SOM boot.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk2p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from Network

+

i.MX 8M Mini boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

4.2.1.1. Flash eMMC from Network in u-boot on Target

+

These steps will show how to update the eMMC via a network. However, they only +work if the size of the image file is less than 1GB. If the image file is +larger, go to the section Format SD Card. Configure the bootmode switch (S1) to boot +from SD Card and put in an SD card. Power on the board and stop in U-Boot +prompt.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+
    +

  • Load your image via network to RAM:

    +
    u-boot=> tftp ${loadaddr} phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • Write the image to the eMMC:

    +
    u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +
+
+
+

4.2.1.2. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host.

+
+

Take a compressed or uncompressed image on the host and send it with ssh through +the network (then uncompress it, if necessary) to the eMMC of the target with a +one-line command:

+
target:~$ ssh <USER>@192.168.3.10 "dd if=<path_to_file>/phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic" | dd of=/dev/mmcblk2
+
+
+
+
+

4.2.1.3. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host.

+
+

Show your available image files on the host:

+
host:~$ ls
+phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic
+
+
+

Send the image with the command dd command combined with ssh through the network +to the eMMC of your device:

+
host:~$ dd if=phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2"
+
+
+
+
+
+

4.2.2. Flash eMMC u-boot image via Network from running u-boot

+

Update the standalone u-boot image imx-boot is also possible from u-boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host.

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x42 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.3. Flash eMMC from USB

+
+

4.2.3.1. Flash eMMC from USB in u-boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in Bootloader after enabling the OPTEE.

+
+

These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch to bootmode switch (S1) and put in an SD card. Power on the board +and stop in u-boot prompt. Insert a USB device with the copied WIC image +to the USB slot.

+

Load your image from the USB device to RAM:

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} *.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic). Set the bootmode switch to +bootmode switch (S1).

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ cd /mnt
+target:~$ ls
+phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic
+
    +
    +
    • +

  • Show list of available MMC devices:

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • The eMMC device can be recognized by the fact that it contains two boot +partitions: (mmcblk2boot0; mmcblk2boot1)

    • +

  • Write the image to the phyCORE-i.MX 8M Mini eMMC (MMC device 2 without partition):

    +
    target:~$ dd if=phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic of=/dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    • +
+
+

Warning

+

Before this will work, you need to configure the multi-port switch +to Default SOM Boot to bootmode switch (S1).

+
+
+
+
+

4.2.4. Flash eMMC from SD Card

+

Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (*.wic) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see Resizing ext4 Root Filesystem.

+
+

4.2.4.1. Flash eMMC from SD card in u-boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in Bootloader after enabling the OPTEE. If the +image file is too large use the Updating eMMC from SD card in +Linux on Target subsection.

+
+
    +

  • Flash an SD card with a working image and create a third FAT partition. Copy +the WIC image (for example phytec-qt5demo-image.wic) to this +partition.

    • +

  • Configure the bootmode switch to boot from the SD Card and insert the SD +card.

    • +

  • Power on the board and stop in u-boot.

    • +

  • Flash your WIC image (for example phytec-qt5demo-image.wic) +from the SD card to eMMC. This will partition the card and copy imx-boot, +Image, dtb, dtbo, and root file system to eMMC.

    • +

  • Load the image:

    +
    u-boot=> fatload mmc 1:3 ${loadaddr} phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • Switch the mmc dev:

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc0(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • Power off the board and change the multi-port switch to Default SOM Boot to +boot from eMMC.

    • +
+
+
+

4.2.4.2. Flash eMMC from SD card in Linux on Target

+

You can also flash the eMMC on Linux. You only need a complete image saved on +the SD card (e.g. phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic).

+
    +

  • Show your saved image files on the SD card:

    +
    target:~$ ls
+phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic
+
    +
    +
    • +

  • Show list of available MMC devices:

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • The eMMC device can be recognized by the fact that it contains two boot +partitions: (mmcblk2boot0; mmcblk2boot1)

    • +

  • Write the image to the phyCORE-i.MX 8M Mini eMMC (MMC device 2 without +partition):

    +
    target:~$ dd if=phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic of=/dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    • +
+
+

Warning

+

Before this will work, you need to configure the bootmode switch (S1) to Default +SOM Boot to boot from eMMC.

+
+
+
+
+
+

4.3. Flash SPI NOR Flash

+

The phyCORE-i.MX8MM modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set bootmode switch (S1) to QSPI boot to boot from QSPI. The SPI Flash is +usually quite small. The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash +populated. Only the bootloader and the environment can be stored. The kernel, +device tree, and file system are taken from eMMC by default.

+

The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with:

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. Flash SPI NOR Flash from Network

+

The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-i.MX 8M Mini.

+
+

Tip

+

A working network is necessary! Setup Network Host.

+
+
+

4.3.1.1. Flash SPI NOR from Network in u-boot on Target

+

Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI-NOR flash needs to be probed:

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • A specially formatted u-boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image over tftp, erase and write the +bootloader to the flash:

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+

Warning

+

Erasing the complete SPI NOR flash when it is fully written will take quite +some time. This can trigger the watchdog to reset. Due to this, erase the +full flash in Linux.

+
+
+
+

4.3.1.2. Flash SPI NOR from Network in kernel on Target

+
    +

  • Copy the image from the host to the target:

    +
    host:~$ scp imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • Find the number of erase blocks of the U-boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the u-boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+

4.3.2. Flash SPI NOR Flash from SD Card

+

The bootloader on SPI NOR flash can be also flashed with SD Card.

+
+

4.3.2.1. Flash SPI NOR from SD Card in u-boot on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi to the FAT partition +on the SD Card. Before reading and writing are possible, the SPI-NOR flash +needs to be probed:

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • A specially formatted U-boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image from the SD Card, erase and write +the bootloader to the flash:

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+

Warning

+

Erasing the complete SPI NOR flash when it is fully written will take quite +some time. This can trigger the watchdog to reset. Due to this, erase the +full flash in Linux.

+
+
+
+

4.3.2.2. Flash SPI NOR from SD Card in kernel on Target

+
    +

  • Mount the SD Card:

    +
    host:~$ mount /dev/mmcblkp1 /mnt
+
    +
    +
    • +

  • Find the number of erase blocks of the u-boot partition:

    +
    target:~$  mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the u-boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A3 RAUC Update & Device Management Manual.

+
+
+
+

5. Development

+
+

5.1. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.1.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.2. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.2.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel image to your tftp directory:

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • Copy the devicetree to your tftp directory:

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • Copy all the overlays you want to use into your tftp directory:

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-qt5demo-image-phyboard-polis-imx8mm-5.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.2.2. Set the bootenv.txt for Netboot

+

Create a bootenv.txt file in your tftp directory and write the following variables into it.

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> has to be replaced with the devicetree overlay filenames that you want to use. +Separate the filenames by spaces. For example:

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

Tip

+

All supported devicetree overlays are in the device tree chapter.

+
+
+
+

5.2.3. Network Settings on Target

+

To customize the targets ethernet configuration, please follow the description +here: Network Environment Customization

+
+
+

5.2.4. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.3.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/phyboard-polis-imx8mm-5/. For flashing a wic image to eMMC, +you will also need phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic.

+
+
+

5.3.3. Prepare Target

+

Set the bootmode switch (S1) to USB Serial Download. Also, connect USB port +X2 to your host.

+
+
+

5.3.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via (X30), as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.3.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic
+
+
+
+
+
+

5.4. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone git://git.phytec.de/u-boot-imx)

+
+
+

5.4.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-imx and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • Our i.MX 8M Mini kernel is based on the linux-imx kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. Get the SDK

+

You can download the SDK here, or build it yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt5demo-image # or another image
+
    +
    +
    • +
+

After a successful build the SDK installer is deployed to build/deploy*/sdk.

+
+
+

5.4.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt5demo-image-cortexa53-crypto-toolchain-BSP-Yocto-NXP-i.MX8MM-PD22.1.1.sh
+host:~$ ./phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt5demo-image-cortexa53-crypto-toolchain-BSP-Yocto-NXP-i.MX8MM-PD22.1.1.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MM-PD22.1.1):
+You are about to install the SDK to "/opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MM-PD22.1.1". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. U-Boot standalone build

+
+

5.5.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag needed at this release is called v2021.04_2.2.0-phy13

    • +

  • Check out the needed U-Boot tag:

    • +
+
host:~$ cd ~/u-boot-imx/
+host:~$ git fetch --all --tags
+host:~$ git checkout tags/v2021.04_2.2.0-phy13
+
+
+
    +

  • Technically, you can now build the U-Boot, but practically there are some +further steps necessary:

    +
      +

    • Create your own development branch:

      +
      host:~$ git switch --create <new-branch>
+
      +
      +
      +

      Note

      +

      You can name your development branch as you like, this is just an example.

      +
      +
      • +
    +
    • +

  • Set up a build environment:

    +
    host:~$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +

  • Set this environment variable before building the Image:

    +
    host:~$ export ATF_LOAD_ADDR=0x920000
+
    +
    +
    • +
+
+
+

5.5.2. Get the needed binaries

+

To build the bootloader, you need to copy these files to your u-boot-imx +build directory and rename them to fit with mkimage script:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx8mm.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +
+

If you already built our BSP with Yocto, you can get the +bl31-imx8mm.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: BSP Images

+

Or you can download the files here: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/imx-boot-tools/

+
+

Warning

+

Make sure you rename the files you need so that they are compatible with the +mkimage tool.

+
+
+
+

5.5.3. Build the bootloader

+
    +

  • build flash.bin (imx-boot):

    +
    host:~$ make phycore-imx8mm_defconfig
+host:~$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. Flash the bootloader to a block device

+

The flash.bin can be found at u-boot-imx/ directory and now can be flashed. A +chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 8M Mini

33 kiB

33 kiB

/dev/mmcblk2

+

E.g. flash SD card:

+
host:~$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=33 conv=sync
+
+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables “BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+

5.5.5. Build U-Boot With a Fixed RAM Size

+

If you cannot boot your system anymore because the hardware introspection in the +EEPROM is damaged or deleted, you can create a flash.bin with a fixed ram size. +You should still contact support and flash the correct EEPROM data, as this +could lead to unexpected behavior.

+

Follow the steps to get the U-boot sources and check the correct branch in the +Build U-Boot section.

+

Edit the file configs/phycore-imx8mm_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MM=y
+CONFIG_PHYCORE_IMX8MM_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_4GB=y
+
+
+

Choose the correct RAM size as populated on the board and uncomment the line for +this ram size. +After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+
+

5.6. Kernel standalone build

+
+

5.6.1. Setup sources

+
    +

  • The used linux-imx branch can be found in the release notes

    • +

  • The tag needed for this release is called v5.10.72_2.2.0-phy17

    • +

  • Check out the needed linux-imx tag:

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v5.10.72_2.2.0-phy17
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-imx$ make imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-imx/arch/arm64/boot/Image

    • +

  • The dtb can be found at +~/linux-imx/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. Copy Kernel to SD Card

+

When one-time boot via netboot is not sufficient, the kernel along with its +modules and the corresponding device tree blob may be copied directly to a +mounted SD card.

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. Accessing the Development states

+
+

5.7.1. Development state of current release

+

These release manifests exist to give you access to the development states +of the Yocto BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line:

+
host:~$ ./phyLinux init -p imx8mm -r BSP-Yocto-NXP-i.MX8MM-PD22.1.y
+
+
+

This will initialize a BSP that will track the latest development state of the +current release (BSP-Yocto-NXP-i.MX8MM-PD22.1.1). From now on repo sync in this folder +will pull all the latest changes from our Git repositories:

+
host:~$ repo sync
+
+
+
+
+

5.7.2. Development state of upcoming release

+

Also development states of upcoming releases can be accessed this way. +For this execute the following command and look for a release with a higher +PDXX.Y number than the latest one (BSP-Yocto-NXP-i.MX8MM-PD22.1.1) and .y at the +end:

+
host:~$ ./phyLinux init -p imx8mm
+
+
+
+
+
+

5.8. Accessing the Latest Upstream Support

+

We have a vanilla manifest that makes use of the Yocto master branches (not an +NXP release), Linux, and U-Boot. This can be used to test the latest upstream +kernel/U-Boot.

+
+

Note

+

The master manifest reflects the latest state of development. This tends to +be broken from time to time. We try to fix the master on a regular basis.

+
+
host:~$ ./phyLinux init -p imx8mm -r BSP-Yocto-Ampliphy-i.MX8MM-master
+
+
+
+
+

5.9. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.9.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 8M Mini BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 8M Mini SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Carrierboard.dtsi - Devices that come from the i.MX 8M Mini SoC but are just routed +down to the carrier board and used there are included in this dtsi.

    • +

  • Board.dts - include the carrier board and module dtsi files. There may also +be some hardware configuration nodes enabled on the carrier board or the +module (i.e. the Board .dts shows the special characteristics of the board +configuration). For example, there are phyCORE-i.MX 8M Mini SOMs which may or may not +have a MIPI DSI to LVDS converter mounted. The converter is enabled (if +available) in the Board .dts and not in the Module .dtsi

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 8 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder arch/arm64/boot/dts/freescale/overlays.

+

Available overlays for phyboard-polis-imx8mm-5.conf are:

+
imx8mm-phyboard-polis-peb-eval-01.dtbo
+imx8mm-phyboard-polis-peb-av-010.dtbo
+imx8mm-phycore-rpmsg.dtbo
+imx8mm-phycore-no-eth.dtbo
+imx8mm-phycore-no-spiflash.dtbo
+imx8mm-vm016.dtbo
+imx8mm-vm016-fpdlink.dtbo
+imx8mm-vm017.dtbo
+imx8mm-vm017-fpdlink.dtbo
+imx8mm-dual-vm017-fpdlink.dtbo
+
+
+

The usage of overlays can be configured during runtime in Linux or U-Boot. +Overlays are applied during the boot process in the bootloader after the +boot command is called and before the kernel is loaded. The next sections +explain the configuration in more detail.

+
+

6.2.2.1. Set ${overlays} variable

+

The ${overlays} U-Boot environment variable contains a space-separated list +of overlays that will be applied during boot. Depending on the boot source the +overlays have to either be placed in the boot partition of eMMC/SD-Card or are +loaded over tftp. Overlays set in the $KERNEL_DEVICETREE Yocto machine variable +will be automatically added to the boot partition of the final WIC image.

+

The ${overlays} variable can be either set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=imx8mm-phyboard-polis-rdk-peb-eval-01.dtbo imx8mm-phyboard-polis-peb-av-010.dtbo
+
+
+

Changes will take effect after the next reboot. If no bootenv.txt file is +available the overlays variable can be set directly in the U-Boot environment.

+
u-boot=> setenv overlays imx8mm-phyboard-polis-peb-av-010.dtbo
+u-boot=> printenv overlays
+overlays=imx8mm-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

If a user defined ${overlays} variable should be directly loaded from U-Boot +environment but there is still an external bootenv.txt available, the ${no_bootenv} +variable needs to be set as a flag:

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx8mm-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

More information about the external environment can be found in +U-boot External Environment subsection of the +device tree overlay section.

+

We use the ${overlays} variable for overlays describing expansion boards and +cameras that can not be detected during run time. To prevent applying overlays +listed in the ${overlays} variable during boot, the ${no_overlays} variable can +be set to 1 in the bootloader environment.

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+

6.2.2.2. Extension Command

+

The U-Boot extension command makes it possible to easily apply overlays that +have been detected and added to a list by the board code callback +extension_board_scan(). +Overlays applied this way disable components that are not populated on the SoM. +The detection is done with the EEPROM data (EEPROM SoM Detection) found on the +SoM i2c EEPROM.

+

It depends on the SoM variant if any device tree overlays will be applied. To check +if an overlay will be applied on the running SoM in U-Boot, run:

+
u-boot=> extension scan
+Found 1 extension board(s).
+u-boot=> extension list
+Extension 0: phyCORE-i.MX8MM no SPI flash
+        Manufacturer:           PHYTEC
+        Version:
+        Devicetree overlay:     imx8mm-phycore-no-spiflash.dtbo
+        Other information:      SPI flash not populated on SoM
+
+
+

If the EEPROM data is not available, no device tree overlays are applied.

+

To prevent running the extension command during boot the ${no_extensions} +variable can be set to 1 in the bootloader environment:

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot External Environment

+

During the start of the Linux Kernel the external environment bootenv.txt +text file will be loaded from the boot partition of an MMC device or via TFTP. +The main intention of this file is to store the ${overlays} variable. This makes +it easy to pre-define the overlays in Yocto depending on the used machine. The +content from the file is defined in the Yocto recipe bootenv found in +meta-phytec: +https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=hardknott

+

Other variables can be set in this file, too. They will overwrite the existing +settings in the environment. But only variables evaluated after issuing the boot +command can be overwritten, such as ${nfsroot} or ${mmcargs}. Changing other +variables in that file will not have an effect. See the usage during netboot as +an example.

+

If the external environment can not be loaded the boot process will be anyway +continued with the values of the existing environment settings.

+
+
+

6.2.4. Change U-boot Environment from Linux on Target

+

Libubootenv is a tool included in our images to modify the U-Boot environment of +Linux on the target machine.

+

Print the U-Boot environment using the following command:

+
target:~$ fw_printenv
+
+
+

Modify a U-Boot environment variable using the following command:

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

Caution

+

Libubootenv takes the environment selected in a configuration file. The +environment to use is inserted there, and by default it is configured to use +the eMMC environment (known as the default used environment).

+

If the eMMC is not flashed or the eMMC environment is deleted, libubootenv +will not work. You should modify the /etc/fw_env.config file to match the +environment source that you want to use.

+
+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 8M Mini BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 8M Mini BSP Device Tree Concept to get an understanding +of our i.MX 8 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 8 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 8M Mini Pin Muxing

+

The i.MX 8M Mini SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 8M Mini terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 8M Mini Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx8mm-phyboard-polis.dtsi:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX     0x00
+                MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX      0x00
+                MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B  0x00
+                MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B  0x00
+        >;
+};
+
+
+

The first part of the string MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad (in this example +SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the desired muxing option for this pad. +The pad setting value (hex value on the right) defines different modes of the pad, for example, if +internal pull resistors are activated or not. In this case, the internal resistors are disabled.

+
+
+

7.2. RS232/RS485

+

The i.MX 8M Mini SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +bootmode switch (S1) needs to be set correctly:

+ + + + + + + +
Switch between UART1 RS485/RS232
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+

7.2.1. RS232

+
    +

  • Display the current settings of a terminal in a human-readable format:

    +
    target:~$ stty -a
+
    +
    +
    • +

  • Configuration of the UART interface can be done with stty. For example:

    +
    target:~$ stty -F /dev/ttymxc0 115200 crtscts raw -echo
+
    +
    +
    • +

  • With a simple echo and cat, basic communication can be tested. Example:

    +
    target:~$ echo 123 > /dev/ttymxc0
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

The host should print out “123”.

+
+
+

7.2.2. RS485

+
+

Hint

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

For easy testing, look at the linux-serial-test. This tool is called the IOCTL +for RS485 and sends a constant stream of data.

+
target:~$ linux-serial-test -p /dev/ttymxc0 -b 115200 --rs485 0
+
+
+

More information about the linux-serial-test tool and its parameters can be +found here: linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Documentation for calling the IOCTL within c-code is described in the Linux +kernel documentation: +https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+

The device tree representation for RS232 and RS485: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n188

+
+
+
+

7.3. Network

+

phyBOARD-Polis-i.MX 8M Mini provides one Gigabit Ethernet interface.

+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n53.

+

+
+

7.3.1. Network Environment Customization

+
+

7.3.1.1. U-boot network-environment

+
    +

  • To find the Ethernet settings in the target bootloader:

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • With your development host set to IP 192.168.3.10 and netmask 255.255.255.0, +the target should return:

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • If you need to make any changes:

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> should be one of ipaddr, netmask, gatewayip or serverip. +<value> will be the actual value of the chosen parameter.

    +
    • +

  • The changes you made are temporary for now. To save these:

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

Here you can also change the IP address to DHCP instead of using a static one.

+
    +

  • Configure:

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • Set up paths for TFTP and NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+

Tip

+

Variables like nfsroot and netargs can be overwritten by the U-boot External +Environment. For netboot, the external environment will be loaded from tftp. +For example, to locally set the nfsroot variable in a bootenv.txt file, +locate the tftproot directory:

+
nfsroot=/home/user/nfssrc
+
+
+

There is no need to store the info on the target. Please note that this does +not work for variables like ipaddr or serveraddr as they need to be already +set when the external environment is being loaded.

+
+
+
+

7.3.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. WLAN

+

For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. Connecting to a WLAN Network

+

First set the correct regulatory domain for your country:

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

You will see:

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

Set up the wireless interface:

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

Now you can scan for available networks:

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection.

+

To do so, add the network-credentials to the file /etc/wpa_supplicant.conf:

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

Now a connection can be established:

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

This should result in the following output:

+
...
+ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section Changing the Network Configuration in the L-813e.A13 Yocto Reference Manual (hardknott).

+

First, create the directory:

+
target:~$ mkdir -p /etc/systemd/network/
+
+
+

Then add the following configuration snippet in /etc/systemd/network/10-wlan0.network:

+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+

Now, restart the network daemon so that the configuration takes effect:

+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+
+

7.3.3. Bluetooth

+

Bluetooth is connected to UART2 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup.

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. Visibility

+

To activate visibility:

+
target:~$ hciconfig hci0 piscan
+
+
+

To disable visibility:

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. Connect

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

Note

+

If the connection fails with the error message: “Failed to connect: +org.bluez.Error.Failed” try restarting PulseAudio with:

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC Card

+

The i.MX 8M Mini supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n266

+

DT configuration for the eMMC interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n315

+
+
+

7.5. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 8M Mini is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw MLC memory cells combined with a memory +controller that handles ECC and wear leveling. They are connected via an SD/MMC +interface to the i.MX 8M Mini and are represented as block devices in the Linux kernel +like SD cards, flash drives, or hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.5.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +cells. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background +Operations (BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+

The userspace tool mmc does not currently support enabling automatic BKOPS +features.

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops enable /dev/mmcblk2
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.5.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 8M Mini SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n> <partition> <device>
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.5.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
    +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+
+
+

7.5.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC memory cells +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC memory cells used in NAND Flash, MLC memory cells have lower +reliability and a higher error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC memory +cells or mark these blocks as discard. The data on the device is lost and will +be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.5.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 8M Mini uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.5.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

The following table is for the offset of the i.MX 8M Mini SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 8M Mini

33 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.6. SPI Master

+

The i.MX 8M Mini controller has a FlexSPI and an ECSPI IP core included. The FlexSPI +host controller supports two SPI channels with up to 4 devices. Each channel +supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data +lines). The ECSPI controller supports 3 SPI interfaces with one dedicated chip +selected for each interface. As chip selects should be realized with GPIOs, more +than one device on each channel is possible.

+
+

7.6.1. SPI NOR Flash

+

phyCORE-i.MX 8M Mini is equipped with a QSPI NOR Flash which connects to the i.MX 8M Mini’s +FlexSPI interface. The QSPI NOR Flash is suitable for booting. Please see +different sections for flashing and bootmode setup. Due to limited space on the +SPI NOR Flash, only the bootloader is stored inside. By default, the kernel, +device tree, and rootfs are taken from eMMC.

+

The Bootloader does detect with the help of the EEPROM Introspection data if an +SPI flash is mounted or not. If no SPI flash is mounted a device tree overlay is +applied with the expansion command to disable the SPI flash device tree node +during boot. If no introspection data is available the SPI NOR flash node is +always enabled. Find more information in the device tree overlay section.

+

The bootloader also passes the SPI MTD partition table to Linux by fixing up the +device tree based on the mtdparts boot parameter. The default partition layout +in the BSP is set to:

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

This is a bootloader environment variable that is defined here and can be +changed during runtime. From Linux userspace, the NOR Flash partitions are +accessible via /dev/mtd<N> devices where <N> is the MTD device number associated +with the NOR flash partition to access. To find the correct MTD device number +for a partition, run on the target:

+
root@phyboard-polis-imx8mm-5:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

It lists all MTD devices and the corresponding partition names. The flash node +is defined inside of the SPI master node in the module DTS. The SPI node +contains all devices connected to this SPI bus which is in this case only the +SPI NOR Flash.

+

The definition of the SPI master node in the device tree can be found here:

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy9#n71

+
+
+
+

7.7. GPIOs

+

The phyBOARD-Polis has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to i.MX 8M Mini pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal i.MX 8M Mini GPIO banks GPIO1 – GPIO5.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO5_07). <X> identifies the GPIO +bank and counts from 1 to 5, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 20 from chip0):

    +
    target:~$ gpioget gpiochip0 20
+
    +
    +
    • +

  • Set the value of GPIO 20 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset --mode=exit gpiochip0 20=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.7.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the defconfig you use in +arch/arm64/configs/ in the linux kernel sources. For our NXP based releases, +this could be for example imx8_phytec_distro.config:

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+

Pinmuxing of some GPIO pins in the device tree imx8mm-phyboard-polis-rdk.dtsi:

+
pinctrl_leds: leds1grp {
+        fsl,pins = <
+                MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1       0x16
+                MX8MM_IOMUXC_GPIO1_IO14_GPIO1_IO14      0x16
+                MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x16
+        >;
+};
+
+
+
+
+
+

7.8. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+mmc1::@    mmc2::@    user-led1@ user-led2@ user-led3@
+
+
+

Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the phyBOARD-Polis.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 255 > /sys/class/leds/user-led1/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/user-led1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n37

+
+
+

7.9. I²C Bus

+

The i.MX 8M Mini contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 8M Mini. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our phyBOARD-Polis.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C1 bus configuration (e.g. imx8mm-phycore-som.dtsi): +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy#n102

+

General I²C4 bus configuration (e.g. imx8mm-phyboard-polis-rdk.dtsi): +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n149

+
+
+

7.10. EEPROM

+

On the phyCORE-i.MX8MM there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues.

+
+

7.10.1. I2C EEPROM on phyCORE-i.MX8MM

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

The I2C EEPROM on the phyCORE-i.MX8MM SoM is connected to I2C address 0x51 on the I2C-0 +bus. It is possible to read and write directly to the device populated:

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the 4KiB EEPROM (bus: I2C-0 addr: 0x51) with zeros leaving out the EEPROM data use:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM Detection

+

The I2C EEPROM, populated on the phyCORE-i.MX8MM, has a separate ID page that is +addressable over I2C address 0x59 on bus 0 and a normal area that is addressable +over I2C address 0x51 on bus 0. PHYTEC uses this data area of 32 Bytes to store +information about the SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the EEPROM ID page data and the first 256 bytes of the normal area are +deleted, the bootloader will fall back to the phyCORE-i.MX8MM Kit RAM setup, which +is 2GiB RAM.

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

SoMs that are flashed with data format API revision 2 will print out information +about the module in the early stage.

+
+
+

7.10.3. Rescue EEPROM Data

+

The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area.

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1
+
+
+
+

Note

+

If you deleted both EEPROM spaces, please contact our support!

+
+

DT representation, e.g. in phyCORE-i.MX 8M Mini file imx8mm-phycore-som.dtsi can be +found in our PHYTEC git: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n271

+
+
+
+

7.11. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC Wakealarm

+

It is possible to issue an interrupt from the RTC to wake up the system. The +format uses the Unix epoch time, which is the number of seconds since UTC +midnight on 1 January 1970. To wake up the system after 4 minutes from suspend +to ram state, type:

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

Note

+

Internally the wake alarm time will be rounded up to the next minute since +the alarm function doesn’t support seconds.

+
+

DT representation for I²C RTCs: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy9#n277

+
+
+
+

7.12. USB Host Controller

+

The USB controller of the i.MX 8M Mini SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +‘HS’). The USB subsystem has two independent USB controller cores. Both cores +are On-The-Go (OTG) controller cores and are capable of acting as a USB +peripheral device or a USB host. Each is connected to a USB 2.0 PHY.

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+

User USB2 (host) configuration is in the kernel device tree +imx8mm.dtsi:

+
&usbotg2 {
+        dr_mode = "host";
+        picophy,pre-emp-curr-control = <3>;
+        picophy,dc-vol-level-adjust = <7>;
+        status = "okay";
+};
+
+
+

DT representation for USB Host: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy9#n240

+
+
+

7.13. USB OTG

+

Most PHYTEC boards provide a USB OTG interface. USB OTG ports automatically act +as a USB device or USB host. The mode depends on the USB hardware attached to +the USB OTG port. If, for example, a USB mass storage device is attached to the +USB OTG port, the device will show up as /dev/sda.

+
+

7.13.1. USB Device

+

In order to connect the board’s USB device to a USB host port (for example a +PC), you need to configure the appropriate USB gadget. With USB configfs you can +define the parameters and functions of the USB gadget. The BSP includes +USB configfs support as a kernel module.

+
target:~$ modprobe libcomposite
+
+
+

Example:

+
    +

  • First, define the parameters such as the USB vendor and product IDs, and set +the information strings for the English (0x409) language:

    • +
+
+

Hint

+

To save time, copy these commands and execute them in a script

+
+
cd /sys/kernel/config/usb_gadget/
+mkdir g1
+cd g1/
+echo "0x1d6b" > idVendor
+echo "0x0104" > idProduct
+mkdir strings/0x409
+echo "0123456789" > strings/0x409/serialnumber
+echo "Foo Inc." > strings/0x409/manufacturer
+echo "Bar Gadget" > strings/0x409/product
+
+
+
    +

  • Next, create a file for the mass storage gadget:

    • +
+
target:~$ dd if=/dev/zero of=/tmp/file.img bs=1M count=64
+
+
+
    +

  • Now you should create the functions you want to use:

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir functions/acm.GS0
+mkdir functions/ecm.usb0
+mkdir functions/mass_storage.0
+echo /tmp/file.img > functions/mass_storage.0/lun.0/file
+
+
+
    +

  • acm: Serial gadget, creates serial interface like /dev/ttyGS0.

    • +

  • ecm: Ethernet gadget, creates ethernet interface, e.g. usb0

    • +

  • mass_storage: The host can partition, format, and mount the gadget mass +storage the same way as any other USB mass storage.

    • +
+
    +

  • Bind the defined functions to a configuration:

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir configs/c.1
+mkdir configs/c.1/strings/0x409
+echo "CDC ACM+ECM+MS" > configs/c.1/strings/0x409/configuration
+ln -s functions/acm.GS0 configs/c.1/
+ln -s functions/ecm.usb0 configs/c.1/
+ln -s functions/mass_storage.0 configs/c.1/
+
+
+
    +

  • Finally, start the USB gadget with the following commands:

    • +
+
target:~$ cd /sys/kernel/config/usb_gadget/g1
+target:~$ ls /sys/class/udc/
+ci_hdrc.0
+target:~$ echo "ci_hdrc.0" >UDC
+
+
+

If your system has more than one USB Device or OTG port, you can pass the right +one to the USB Device Controller (UDC).

+
    +

  • To stop the USB gadget and unbind the used functions, execute:

    • +
+
target:~$ echo "" > /sys/kernel/config/usb_gadget/g1/UDC
+
+
+

Both USB interfaces are configured as host in the kernel device tree +imx8mm-phyboard-polis.dtsi. See: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n228

+
+
+
+

7.14. CAN FD

+

The phyBOARD-Polis has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
+

Hint

+

phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. +There are different interfaces involved, which limits the datarate +capabilities of CANFD.

+
+
+

Hint

+

On phyBOARD-Polis-i.MX8MM a terminating resistor can be enabled by setting +S5 to ON if required.

+
+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The two CAN interfaces should show up as +can0 and can1.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    The information for can0 will look like:

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+
+

Warning

+

The mcp2518fd SPI to CANfd supports only baudrates starting from 125kB/s. +Slower rates can be selected but may not work correctly.

+
+

Device Tree CAN configuration of imx8mm-phyboard-polis.dtsi: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n106

+
+
+

7.15. PCIe

+

The phyCORE-i.MX 8M Mini has one Mini-PCIe slot. In general, PCIe autodetects new +devices on the bus. After connecting the device and booting up the system, you +can use the command lspci to see all PCIe devices recognized.

+
    +

  • Type:

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • You will receive:

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

In this example, the PCIe device is the Intel Corporation WiFi Link 5100.

+

For PCIe devices, you have to enable the correct driver in the kernel +configuration. This WLAN card, for example, is manufactured by Intel. The +option for the driver, which must be enabled, is named CONFIG_IWLWIFI and can be +found under Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimat in +the kernel configuration.

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • The linux-imx is represented by: virtual/kernel

      • +
    +
    • +
+

For some devices like the WLAN card, additional binary firmware blobs are +needed. These firmware blobs have to be placed in /lib/firmware/ before the +device can be used.

+
    +

  • Type:

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • For example, if you try to bring up the network interface:

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • You will get the following output on the serial console:

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

Tip

+

Some PCIe devices, e.g. the Ethernet card, may function properly even if no +firmware blob is loaded from /lib/firmware/ and you received an error message +as shown in the first line of the output above. This is because some +manufacturers provide the firmware as a fallback on the card itself. In this +case, the behavior and output depend strongly on the manufacturer’s firmware.

+
+
+
+

7.16. Audio

+

The PEB-AV-10-Connector exists in two versions and the 1531.1 version is +populated with a TI TLV320AIC3007 audio codec. Audio support is done via the I2S +interface and controlled via I2C.

+

There is a 3.5mm headset jack with OMTP standard and an 8-pin header to connect +audio devices with the AV-Connector. The 8-pin header contains a mono speaker, +headphones, and line-in signals.

+

To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices:

+
target:~$ aplay -L
+
+
+

Or type for recording devices:

+
target:~$ arecord -L
+
+
+
+

7.16.1. Alsamixer

+

To inspect the capabilities of your soundcard, call:

+
target:~$ alsamixer
+
+
+

You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. “MM” means the feature is muted +(both output, left & right), which can be toggled by hitting m. You can also +toggle by hitting ‘<’ for left and ‘>’ for right output. With the tab +key, you can switch between controls for playback and recording.

+
+
+

7.16.2. ALSA configuration

+

Our BSP comes with a ALSA configuration file /etc/asound.conf.

+

The ALSA configuration file can be edited as desired or deleted since it is not +required for ALSA to work properly.

+
target:~$ vi /etc/asound.conf
+
+
+

To set PEB-AV-10 as output, set playback.pcm from “dummy” to “pebav10”:

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

If the sound is not audible change playback devices to the software volume control +playback devices, set playback.pcm to the respective softvol playback device e.g. +“softvol_pebav10”. Use alsamixer controls to vary the volume levels.

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.16.3. Pulseaudio Configuration

+

For applications using Pulseaudio, check for available sinks:

+
target:~$ pactl list short sinks
+0   alsa_output.platform-snd_dummy.0.stereo-fallback    module-alsa-card.c  s16le 2ch 44100Hz   SUSPENDED
+1   alsa_output.platform-sound-peb-av-10.stereo-fallback    module-alsa-card.c  s16le 2ch 44100Hz   SUSPENDED
+
+
+

To select PEB-AV-10, type:

+
target:~$ pactl set-default-sink 1
+
+
+
+
+

7.16.4. Playback

+

Run speaker-test to check playback availability:

+
target:~$ speaker-test -c 2 -t wav
+
+
+

To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds:

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

To playback other formats like mp3 for example, you can use Gstreamer:

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.16.5. Capture

+

arecord is a command-line tool for capturing audio streams which use Line In as +the default input source. To select a different audio source you can +use alsamixer. For example, switch on Right PGA Mixer Mic3R and Left PGA Mixer +Mic3R in order to capture the audio from the microphone input of the +TLV320-Codec using the 3.5mm jack.

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

Hint

+

Since playback and capture share hardware interfaces, it is not possible to +use different sampling rates and formats for simultaneous playback and +capture operations.

+
+

Device Tree Audio configuration: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mm-phyboard-polis-peb-av-010.dtso?h=v5.10.72_2.2.0-phy17#n56

+
+
+
+

7.17. Video

+
+

7.17.1. Videos with Gstreamer

+

The video is installed by default in the BSP:

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/phytec-qtdemo/videos/caminandes.webm
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=<video.mp4> \
+\! qtdemux  \! h264parse \! queue \! vpudec \! waylandsink async=false enable-last-sample=false \
+qos=false sync=false
+
+
+
    +

  • Or:

    • +
+
target:~$ gplay-1.0 /usr/share/phytec-qtdemo/videos/caminandes.webm
+
+
+
+
+

7.17.2. kmssink Plugin ID Evaluation

+

The kmssink plugin needs a connector ID. To get the connector ID, you can use +the tool modetest.

+
target:~$ modetest -c imx-drm
+
+
+

The output will show something like:

+
Connectors:
+id  encoder status      name        size (mm)   modes   encoders
+35  34  connected   LVDS-1          216x135     1   34
+  modes:
+    index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
+  #0 1280x800 59.07 1280 1380 1399 1440 800 804 808 823 70000 flags: phsync, pvsync; type: preferred, driver
+  props:
+    1 EDID:
+        flags: immutable blob
+        blobs:
+
+        value:
+    2 DPMS:
+        flags: enum
+        enums: On=0 Standby=1 Suspend=2 Off=3
+        value: 0
+    5 link-status:
+        flags: enum
+        enums: Good=0 Bad=1
+        value: 0
+    6 non-desktop:
+        flags: immutable range
+        values: 0 1
+        value: 0
+    4 TILE:
+        flags: immutable blob
+        blobs:
+
+        value:
+
+
+
+
+
+

7.18. Display

+

The 10” Display is always active. If the PEB-AV-Connector is not connected, an +error message may occur at boot.

+
+

7.18.1. Qt Demo

+

With the phytec-qt5demo-image, Weston starts during boot. The phytec-qt5demo can be +stopped with:

+
target:~$ systemctl stop phytec-qtdemo
+
+
+
    +

  • To start the demo again, run:

    +
    target:~$ systemctl start phytec-qtdemo
+
    +
    +
    • +

  • To disable autostart of the demo run:

    +
    target:~$ systemctl disable phytec-qtdemo
+
    +
    +
    • +

  • To enable autostart of the demo, run:

    +
    target:~$ systemctl enable phytec-qtdemo
+
    +
    +
    • +

  • Weston can be stopped with:

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

Note

+

The Qt demo must be closed before Weston can be closed.

+
+
+
+

7.18.2. Backlight Control

+

If a display is connected to the PHYTEC board, you can control its backlight +with the Linux kernel sysfs interface. All available backlight devices in the +system can be found in the folder /sys/class/backlight. Reading the appropriate +files and writing to them allows you to control the backlight.

+
+

Note

+

Some boards with multiple display connectors might have multiple backlight +controls in /sys/class/backlight. For example: backlight0 and backlight1

+
+
    +

  • To get, for example, the maximum brightness level (max_brightness) execute:

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    Valid brightness values are 0 to <max_brightness>.

    +
    • +

  • To obtain the current brightness level, type:

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • Write to the file brightness to change the brightness:

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    turns the backlight off for example.

    +

    For documentation of all files, see +https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight.

    +
    • +
+

The device tree of PEB-AV-10 can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mm-phyboard-polis-peb-av-010.dtso?h=v5.10.72_2.2.0-phy17

+
+
+
+

7.19. Power Management

+
+

7.19.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 8M Mini SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as ‘Dynamic Voltage and +Frequency Scaling’ (DVFS). The i.MX 8M Mini BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the i.MX 8 +variant used, several different frequencies are supported.

+
+

Tip

+

Although the DVFS framework provides frequency settings for each CPU core, a +change in the frequency settings of one CPU core always affects all other CPU +cores too. So all CPU cores always share the same DVFS setting. An individual +DVFS setting for each core is not possible.

+
+
    +

  • To get a complete list type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately +1,6 GHz, the result will be:

    +
    1200000 1600000
+
    +
    +
    • +

  • To ask for the current frequency type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

So-called governors are automatically selecting one of these frequencies in +accordance with their goals.

+
    +

  • List all governors available with the following command:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    The result will be:

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative is much like the ondemand governor. It differs in behavior in +that it gracefully increases and decreases the CPU speed rather than jumping +to max speed the moment there is any load on the CPU.

    • +

  • ondemand (default) switches between possible CPU core frequencies in +reference to the current system load. When the system load increases above a +specific limit, it increases the CPU core frequency immediately.

    • +

  • powersave always selects the lowest possible CPU core frequency.

    • +

  • performance always selects the highest possible CPU core frequency.

    • +

  • userspace allows the user or userspace program running as root to set a +specific frequency (e.g. to 1600000). Type:

    • +

  • In order to ask for the current governor, type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    You will normally get:

    +
    ondemand
+
    +
    +
    • +

  • Switching over to another governor (e.g. userspace) is done with:

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • Now you can set the speed:

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +Documentation/admin-guide/pm/cpufreq.rst.

+
+
+

7.19.2. CPU Core Management

+

The i.MX 8M Mini SoC can have multiple processor cores on the die. The i.MX 8M Mini, for +example, has 4 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    Here the system has four processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.19.3. Suspend to RAM

+

The phyCORE-i.MX8MM supports basic suspend and resume. Different wake-up sources can be +used. Suspend/resume is possible with:

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

To wake up with serial console run

+
target:~$ echo enabled > /sys/class/tty/ttymxc2/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.20. Thermal Management

+
+

7.20.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.20.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 8M Mini SoC platform. The i.MX 8 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Industrial +and Commercial.

+ + + + + + + + + + + + + + + + + +

Commercial

Industrial

passive (warning)

85°C

95°C

critical (shutdown)

90°C

100°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise, Fair Share, Bang Bang, and +Userspace. The default policy used in the BSP is step_wise. If the value of the +SoC temperature in the sysfs file temp is above trip_point_0, the CPU frequency +is set to the lowest CPU frequency. When the SoC temperature drops below +trip_point_0 again, the throttling is released.

+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+

7.20.3. GPIO Fan

+
+

Note

+

Only GPIO fan supported.

+
+

A GPIO fan can be connected to the phyBOARD-Polis-i.MX 8M Mini. The SoC only contains one +temperature sensor which is already used by the thermal frequency scaling. The +fan can not be controlled by the kernel. We use lmsensors with hwmon for this +instead. lmsensors reads the temperature periodically and enables or disables +the fan at a configurable threshold. For the phyBOARD-Polis-i.MX 8M Mini, this is 60°C.

+

The settings can be configured in the configuration file:

+
/etc/fancontrol
+
+
+

Fan control is started by a systemd service during boot. This can be disabled +with:

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.21. Watchdog

+

The PHYTEC i.MX 8M Mini modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.21.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.22. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 8M Mini provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 8M Mini Reference Manual). The following list is +an abstract from the i.MX 8M Mini Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x30350000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x30350000

Description

OCOTP_MAC_ADDR0

9

0

0x640

contains lower 32 bits +of ENET0 MAC address

OCOTP_MAC_ADDR1

9

1

0x650

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

OCOTP_MAC_ADDR2

9

2

0x660

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 8M Mini Security Reference Manual.

+
+

7.22.1. Reading Fuse Values in uBoot

+

You can read the content of a fuse using memory-mapped shadow registers. To +calculate the memory address, use the fuse Bank and Word in the following +formula:

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.22.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+
+

8. i.MX 8M Mini M4 Core

+

In addition to the Cortex-A53 cores, there is a Cortex-M4 Core as MCU +integrated into the i.MX 8M Mini SoC. Our Yocto-Linux-BSP runs on the A53-Cores and +the M4 Core can be used as a secondary core for additional tasks using +bare-metal or RTOS firmware. +Both cores have access to the same peripherals and thus peripheral +usage needs to be limited either in the M4 Core’s firmware or the devicetree +for the Linux operating system. This section describes how to build firmware +examples and how to run them on phyBOARD-Polis.

+

The phyBOARD-Polis is currently supported by the NXP MCUXpresso SDK and by +The Zephyr Project. This section only describes the NXP MCUXpresso SDK because +the MCUXpresso SDK has more supported features at the moment.

+

If you want to use the M4 Core with The Zephyr Project, please refer to the +The Zephyr Project documentation:

+ +
+

8.1. Getting the Firmware Examples

+

The firmware can be built using the NXP MCUxpresso SDK with a compatible +compiler toolchain using command-line tools.

+
+

8.1.1. Getting the Sources

+

The MCUX SDK and the examples for the i.MX 8M Mini can be obtained from PHYTEC’s GitHub +page:

+ +
    +

  1. Initialize the MCUX SDK via west:

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    This will create a mcuxsdk directory with the mcux-sdk repository in it. +The mcux-sdk-phytec-examples repository will be automatically cloned into +the mcuxsdk directory. +The given argument <VERSION> is a the branch name of the mcux-sdk repository +that represents the MCUX SDK version. For the newest tested version +you can use 2.13.0.

    +
    +

    Note

    +

    west is a repository management tool and a part of the Zephyr +Project. +To install west, you can use pip. In this example west is installed in +a python virtual environment:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. Update the dependencies:

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    The directory examples-phytec contains all examples ported and tested +for phyBOARD-Polis with version 2.13.0 of MCUX.

    +

    To build the firmware, a compiler toolchain and make/cmake are required. +The GNU Arm Embedded Toolchain may be available in your distribution’s +repositories, e.g. for Ubuntu.

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    The compiler toolchain can also be obtained directly from +https://developer.arm.com/. After the archive has been extracted, +the ARMGCC_DIR has to be added to the environment, e.g. for the +ARM toolchain 10-2020-q4-major release located in the home directory:

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. Building the Firmware

+

To build the PHYTEC samples an environment has to be sourced

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

The scripts to build the firmware are located in +<sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc. +There are scripts for each memory location the firmware is supposed to run in, +e.g.

+
host:~$ ./build_release.sh
+
+
+

to build the firmware for the M4 Core’s TCM. The output will be placed under +release/ in the armgcc directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+

To build the firmware for the DRAM, run the script build_ddr_release. +The script of the firmware that is supposed to run, e.g.

+
host:~$ ./build_ddr_release.sh
+
+
+

The output will be placed under ddr_release/ in the armgcc +directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+
+
+
+

8.2. Running M4 Core Examples

+

There are two ways to run the M4 Core with the built firmware, U-Boot and +Remoteproc within a running Linux.

+

To receive debug messages start your favorite terminal software (e.g. Minicom, +Tio, or Tera Term) on your host PC and configure it for 115200 baud, 8 data +bits, no parity, and 1 stop bit (8n1) with no handshake.

+

Once a micro-USB cable is connected to the USB-debug port on the phyBOARD-Polis, two +ttyUSB devices are registered. One prints messages from A53-Core’s debug UART +and the other one from the M4 Core’s debug UART.

+
+

8.2.1. Running Examples from U-Boot

+

To load firmware using the bootloader U-Boot, the bootaux command can be used:

+
    +

  1. Prepare an SD Card with our Yocto-BSP

    2. +

  2. Copy the generated .bin file to the SD Cards first partition

    3. +

  3. Stop the autoboot by pressing any key

    4. +

  4. Type the command depending on the type of firmware:

    5. +
+

For firmware built to run in the M4 Core’s TCM:

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

For firmware built to run in the DRAM:

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

The program’s output should appear on the M4 Core’s debug UART.

+
+
+

8.2.2. Running Examples from Linux using Remoteproc

+

Remoteproc is a module that allows you to control the M4 Core from Linux +during runtime. Firmware built for TCM can be loaded and the execution started +or stopped. To use Remoteproc a devicetree overlay needs to be set:

+

Edit the bootenv.txt file located in the /boot directory on the target by +adding imx8mm-phycore-rpmsg.dtbo:

+
overlays=imx8mm-phycore-rpmsg.dtbo
+
+
+

Restart the target and execute in U-Boot:

+
u-boot=> run prepare_mcore
+
+
+

Firmware .elf files for the M4 Core can be found under /lib/firmware. +To load the firmware, type:

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

To load a different firmware, the M4 Core needs to be stopped:

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

Note

+

The samples found in /lib/firmware on the target come from NXP’s +Yocto layer meta-imx. +To use the samples you built yourself through MCUX SDK, please copy them +to /lib/firmware on the target after building them.

+
+
+ +
+
+
+

9. BSP Extensions

+
+

9.1. Chromium

+

Our BSP for the phyBOARD-Polis-i.MX 8M Mini supports Chromium. You can include it in the +phytec-qt5demo-image with only a few steps.

+
+

9.1.1. Adding Chromium to Your local.conf

+

To include Chromium you have to add the following line into your local.conf. You +can find it in <yocto_dir>/build/conf/local.conf. This adds Chromium to your +next image build.

+
IMAGE_INSTALL_append = " chromium-ozone-wayland"
+
+
+
+

Note

+

Compiling Chromium takes a long time.

+
+
+
+

9.1.2. Get Chromium Running on the Target

+

To run Chromium, it needs a few arguments to use the hardware graphics +acceleration:

+
target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox
+
+
+

If you want to start Chromium via SSH, you must first define the display on +which Chromium will run. For example:

+
target$ DISPLAY=:0
+
+
+

After you have defined this, you can start it via virtual terminal on Weston as +shown above.

+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mm/pd23.1.0.html b/previews/271/bsp/imx8/imx8mm/pd23.1.0.html new file mode 100644 index 000000000..405f1a02f --- /dev/null +++ b/previews/271/bsp/imx8/imx8mm/pd23.1.0.html @@ -0,0 +1,4636 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 8M Mini BSP Manual

Document Title

i.MX 8M Mini BSP Manual

Document Type

BSP Manual

Yocto Manual

Kirkstone

Release Date

2024/01/10

Is Branch of

i.MX 8M Mini BSP Manual

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-NXP-i.MX8MM-PD23.1.0

Major

2023/12/12

Released

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +phyCORE-i.MX8M Mini Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads of our product.

+
+

1.1. Supported Hardware

+

The phyBOARD-Polis populated with either the i.MX 8M Mini SoC or i.MX 8M Nano SoC, is +supported.

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-NXP-i.MX8MM-PD23.1.0 download. +If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware

+
+

1.1.1. phyBOARD-Polis Components

+ + + + + + +
+../../../_images/polis-front.jpg +
+

phyBOARD-Polis Components (top)

+
+
+
+../../../_images/polis-back.jpg + +
+

phyBOARD-Polis Components (bottom)

+
+
+
+
+
+
+
+

2. Getting Started

+

The phyCORE-i.MX8M Mini Kit is shipped with a pre-flashed SD card. It contains the +phytec-qt6demo-image and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+

There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool dd. An +alternative way is to use PHYTEC’s system initialization program called +partup, which makes it especially easy to +format more complex systems. You can get prebuilt Linux binaries of partup from its release page. Also read +partup’s README for installation +instructions.

+
+

2.1. Get the Image

+

The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using dd, can be downloaded from the PHYTEC download server.

+

Get either the partup package or the WIC image from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt6demo-image-phyboard-polis-imx8mm-5.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+
+
+
+

Note

+

For eMMC, more complex partitioning schemes or even just large images, we +recommend using the partup package, as it is faster in writing than dd +and allows for a more flexible configuration of the target flash device.

+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card, you must have root privileges on your Linux +host PC. Be very careful when specifying the destination device! All files +on the selected device will be erased immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system on your host PC!

+
+
+

2.2.1. Finding the Correct Device

+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+

Unmount all those partitions, e.g.:

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

Now, the SD card is ready to be flashed with an image, using either partup, +dd or bmap-tools.

+
+
+

2.2.2. Using partup

+

Writing to an SD card with partup is done in a single command:

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-polis-imx8mm-5.partup /dev/<your_device>
+
+
+

Make sure to replace <your_device> with your actual device name found previously.

+

Further usage of partup is explained at its official documentation website.

+
+

Note

+

partup has the advantage of allowing to clear specific raw areas in the +MMC user area, which is used in our provided partup packages to erase any +existing U-Boot environments. This is a known issue bmaptool does not +solve, as mentioned below.

+

Another key advantage of partup over other flashing tools is that it allows +configuring MMC specific parts, like writing to eMMC boot partitions, without +the need to call multiple other commands when writing.

+
+
+
+

2.2.3. Using bmap-tools

+

An alternative and also fast way to prepare an SD card is using +bmap-tools. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host:~$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /dev/<your_device>
+
+
+

Replace <your_device> with your actual SD card’s device name found previously, +and make sure to place the file <IMAGENAME>-<MACHINE>.wic.bmap alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip.

+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.2.4. Using dd

+

After having unmounted all SD card’s partitions, you can create your bootable SD card.

+

Some PHYTEC BSPs produce uncompressed images (with filename-extension *.wic), +and some others produce compressed images (with filename-extension *.wic.xz).

+

To flash an uncompressed images (*.wic) use command below:

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Or to flash a compressed images (*.wic.xz) use that command:

+
host:~$ xzcat phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Again, make sure to replace <your_device> with your actual device name found +previously.

+

The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

+
+
+
+

2.3. First Start-up

+ + + + + + + +
Bootmode Selection
+../../../_images/SD_Card_Boot.jpg +
+

Mini

+
+
+
+
    +

  • Insert the SD card

    • +

  • Connect the target and the host with mirco USB on (X30) +debug USB

    • +

  • Power up the board

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 8M Mini BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (kirkstone).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (kirkstone).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-IMX8MM; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-xwayland MACHINE=phyboard-polis-imx8mm-5 ./phyLinux init -p imx8mm -r BSP-Yocto-NXP-i.MX8MM-PD23.1.0
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the phyboard-polis-imx8mm-5 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx8mm.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, +lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY firmware images

    • +

  • imx-boot: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM +Trusted Firmware and DDR firmware. This is the final bootloader image which is +bootable.

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx8mm-phyboard-polis-rdk*.dtb: Kernel device tree file

    • +

  • imx8mm-phy*.dtbo: Kernel device tree overlay files

    • +

  • phytec-qt6demo-image*.tar.gz: Root file system

    • +

  • phytec-qt6demo-image*.wic: SD card image

    • +
+
+
+
+
+

4. Installing the OS

+
+

4.1. Bootmode Switch (S1)

+

The phyBOARD-Polis features a boot switch with six individually switchable ports to +select the phyCORE-i.MX 8M Mini default bootsource.

+
+

4.1.1. Mini

+ + + + + + + + + + +
Bootmode Selection
+../../../_images/eMMC.jpg +
+

eMMC (Default SoM boot)

+
+
+
+../../../_images/SPI_NOR.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download1.png +
+

USB Serial Download

+
+
+
+../../../_images/SD_Card_Boot.jpg +
+

SD Card

+
+
+
+ + + + + + + +
Switch between UART1 RS485/RS232
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+
+
+

4.2. Flash eMMC

+

For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see Setup Network Host.

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S1) is set to eMMC.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk2p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from Network

+

i.MX 8M Mini boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

4.2.1.1. Flash eMMC from Network in U-Boot on Target

+

These steps will show how to update the eMMC via a network.

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE.

+
+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Load your image via network to RAM:

+
    +

  • when using dhcp

    +
    u-boot=> dhcp phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.1 (1 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.1
+Filename 'phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • when using a static ip address (serverip and ipaddr must be set +additionally).

    +
    u-boot=> tftp ${loadaddr} phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
+
+
+
+

4.2.1.2. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Take a compressed or uncompressed image with accompanying block map on the host +and send it with ssh through the network to the eMMC of the target with a +one-line command:

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic.* /tmp && bmaptool copy /tmp/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /dev/mmcblk2
+
+
+
+
+

4.2.1.3. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Show your available image files on the host:

+
host:~$ ls /srv/tftp
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic.bmap
+
+
+

Send the image with the bmaptool command combined with ssh through the network +to the eMMC of your device:

+
host:~$ scp /srv/tftp/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /dev/mmcblk2"
+
+
+
+
+
+

4.2.2. Flash eMMC U-Boot image via Network from running U-Boot

+

Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x42 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.3. Flash eMMC from USB stick

+
+

4.2.3.1. Flash eMMC from USB stick in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE.

+
+

These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch (S1) to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied WIC image to the USB slot.

+

Load your image from the USB device to RAM:

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} *.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic). Set the bootmode switch (S1) to SD Card.

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ ls /mnt
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Mini eMMC (MMC device 2 without partition):

    +
    target:~$ bmaptool copy /mnt/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Tip

    +

    Before this will work, you need to configure the bootmode switch (S1) to +eMMC.

    +
    +
    • +
+
+
+
+

4.2.4. Flash eMMC from SD Card

+

Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (*.wic) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see Resizing ext4 Root Filesystem.

+

Alternatively, flash a partup package to the SD card, as described in +Getting Started. This will ensure the full space of the SD card is used.

+
+

4.2.4.1. Flash eMMC from SD card in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE. If the +image file is too large use the Updating eMMC from SD card in +Linux on Target subsection.

+
+
    +

  • Flash an SD card with a working image and create a third ext4 partition. Copy +the WIC image (for example phytec-qt6demo-image.wic) to this +partition.

    • +

  • Configure the bootmode switch (S1) to SD Card and insert the SD Card.

    • +

  • Power on the board and stop in U-Boot.

    • +

  • Load the image:

    +
    u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • Switch the mmc dev to eMMC:

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • Flash your WIC image (for example phytec-qt6demo-image.wic) +from the SD card to eMMC. This will partition the card and copy imx-boot, +Image, dtb, dtbo, and root file system to eMMC.

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • Power off the board and change the bootmode switch (S1) to eMMC.

    • +
+
+
+

4.2.4.2. Flash eMMC from SD card in Linux on Target

+

You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card.

+
    +

  • Show your saved partup package or WIC image files on the SD card:

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.partup
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Mini eMMC (MMC device 2 without +partition) using partup:

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-polis-imx8mm-5.partup /dev/mmcblk2
+
    +
    +

    Flashing the partup package has the advantage of using the full capacity of +the eMMC device, adjusting partitions accordingly.

    +
    +

    Note

    +

    Alternatively, bmaptool may be used instead:

    +
    target:~$ bmaptool copy phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /dev/mmcblk2
+
    +
    +

    Keep in mind that the root partition does not make use of the full space when +flashing with bmaptool.

    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Warning

    +

    Before this will work, you need to configure the bootmode switch (S1) to eMMC.

    +
    +
    • +
+
+
+
+
+

4.3. Flash SPI NOR Flash

+

The phyCORE-i.MX8MM modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set bootmode switch (S1) to SPI NOR. The SPI Flash is usually quite small. +The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash populated. Only the +bootloader and the environment can be stored. The kernel, device tree, and file +system are taken from eMMC by default.

+

The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with:

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. Flash SPI NOR Flash from Network

+

The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-i.MX 8M Mini.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+
+

4.3.1.1. Flash SPI NOR from Network in U-Boot on Target

+

Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI NOR flash needs to be probed:

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • A specially formatted U-Boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image over tftp, erase and write the +bootloader to the flash:

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+

4.3.1.2. Flash SPI NOR from Network in kernel on Target

+
    +

  • Copy the image from the host to the target:

    +
    host:~$ scp imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • Find the number of blocks to erase of the U-boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the U-Boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+

4.3.2. Flash SPI NOR Flash from SD Card

+

The bootloader on SPI NOR flash can be also flashed with SD Card.

+
+

4.3.2.1. Flash SPI NOR from SD Card in U-Boot on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi to the first partition +on the SD Card.

    • +

  • Before reading and writing are possible, the SPI-NOR flash +needs to be probed:

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • A specially formatted U-boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image from the SD Card, erase and write +the bootloader to the flash:

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+

4.3.2.2. Flash SPI NOR from SD Card in kernel on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi to the first partition +on the SD Card.

    • +

  • Mount the SD Card:

    +
    target:~$ mount /dev/mmcblk1p1 /mnt
+
    +
    +
    • +

  • Find the number of blocks to erase of the U-Boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the u-boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A5 RAUC Update & Device Management Manual.

+
+
+
+

5. Development

+
+

5.1. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.1.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.2. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.2.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel image to your tftp directory:

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • Copy the devicetree to your tftp directory:

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • Copy all the overlays you want to use into your tftp directory:

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-polis-imx8mm-5.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.2.2. Set the bootenv.txt for Netboot

+

Create a bootenv.txt file in your tftp directory and write the following variables into it.

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> has to be replaced with the devicetree overlay filenames that you want to use. +Separate the filenames by spaces. For example:

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

Tip

+

All supported devicetree overlays are in the device tree chapter.

+
+
+
+

5.2.3. Network Settings on Target

+

To customize the targets ethernet configuration, please follow the description +here: Network Environment Customization

+
+
+

5.2.4. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.3.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/phyboard-polis-imx8mm-5/. For flashing a wic image to eMMC, +you will also need phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic.

+
+
+

5.3.3. Prepare Target

+

Set the bootmode switch (S1) to USB Serial Download. Also, connect USB port +X2 to your host.

+
+
+

5.3.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via (X30), as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.3.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+
+
+
+
+
+

5.4. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone git://git.phytec.de/u-boot-imx)

+
+
+

5.4.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-imx and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • Our i.MX 8M Mini kernel is based on the linux-imx kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. Get the SDK

+

You can download the SDK here, or build it yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

After a successful build the SDK installer is deployed to build/deploy*/sdk.

+
+
+

5.4.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-4.0.13.sh
+host:~$ ./phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-4.0.13.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-xwayland/4.0.13):
+You are about to install the SDK to "/opt/ampliphy-vendor-xwayland/4.0.13". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-vendor-xwayland/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. U-Boot standalone build

+
+

Note

+

The regulator for the SD card reset pin has been disabled to ensure +compatibility with 1532.1 revision baseboards. If you have a revision +1532.2(a) or higher baseboard, you may enable the device tree nodes for +highest performance. In the imx8mm-phyboard-polis-rdk-u-boot.dtsi file, +remove the following lines:

+
/delete-node/ &reg_usdhc2_vmmc;
+/delete-property/ vmmc-supply;
+
+
+
+
+

5.5.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag used in this release is called v2022.04_2.2.2-phy5

    • +

  • Check out the needed U-Boot tag:

    +
    host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2022.04_2.2.2-phy5
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor-xwayland/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. Get the needed binaries

+

To build the bootloader, you need to copy these files to your u-boot-imx +build directory and rename them to fit with mkimage script:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx8mm.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +
+

If you already built our BSP with Yocto, you can get the +bl31-imx8mm.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: BSP Images

+

Or you can download the files here: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/imx-boot-tools/

+
+

Warning

+

Make sure you rename the files you need so that they are compatible with the +mkimage tool.

+
+
+
+

5.5.3. Build the bootloader

+
    +

  • build flash.bin (imx-boot):

    +
    host:~/u-boot-imx$ make phycore-imx8mm_defconfig
+host:~/u-boot-imx$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. Flash the bootloader to a block device

+

The flash.bin can be found at u-boot-imx/ directory and now can be +flashed. A chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 8M Mini

33 kiB

33 kiB

/dev/mmcblk2

+

E.g. flash SD card:

+
host:~/u-boot-imx$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=33 conv=sync
+
+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables +“BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+

5.5.5. Build U-Boot With a Fixed RAM Size

+

If you cannot boot your system anymore because the hardware introspection in the +EEPROM is damaged or deleted, you can create a flash.bin with a fixed ram size. +You should still contact support and flash the correct EEPROM data, as this +could lead to unexpected behavior.

+

Follow the steps to get the U-boot sources and check the correct branch in the +Build U-Boot section.

+

Edit the file configs/phycore-imx8mm_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MM=y
+CONFIG_PHYCORE_IMX8MM_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_4GB=y
+
+
+

Choose the correct RAM size as populated on the board and uncomment the line for +this ram size. +After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+
+

5.6. Kernel standalone build

+
+

5.6.1. Setup sources

+
    +

  • The used linux-imx branch can be found in the release notes

    • +

  • The tag needed for this release is called v5.15.71_2.2.2-phy3

    • +

  • Check out the needed linux-imx tag:

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v5.15.71_2.2.2-phy3
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor-xwayland/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-imx$ make imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-imx/arch/arm64/boot/Image

    • +

  • The dtb can be found at +~/linux-imx/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. Copy Kernel to SD Card

+

When one-time boot via netboot is not sufficient, the kernel along with its +modules and the corresponding device tree blob may be copied directly to a +mounted SD card.

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. Accessing the Development states

+
+

5.7.1. Development state of current release

+

These release manifests exist to give you access to the development states +of the Yocto BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line:

+
host:~$ ./phyLinux init -p imx8mm -r BSP-Yocto-NXP-i.MX8MM-PD23.1.y
+
+
+

This will initialize a BSP that will track the latest development state of the +current release (BSP-Yocto-NXP-i.MX8MM-PD23.1.0). From now on repo sync in this folder +will pull all the latest changes from our Git repositories:

+
host:~$ repo sync
+
+
+
+
+

5.7.2. Development state of upcoming release

+

Also development states of upcoming releases can be accessed this way. +For this execute the following command and look for a release with a higher +PDXX.Y number than the latest one (BSP-Yocto-NXP-i.MX8MM-PD23.1.0) and .y at the +end:

+
host:~$ ./phyLinux init -p imx8mm
+
+
+
+
+
+

5.8. Accessing the Latest Upstream Support

+

We have a vanilla manifest that makes use of the Yocto master branches (not an +NXP release), Linux, and U-Boot. This can be used to test the latest upstream +kernel/U-Boot.

+
+

Note

+

The master manifest reflects the latest state of development. This tends to +be broken from time to time. We try to fix the master on a regular basis.

+
+
host:~$ ./phyLinux init -p imx8mm -r BSP-Yocto-Ampliphy-i.MX8MM-master
+
+
+
+
+

5.9. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.9.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 8M Mini BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 8M Mini SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Board.dts - include the module dtsi file. Devices that come from the i.MX 8M Mini +SoC but are just routed down to the carrier board and used there are included +in this dts.

    • +

  • Overlay.dtso - enable/disable features depending on optional hardware that +may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10)

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 8 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder arch/arm64/boot/dts/freescale/overlays.

+

Available overlays for phyboard-polis-imx8mm-5.conf are:

+
imx8mm-phyboard-polis-peb-eval-01.dtbo
+imx8mm-phyboard-polis-peb-av-010.dtbo
+imx8mm-phycore-rpmsg.dtbo
+imx8mm-phycore-no-eth.dtbo
+imx8mm-phycore-no-spiflash.dtbo
+imx8mm-vm016.dtbo
+imx8mm-vm016-fpdlink.dtbo
+imx8mm-vm017.dtbo
+imx8mm-vm017-fpdlink.dtbo
+imx8mm-dual-vm017-fpdlink.dtbo
+
+
+

The usage of overlays can be configured during runtime in Linux or U-Boot. +Overlays are applied during the boot process in the bootloader after the +boot command is called and before the kernel is loaded. The next sections +explain the configuration in more detail.

+
+

6.2.2.1. Set ${overlays} variable

+

The ${overlays} U-Boot environment variable contains a space-separated list +of overlays that will be applied during boot. Depending on the boot source the +overlays have to either be placed in the boot partition of eMMC/SD-Card or are +loaded over tftp. Overlays set in the $KERNEL_DEVICETREE Yocto machine variable +will be automatically added to the boot partition of the final WIC image.

+

The ${overlays} variable can be either set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=imx8mm-phyboard-polis-rdk-peb-eval-01.dtbo imx8mm-phyboard-polis-peb-av-010.dtbo
+
+
+

Changes will take effect after the next reboot. If no bootenv.txt file is +available the overlays variable can be set directly in the U-Boot environment.

+
u-boot=> setenv overlays imx8mm-phyboard-polis-peb-av-010.dtbo
+u-boot=> printenv overlays
+overlays=imx8mm-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

If a user defined ${overlays} variable should be directly loaded from U-Boot +environment but there is still an external bootenv.txt available, the ${no_bootenv} +variable needs to be set as a flag:

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx8mm-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

More information about the external environment can be found in +U-boot External Environment subsection of the +device tree overlay section.

+

We use the ${overlays} variable for overlays describing expansion boards and +cameras that can not be detected during run time. To prevent applying overlays +listed in the ${overlays} variable during boot, the ${no_overlays} variable can +be set to 1 in the bootloader environment.

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+

6.2.2.2. Extension Command

+

The U-Boot extension command makes it possible to easily apply overlays that +have been detected and added to a list by the board code callback +extension_board_scan(). +Overlays applied this way disable components that are not populated on the SoM. +The detection is done with the EEPROM data (EEPROM SoM Detection) found on the +SoM i2c EEPROM.

+

It depends on the SoM variant if any device tree overlays will be applied. To check +if an overlay will be applied on the running SoM in U-Boot, run:

+
u-boot=> extension scan
+Found 1 extension board(s).
+u-boot=> extension list
+Extension 0: phyCORE-i.MX8MM no SPI flash
+        Manufacturer:           PHYTEC
+        Version:
+        Devicetree overlay:     imx8mm-phycore-no-spiflash.dtbo
+        Other information:      SPI flash not populated on SoM
+
+
+

If the EEPROM data is not available, no device tree overlays are applied.

+

To prevent running the extension command during boot the ${no_extensions} +variable can be set to 1 in the bootloader environment:

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot External Environment

+

During the start of the Linux Kernel the external environment bootenv.txt +text file will be loaded from the boot partition of an MMC device or via TFTP. +The main intention of this file is to store the ${overlays} variable. This makes +it easy to pre-define the overlays in Yocto depending on the used machine. The +content from the file is defined in the Yocto recipe bootenv found in +meta-phytec: +https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=kirkstone

+

Other variables can be set in this file, too. They will overwrite the existing +settings in the environment. But only variables evaluated after issuing the boot +command can be overwritten, such as ${nfsroot} or ${mmcargs}. Changing other +variables in that file will not have an effect. See the usage during netboot as +an example.

+

If the external environment can not be loaded the boot process will be anyway +continued with the values of the existing environment settings.

+
+
+

6.2.4. Change U-boot Environment from Linux on Target

+

Libubootenv is a tool included in our images to modify the U-Boot environment of +Linux on the target machine.

+

Print the U-Boot environment using the following command:

+
target:~$ fw_printenv
+
+
+

Modify a U-Boot environment variable using the following command:

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

Caution

+

Libubootenv takes the environment selected in a configuration file. The +environment to use is inserted there, and by default it is configured to use +the eMMC environment (known as the default used environment).

+

If the eMMC is not flashed or the eMMC environment is deleted, libubootenv +will not work. You should modify the /etc/fw_env.config file to match the +environment source that you want to use.

+
+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 8M Mini BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 8M Mini BSP Device Tree Concept to get an understanding +of our i.MX 8 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 8 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 8M Mini Pin Muxing

+

The i.MX 8M Mini SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 8M Mini terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 8M Mini Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx8mm-phyboard-polis-rdk.dts:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX     0x00
+                MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX      0x00
+                MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B  0x00
+                MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B  0x00
+        >;
+};
+
+
+

The first part of the string MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad (in this example +SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the desired muxing option for this pad. +The pad setting value (hex value on the right) defines different modes of the pad, for example, if +internal pull resistors are activated or not. In this case, the internal resistors are disabled.

+
+
+

7.2. RS232/RS485

+

The i.MX 8M Mini SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +bootmode switch (S1) needs to be set correctly:

+ + + + + + + +
Switch between UART1 RS485/RS232
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+

7.2.1. RS232

+
    +

  • Display the current settings of a terminal in a human-readable format:

    +
    target:~$ stty -a
+
    +
    +
    • +

  • Configuration of the UART interface can be done with stty. For example:

    +
    target:~$ stty -F /dev/ttymxc0 115200 crtscts raw -echo
+
    +
    +
    • +

  • With a simple echo and cat, basic communication can be tested. Example:

    +
    target:~$ echo 123 > /dev/ttymxc0
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

The host should print out “123”.

+
+
+

7.2.2. RS485

+
+

Hint

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

For easy testing, look at the linux-serial-test. This tool is called the IOCTL +for RS485 and sends a constant stream of data.

+
target:~$ linux-serial-test -p /dev/ttymxc0 -b 115200 --rs485 0
+
+
+

More information about the linux-serial-test tool and its parameters can be +found here: linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Documentation for calling the IOCTL within c-code is described in the Linux +kernel documentation: +https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see “test” printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final “count for this session”. There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+

The device tree representation for RS232 and RS485: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n291

+
+
+
+
+

7.3. Network

+

phyBOARD-Polis-i.MX 8M Mini provides one Gigabit Ethernet interface.

+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n59.

+

+
+

7.3.1. Network Environment Customization

+
+

7.3.1.1. U-boot network-environment

+
    +

  • To find the Ethernet settings in the target bootloader:

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • With your development host set to IP 192.168.3.10 and netmask 255.255.255.0, +the target should return:

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • If you need to make any changes:

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> should be one of ipaddr, netmask, gatewayip or serverip. +<value> will be the actual value of the chosen parameter.

    +
    • +

  • The changes you made are temporary for now. To save these:

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

Here you can also change the IP address to DHCP instead of using a static one.

+
    +

  • Configure:

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • Set up paths for TFTP and NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+

Tip

+

Variables like nfsroot and netargs can be overwritten by the U-boot External +Environment. For netboot, the external environment will be loaded from tftp. +For example, to locally set the nfsroot variable in a bootenv.txt file, +locate the tftproot directory:

+
nfsroot=/home/user/nfssrc
+
+
+

There is no need to store the info on the target. Please note that this does +not work for variables like ipaddr or serveraddr as they need to be already +set when the external environment is being loaded.

+
+
+
+

7.3.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. WLAN

+

For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. Connecting to a WLAN Network

+

First set the correct regulatory domain for your country:

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

You will see:

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

Set up the wireless interface:

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

Now you can scan for available networks:

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection.

+

To do so, add the network-credentials to the file /etc/wpa_supplicant.conf:

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

Now a connection can be established:

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

This should result in the following output:

+
...
+ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (kirkstone).

+

First, create the directory:

+
target:~$ mkdir -p /etc/systemd/network/
+
+
+

Then add the following configuration snippet in /etc/systemd/network/10-wlan0.network:

+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+

Now, restart the network daemon so that the configuration takes effect:

+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+
+

7.3.3. Bluetooth

+

Bluetooth is connected to UART2 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup.

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. Visibility

+

To activate visibility:

+
target:~$ hciconfig hci0 piscan
+
+
+

To disable visibility:

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. Connect

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

Note

+

If the connection fails with the error message: “Failed to connect: +org.bluez.Error.Failed” try restarting PulseAudio with:

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC Card

+

The i.MX 8M Mini supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n383

+

DT configuration for the eMMC interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n335

+
+
+

7.5. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 8M Mini is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw Multi-Level Cells (MLC) or Triple-Level +Cells (TLC) combined with a memory controller that handles ECC and wear +leveling. They are connected via an SD/MMC interface to the i.MX 8M Mini and are +represented as block devices in the Linux kernel like SD cards, flash drives, or +hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.5.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +or TLC. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background Operations +(BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • Enabling can be done with this command:

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.5.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 8M Mini SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.5.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
+
+

7.5.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC or TLC +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC used in NAND Flash, MLC or TLC have lower reliability and a higher +error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC or TLC +or mark these blocks as discard. The data on the device is lost and +will be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.5.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 8M Mini uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.5.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

The following table is for the offset of the i.MX 8M Mini SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 8M Mini

33 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.6. SPI Master

+

The i.MX 8M Mini controller has a FlexSPI and an ECSPI IP core included. The FlexSPI +host controller supports two SPI channels with up to 4 devices. Each channel +supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data +lines). The ECSPI controller supports 3 SPI interfaces with one dedicated chip +selected for each interface. As chip selects should be realized with GPIOs, more +than one device on each channel is possible.

+
+

7.6.1. SPI NOR Flash

+

phyCORE-i.MX 8M Mini is equipped with a QSPI NOR Flash which connects to the i.MX 8M Mini’s +FlexSPI interface. The QSPI NOR Flash is suitable for booting. Please see +different sections for flashing and bootmode setup. Due to limited space on the +SPI NOR Flash, only the bootloader is stored inside. By default, the kernel, +device tree, and rootfs are taken from eMMC.

+

The Bootloader does detect with the help of the EEPROM Introspection data if an +SPI flash is mounted or not. If no SPI flash is mounted a device tree overlay is +applied with the expansion command to disable the SPI flash device tree node +during boot. If no introspection data is available the SPI NOR flash node is +always enabled. Find more information in the device tree overlay section.

+

The bootloader also passes the SPI MTD partition table to Linux by fixing up the +device tree based on the mtdparts boot parameter. The default partition layout +in the BSP is set to:

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

This is a bootloader environment variable that is defined here and can be +changed during runtime. From Linux userspace, the NOR Flash partitions are +accessible via /dev/mtd<N> devices where <N> is the MTD device number associated +with the NOR flash partition to access. To find the correct MTD device number +for a partition, run on the target:

+
root@phyboard-polis-imx8mm-5:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

It lists all MTD devices and the corresponding partition names. The flash node +is defined inside of the SPI master node in the module DTS. The SPI node +contains all devices connected to this SPI bus which is in this case only the +SPI NOR Flash.

+

The definition of the SPI master node in the device tree can be found here:

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n87

+
+
+
+

7.7. GPIOs

+

The phyBOARD-Polis has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to i.MX 8M Mini pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal i.MX 8M Mini GPIO banks GPIO1 – GPIO5.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO5_07). <X> identifies the GPIO +bank and counts from 1 to 5, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 20 from chip0):

    +
    target:~$ gpioget gpiochip0 20
+
    +
    +
    • +

  • Set the value of GPIO 20 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset --mode=exit gpiochip0 20=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.7.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the defconfig you use in +arch/arm64/configs/ in the linux kernel sources. For our NXP based releases, +this could be for example imx8_phytec_distro.config:

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+

Pinmuxing of some GPIO pins in the device tree imx8mm-phyboard-polis-rdk.dts:

+
pinctrl_leds: leds1grp {
+        fsl,pins = <
+                MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1       0x16
+                MX8MM_IOMUXC_GPIO1_IO14_GPIO1_IO14      0x16
+                MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x16
+        >;
+};
+
+
+
+
+
+

7.8. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the phyBOARD-Polis.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n36

+
+
+

7.9. I²C Bus

+

The i.MX 8M Mini contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 8M Mini. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our phyBOARD-Polis.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C1 bus configuration (e.g. imx8mm-phycore-som.dtsi): +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n119

+

General I²C4 bus configuration (e.g. imx8mm-phyboard-polis-rdk.dts): +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n244

+
+
+

7.10. EEPROM

+

On the phyCORE-i.MX8MM there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues.

+
+

7.10.1. I2C EEPROM on phyCORE-i.MX8MM

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

The I2C EEPROM on the phyCORE-i.MX8MM SoM is connected to I2C address 0x51 on the I2C-0 +bus. It is possible to read and write directly to the device populated:

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the 4KiB EEPROM (bus: I2C-0 addr: 0x51) with zeros leaving out the EEPROM data use:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM Detection

+

The I2C EEPROM, populated on the phyCORE-i.MX8MM, has a separate ID page that is +addressable over I2C address 0x59 on bus 0 and a normal area that is addressable +over I2C address 0x51 on bus 0. PHYTEC uses this data area of 32 Bytes to store +information about the SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the EEPROM ID page data and the first 256 bytes of the normal area are +deleted, the bootloader will fall back to the phyCORE-i.MX8MM Kit RAM setup, which +is 2GiB RAM.

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

SoMs that are flashed with data format API revision 2 will print out information +about the module in the early stage.

+
+
+

7.10.3. Rescue EEPROM Data

+

The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area.

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1
+
+
+
+

Note

+

If you deleted both EEPROM spaces, please contact our support!

+
+

DT representation, e.g. in phyCORE-i.MX 8M Mini file imx8mm-phycore-som.dtsi can be +found in our PHYTEC git: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n311

+
+
+
+

7.11. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC Wakealarm

+

It is possible to issue an interrupt from the RTC to wake up the system. The +format uses the Unix epoch time, which is the number of seconds since UTC +midnight on 1 January 1970. To wake up the system after 4 minutes from suspend +to ram state, type:

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

Note

+

Internally the wake alarm time will be rounded up to the next minute since +the alarm function doesn’t support seconds.

+
+
+
+

7.11.2. RTC Parameters

+

RTCs have a few abilities which can be read/set with the help of hwclock +tool.

+
    +

  • We can check RTC supported features with:

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x11.
+
    +
    +

    What this value means is encoded in kernel, each set bit translates to:

    +
    #define RTC_FEATURE_ALARM              0
+#define RTC_FEATURE_ALARM_RES_MINUTE   1
+#define RTC_FEATURE_NEED_WEEK_DAY      2
+#define RTC_FEATURE_ALARM_RES_2S       3
+#define RTC_FEATURE_UPDATE_INTERRUPT   4
+#define RTC_FEATURE_CORRECTION         5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE 6
+#define RTC_FEATURE_CNT                7
+
    +
    +
    • +

  • We can check RTC BSM (Backup Switchover Mode) with:

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • We can set RTC BSM with:

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    What BSM values mean translates to these values:

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    Tip

    +

    You should set BSM mode to DSM or LSM for RTC to switch to backup power +source when the initial power source is not available. Check RV-3028 RTC +datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching +Mode) actually mean.

    +
    +
    • +
+

DT representation for I²C RTCs: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n319

+
+
+
+

7.12. USB Host Controller

+

The USB controller of the i.MX 8M Mini SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +‘HS’). The USB subsystem has two independent USB controller cores. Both cores +are On-The-Go (OTG) controller cores and are capable of acting as a USB +peripheral device or a USB host. Each is connected to a USB 2.0 PHY.

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+

User USB2 (host) configuration is in the kernel device tree +imx8mm-phyboard-polis-rdk.dts:

+
&usbotg2 {
+        dr_mode = "host";
+        picophy,pre-emp-curr-control = <3>;
+        picophy,dc-vol-level-adjust = <7>;
+        status = "okay";
+};
+
+
+

DT representation for USB Host: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n347

+
+
+

7.13. USB OTG

+

Most PHYTEC boards provide a USB OTG interface. USB OTG ports automatically act +as a USB device or USB host. The mode depends on the USB hardware attached to +the USB OTG port. If, for example, a USB mass storage device is attached to the +USB OTG port, the device will show up as /dev/sda.

+
+

7.13.1. USB Device

+

In order to connect the board’s USB device to a USB host port (for example a +PC), you need to configure the appropriate USB gadget. With USB configfs you can +define the parameters and functions of the USB gadget. The BSP includes +USB configfs support as a kernel module.

+
target:~$ modprobe libcomposite
+
+
+

Example:

+
    +

  • First, define the parameters such as the USB vendor and product IDs, and set +the information strings for the English (0x409) language:

    • +
+
+

Hint

+

To save time, copy these commands and execute them in a script

+
+
cd /sys/kernel/config/usb_gadget/
+mkdir g1
+cd g1/
+echo "0x1d6b" > idVendor
+echo "0x0104" > idProduct
+mkdir strings/0x409
+echo "0123456789" > strings/0x409/serialnumber
+echo "Foo Inc." > strings/0x409/manufacturer
+echo "Bar Gadget" > strings/0x409/product
+
+
+
    +

  • Next, create a file for the mass storage gadget:

    • +
+
target:~$ dd if=/dev/zero of=/tmp/file.img bs=1M count=64
+
+
+
    +

  • Now you should create the functions you want to use:

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir functions/acm.GS0
+mkdir functions/ecm.usb0
+mkdir functions/mass_storage.0
+echo /tmp/file.img > functions/mass_storage.0/lun.0/file
+
+
+
    +

  • acm: Serial gadget, creates serial interface like /dev/ttyGS0.

    • +

  • ecm: Ethernet gadget, creates ethernet interface, e.g. usb0

    • +

  • mass_storage: The host can partition, format, and mount the gadget mass +storage the same way as any other USB mass storage.

    • +
+
    +

  • Bind the defined functions to a configuration:

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir configs/c.1
+mkdir configs/c.1/strings/0x409
+echo "CDC ACM+ECM+MS" > configs/c.1/strings/0x409/configuration
+ln -s functions/acm.GS0 configs/c.1/
+ln -s functions/ecm.usb0 configs/c.1/
+ln -s functions/mass_storage.0 configs/c.1/
+
+
+
    +

  • Finally, start the USB gadget with the following commands:

    • +
+
target:~$ cd /sys/kernel/config/usb_gadget/g1
+target:~$ ls /sys/class/udc/
+ci_hdrc.0
+target:~$ echo "ci_hdrc.0" >UDC
+
+
+

If your system has more than one USB Device or OTG port, you can pass the right +one to the USB Device Controller (UDC).

+
    +

  • To stop the USB gadget and unbind the used functions, execute:

    • +
+
target:~$ echo "" > /sys/kernel/config/usb_gadget/g1/UDC
+
+
+

Both USB interfaces are configured as host in the kernel device tree +imx8mm-phyboard-polis-rdk.dts. See: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n335

+
+
+
+

7.14. CAN FD

+

The phyBOARD-Polis has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
+

Hint

+

phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. +There are different interfaces involved, which limits the datarate +capabilities of CANFD.

+
+
+

Hint

+

On phyBOARD-Polis-i.MX8MM a terminating resistor can be enabled by setting +S5 to ON if required.

+
+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The two CAN interfaces should show up as +can0 and can1.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    The information for can0 will look like:

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+
+

Warning

+

The mcp2518fd SPI to CANfd supports only baudrates starting from 125kB/s. +Slower rates can be selected but may not work correctly.

+
+

Device Tree CAN configuration of imx8mm-phyboard-polis-rdk.dts: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n175

+
+
+

7.15. PCIe

+

The phyCORE-i.MX 8M Mini has one Mini-PCIe slot. In general, PCIe autodetects new +devices on the bus. After connecting the device and booting up the system, you +can use the command lspci to see all PCIe devices recognized.

+
    +

  • Type:

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • You will receive:

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

In this example, the PCIe device is the Intel Corporation WiFi Link 5100.

+

For PCIe devices, you have to enable the correct driver in the kernel +configuration. This WLAN card, for example, is manufactured by Intel. The +option for the driver, which must be enabled, is named CONFIG_IWLWIFI and can be +found under Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimat in +the kernel configuration.

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • The linux-imx is represented by: virtual/kernel

      • +
    +
    • +
+

For some devices like the WLAN card, additional binary firmware blobs are +needed. These firmware blobs have to be placed in /lib/firmware/ before the +device can be used.

+
    +

  • Type:

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • For example, if you try to bring up the network interface:

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • You will get the following output on the serial console:

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

Tip

+

Some PCIe devices, e.g. the Ethernet card, may function properly even if no +firmware blob is loaded from /lib/firmware/ and you received an error message +as shown in the first line of the output above. This is because some +manufacturers provide the firmware as a fallback on the card itself. In this +case, the behavior and output depend strongly on the manufacturer’s firmware.

+
+
+
+

7.16. Audio

+

The PEB-AV-10-Connector exists in two versions and the 1531.1 version is +populated with a TI TLV320AIC3007 audio codec. Audio support is done via the I2S +interface and controlled via I2C.

+

There is a 3.5mm headset jack with OMTP standard and an 8-pin header to connect +audio devices with the AV-Connector. The 8-pin header contains a mono speaker, +headphones, and line-in signals.

+

To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices:

+
target:~$ aplay -L
+
+
+

Or type for recording devices:

+
target:~$ arecord -L
+
+
+
+

7.16.1. Alsamixer

+

To inspect the capabilities of your soundcard, call:

+
target:~$ alsamixer
+
+
+

You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. “MM” means the feature is muted +(both output, left & right), which can be toggled by hitting ‘m’. You can also +toggle by hitting ‘<’ for left and ‘>’ for right output. With the tab +key, you can switch between controls for playback and recording.

+
+
+

7.16.2. Restore default volumes

+

There are some default settings stored in /var/lib/alsa/asound.state. +You can save your current alsa settings with:

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

You can restore saved alsa settings with:

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.16.3. ALSA configuration

+

Our BSP comes with a ALSA configuration file /etc/asound.conf.

+

The ALSA configuration file can be edited as desired or deleted since it is not +required for ALSA to work properly.

+
target:~$ vi /etc/asound.conf
+
+
+

To set PEB-AV-10 as output, set playback.pcm from “dummy” to “pebav10”:

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

If the sound is not audible change playback devices to the software volume control +playback devices, set playback.pcm to the respective softvol playback device e.g. +“softvol_pebav10”. Use alsamixer controls to vary the volume levels.

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.16.4. Pulseaudio Configuration

+

For applications using Pulseaudio, check for available sinks:

+
target:~$ pactl list short sinks
+
+
+

To select the output device, type:

+
target:~$ pactl set-default-sink <sink_number>
+
+
+
+
+

7.16.5. Playback

+

Run speaker-test to check playback availability:

+
target:~$ speaker-test -c 2 -t wav
+
+
+

To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds:

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

To playback other formats like mp3 for example, you can use Gstreamer:

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.16.6. Capture

+

arecord is a command-line tool for capturing audio streams which use Line In as +the default input source. To select a different audio source you can +use alsamixer. For example, switch on Right PGA Mixer Mic3R and Left PGA Mixer +Mic3R in order to capture the audio from the microphone input of the +TLV320-Codec using the 3.5mm jack.

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

Hint

+

Since playback and capture share hardware interfaces, it is not possible to +use different sampling rates and formats for simultaneous playback and +capture operations.

+
+

Device Tree Audio configuration: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mm-phyboard-polis-peb-av-010.dtsi?h=v5.15.71_2.2.2-phy3#n54

+
+
+
+

7.17. Video

+
+

7.17.1. Videos with Gstreamer

+

One example video is installed by default in the BSP at /usr/share/qtphy/videos/. +Start the video playback with one of these commands:

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.18. Display

+

The 10” Display is always active. If the PEB-AV-Connector is not connected, an +error message may occur at boot.

+
+

7.18.1. Qt Demo

+

With the phytec-qt6demo-image, Weston starts during boot. Our Qt6 demo application named +“qtphy” can be stopped with:

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • To start the demo again, run:

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • To disable autostart of the demo, run:

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • To enable autostart of the demo, run:

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston can be stopped with:

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

Note

+

The Qt demo must be closed before Weston can be closed.

+
+
+
+

7.18.2. Backlight Control

+

If a display is connected to the PHYTEC board, you can control its backlight +with the Linux kernel sysfs interface. All available backlight devices in the +system can be found in the folder /sys/class/backlight. Reading the appropriate +files and writing to them allows you to control the backlight.

+
+

Note

+

Some boards with multiple display connectors might have multiple backlight +controls in /sys/class/backlight. For example: backlight0 and backlight1

+
+
    +

  • To get, for example, the maximum brightness level (max_brightness) execute:

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    Valid brightness values are 0 to <max_brightness>.

    +
    • +

  • To obtain the current brightness level, type:

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • Write to the file brightness to change the brightness:

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    turns the backlight off for example.

    +

    For documentation of all files, see +https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight.

    +
    • +
+

The device tree of PEB-AV-10 can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mm-phyboard-polis-peb-av-010.dtsi?h=v5.15.71_2.2.2-phy3

+
+
+
+

7.19. Power Management

+
+

7.19.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 8M Mini SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as ‘Dynamic Voltage and +Frequency Scaling’ (DVFS). The i.MX 8M Mini BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the i.MX 8 +variant used, several different frequencies are supported.

+
+

Tip

+

Although the DVFS framework provides frequency settings for each CPU core, a +change in the frequency settings of one CPU core always affects all other CPU +cores too. So all CPU cores always share the same DVFS setting. An individual +DVFS setting for each core is not possible.

+
+
    +

  • To get a complete list type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately +1,6 GHz, the result will be:

    +
    1200000 1600000
+
    +
    +
    • +

  • To ask for the current frequency type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

So-called governors are automatically selecting one of these frequencies in +accordance with their goals.

+
    +

  • List all governors available with the following command:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    The result will be:

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative is much like the ondemand governor. It differs in behavior in +that it gracefully increases and decreases the CPU speed rather than jumping +to max speed the moment there is any load on the CPU.

    • +

  • ondemand (default) switches between possible CPU core frequencies in +reference to the current system load. When the system load increases above a +specific limit, it increases the CPU core frequency immediately.

    • +

  • powersave always selects the lowest possible CPU core frequency.

    • +

  • performance always selects the highest possible CPU core frequency.

    • +

  • userspace allows the user or userspace program running as root to set a +specific frequency (e.g. to 1600000). Type:

    • +

  • In order to ask for the current governor, type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    You will normally get:

    +
    ondemand
+
    +
    +
    • +

  • Switching over to another governor (e.g. userspace) is done with:

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • Now you can set the speed:

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +Documentation/admin-guide/pm/cpufreq.rst.

+
+
+

7.19.2. CPU Core Management

+

The i.MX 8M Mini SoC can have multiple processor cores on the die. The i.MX 8M Mini, for +example, has 4 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    Here the system has four processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.19.3. Suspend to RAM

+

The phyCORE-i.MX8MM supports basic suspend and resume. Different wake-up sources can be +used. Suspend/resume is possible with:

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

To wake up with serial console run

+
target:~$ echo enabled > /sys/class/tty/ttymxc2/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.20. Thermal Management

+
+

7.20.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.20.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 8M Mini SoC platform. The i.MX 8 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Industrial +and Commercial.

+ + + + + + + + + + + + + + + + + +

Commercial

Industrial

passive (warning)

85°C

95°C

critical (shutdown)

90°C

100°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise, Fair Share, Bang Bang, and +Userspace. The default policy used in the BSP is step_wise. If the value of the +SoC temperature in the sysfs file temp is above trip_point_0, the CPU frequency +is set to the lowest CPU frequency. When the SoC temperature drops below +trip_point_0 again, the throttling is released.

+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+

7.20.3. GPIO Fan

+
+

Note

+

Only GPIO fan supported.

+
+

A GPIO fan can be connected to the phyBOARD-Polis-i.MX 8M Mini. The SoC only contains one +temperature sensor which is already used by the thermal frequency scaling. The +fan can not be controlled by the kernel. We use lmsensors with hwmon for this +instead. lmsensors reads the temperature periodically and enables or disables +the fan at a configurable threshold. For the phyBOARD-Polis-i.MX 8M Mini, this is 60°C.

+

The settings can be configured in the configuration file:

+
/etc/fancontrol
+
+
+

Fan control is started by a systemd service during boot. This can be disabled +with:

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.21. Watchdog

+

The PHYTEC i.MX 8M Mini modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.21.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.22. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 8M Mini provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 8M Mini Reference Manual). The following list is +an abstract from the i.MX 8M Mini Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x30350000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x30350000

Description

OCOTP_MAC_ADDR0

9

0

0x640

contains lower 32 bits +of ENET0 MAC address

OCOTP_MAC_ADDR1

9

1

0x650

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

OCOTP_MAC_ADDR2

9

2

0x660

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 8M Mini Security Reference Manual.

+
+

7.22.1. Reading Fuse Values in uBoot

+

You can read the content of a fuse using memory-mapped shadow registers. To +calculate the memory address, use the fuse Bank and Word in the following +formula:

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.22.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+
+

8. i.MX 8M Mini M4 Core

+

In addition to the Cortex-A53 cores, there is a Cortex-M4 Core as MCU +integrated into the i.MX 8M Mini SoC. Our Yocto-Linux-BSP runs on the A53-Cores and +the M4 Core can be used as a secondary core for additional tasks using +bare-metal or RTOS firmware. +Both cores have access to the same peripherals and thus peripheral +usage needs to be limited either in the M4 Core’s firmware or the devicetree +for the Linux operating system. This section describes how to build firmware +examples and how to run them on phyBOARD-Polis.

+

The phyBOARD-Polis is currently supported by the NXP MCUXpresso SDK and by +The Zephyr Project. This section only describes the NXP MCUXpresso SDK because +the MCUXpresso SDK has more supported features at the moment.

+

If you want to use the M4 Core with The Zephyr Project, please refer to the +The Zephyr Project documentation:

+ +
+

8.1. Getting the Firmware Examples

+

The firmware can be built using the NXP MCUxpresso SDK with a compatible +compiler toolchain using command-line tools.

+
+

8.1.1. Getting the Sources

+

The MCUX SDK and the examples for the i.MX 8M Mini can be obtained from PHYTEC’s GitHub +page:

+ +
    +

  1. Initialize the MCUX SDK via west:

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    This will create a mcuxsdk directory with the mcux-sdk repository in it. +The mcux-sdk-phytec-examples repository will be automatically cloned into +the mcuxsdk directory. +The given argument <VERSION> is a the branch name of the mcux-sdk repository +that represents the MCUX SDK version. For the newest tested version +you can use 2.13.0.

    +
    +

    Note

    +

    west is a repository management tool and a part of the Zephyr +Project. +To install west, you can use pip. In this example west is installed in +a python virtual environment:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. Update the dependencies:

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    The directory examples-phytec contains all examples ported and tested +for phyBOARD-Polis with version 2.13.0 of MCUX.

    +

    To build the firmware, a compiler toolchain and make/cmake are required. +The GNU Arm Embedded Toolchain may be available in your distribution’s +repositories, e.g. for Ubuntu.

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    The compiler toolchain can also be obtained directly from +https://developer.arm.com/. After the archive has been extracted, +the ARMGCC_DIR has to be added to the environment, e.g. for the +ARM toolchain 10-2020-q4-major release located in the home directory:

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. Building the Firmware

+

To build the PHYTEC samples an environment has to be sourced

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

The scripts to build the firmware are located in +<sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc. +There are scripts for each memory location the firmware is supposed to run in, +e.g.

+
host:~$ ./build_release.sh
+
+
+

to build the firmware for the M4 Core’s TCM. The output will be placed under +release/ in the armgcc directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+

To build the firmware for the DRAM, run the script build_ddr_release. +The script of the firmware that is supposed to run, e.g.

+
host:~$ ./build_ddr_release.sh
+
+
+

The output will be placed under ddr_release/ in the armgcc +directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+
+
+
+

8.2. Running M4 Core Examples

+

There are two ways to run the M4 Core with the built firmware, U-Boot and +Remoteproc within a running Linux.

+

To receive debug messages start your favorite terminal software (e.g. Minicom, +Tio, or Tera Term) on your host PC and configure it for 115200 baud, 8 data +bits, no parity, and 1 stop bit (8n1) with no handshake.

+

Once a micro-USB cable is connected to the USB-debug port on the phyBOARD-Polis, two +ttyUSB devices are registered. One prints messages from A53-Core’s debug UART +and the other one from the M4 Core’s debug UART.

+
+

8.2.1. Running Examples from U-Boot

+

To load firmware using the bootloader U-Boot, the bootaux command can be used:

+
    +

  1. Prepare an SD Card with our Yocto-BSP

    2. +

  2. Copy the generated .bin file to the SD Cards first partition

    3. +

  3. Stop the autoboot by pressing any key

    4. +

  4. Type the command depending on the type of firmware:

    5. +
+

For firmware built to run in the M4 Core’s TCM:

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

For firmware built to run in the DRAM:

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

The program’s output should appear on the M4 Core’s debug UART.

+
+
+

8.2.2. Running Examples from Linux using Remoteproc

+

Remoteproc is a module that allows you to control the M4 Core from Linux +during runtime. Firmware built for TCM can be loaded and the execution started +or stopped. To use Remoteproc a devicetree overlay needs to be set:

+

Edit the bootenv.txt file located in the /boot directory on the target by +adding imx8mm-phycore-rpmsg.dtbo:

+
overlays=imx8mm-phycore-rpmsg.dtbo
+
+
+

Restart the target and execute in U-Boot:

+
u-boot=> run prepare_mcore
+
+
+

Firmware .elf files for the M4 Core can be found under /lib/firmware. +To load the firmware, type:

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

To load a different firmware, the M4 Core needs to be stopped:

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

Note

+

The samples found in /lib/firmware on the target come from NXP’s +Yocto layer meta-imx. +To use the samples you built yourself through MCUX SDK, please copy them +to /lib/firmware on the target after building them.

+
+
+ +
+
+
+

9. BSP Extensions

+
+

9.1. Chromium

+

Our BSP for the phyBOARD-Polis-i.MX 8M Mini supports Chromium. You can include it in the +phytec-qt6demo-image with only a few steps.

+
+

9.1.1. Adding Chromium to Your local.conf

+

To include Chromium you have to add the following line into your local.conf. You +can find it in <yocto_dir>/build/conf/local.conf. This adds Chromium to your +next image build.

+
IMAGE_INSTALL:append = " chromium-ozone-wayland"
+
+
+
+

Note

+

Compiling Chromium takes a long time.

+
+
+
+

9.1.2. Get Chromium Running on the Target

+

To run Chromium, it needs a few arguments to use the hardware graphics +acceleration:

+
target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox
+
+
+

If you want to start Chromium via SSH, you must first define the display on +which Chromium will run. For example:

+
target$ DISPLAY=:0
+
+
+

After you have defined this, you can start it via virtual terminal on Weston as +shown above.

+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mn/head.html b/previews/271/bsp/imx8/imx8mn/head.html new file mode 100644 index 000000000..564c19678 --- /dev/null +++ b/previews/271/bsp/imx8/imx8mn/head.html @@ -0,0 +1,4087 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + + + + +

L-1002e.Ax i.MX 8M Nano BSP +Manual Head

Document Title

L-1002e.Ax i.MX 8M Nano BSP +Manual Head

Document Type

BSP Manual

Article Number

L-1002e.Ax

Yocto Manual

Release Date

XXXX/XX/XX

Is Branch of

L-1002e.Ax i.MX 8M Nano BSP +Manual Head

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +phyCORE-i.MX8M Nano Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads of our product.

+
+

1.1. Supported Hardware

+

The phyBOARD-Polis populated with the i.MX 8M Nano SoC is supported.

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-NXP-i.MX8MM-PD23.1.0 download. +If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware

+
+

1.1.1. phyBOARD-Polis Components

+ + + + + + +
+../../../_images/polis-front.jpg +
+

phyBOARD-Polis Components (top)

+
+
+
+../../../_images/polis-back.jpg + +
+

phyBOARD-Polis Components (bottom)

+
+
+
+
+
+
+
+

2. Getting Started

+

The phyCORE-i.MX8M Nano Kit is shipped with a pre-flashed SD card. It contains the +phytec-headless-image and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+

There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool dd. An +alternative way is to use PHYTEC’s system initialization program called +partup, which makes it especially easy to +format more complex systems. You can get prebuilt Linux binaries of partup from its release page. Also read +partup’s README for installation +instructions.

+
+

2.1. Get the Image

+

The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using dd, can be downloaded from the PHYTEC download server.

+

Get either the partup package or the WIC image from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.wic
+
+
+
+

Note

+

For eMMC, more complex partitioning schemes or even just large images, we +recommend using the partup package, as it is faster in writing than dd +and allows for a more flexible configuration of the target flash device.

+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card, you must have root privileges on your Linux +host PC. Be very careful when specifying the destination device! All files +on the selected device will be erased immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system on your host PC!

+
+
+

2.2.1. Finding the Correct Device

+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+

Unmount all those partitions, e.g.:

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

Now, the SD card is ready to be flashed with an image, using either partup, +dd or bmap-tools.

+
+
+

2.2.2. Using bmap-tools

+

One way to prepare an SD card is using +bmap-tools. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host:~$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host:~$ bmaptool copy phytec-headless-image-phyboard-polis-imx8mn-2?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

Replace <your_device> with your actual SD card’s device name found previously, +and make sure to place the file <IMAGENAME>-<MACHINE>.wic.bmap alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip.

+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.2.3. Using partup

+

Writing to an SD card with partup is done in a single command:

+
host:~$ sudo partup install phytec-headless-image-phyboard-polis-imx8mn-2?(.rootfs).partup /dev/<your_device>
+
+
+

Make sure to replace <your_device> with your actual device name found previously.

+

Further usage of partup is explained at its official documentation website.

+
+

Warning

+

Host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to write partup packages created with Yocto Mickledore +or newer to SD-Card. This is due to a new default option in resize2fs which causes an +incompatibility. See release notes.

+
+
+

Note

+

partup has the advantage of allowing to clear specific raw areas in the +MMC user area, which is used in our provided partup packages to erase any +existing U-Boot environments. This is a known issue bmaptool does not +solve, as mentioned in the previous chapter.

+

Another key advantage of partup over other flashing tools is that it allows +configuring MMC specific parts, like writing to eMMC boot partitions, without +the need to call multiple other commands when writing.

+
+
+
+

2.2.4. Using dd

+

After having unmounted all SD card’s partitions, you can create your bootable SD card.

+

Some PHYTEC BSPs produce uncompressed images (with filename-extension *.wic), +and some others produce compressed images (with filename-extension *.wic.xz).

+

To flash an uncompressed images (*.wic) use command below:

+
host:~$ sudo dd if=phytec-headless-image-phyboard-polis-imx8mn-2?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Or to flash a compressed images (*.wic.xz) use that command:

+
host:~$ xzcat phytec-headless-image-phyboard-polis-imx8mn-2?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Again, make sure to replace <your_device> with your actual device name found +previously.

+

The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

+
+
+
+

2.3. First Start-up

+ + + + + + + +
Bootmode Selection
+../../../_images/Nano_SD_BOOT.jpg + +
+

SD Card Boot

+
+
+
+
    +

  • Insert the SD card

    • +

  • Connect the target and the host with mirco USB on (X30) +debug USB

    • +

  • Power up the board

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 8M Nano BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (kirkstone).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (kirkstone).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-IMX8MM; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-vendor MACHINE=phyboard-polis-imx8mn-2 ./phyLinux init -p imx8mn -r BSP-Yocto-NXP-i.MX8MM-PD23.1.0
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the phyboard-polis-imx8mn-2 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx8mn.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, +lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY firmware images

    • +

  • imx-boot: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM +Trusted Firmware and DDR firmware. This is the final bootloader image which is +bootable.

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx8mn-phyboard-polis*.dtb: Kernel device tree file

    • +

  • imx8mn-phy*.dtbo: Kernel device tree overlay files

    • +

  • phytec-headless-image*.tar.gz: Root file system

    • +

  • phytec-headless-image*.rootfs.wic.xz: compressed SD card image

    • +
+
+
+
+
+

4. Installing the OS

+
+

4.1. Bootmode Switch (S1)

+

The phyBOARD-Polis features a boot switch with six individually switchable ports to +select the phyCORE-i.MX 8M Nano default bootsource.

+

Hardware revision baseboard: 1532.2 and newer

+ + + + + + + + + + + + + +
Bootmode Selection
+../../../_images/Nano_eMMC_BOOT.png + +
+

eMMC (Default SoM boot)

+
+
+
+../../../_images/Nano_Serial_downloader_BOOT.png + +
+

USB Serial Downloader

+
+
+
+../../../_images/Nano_SD_BOOT.jpg + +
+

SD Card

+
+
+
+../../../_images/Nano_Fuse_BOOT.png + +
+

Internal Fuses

+
+
+
+../../../_images/Nano_QSPI_BOOT.png + +
+

SPI NOR

+
+
+

+ + + + + + + +
Switch between USB HOST/OTG using Pos5 of switch(S1)
+../../../_images/USB_HOST.jpg + +
+

USB HOST

+
+
+
+../../../_images/USB_OTG.png + +
+

USB OTG

+
+
+
+ + + + + + + +
Switch between UART1 RS485/RS232 using Pos4 of switch(S1)
+../../../_images/UART1_RS4851.png + +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS2321.jpg + +
+

UART1 RS232

+
+
+
+
+
+

4.2. Flash eMMC

+

For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see Setup Network Host.

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S1) is set to eMMC.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk2p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from Network

+

i.MX 8M Nano boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

4.2.1.1. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Show your available image files on the host:

+
host:~$ ls /srv/tftp
+phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.xz
+phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.bmap
+
+
+

Send the image with the bmaptool command combined with ssh through the network +to the eMMC of your device:

+
host:~$ scp /srv/tftp/phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.xz /dev/mmcblk2"
+
+
+
+
+

4.2.1.2. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Take a compressed or decompressed image with the accompanying block map file +*.bmap on the host and send it with ssh through the network to the eMMC of +the target with a one-line command:

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.* /tmp && bmaptool copy /tmp/phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.xz /dev/mmcblk2
+
+
+
+
+

4.2.1.3. Flash eMMC from Network in U-Boot on Target

+

These steps will show how to update the eMMC via a network.

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE.

+
+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Uncompress your image

+
host:~$ unxz /srv/tftp/phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.xz
+
+
+

Load your image via network to RAM:

+
    +

  • when using dhcp

    +
    u-boot=> dhcp phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.1 (1 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.1
+Filename 'phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • when using a static ip address (serverip and ipaddr must be set +additionally).

    +
    u-boot=> tftp ${loadaddr} phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
+
+
+
+
+

4.2.2. Flash eMMC U-Boot image via Network from running U-Boot

+

Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.3. Flash eMMC from USB stick

+
+

4.2.3.1. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-headless-image-phyboard-polis-imx8mn-2.|yocto-imageext|). Set the bootmode switch (S1) to SD Card.

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ ls /mnt
+phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.xz
+phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Nano eMMC (MMC device 2 without partition):

    +
    target:~$ bmaptool copy /mnt/phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.xz /dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Tip

    +

    Before this will work, you need to configure the bootmode switch (S1) to +eMMC.

    +
    +
    • +
+
+
+

4.2.3.2. Flash eMMC from USB stick in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE.

+
+

These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch (S1) to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied uncompressed WIC image to +the USB slot.

+

Load your image from the USB device to RAM:

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 0x58000000 phytec-headless-image-|yocto-machinename|.rootfs.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write 0x58000000 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+
+

4.2.4. Flash eMMC from SD Card

+

Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (*.wic) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see Resizing ext4 Root Filesystem.

+

Alternatively, flash a partup package to the SD card, as described in +Getting Started. This will ensure the full space of the SD card is used.

+
+

4.2.4.1. Flash eMMC from SD card in Linux on Target

+

You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card.

+
    +

  • Show your saved partup package or WIC image files on the SD card:

    +
    target:~$ ls
+phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.partup
+phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.xz
+phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Nano eMMC (MMC device 2 without +partition) using partup:

    +
    target:~$ partup install phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.partup /dev/mmcblk2
+
    +
    +

    Flashing the partup package has the advantage of using the full capacity of +the eMMC device, adjusting partitions accordingly.

    +
    +

    Note

    +

    Alternatively, bmaptool may be used instead:

    +
    target:~$ bmaptool copy phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.xz /dev/mmcblk2
+
    +
    +

    Keep in mind that the root partition does not make use of the full space when +flashing with bmaptool.

    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Warning

    +

    Before this will work, you need to configure the bootmode switch (S1) to eMMC.

    +
    +
    • +
+
+
+

4.2.4.2. Flash eMMC from SD card in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE. If the +image file is too large use the Updating eMMC from SD card in +Linux on Target subsection.

+
+
    +

  • Flash an SD card with a working image and create a third ext4 partition. Copy +the WIC image (for example phytec-headless-image.rootfs.wic) to this +partition.

    • +

  • Configure the bootmode switch (S1) to SD Card and insert the SD Card.

    • +

  • Power on the board and stop in U-Boot.

    • +

  • Load the image:

    +
    u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • Switch the mmc dev to eMMC:

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • Flash your WIC image (for example phytec-headless-image.rootfs.wic) +from the SD card to eMMC. This will partition the card and copy imx-boot, +Image, dtb, dtbo, and root file system to eMMC.

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • Power off the board and change the bootmode switch (S1) to eMMC.

    • +
+
+
+
+
+

4.3. Flash SPI NOR Flash

+

The phyCORE-i.MX8MN modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set bootmode switch (S1) to SPI NOR. The SPI Flash is usually quite small. +The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash populated. Only the +bootloader and the environment can be stored. The kernel, device tree, and file +system are taken from eMMC by default.

+

The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with:

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. Flash SPI NOR Flash from Network

+

The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-i.MX 8M Nano.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+
+

4.3.1.1. Flash SPI NOR from Network in kernel on Target

+
    +

  • Copy the image from the host to the target:

    +
    host:~$ scp imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • Find the number of blocks to erase of the U-boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the U-Boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.1.2. Flash SPI NOR from Network in U-Boot on Target

+

Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI NOR flash needs to be probed:

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • A specially formatted U-Boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image over tftp, erase and write the +bootloader to the flash:

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+

4.3.2. Flash SPI NOR Flash from SD Card

+

The bootloader on SPI NOR flash can be also flashed with SD Card.

+
+

4.3.2.1. Flash SPI NOR from SD Card in kernel on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi to the first partition +on the SD Card.

    • +

  • Mount the SD Card:

    +
    target:~$ mount /dev/mmcblk1p1 /mnt
+
    +
    +
    • +

  • Find the number of blocks to erase of the U-Boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the u-boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.2.2. Flash SPI NOR from SD Card in U-Boot on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi to the first partition +on the SD Card.

    • +

  • Before reading and writing are possible, the SPI-NOR flash +needs to be probed:

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • A specially formatted U-boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image from the SD Card, erase and write +the bootloader to the flash:

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A6 RAUC Update & Device Management Manual.

+
+
+
+

5. Development

+
+

5.1. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.1.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.2. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.2.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel image to your tftp directory:

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • Copy the devicetree to your tftp directory:

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • Copy all the overlays you want to use into your tftp directory:

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-headless-image-phyboard-polis-imx8mn-2.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.2.2. Set the bootenv.txt for Netboot

+

Create a bootenv.txt file in your tftp directory and write the following variables into it.

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> has to be replaced with the devicetree overlay filenames that you want to use. +Separate the filenames by spaces. For example:

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

Tip

+

All supported devicetree overlays are in the device tree chapter.

+
+
+
+

5.2.3. Network Settings on Target

+

To customize the targets ethernet configuration, please follow the description +here: Network Environment Customization

+
+
+

5.2.4. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.3.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy-ampliphy-vendor/images/phyboard-polis-imx8mn-2/. For flashing a wic image to eMMC, +you will also need phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.

+
+
+

5.3.3. Prepare Target

+

Set the bootmode switch (S1) to USB Serial Download. Also, connect USB port +X2 to your host.

+
+
+

5.3.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via (X30), as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.3.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic
+
+
+
+
+

5.3.7. Flashing SPI NOR Flash via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b qspi imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi
+
+
+

This will update the U-Boot on SPI NOR Flash but not the environment. You may need to erase the old +environment so the default environment of the new U-Boot gets loaded:

+
u-boot=> env erase
+u-boot=> reset
+
+
+
+
+
+

5.4. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone git://git.phytec.de/u-boot-imx)

+
+
+

5.4.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-imx and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • Our i.MX 8M Nano kernel is based on the linux-imx kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. Get the SDK

+

You can download the SDK here, or build it yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-headless-image # or another image
+
    +
    +
    • +
+

After a successful build the SDK installer is deployed to build/deploy*/sdk.

+
+
+

5.4.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-vendor-glibc-x86_64-phytec-headless-image-cortexa53-crypto-toolchain-4.0.13.sh
+host:~$ ./phytec-ampliphy-vendor-glibc-x86_64-phytec-headless-image-cortexa53-crypto-toolchain-4.0.13.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor/4.0.13):
+You are about to install the SDK to "/opt/ampliphy-vendor/4.0.13". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-vendor/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. U-Boot standalone build

+
+

5.5.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag used in this release is called v2022.04_2.2.2-phy5

    • +

  • Check out the needed U-Boot tag:

    +
    host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2022.04_2.2.2-phy5
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. Get the needed binaries

+

To build the bootloader, you need to copy these files to your u-boot-imx +build directory and rename them to fit with mkimage script:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx8mn.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +
+

If you already built our BSP with Yocto, you can get the +bl31-imx8mn.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: BSP Images

+

Or you can download the files here: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/imx-boot-tools/

+
+

Warning

+

Make sure you rename the files you need so that they are compatible with the +mkimage tool.

+
+
+
+

5.5.3. Build the bootloader

+
    +

  • build flash.bin (imx-boot):

    +
    host:~/u-boot-imx$ make phycore-imx8mn_defconfig
+host:~/u-boot-imx$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. Flash the bootloader to a block device

+

The flash.bin can be found at u-boot-imx/ directory and now can be +flashed. A chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

+

E.g. flash SD card:

+
host:~/u-boot-imx$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables +“BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+
+

5.6. Kernel standalone build

+
+

5.6.1. Setup sources

+
    +

  • The used linux-imx branch can be found in the release notes

    • +

  • The tag needed for this release is called v5.15.71_2.2.2-phy3

    • +

  • Check out the needed linux-imx tag:

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v5.15.71_2.2.2-phy3
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-imx$ make imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-imx/arch/arm64/boot/Image

    • +

  • The dtb can be found at +~/linux-imx/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. Copy Kernel to SD Card

+

When one-time boot via netboot is not sufficient, the kernel along with its +modules and the corresponding device tree blob may be copied directly to a +mounted SD card.

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. Accessing the Development states

+
+

5.7.1. Development state of current release

+

These release manifests exist to give you access to the development states +of the Yocto BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line:

+
host:~$ ./phyLinux init -p imx8mn -r BSP-Yocto-NXP-i.MX8MM-PD23.1.y
+
+
+

This will initialize a BSP that will track the latest development state of the +current release (BSP-Yocto-NXP-i.MX8MM-PD23.1.0). From now on repo sync in this folder +will pull all the latest changes from our Git repositories:

+
host:~$ repo sync
+
+
+
+
+

5.7.2. Development state of upcoming release

+

Also development states of upcoming releases can be accessed this way. +For this execute the following command and look for a release with a higher +PDXX.Y number than the latest one (BSP-Yocto-NXP-i.MX8MM-PD23.1.0) and .y at the +end:

+
host:~$ ./phyLinux init -p imx8mn
+
+
+
+
+
+

5.8. Accessing the Latest Upstream Support

+

We have a vanilla manifest that makes use of the Yocto master branches (not an +NXP release), Linux, and U-Boot. This can be used to test the latest upstream +kernel/U-Boot.

+
+

Note

+

The master manifest reflects the latest state of development. This tends to +be broken from time to time. We try to fix the master on a regular basis.

+
+
host:~$ ./phyLinux init -p imx8mn -r BSP-Yocto-Ampliphy-i.MX8MM-master
+
+
+
+
+

5.9. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.9.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-headless-image-phyboard-polis-imx8mn-2.wic image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-headless-image-phyboard-polis-imx8mn-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-headless-image-phyboard-polis-imx8mn-2.wic image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-headless-image-phyboard-polis-imx8mn-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 8M Nano BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 8M Nano SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Board.dts - include the module dtsi file. Devices that come from the i.MX 8M Nano +SoC but are just routed down to the carrier board and used there are included +in this dts.

    • +

  • Overlay.dtso - enable/disable features depending on optional hardware that +may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10)

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 8 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the folder arch/arm64/boot/dts/freescale/.

+

Available overlays for phyboard-polis-imx8mn-2.conf are:

+
imx8mn-phyboard-polis-peb-eval-01.dtbo
+imx8mn-phyboard-polis-peb-av-010.dtbo
+imx8mn-phycore-rpmsg.dtbo
+imx8mn-phycore-no-eth.dtbo
+imx8mn-phycore-no-spiflash.dtbo
+imx8mn-vm016.dtbo
+imx8mn-vm016-fpdlink.dtbo
+imx8mn-vm017.dtbo
+imx8mn-vm017-fpdlink.dtbo
+imx8mn-dual-vm017-fpdlink.dtbo
+
+
+

The usage of overlays can be configured during runtime in Linux or U-Boot. +Overlays are applied during the boot process in the bootloader after the +boot command is called and before the kernel is loaded. The next sections +explain the configuration in more detail.

+
+

6.2.2.1. Set ${overlays} variable

+

The ${overlays} U-Boot environment variable contains a space-separated list +of overlays that will be applied during boot. Depending on the boot source the +overlays have to either be placed in the boot partition of eMMC/SD-Card or are +loaded over tftp. Overlays set in the $KERNEL_DEVICETREE Yocto machine variable +will be automatically added to the boot partition of the final WIC image.

+

The ${overlays} variable can be either set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=imx8mn-phyboard-polis-peb-eval-01.dtbo imx8mn-phyboard-polis-peb-av-010.dtbo
+
+
+

Changes will take effect after the next reboot. If no bootenv.txt file is +available the overlays variable can be set directly in the U-Boot environment.

+
u-boot=> setenv overlays imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> printenv overlays
+overlays=imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

If a user defined ${overlays} variable should be directly loaded from U-Boot +environment but there is still an external bootenv.txt available, the ${no_bootenv} +variable needs to be set as a flag:

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

More information about the external environment can be found in +U-boot External Environment subsection of the +device tree overlay section.

+

We use the ${overlays} variable for overlays describing expansion boards and +cameras that can not be detected during run time. To prevent applying overlays +listed in the ${overlays} variable during boot, the ${no_overlays} variable can +be set to 1 in the bootloader environment.

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+

6.2.2.2. Extension Command

+

The U-Boot extension command makes it possible to easily apply overlays that +have been detected and added to a list by the board code callback +extension_board_scan(). +Overlays applied this way disable components that are not populated on the SoM. +The detection is done with the EEPROM data (EEPROM SoM Detection) found on the +SoM i2c EEPROM.

+

It depends on the SoM variant if any device tree overlays will be applied. To check +if an overlay will be applied on the running SoM in U-Boot, run:

+
u-boot=> extension scan
+Found 1 extension board(s).
+u-boot=> extension list
+Extension 0: phyCORE-i.MX8MN no SPI flash
+        Manufacturer:           PHYTEC
+        Version:
+        Devicetree overlay:     imx8mn-phycore-no-spiflash.dtbo
+        Other information:      SPI flash not populated on SoM
+
+
+

If the EEPROM data is not available, no device tree overlays are applied.

+

To prevent running the extension command during boot the ${no_extensions} +variable can be set to 1 in the bootloader environment:

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot External Environment

+

During the start of the Linux Kernel the external environment bootenv.txt +text file will be loaded from the boot partition of an MMC device or via TFTP. +The main intention of this file is to store the ${overlays} variable. This makes +it easy to pre-define the overlays in Yocto depending on the used machine. The +content from the file is defined in the Yocto recipe bootenv found in +meta-phytec: +https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=kirkstone

+

Other variables can be set in this file, too. They will overwrite the existing +settings in the environment. But only variables evaluated after issuing the boot +command can be overwritten, such as ${nfsroot} or ${mmcargs}. Changing other +variables in that file will not have an effect. See the usage during netboot as +an example.

+

If the external environment can not be loaded the boot process will be anyway +continued with the values of the existing environment settings.

+
+
+

6.2.4. Change U-boot Environment from Linux on Target

+

Libubootenv is a tool included in our images to modify the U-Boot environment of +Linux on the target machine.

+

Print the U-Boot environment using the following command:

+
target:~$ fw_printenv
+
+
+

Modify a U-Boot environment variable using the following command:

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

Caution

+

Libubootenv takes the environment selected in a configuration file. The +environment to use is inserted there, and by default it is configured to use +the eMMC environment (known as the default used environment).

+

If the eMMC is not flashed or the eMMC environment is deleted, libubootenv +will not work. You should modify the /etc/fw_env.config file to match the +environment source that you want to use.

+
+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 8M Nano BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 8M Nano BSP Device Tree Concept to get an understanding +of our i.MX 8 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 8 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 8M Nano Pin Muxing

+

The i.MX 8M Nano SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 8M Nano terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 8M Nano Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx8mn-phyboard-polis.dts:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX     0x00
+                MX8MN_IOMUXC_SAI2_RXC_UART1_DCE_RX      0x00
+                MX8MN_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B  0x00
+                MX8MN_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B  0x00
+        >;
+};
+
+
+

The first part of the string MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad +(in this example SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the right) +defines different modes of the pad, for example, if internal pull resistors are +activated or not. In this case, the internal resistors are disabled.

+
+
+

7.2. RS232/RS485

+

The i.MX 8M Nano SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +bootmode switch (S1) needs to be set correctly:

+ + + + + + + +
Switch between UART1 RS485/RS232
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+

7.2.1. RS232

+
    +

  • Display the current settings of a terminal in a human-readable format:

    +
    target:~$ stty -a
+
    +
    +
    • +

  • Configuration of the UART interface can be done with stty. For example:

    +
    target:~$ stty -F /dev/ttymxc0 115200 crtscts raw -echo
+
    +
    +
    • +

  • With a simple echo and cat, basic communication can be tested. Example:

    +
    target:~$ echo 123 > /dev/ttymxc0
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

The host should print out “123”.

+
+
+

7.2.2. RS485

+
+

Hint

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

For easy testing, look at the linux-serial-test. This tool is called the IOCTL +for RS485 and sends a constant stream of data.

+
target:~$ linux-serial-test -p /dev/ttymxc0 -b 115200 --rs485 0
+
+
+

More information about the linux-serial-test tool and its parameters can be +found here: linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Documentation for calling the IOCTL within c-code is described in the Linux +kernel documentation: +https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection1.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see “test” printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final “count for this session”. There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+

The device tree representation for RS232 and RS485: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n220

+
+
+
+
+

7.3. Network

+

phyBOARD-Polis-i.MX 8M Nano provides one Gigabit Ethernet interface.

+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n50.

+

+
+

7.3.1. Network Environment Customization

+
+

7.3.1.1. U-boot network-environment

+
    +

  • To find the Ethernet settings in the target bootloader:

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • With your development host set to IP 192.168.3.10 and netmask 255.255.255.0, +the target should return:

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • If you need to make any changes:

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> should be one of ipaddr, netmask, gatewayip or serverip. +<value> will be the actual value of the chosen parameter.

    +
    • +

  • The changes you made are temporary for now. To save these:

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

Here you can also change the IP address to DHCP instead of using a static one.

+
    +

  • Configure:

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • Set up paths for TFTP and NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+

Tip

+

Variables like nfsroot and netargs can be overwritten by the U-boot External +Environment. For netboot, the external environment will be loaded from tftp. +For example, to locally set the nfsroot variable in a bootenv.txt file, +locate the tftproot directory:

+
nfsroot=/home/user/nfssrc
+
+
+

There is no need to store the info on the target. Please note that this does +not work for variables like ipaddr or serveraddr as they need to be already +set when the external environment is being loaded.

+
+
+
+

7.3.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. WLAN

+

For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. Connecting to a WLAN Network

+

First set the correct regulatory domain for your country:

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

You will see:

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

Set up the wireless interface:

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

Now you can scan for available networks:

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection.

+

To do so, add the network-credentials to the file /etc/wpa_supplicant.conf:

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

Now a connection can be established:

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

This should result in the following output:

+
Successfully initialized wpa_supplicant
+
+
+

The ip address is automatically configured over DHCP. For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (kirkstone).

+
+
+
+

7.3.3. Bluetooth

+

Bluetooth is connected to UART2 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup.

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. Visibility

+

To activate visibility:

+
target:~$ hciconfig hci0 piscan
+
+
+

To disable visibility:

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. Connect

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

Note

+

If the connection fails with the error message: “Failed to connect: +org.bluez.Error.Failed” try restarting PulseAudio with:

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC Card

+

The i.MX 8M Nano supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n301

+

DT configuration for the eMMC interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n309

+
+
+

7.5. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 8M Nano is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw Multi-Level Cells (MLC) or Triple-Level +Cells (TLC) combined with a memory controller that handles ECC and wear +leveling. They are connected via an SD/MMC interface to the i.MX 8M Nano and are +represented as block devices in the Linux kernel like SD cards, flash drives, or +hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.5.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +or TLC. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background Operations +(BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • Enabling can be done with this command:

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.5.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 8M Nano SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.5.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
+
+

7.5.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC or TLC +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC used in NAND Flash, MLC or TLC have lower reliability and a higher +error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC or TLC +or mark these blocks as discard. The data on the device is lost and +will be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.5.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 8M Nano uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.5.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

The following table is for the offset of the i.MX 8M Nano SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.6. SPI Master

+

The i.MX 8M Nano controller has a FlexSPI and an ECSPI IP core included. The FlexSPI +host controller supports two SPI channels with up to 4 devices. Each channel +supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data +lines). The ECSPI controller supports 3 SPI interfaces with one dedicated chip +selected for each interface. As chip selects should be realized with GPIOs, more +than one device on each channel is possible.

+
+

7.6.1. SPI NOR Flash

+

phyCORE-i.MX 8M Nano is equipped with a QSPI NOR Flash which connects to the i.MX 8M Nano’s +FlexSPI interface. The QSPI NOR Flash is suitable for booting. Please see +different sections for flashing and bootmode setup. Due to limited space on the +SPI NOR Flash, only the bootloader is stored inside. By default, the kernel, +device tree, and rootfs are taken from eMMC.

+

The Bootloader does detect with the help of the EEPROM Introspection data if an +SPI flash is mounted or not. If no SPI flash is mounted a device tree overlay is +applied with the expansion command to disable the SPI flash device tree node +during boot. If no introspection data is available the SPI NOR flash node is +always enabled. Find more information in the device tree overlay section.

+

The bootloader also passes the SPI MTD partition table to Linux by fixing up the +device tree based on the mtdparts boot parameter. The default partition layout +in the BSP is set to:

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

This is a bootloader environment variable that is defined here and can be +changed during runtime. From Linux userspace, the NOR Flash partitions are +accessible via /dev/mtd<N> devices where <N> is the MTD device number associated +with the NOR flash partition to access. To find the correct MTD device number +for a partition, run on the target:

+
root@phyboard-polis-imx8mn-2:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

It lists all MTD devices and the corresponding partition names. The flash node +is defined inside of the SPI master node in the module DTS. The SPI node +contains all devices connected to this SPI bus which is in this case only the +SPI NOR Flash.

+

The definition of the SPI master node in the device tree can be found here:

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n78

+
+
+
+

7.7. GPIOs

+

The phyBOARD-Polis has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to i.MX 8M Nano pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal i.MX 8M Nano GPIO banks GPIO1 – GPIO5.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO5_07). <X> identifies the GPIO +bank and counts from 1 to 5, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo -c gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 20 from chip0):

    +
    target:~$ gpioget -c gpiochip0 20
+
    +
    +
    • +

  • Set the value of GPIO 20 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset -z -c gpiochip0 20=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <line=value>...
+
+Set values of GPIO lines.
+
+Lines are specified by name, or optionally by offset if the chip option
+is provided.
+Values may be '1' or '0', or equivalently 'active'/'inactive' or 'on'/'off'.
+
+The line output state is maintained until the process exits, but after that
+is not guaranteed.
+
+Options:
+      --banner            display a banner on successful startup
+  -b, --bias <bias>       specify the line bias
+                  Possible values: 'pull-down', 'pull-up', 'disabled'.
+                  (default is to leave bias unchanged)
+      --by-name           treat lines as names even if they would parse as an offset
+  -c, --chip <chip>       restrict scope to a particular chip
+  -C, --consumer <name>   consumer name applied to requested lines (default is 'gpioset')
+  -d, --drive <drive>     specify the line drive mode
+                  Possible values: 'push-pull', 'open-drain', 'open-source'.
+                  (default is 'push-pull')
+  -h, --help              display this help and exit
+  -l, --active-low        treat the line as active low
+  -p, --hold-period <period>
+                  the minimum time period to hold lines at the requested values
+  -s, --strict            abort if requested line names are not unique
+  -t, --toggle <period>[,period]...
+                  toggle the line(s) after the specified period(s)
+                  If the last period is non-zero then the sequence repeats.
+      --unquoted  don't quote line names
+  -v, --version           output version information and exit
+  -z, --daemonize set values then detach from the controlling terminal
+
+Chips:
+    A GPIO chip may be identified by number, name, or path.
+    e.g. '0', 'gpiochip0', and '/dev/gpiochip0' all refer to the same chip.
+
+Periods:
+    Periods are taken as milliseconds unless units are specified. e.g. 10us.
+    Supported units are 's', 'ms', and 'us'.
+
+*Note*
+    The state of a GPIO line controlled over the character device reverts to default
+    when the last process referencing the file descriptor representing the device file exits.
+    This means that it's wrong to run gpioset, have it exit and expect the line to continue
+    being driven high or low. It may happen if given pin is floating but it must be interpreted
+    as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.7.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the defconfig you use in +arch/arm64/configs/ in the linux kernel sources. For our NXP based releases, +this could be for example imx8_phytec_distro.config:

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+

Pinmuxing of some GPIO pins in the device tree imx8mn-phyboard-polis.dts:

+
pinctrl_leds: leds1grp {
+        fsl,pins = <
+                MX8MN_IOMUXC_GPIO1_IO01_GPIO1_IO1       0x16
+                MX8MN_IOMUXC_GPIO1_IO14_GPIO1_IO14      0x16
+                MX8MN_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x16
+        >;
+};
+
+
+
+
+
+

7.8. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the phyBOARD-Polis.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n45

+
+
+

7.9. I²C Bus

+

The i.MX 8M Nano contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 8M Nano. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our phyBOARD-Polis.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C1 bus configuration (e.g. imx8mn-phycore-som.dtsi): +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n106

+

General I²C3 bus configuration (e.g. imx8mn-phyboard-polis.dts): +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n196

+
+
+

7.10. EEPROM

+

On the phyCORE-i.MX8MN there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues.

+
+

Note

+

If you deleted reserved EEPROM spaces, please contact our support!

+
+
+

7.10.1. I2C EEPROM on phyCORE-i.MX8MN

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

The I2C EEPROM on the phyCORE-i.MX8MN SoM is connected to I2C address 0x51 on the I2C-0 +bus. It is possible to read and write directly to the device populated:

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the 4KiB EEPROM (bus: I2C-0 addr: 0x51) with zeros leaving out the EEPROM data use:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM Detection

+

The I2C EEPROM, populated on the phyCORE-i.MX8MN, has a separate ID page that is +addressable over I2C address 0x59 on bus 0 and a normal area that is addressable +over I2C address 0x51 on bus 0. PHYTEC uses this data area of 32 Bytes to store +information about the SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the EEPROM ID page data and the first 256 bytes of the normal area are +deleted, the bootloader will fall back to the phyCORE-i.MX8MN Kit RAM setup, which +is 1GiB RAM.

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

SoMs that are flashed with data format API revision 2 will print out information +about the module in the early stage.

+

DT representation, e.g. in phyCORE-i.MX 8M Nano file imx8mn-phycore-som.dtsi can be +found in our PHYTEC git: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n259

+
+
+
+

7.11. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC Wakealarm

+

It is possible to issue an interrupt from the RTC to wake up the system. The +format uses the Unix epoch time, which is the number of seconds since UTC +midnight on 1 January 1970. To wake up the system after 4 minutes from suspend +to ram state, type:

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

Note

+

Internally the wake alarm time will be rounded up to the next minute since +the alarm function doesn’t support seconds.

+
+
+
+

7.11.2. RTC Parameters

+

RTCs have a few abilities which can be read/set with the help of hwclock +tool.

+
    +

  • We can check RTC supported features with:

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    What this value means is encoded in kernel, each set bit translates to:

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • We can check RTC BSM (Backup Switchover Mode) with:

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • We can set RTC BSM with:

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    What BSM values mean translates to these values:

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    Tip

    +

    You should set BSM mode to DSM or LSM for RTC to switch to backup power +source when the initial power source is not available. Check RV-3028 RTC +datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching +Mode) actually mean.

    +
    +
    • +
+

DT representation for I²C RTCs: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n267

+
+
+
+

7.12. USB Host Controller

+

The USB controller of the i.MX 8M Nano SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +‘HS’).

+

The i.MX 8M Nano SoC has a single USB controller core that is set to OTG mode. +To use the micro USB / OTG port dip switch S1 Pos5 has to be set to on.

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+
+
+

7.13. USB OTG

+

Most PHYTEC boards provide a USB OTG interface. USB OTG ports automatically act +as a USB device or USB host. The mode depends on the USB hardware attached to +the USB OTG port. If, for example, a USB mass storage device is attached to the +USB OTG port, the device will show up as /dev/sda.

+
+

7.13.1. USB Device

+

In order to connect the board’s USB device to a USB host port (for example a +PC), you need to configure the appropriate USB gadget. With USB configfs you can +define the parameters and functions of the USB gadget. The BSP includes +USB configfs support as a kernel module.

+
target:~$ modprobe libcomposite
+
+
+

Example:

+
    +

  • First, define the parameters such as the USB vendor and product IDs, and set +the information strings for the English (0x409) language:

    • +
+
+

Hint

+

To save time, copy these commands and execute them in a script

+
+
cd /sys/kernel/config/usb_gadget/
+mkdir g1
+cd g1/
+echo "0x1d6b" > idVendor
+echo "0x0104" > idProduct
+mkdir strings/0x409
+echo "0123456789" > strings/0x409/serialnumber
+echo "Foo Inc." > strings/0x409/manufacturer
+echo "Bar Gadget" > strings/0x409/product
+
+
+
    +

  • Next, create a file for the mass storage gadget:

    • +
+
target:~$ dd if=/dev/zero of=/tmp/file.img bs=1M count=64
+
+
+
    +

  • Now you should create the functions you want to use:

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir functions/acm.GS0
+mkdir functions/ecm.usb0
+mkdir functions/mass_storage.0
+echo /tmp/file.img > functions/mass_storage.0/lun.0/file
+
+
+
    +

  • acm: Serial gadget, creates serial interface like /dev/ttyGS0.

    • +

  • ecm: Ethernet gadget, creates ethernet interface, e.g. usb0

    • +

  • mass_storage: The host can partition, format, and mount the gadget mass +storage the same way as any other USB mass storage.

    • +
+
    +

  • Bind the defined functions to a configuration:

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir configs/c.1
+mkdir configs/c.1/strings/0x409
+echo "CDC ACM+ECM+MS" > configs/c.1/strings/0x409/configuration
+ln -s functions/acm.GS0 configs/c.1/
+ln -s functions/ecm.usb0 configs/c.1/
+ln -s functions/mass_storage.0 configs/c.1/
+
+
+
    +

  • Finally, start the USB gadget with the following commands:

    • +
+
target:~$ cd /sys/kernel/config/usb_gadget/g1
+target:~$ ls /sys/class/udc/
+ci_hdrc.0
+target:~$ echo "ci_hdrc.0" >UDC
+
+
+

If your system has more than one USB Device or OTG port, you can pass the right +one to the USB Device Controller (UDC).

+
    +

  • To stop the USB gadget and unbind the used functions, execute:

    • +
+
target:~$ echo "" > /sys/kernel/config/usb_gadget/g1/UDC
+
+
+

The USB interface is configured as host in the kernel device tree +imx8mn-phyboard-polis.dts. See: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n264

+
+
+
+

7.14. CAN FD

+

The phyBOARD-Polis has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
+

Hint

+

phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. +There are different interfaces involved, which limits the datarate +capabilities of CANFD.

+
+
+

Hint

+

On phyBOARD-Polis-i.MX8MN a terminating resistor can be enabled by setting +S5 to ON if required.

+
+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The two CAN interfaces should show up as +can0 and can1.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    The information for can0 will look like:

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+
+

Warning

+

The mcp2518fd SPI to CANfd supports only baudrates starting from 125kB/s. +Slower rates can be selected but may not work correctly.

+
+

Device Tree CAN configuration of imx8mn-phyboard-polis.dts: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n125

+
+
+

7.15. Power Management

+
+

7.15.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 8M Nano SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as ‘Dynamic Voltage and +Frequency Scaling’ (DVFS). The i.MX 8M Nano BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the i.MX 8 +variant used, several different frequencies are supported.

+
+

Tip

+

Although the DVFS framework provides frequency settings for each CPU core, a +change in the frequency settings of one CPU core always affects all other CPU +cores too. So all CPU cores always share the same DVFS setting. An individual +DVFS setting for each core is not possible.

+
+
    +

  • To get a complete list type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately +1,6 GHz, the result will be:

    +
    1200000 1600000
+
    +
    +
    • +

  • To ask for the current frequency type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

So-called governors are automatically selecting one of these frequencies in +accordance with their goals.

+
    +

  • List all governors available with the following command:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    The result will be:

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative is much like the ondemand governor. It differs in behavior in +that it gracefully increases and decreases the CPU speed rather than jumping +to max speed the moment there is any load on the CPU.

    • +

  • ondemand (default) switches between possible CPU core frequencies in +reference to the current system load. When the system load increases above a +specific limit, it increases the CPU core frequency immediately.

    • +

  • powersave always selects the lowest possible CPU core frequency.

    • +

  • performance always selects the highest possible CPU core frequency.

    • +

  • userspace allows the user or userspace program running as root to set a +specific frequency (e.g. to 1600000). Type:

    • +

  • In order to ask for the current governor, type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    You will normally get:

    +
    ondemand
+
    +
    +
    • +

  • Switching over to another governor (e.g. userspace) is done with:

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • Now you can set the speed:

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +Documentation/admin-guide/pm/cpufreq.rst.

+
+
+

7.15.2. CPU Core Management

+

The i.MX 8M Nano SoC can have multiple processor cores on the die. The i.MX 8M Nano, for +example, has 4 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    Here the system has four processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.15.3. Suspend to RAM

+

The phyCORE-i.MX8MN supports basic suspend and resume. Different wake-up sources can be +used. Suspend/resume is possible with:

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

To wake up with serial console run

+
target:~$ echo enabled > /sys/class/tty/ttymxc2/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.16. Thermal Management

+
+

7.16.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.16.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 8M Nano SoC platform. The i.MX 8 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Industrial +and Commercial.

+ + + + + + + + + + + + + + + + + +

Commercial

Industrial

passive (warning)

85°C

95°C

critical (shutdown)

90°C

100°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise, Fair Share, Bang Bang, and +Userspace. The default policy used in the BSP is step_wise. If the value of the +SoC temperature in the sysfs file temp is above trip_point_0, the CPU frequency +is set to the lowest CPU frequency. When the SoC temperature drops below +trip_point_0 again, the throttling is released.

+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+

7.16.3. GPIO Fan

+
+

Note

+

Only GPIO fan supported.

+
+

A GPIO fan can be connected to the phyBOARD-Polis-i.MX 8M Nano. The SoC only contains one +temperature sensor which is already used by the thermal frequency scaling. The +fan can not be controlled by the kernel. We use lmsensors with hwmon for this +instead. lmsensors reads the temperature periodically and enables or disables +the fan at a configurable threshold. For the phyBOARD-Polis-i.MX 8M Nano, this is 60°C.

+

The settings can be configured in the configuration file:

+
/etc/fancontrol
+
+
+

Fan control is started by a systemd service during boot. This can be disabled +with:

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.17. Watchdog

+

The PHYTEC i.MX 8M Nano modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.17.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.18. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 8M Nano provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 8M Nano Reference Manual). The following list is +an abstract from the i.MX 8M Nano Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x30350000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x30350000

Description

OCOTP_MAC_ADDR0

9

0

0x640

contains lower 32 bits +of ENET0 MAC address

OCOTP_MAC_ADDR1

9

1

0x650

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

OCOTP_MAC_ADDR2

9

2

0x660

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 8M Nano Security Reference Manual.

+
+

7.18.1. Reading Fuse Values in uBoot

+

You can read the content of a fuse using memory-mapped shadow registers. To +calculate the memory address, use the fuse Bank and Word in the following +formula:

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.18.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mn/imx8mn.html b/previews/271/bsp/imx8/imx8mn/imx8mn.html new file mode 100644 index 000000000..53655e36f --- /dev/null +++ b/previews/271/bsp/imx8/imx8mn/imx8mn.html @@ -0,0 +1,389 @@ + + + + + + + + + i.MX 8M Nano Manuals — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

i.MX 8M Nano Manuals

+ +
+

BSP-Yocto-NXP-i.MX8MM-PD23.1.0

+
+

Table of Contents

+ +
+
+
+

BSP-Yocto-NXP-i.MX8MM-PD22.1.1

+
+

Table of Contents

+ +
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mn/pd22.1.1.html b/previews/271/bsp/imx8/imx8mn/pd22.1.1.html new file mode 100644 index 000000000..200fe7500 --- /dev/null +++ b/previews/271/bsp/imx8/imx8mn/pd22.1.1.html @@ -0,0 +1,3959 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 8M Nano BSP Manual

Document Title

i.MX 8M Nano BSP Manual

Document Type

BSP Manual

Yocto Manual

Release Date

2023/05/25

Is Branch of

i.MX 8M Nano BSP Manual

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-NXP-i.MX8MM-PD22.1.1

Minor

2023/05/23

Released

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +phyCORE-i.MX8M Nano Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads of our product.

+
+

1.1. Supported Hardware

+

The phyBOARD-Polis populated with the i.MX 8M Nano SoC is supported.

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-NXP-i.MX8MM-PD22.1.1 download. +If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware

+
+

1.1.1. phyBOARD-Polis Components

+ + + + + + +
+../../../_images/polis-front.jpg +
+

phyBOARD-Polis Components (top)

+
+
+
+../../../_images/polis-back.jpg + +
+

phyBOARD-Polis Components (bottom)

+
+
+
+
+
+
+
+

2. Getting Started

+

The phyCORE-i.MX8M Nano Kit is shipped with a pre-flashed SD card. It contains the +phytec-headless-image and can be used directly as a boot source. The eMMC is +programmed with only a U-boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+
+

2.1. Get the Image

+

The WIC image contains all BSP files in several, correctly pre-formatted +partitions and can be copied to an SD card easily using the single Linux +command dd. It can be built by Yocto or downloaded from the PHYTEC download +server.

+

Get the WIC file from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.wic
+
+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card with the dd command, you must have root +privileges. Be very careful when specifying the destination device with +dd! All files on the selected destination device will be erased +immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system!

+
+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. Unmount any mounted partitions before +you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+
    +

  • Unmount all partitions, e.g.:

    +
    host$ sudo umount /dev/sde1
+
    +
    +
    • +

  • After having unmounted all partitions, you can create your bootable SD card:

    +
    host$ sudo dd if=<IMAGENAME>-<MACHINE>.wic of=/dev/sdX bs=1M conv=fsync status=progress
+
    +
    +

    Again, make sure to replace /dev/sdX with your actual device name found +previously.

    +

    The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

    +
    • +
+

An alternative and much faster way to prepare an SD card can be done by using +bmap-tools from Intel. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host$ bmaptool copy <IMAGENAME>-<MACHINE>.wic /dev/<your_device>
+
+
+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.3. First Start-up

+ + + + + + + +
Bootmode Selection
+../../../_images/Nano_SD_BOOT.jpg + +
+

SD Card Boot

+
+
+
+
    +

  • Insert the SD card

    • +

  • Connect the target and the host with mirco USB on (X30) +debug USB

    • +

  • Power up the board

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 8M Nano BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: L-813e.A12 Yocto Reference Manual (Hardknott).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +L-813e.A12 Yocto Reference Manual (Hardknott).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-IMX8MM; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-vendor MACHINE=phyboard-polis-imx8mn-2 ./phyLinux init -p imx8mn -r BSP-Yocto-NXP-i.MX8MM-PD22.1.1
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the phyboard-polis-imx8mn-2 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx8mm.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, +lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY firmware images

    • +

  • imx-boot: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM +Trusted Firmware and DDR firmware. This is the final bootloader image which is +bootable.

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx8mn-phyboard-polis-dsi*.dtb: Kernel device tree file

    • +

  • imx8mn-phy*.dtbo: Kernel device tree overlay files

    • +

  • phytec-headless-image*.tar.gz: Root file system

    • +

  • phytec-headless-image*.wic: SD card image

    • +
+
+
+
+
+

4. Installing the OS

+
+

4.1. Bootmode Switch (S1)

+

The phyBOARD-Polis features a boot switch with six individually switchable ports to +select the phyCORE-i.MX 8M Nano default bootsource.

+

Hardware revision baseboard: 1532.2 and newer

+ + + + + + + + + + + + + +
Bootmode Selection
+../../../_images/Nano_eMMC_BOOT.png + +
+

eMMC (Default SoM boot)

+
+
+
+../../../_images/Nano_Serial_downloader_BOOT.png + +
+

USB Serial Downloader

+
+
+
+../../../_images/Nano_SD_BOOT.jpg + +
+

SD Card

+
+
+
+../../../_images/Nano_Fuse_BOOT.png + +
+

Internal Fuses

+
+
+
+../../../_images/Nano_QSPI_BOOT.png + +
+

SPI NOR

+
+
+

+ + + + + + + +
Switch between USB HOST/OTG using Pos5 of switch(S1)
+../../../_images/USB_HOST.jpg + +
+

USB HOST

+
+
+
+../../../_images/USB_OTG.png + +
+

USB OTG

+
+
+
+ + + + + + + +
Switch between UART1 RS485/RS232 using Pos4 of switch(S1)
+../../../_images/UART1_RS4851.png + +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS2321.jpg + +
+

UART1 RS232

+
+
+
+
+
+

4.2. Flash eMMC

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S1) is set to Default SOM boot.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk2p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from Network

+

i.MX 8M Nano boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

4.2.1.1. Flash eMMC from Network in u-boot on Target

+

These steps will show how to update the eMMC via a network. However, they only +work if the size of the image file is less than 1GB. If the image file is +larger, go to the section Format SD Card. Configure the bootmode switch (S1) to boot +from SD Card and put in an SD card. Power on the board and stop in U-Boot +prompt.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+
    +

  • Load your image via network to RAM:

    +
    u-boot=> tftp ${loadaddr} phytec-headless-image-phyboard-polis-imx8mn-2.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-phyboard-polis-imx8mn-2.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • Write the image to the eMMC:

    +
    u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +
+
+
+

4.2.1.2. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host.

+
+

Take a compressed or uncompressed image on the host and send it with ssh through +the network (then uncompress it, if necessary) to the eMMC of the target with a +one-line command:

+
target:~$ ssh <USER>@192.168.3.10 "dd if=<path_to_file>/phytec-headless-image-phyboard-polis-imx8mn-2.wic" | dd of=/dev/mmcblk2
+
+
+
+
+

4.2.1.3. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host.

+
+

Show your available image files on the host:

+
host:~$ ls
+phytec-headless-image-phyboard-polis-imx8mn-2.wic
+
+
+

Send the image with the command dd command combined with ssh through the network +to the eMMC of your device:

+
host:~$ dd if=phytec-headless-image-phyboard-polis-imx8mn-2.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2"
+
+
+
+
+
+

4.2.2. Flash eMMC u-boot image via Network from running u-boot

+

Update the standalone u-boot image imx-boot is also possible from u-boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host.

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.3. Flash eMMC from USB

+
+

4.2.3.1. Flash eMMC from USB in u-boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in Bootloader after enabling the OPTEE.

+
+

These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch to bootmode switch (S1) and put in an SD card. Power on the board +and stop in u-boot prompt. Insert a USB device with the copied WIC image +to the USB slot.

+

Load your image from the USB device to RAM:

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} *.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-headless-image-phyboard-polis-imx8mn-2.wic). Set the bootmode switch to +bootmode switch (S1).

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ cd /mnt
+target:~$ ls
+phytec-headless-image-phyboard-polis-imx8mn-2.wic
+
    +
    +
    • +

  • Show list of available MMC devices:

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • The eMMC device can be recognized by the fact that it contains two boot +partitions: (mmcblk2boot0; mmcblk2boot1)

    • +

  • Write the image to the phyCORE-i.MX 8M Nano eMMC (MMC device 2 without partition):

    +
    target:~$ dd if=phytec-headless-image-phyboard-polis-imx8mn-2.wic of=/dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    • +
+
+

Warning

+

Before this will work, you need to configure the multi-port switch +to Default SOM Boot to bootmode switch (S1).

+
+
+
+
+

4.2.4. Flash eMMC from SD Card

+

Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (*.wic) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see Resizing ext4 Root Filesystem.

+
+

4.2.4.1. Flash eMMC from SD card in u-boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in Bootloader after enabling the OPTEE. If the +image file is too large use the Updating eMMC from SD card in +Linux on Target subsection.

+
+
    +

  • Flash an SD card with a working image and create a third FAT partition. Copy +the WIC image (for example phytec-headless-image.wic) to this +partition.

    • +

  • Configure the bootmode switch to boot from the SD Card and insert the SD +card.

    • +

  • Power on the board and stop in u-boot.

    • +

  • Flash your WIC image (for example phytec-headless-image.wic) +from the SD card to eMMC. This will partition the card and copy imx-boot, +Image, dtb, dtbo, and root file system to eMMC.

    • +

  • Load the image:

    +
    u-boot=> fatload mmc 1:3 ${loadaddr} phytec-headless-image-phyboard-polis-imx8mn-2.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • Switch the mmc dev:

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc0(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • Power off the board and change the multi-port switch to Default SOM Boot to +boot from eMMC.

    • +
+
+
+

4.2.4.2. Flash eMMC from SD card in Linux on Target

+

You can also flash the eMMC on Linux. You only need a complete image saved on +the SD card (e.g. phytec-headless-image-phyboard-polis-imx8mn-2.wic).

+
    +

  • Show your saved image files on the SD card:

    +
    target:~$ ls
+phytec-headless-image-phyboard-polis-imx8mn-2.wic
+
    +
    +
    • +

  • Show list of available MMC devices:

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • The eMMC device can be recognized by the fact that it contains two boot +partitions: (mmcblk2boot0; mmcblk2boot1)

    • +

  • Write the image to the phyCORE-i.MX 8M Nano eMMC (MMC device 2 without +partition):

    +
    target:~$ dd if=phytec-headless-image-phyboard-polis-imx8mn-2.wic of=/dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    • +
+
+

Warning

+

Before this will work, you need to configure the bootmode switch (S1) to Default +SOM Boot to boot from eMMC.

+
+
+
+
+
+

4.3. Flash SPI NOR Flash

+

The phyCORE-i.MX8MN modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set bootmode switch (S1) to QSPI boot to boot from QSPI. The SPI Flash is +usually quite small. The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash +populated. Only the bootloader and the environment can be stored. The kernel, +device tree, and file system are taken from eMMC by default.

+

The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with:

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. Flash SPI NOR Flash from Network

+

The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-i.MX 8M Nano.

+
+

Tip

+

A working network is necessary! Setup Network Host.

+
+
+

4.3.1.1. Flash SPI NOR from Network in u-boot on Target

+

Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI-NOR flash needs to be probed:

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • A specially formatted u-boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image over tftp, erase and write the +bootloader to the flash:

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+

Warning

+

Erasing the complete SPI NOR flash when it is fully written will take quite +some time. This can trigger the watchdog to reset. Due to this, erase the +full flash in Linux.

+
+
+
+

4.3.1.2. Flash SPI NOR from Network in kernel on Target

+
    +

  • Copy the image from the host to the target:

    +
    host:~$ scp imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • Find the number of erase blocks of the U-boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the u-boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+

4.3.2. Flash SPI NOR Flash from SD Card

+

The bootloader on SPI NOR flash can be also flashed with SD Card.

+
+

4.3.2.1. Flash SPI NOR from SD Card in u-boot on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi to the FAT partition +on the SD Card. Before reading and writing are possible, the SPI-NOR flash +needs to be probed:

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • A specially formatted U-boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image from the SD Card, erase and write +the bootloader to the flash:

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+

Warning

+

Erasing the complete SPI NOR flash when it is fully written will take quite +some time. This can trigger the watchdog to reset. Due to this, erase the +full flash in Linux.

+
+
+
+

4.3.2.2. Flash SPI NOR from SD Card in kernel on Target

+
    +

  • Mount the SD Card:

    +
    host:~$ mount /dev/mmcblkp1 /mnt
+
    +
    +
    • +

  • Find the number of erase blocks of the u-boot partition:

    +
    target:~$  mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the u-boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A3 RAUC Update & Device Management Manual.

+
+
+
+

5. Development

+
+

5.1. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.1.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.2. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.2.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel image to your tftp directory:

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • Copy the devicetree to your tftp directory:

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • Copy all the overlays you want to use into your tftp directory:

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-headless-image-phyboard-polis-imx8mn-2.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.2.2. Set the bootenv.txt for Netboot

+

Create a bootenv.txt file in your tftp directory and write the following variables into it.

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> has to be replaced with the devicetree overlay filenames that you want to use. +Separate the filenames by spaces. For example:

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

Tip

+

All supported devicetree overlays are in the device tree chapter.

+
+
+
+

5.2.3. Network Settings on Target

+

To customize the targets ethernet configuration, please follow the description +here: Network Environment Customization

+
+
+

5.2.4. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.3.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/phyboard-polis-imx8mn-2/. For flashing a wic image to eMMC, +you will also need phytec-headless-image-phyboard-polis-imx8mn-2.wic.

+
+
+

5.3.3. Prepare Target

+

Set the bootmode switch (S1) to USB Serial Download. Also, connect USB port +X2 to your host.

+
+
+

5.3.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via (X30), as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.3.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-headless-image-phyboard-polis-imx8mn-2.wic
+
+
+
+
+
+

5.4. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone git://git.phytec.de/u-boot-imx)

+
+
+

5.4.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-imx and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • Our i.MX 8M Nano kernel is based on the linux-imx kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. Get the SDK

+

You can download the SDK here, or build it yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-headless-image # or another image
+
    +
    +
    • +
+

After a successful build the SDK installer is deployed to build/deploy*/sdk.

+
+
+

5.4.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-vendor-glibc-x86_64-phytec-headless-image-cortexa53-crypto-toolchain-BSP-Yocto-NXP-i.MX8MP-PD22.1.1.sh
+host:~$ ./phytec-ampliphy-vendor-glibc-x86_64-phytec-headless-image-cortexa53-crypto-toolchain-BSP-Yocto-NXP-i.MX8MP-PD22.1.1.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor/BSP-Yocto-NXP-i.MX8MP-PD22.1.1):
+You are about to install the SDK to "/opt/ampliphy-vendor/BSP-Yocto-NXP-i.MX8MP-PD22.1.1". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-vendor/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. U-Boot standalone build

+
+

5.5.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag needed at this release is called v2021.04_2.2.0-phy13

    • +

  • Check out the needed U-Boot tag:

    • +
+
host:~$ cd ~/u-boot-imx/
+host:~$ git fetch --all --tags
+host:~$ git checkout tags/v2021.04_2.2.0-phy13
+
+
+
    +

  • Technically, you can now build the U-Boot, but practically there are some +further steps necessary:

    +
      +

    • Create your own development branch:

      +
      host:~$ git switch --create <new-branch>
+
      +
      +
      +

      Note

      +

      You can name your development branch as you like, this is just an example.

      +
      +
      • +
    +
    • +

  • Set up a build environment:

    +
    host:~$ source /opt/ampliphy-vendor/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +

  • Set this environment variable before building the Image:

    +
    host:~$ export ATF_LOAD_ADDR=0x960000
+
    +
    +
    • +
+
+
+

5.5.2. Get the needed binaries

+

To build the bootloader, you need to copy these files to your u-boot-imx +build directory and rename them to fit with mkimage script:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx8mn.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +
+

If you already built our BSP with Yocto, you can get the +bl31-imx8mn.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: BSP Images

+

Or you can download the files here: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/images/ampliphy-vendor/phyboard-polis-imx8mn-2/imx-boot-tools/

+
+

Warning

+

Make sure you rename the files you need so that they are compatible with the +mkimage tool.

+
+
+
+

5.5.3. Build the bootloader

+
    +

  • build flash.bin (imx-boot):

    +
    host:~$ make phycore-imx8mn_defconfig
+host:~$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. Flash the bootloader to a block device

+

The flash.bin can be found at u-boot-imx/ directory and now can be flashed. A +chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

+

E.g. flash SD card:

+
host:~$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables “BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+
+

5.6. Kernel standalone build

+
+

5.6.1. Setup sources

+
    +

  • The used linux-imx branch can be found in the release notes

    • +

  • The tag needed for this release is called v5.10.72_2.2.0-phy17

    • +

  • Check out the needed linux-imx tag:

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v5.10.72_2.2.0-phy17
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-imx$ make imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-imx/arch/arm64/boot/Image

    • +

  • The dtb can be found at +~/linux-imx/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. Copy Kernel to SD Card

+

When one-time boot via netboot is not sufficient, the kernel along with its +modules and the corresponding device tree blob may be copied directly to a +mounted SD card.

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. Accessing the Development states

+
+

5.7.1. Development state of current release

+

These release manifests exist to give you access to the development states +of the Yocto BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line:

+
host:~$ ./phyLinux init -p imx8mn -r BSP-Yocto-NXP-i.MX8MM-PD22.1.y
+
+
+

This will initialize a BSP that will track the latest development state of the +current release (BSP-Yocto-NXP-i.MX8MM-PD22.1.1). From now on repo sync in this folder +will pull all the latest changes from our Git repositories:

+
host:~$ repo sync
+
+
+
+
+

5.7.2. Development state of upcoming release

+

Also development states of upcoming releases can be accessed this way. +For this execute the following command and look for a release with a higher +PDXX.Y number than the latest one (BSP-Yocto-NXP-i.MX8MM-PD22.1.1) and .y at the +end:

+
host:~$ ./phyLinux init -p imx8mn
+
+
+
+
+
+

5.8. Accessing the Latest Upstream Support

+

We have a vanilla manifest that makes use of the Yocto master branches (not an +NXP release), Linux, and U-Boot. This can be used to test the latest upstream +kernel/U-Boot.

+
+

Note

+

The master manifest reflects the latest state of development. This tends to +be broken from time to time. We try to fix the master on a regular basis.

+
+
host:~$ ./phyLinux init -p imx8mn -r BSP-Yocto-Ampliphy-i.MX8MM-master
+
+
+
+
+

5.9. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.9.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-headless-image-phyboard-polis-imx8mn-2.wic image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-headless-image-phyboard-polis-imx8mn-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-headless-image-phyboard-polis-imx8mn-2.wic image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-headless-image-phyboard-polis-imx8mn-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 8M Nano BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 8M Nano SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Carrierboard.dtsi - Devices that come from the i.MX 8M Nano SoC but are just routed +down to the carrier board and used there are included in this dtsi.

    • +

  • Board.dts - include the carrier board and module dtsi files. There may also +be some hardware configuration nodes enabled on the carrier board or the +module (i.e. the Board .dts shows the special characteristics of the board +configuration). For example, there are phyCORE-i.MX 8M Nano SOMs which may or may not +have a MIPI DSI to LVDS converter mounted. The converter is enabled (if +available) in the Board .dts and not in the Module .dtsi

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 8 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder arch/arm64/boot/dts/freescale/overlays.

+

Available overlays for phyboard-polis-imx8mn-2.conf are:

+
imx8mn-phyboard-polis-peb-eval-01.dtbo
+imx8mn-phyboard-polis-peb-av-010.dtbo
+imx8mn-phycore-rpmsg.dtbo
+imx8mn-phycore-no-eth.dtbo
+imx8mn-phycore-no-spiflash.dtbo
+imx8mn-vm016.dtbo
+imx8mn-vm016-fpdlink.dtbo
+imx8mn-vm017.dtbo
+imx8mn-vm017-fpdlink.dtbo
+imx8mn-dual-vm017-fpdlink.dtbo
+
+
+

The usage of overlays can be configured during runtime in Linux or U-Boot. +Overlays are applied during the boot process in the bootloader after the +boot command is called and before the kernel is loaded. The next sections +explain the configuration in more detail.

+
+

6.2.2.1. Set ${overlays} variable

+

The ${overlays} U-Boot environment variable contains a space-separated list +of overlays that will be applied during boot. Depending on the boot source the +overlays have to either be placed in the boot partition of eMMC/SD-Card or are +loaded over tftp. Overlays set in the $KERNEL_DEVICETREE Yocto machine variable +will be automatically added to the boot partition of the final WIC image.

+

The ${overlays} variable can be either set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=imx8mn-phyboard-polis-peb-eval-01.dtbo imx8mn-phyboard-polis-peb-av-010.dtbo
+
+
+

Changes will take effect after the next reboot. If no bootenv.txt file is +available the overlays variable can be set directly in the U-Boot environment.

+
u-boot=> setenv overlays imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> printenv overlays
+overlays=imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

If a user defined ${overlays} variable should be directly loaded from U-Boot +environment but there is still an external bootenv.txt available, the ${no_bootenv} +variable needs to be set as a flag:

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

More information about the external environment can be found in +U-boot External Environment subsection of the +device tree overlay section.

+

We use the ${overlays} variable for overlays describing expansion boards and +cameras that can not be detected during run time. To prevent applying overlays +listed in the ${overlays} variable during boot, the ${no_overlays} variable can +be set to 1 in the bootloader environment.

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+

6.2.2.2. Extension Command

+

The U-Boot extension command makes it possible to easily apply overlays that +have been detected and added to a list by the board code callback +extension_board_scan(). +Overlays applied this way disable components that are not populated on the SoM. +The detection is done with the EEPROM data (EEPROM SoM Detection) found on the +SoM i2c EEPROM.

+

It depends on the SoM variant if any device tree overlays will be applied. To check +if an overlay will be applied on the running SoM in U-Boot, run:

+
u-boot=> extension scan
+Found 1 extension board(s).
+u-boot=> extension list
+Extension 0: phyCORE-i.MX8MN no SPI flash
+        Manufacturer:           PHYTEC
+        Version:
+        Devicetree overlay:     imx8mn-phycore-no-spiflash.dtbo
+        Other information:      SPI flash not populated on SoM
+
+
+

If the EEPROM data is not available, no device tree overlays are applied.

+

To prevent running the extension command during boot the ${no_extensions} +variable can be set to 1 in the bootloader environment:

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot External Environment

+

During the start of the Linux Kernel the external environment bootenv.txt +text file will be loaded from the boot partition of an MMC device or via TFTP. +The main intention of this file is to store the ${overlays} variable. This makes +it easy to pre-define the overlays in Yocto depending on the used machine. The +content from the file is defined in the Yocto recipe bootenv found in +meta-phytec: +https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=hardknott

+

Other variables can be set in this file, too. They will overwrite the existing +settings in the environment. But only variables evaluated after issuing the boot +command can be overwritten, such as ${nfsroot} or ${mmcargs}. Changing other +variables in that file will not have an effect. See the usage during netboot as +an example.

+

If the external environment can not be loaded the boot process will be anyway +continued with the values of the existing environment settings.

+
+
+

6.2.4. Change U-boot Environment from Linux on Target

+

Libubootenv is a tool included in our images to modify the U-Boot environment of +Linux on the target machine.

+

Print the U-Boot environment using the following command:

+
target:~$ fw_printenv
+
+
+

Modify a U-Boot environment variable using the following command:

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

Caution

+

Libubootenv takes the environment selected in a configuration file. The +environment to use is inserted there, and by default it is configured to use +the eMMC environment (known as the default used environment).

+

If the eMMC is not flashed or the eMMC environment is deleted, libubootenv +will not work. You should modify the /etc/fw_env.config file to match the +environment source that you want to use.

+
+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 8M Nano BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 8M Nano BSP Device Tree Concept to get an understanding +of our i.MX 8 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 8 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 8M Nano Pin Muxing

+

The i.MX 8M Nano SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 8M Nano terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 8M Nano Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx8mn-phyboard-polis.dtsi:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX     0x00
+                MX8MN_IOMUXC_SAI2_RXC_UART1_DCE_RX      0x00
+                MX8MN_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B  0x00
+                MX8MN_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B  0x00
+        >;
+};
+
+
+

The first part of the string MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad +(in this example SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the right) +defines different modes of the pad, for example, if internal pull resistors are +activated or not. In this case, the internal resistors are disabled.

+
+
+

7.2. RS232/RS485

+

The i.MX 8M Nano SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +bootmode switch (S1) needs to be set correctly:

+ + + + + + + +
Switch between UART1 RS485/RS232
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+

7.2.1. RS232

+
    +

  • Display the current settings of a terminal in a human-readable format:

    +
    target:~$ stty -a
+
    +
    +
    • +

  • Configuration of the UART interface can be done with stty. For example:

    +
    target:~$ stty -F /dev/ttymxc0 115200 crtscts raw -echo
+
    +
    +
    • +

  • With a simple echo and cat, basic communication can be tested. Example:

    +
    target:~$ echo 123 > /dev/ttymxc0
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

The host should print out “123”.

+
+
+

7.2.2. RS485

+
+

Hint

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

For easy testing, look at the linux-serial-test. This tool is called the IOCTL +for RS485 and sends a constant stream of data.

+
target:~$ linux-serial-test -p /dev/ttymxc0 -b 115200 --rs485 0
+
+
+

More information about the linux-serial-test tool and its parameters can be +found here: linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Documentation for calling the IOCTL within c-code is described in the Linux +kernel documentation: +https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+

The device tree representation for RS232 and RS485: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n166

+
+
+
+

7.3. Network

+

phyBOARD-Polis-i.MX 8M Nano provides one Gigabit Ethernet interface.

+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n47.

+

+
+

7.3.1. Network Environment Customization

+
+

7.3.1.1. U-boot network-environment

+
    +

  • To find the Ethernet settings in the target bootloader:

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • With your development host set to IP 192.168.3.10 and netmask 255.255.255.0, +the target should return:

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • If you need to make any changes:

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> should be one of ipaddr, netmask, gatewayip or serverip. +<value> will be the actual value of the chosen parameter.

    +
    • +

  • The changes you made are temporary for now. To save these:

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

Here you can also change the IP address to DHCP instead of using a static one.

+
    +

  • Configure:

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • Set up paths for TFTP and NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+

Tip

+

Variables like nfsroot and netargs can be overwritten by the U-boot External +Environment. For netboot, the external environment will be loaded from tftp. +For example, to locally set the nfsroot variable in a bootenv.txt file, +locate the tftproot directory:

+
nfsroot=/home/user/nfssrc
+
+
+

There is no need to store the info on the target. Please note that this does +not work for variables like ipaddr or serveraddr as they need to be already +set when the external environment is being loaded.

+
+
+
+

7.3.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. WLAN

+

For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. Connecting to a WLAN Network

+

First set the correct regulatory domain for your country:

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

You will see:

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

Set up the wireless interface:

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

Now you can scan for available networks:

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection.

+

To do so, add the network-credentials to the file /etc/wpa_supplicant.conf:

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

Now a connection can be established:

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

This should result in the following output:

+
...
+ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section Changing the Network Configuration in the L-813e.A12 Yocto Reference Manual (Hardknott).

+

First, create the directory:

+
target:~$ mkdir -p /etc/systemd/network/
+
+
+

Then add the following configuration snippet in /etc/systemd/network/10-wlan0.network:

+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+

Now, restart the network daemon so that the configuration takes effect:

+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+
+

7.3.3. Bluetooth

+

Bluetooth is connected to UART2 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup.

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. Visibility

+

To activate visibility:

+
target:~$ hciconfig hci0 piscan
+
+
+

To disable visibility:

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. Connect

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

Note

+

If the connection fails with the error message: “Failed to connect: +org.bluez.Error.Failed” try restarting PulseAudio with:

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC Card

+

The i.MX 8M Nano supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n238

+

DT configuration for the eMMC interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n293

+
+
+

7.5. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 8M Nano is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw MLC memory cells combined with a memory +controller that handles ECC and wear leveling. They are connected via an SD/MMC +interface to the i.MX 8M Nano and are represented as block devices in the Linux kernel +like SD cards, flash drives, or hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.5.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +cells. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background +Operations (BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+

The userspace tool mmc does not currently support enabling automatic BKOPS +features.

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops enable /dev/mmcblk2
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.5.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 8M Nano SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n> <partition> <device>
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.5.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
    +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+
+
+

7.5.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC memory cells +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC memory cells used in NAND Flash, MLC memory cells have lower +reliability and a higher error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC memory +cells or mark these blocks as discard. The data on the device is lost and will +be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.5.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 8M Nano uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.5.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

The following table is for the offset of the i.MX 8M Nano SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.6. SPI Master

+

The i.MX 8M Nano controller has a FlexSPI and an ECSPI IP core included. The FlexSPI +host controller supports two SPI channels with up to 4 devices. Each channel +supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data +lines). The ECSPI controller supports 3 SPI interfaces with one dedicated chip +selected for each interface. As chip selects should be realized with GPIOs, more +than one device on each channel is possible.

+
+

7.6.1. SPI NOR Flash

+

phyCORE-i.MX 8M Nano is equipped with a QSPI NOR Flash which connects to the i.MX 8M Nano’s +FlexSPI interface. The QSPI NOR Flash is suitable for booting. Please see +different sections for flashing and bootmode setup. Due to limited space on the +SPI NOR Flash, only the bootloader is stored inside. By default, the kernel, +device tree, and rootfs are taken from eMMC.

+

The Bootloader does detect with the help of the EEPROM Introspection data if an +SPI flash is mounted or not. If no SPI flash is mounted a device tree overlay is +applied with the expansion command to disable the SPI flash device tree node +during boot. If no introspection data is available the SPI NOR flash node is +always enabled. Find more information in the device tree overlay section.

+

The bootloader also passes the SPI MTD partition table to Linux by fixing up the +device tree based on the mtdparts boot parameter. The default partition layout +in the BSP is set to:

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

This is a bootloader environment variable that is defined here and can be +changed during runtime. From Linux userspace, the NOR Flash partitions are +accessible via /dev/mtd<N> devices where <N> is the MTD device number associated +with the NOR flash partition to access. To find the correct MTD device number +for a partition, run on the target:

+
root@phyboard-polis-imx8mn-2:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

It lists all MTD devices and the corresponding partition names. The flash node +is defined inside of the SPI master node in the module DTS. The SPI node +contains all devices connected to this SPI bus which is in this case only the +SPI NOR Flash.

+

The definition of the SPI master node in the device tree can be found here:

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n75

+
+
+
+

7.7. GPIOs

+

The phyBOARD-Polis has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to i.MX 8M Nano pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal i.MX 8M Nano GPIO banks GPIO1 – GPIO5.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO5_07). <X> identifies the GPIO +bank and counts from 1 to 5, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 20 from chip0):

    +
    target:~$ gpioget gpiochip0 20
+
    +
    +
    • +

  • Set the value of GPIO 20 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset --mode=exit gpiochip0 20=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.7.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the defconfig you use in +arch/arm64/configs/ in the linux kernel sources. For our NXP based releases, +this could be for example imx8_phytec_distro.config:

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+

Pinmuxing of some GPIO pins in the device tree imx8mn-phyboard-polis.dtsi:

+
pinctrl_leds: leds1grp {
+        fsl,pins = <
+                MX8MN_IOMUXC_GPIO1_IO01_GPIO1_IO1       0x16
+                MX8MN_IOMUXC_GPIO1_IO14_GPIO1_IO14      0x16
+                MX8MN_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x16
+        >;
+};
+
+
+
+
+
+

7.8. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+mmc1::@    mmc2::@    user-led1@ user-led2@ user-led3@
+
+
+

Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the phyBOARD-Polis.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 255 > /sys/class/leds/user-led1/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/user-led1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n35

+
+
+

7.9. I²C Bus

+

The i.MX 8M Nano contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 8M Nano. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our phyBOARD-Polis.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C1 bus configuration (e.g. imx8mn-phycore-som.dtsi): +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n98

+

General I²C3 bus configuration (e.g. imx8mn-phyboard-polis.dtsi): +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n147

+
+
+

7.10. EEPROM

+

On the phyCORE-i.MX8MN there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues.

+
+

7.10.1. I2C EEPROM on phyCORE-i.MX8MN

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

The I2C EEPROM on the phyCORE-i.MX8MN SoM is connected to I2C address 0x51 on the I2C-0 +bus. It is possible to read and write directly to the device populated:

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the 4KiB EEPROM (bus: I2C-0 addr: 0x51) with zeros leaving out the EEPROM data use:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM Detection

+

The I2C EEPROM, populated on the phyCORE-i.MX8MN, has a separate ID page that is +addressable over I2C address 0x59 on bus 0 and a normal area that is addressable +over I2C address 0x51 on bus 0. PHYTEC uses this data area of 32 Bytes to store +information about the SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the EEPROM ID page data and the first 256 bytes of the normal area are +deleted, the bootloader will fall back to the phyCORE-i.MX8MN Kit RAM setup, which +is 1GiB RAM.

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

SoMs that are flashed with data format API revision 2 will print out information +about the module in the early stage.

+
+
+

7.10.3. Rescue EEPROM Data

+

The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area.

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1
+
+
+
+

Note

+

If you deleted both EEPROM spaces, please contact our support!

+
+

DT representation, e.g. in phyCORE-i.MX 8M Nano file imx8mn-phycore-som.dtsi can be +found in our PHYTEC git: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n248

+
+
+
+

7.11. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC Wakealarm

+

It is possible to issue an interrupt from the RTC to wake up the system. The +format uses the Unix epoch time, which is the number of seconds since UTC +midnight on 1 January 1970. To wake up the system after 4 minutes from suspend +to ram state, type:

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

Note

+

Internally the wake alarm time will be rounded up to the next minute since +the alarm function doesn’t support seconds.

+
+

DT representation for I²C RTCs: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy9#n254

+
+
+
+

7.12. USB Host Controller

+

The USB controller of the i.MX 8M Nano SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +‘HS’).

+

The i.MX 8M Nano SoC has a single USB controller core that is set to OTG mode. +To use the micro USB / OTG port dip switch S1 Pos5 has to be set to on.

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+
+
+

7.13. USB OTG

+

Most PHYTEC boards provide a USB OTG interface. USB OTG ports automatically act +as a USB device or USB host. The mode depends on the USB hardware attached to +the USB OTG port. If, for example, a USB mass storage device is attached to the +USB OTG port, the device will show up as /dev/sda.

+
+

7.13.1. USB Device

+

In order to connect the board’s USB device to a USB host port (for example a +PC), you need to configure the appropriate USB gadget. With USB configfs you can +define the parameters and functions of the USB gadget. The BSP includes +USB configfs support as a kernel module.

+
target:~$ modprobe libcomposite
+
+
+

Example:

+
    +

  • First, define the parameters such as the USB vendor and product IDs, and set +the information strings for the English (0x409) language:

    • +
+
+

Hint

+

To save time, copy these commands and execute them in a script

+
+
cd /sys/kernel/config/usb_gadget/
+mkdir g1
+cd g1/
+echo "0x1d6b" > idVendor
+echo "0x0104" > idProduct
+mkdir strings/0x409
+echo "0123456789" > strings/0x409/serialnumber
+echo "Foo Inc." > strings/0x409/manufacturer
+echo "Bar Gadget" > strings/0x409/product
+
+
+
    +

  • Next, create a file for the mass storage gadget:

    • +
+
target:~$ dd if=/dev/zero of=/tmp/file.img bs=1M count=64
+
+
+
    +

  • Now you should create the functions you want to use:

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir functions/acm.GS0
+mkdir functions/ecm.usb0
+mkdir functions/mass_storage.0
+echo /tmp/file.img > functions/mass_storage.0/lun.0/file
+
+
+
    +

  • acm: Serial gadget, creates serial interface like /dev/ttyGS0.

    • +

  • ecm: Ethernet gadget, creates ethernet interface, e.g. usb0

    • +

  • mass_storage: The host can partition, format, and mount the gadget mass +storage the same way as any other USB mass storage.

    • +
+
    +

  • Bind the defined functions to a configuration:

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir configs/c.1
+mkdir configs/c.1/strings/0x409
+echo "CDC ACM+ECM+MS" > configs/c.1/strings/0x409/configuration
+ln -s functions/acm.GS0 configs/c.1/
+ln -s functions/ecm.usb0 configs/c.1/
+ln -s functions/mass_storage.0 configs/c.1/
+
+
+
    +

  • Finally, start the USB gadget with the following commands:

    • +
+
target:~$ cd /sys/kernel/config/usb_gadget/g1
+target:~$ ls /sys/class/udc/
+ci_hdrc.0
+target:~$ echo "ci_hdrc.0" >UDC
+
+
+

If your system has more than one USB Device or OTG port, you can pass the right +one to the USB Device Controller (UDC).

+
    +

  • To stop the USB gadget and unbind the used functions, execute:

    • +
+
target:~$ echo "" > /sys/kernel/config/usb_gadget/g1/UDC
+
+
+

Both USB interfaces are configured as host in the kernel device tree +imx8mn-phyboard-polis.dtsi. See: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n206

+
+
+
+

7.14. CAN FD

+

The phyBOARD-Polis has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
+

Hint

+

phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. +There are different interfaces involved, which limits the datarate +capabilities of CANFD.

+
+
+

Hint

+

On phyBOARD-Polis-i.MX8MN a terminating resistor can be enabled by setting +S5 to ON if required.

+
+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The two CAN interfaces should show up as +can0 and can1.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    The information for can0 will look like:

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+
+

Warning

+

The mcp2518fd SPI to CANfd supports only baudrates starting from 125kB/s. +Slower rates can be selected but may not work correctly.

+
+

Device Tree CAN configuration of imx8mn-phyboard-polis.dtsi: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n104

+
+
+

7.15. Power Management

+
+

7.15.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 8M Nano SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as ‘Dynamic Voltage and +Frequency Scaling’ (DVFS). The i.MX 8M Nano BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the i.MX 8 +variant used, several different frequencies are supported.

+
+

Tip

+

Although the DVFS framework provides frequency settings for each CPU core, a +change in the frequency settings of one CPU core always affects all other CPU +cores too. So all CPU cores always share the same DVFS setting. An individual +DVFS setting for each core is not possible.

+
+
    +

  • To get a complete list type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately +1,6 GHz, the result will be:

    +
    1200000 1600000
+
    +
    +
    • +

  • To ask for the current frequency type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

So-called governors are automatically selecting one of these frequencies in +accordance with their goals.

+
    +

  • List all governors available with the following command:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    The result will be:

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative is much like the ondemand governor. It differs in behavior in +that it gracefully increases and decreases the CPU speed rather than jumping +to max speed the moment there is any load on the CPU.

    • +

  • ondemand (default) switches between possible CPU core frequencies in +reference to the current system load. When the system load increases above a +specific limit, it increases the CPU core frequency immediately.

    • +

  • powersave always selects the lowest possible CPU core frequency.

    • +

  • performance always selects the highest possible CPU core frequency.

    • +

  • userspace allows the user or userspace program running as root to set a +specific frequency (e.g. to 1600000). Type:

    • +

  • In order to ask for the current governor, type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    You will normally get:

    +
    ondemand
+
    +
    +
    • +

  • Switching over to another governor (e.g. userspace) is done with:

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • Now you can set the speed:

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +Documentation/admin-guide/pm/cpufreq.rst.

+
+
+

7.15.2. CPU Core Management

+

The i.MX 8M Nano SoC can have multiple processor cores on the die. The i.MX 8M Nano, for +example, has 4 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    Here the system has four processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.15.3. Suspend to RAM

+

The phyCORE-i.MX8MN supports basic suspend and resume. Different wake-up sources can be +used. Suspend/resume is possible with:

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

To wake up with serial console run

+
target:~$ echo enabled > /sys/class/tty/ttymxc2/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.16. Thermal Management

+
+

7.16.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.16.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 8M Nano SoC platform. The i.MX 8 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Industrial +and Commercial.

+ + + + + + + + + + + + + + + + + +

Commercial

Industrial

passive (warning)

85°C

95°C

critical (shutdown)

90°C

100°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise, Fair Share, Bang Bang, and +Userspace. The default policy used in the BSP is step_wise. If the value of the +SoC temperature in the sysfs file temp is above trip_point_0, the CPU frequency +is set to the lowest CPU frequency. When the SoC temperature drops below +trip_point_0 again, the throttling is released.

+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+

7.16.3. GPIO Fan

+
+

Note

+

Only GPIO fan supported.

+
+

A GPIO fan can be connected to the phyBOARD-Polis-i.MX 8M Nano. The SoC only contains one +temperature sensor which is already used by the thermal frequency scaling. The +fan can not be controlled by the kernel. We use lmsensors with hwmon for this +instead. lmsensors reads the temperature periodically and enables or disables +the fan at a configurable threshold. For the phyBOARD-Polis-i.MX 8M Nano, this is 60°C.

+

The settings can be configured in the configuration file:

+
/etc/fancontrol
+
+
+

Fan control is started by a systemd service during boot. This can be disabled +with:

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.17. Watchdog

+

The PHYTEC i.MX 8M Nano modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.17.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.18. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 8M Nano provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 8M Nano Reference Manual). The following list is +an abstract from the i.MX 8M Nano Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x30350000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x30350000

Description

OCOTP_MAC_ADDR0

9

0

0x640

contains lower 32 bits +of ENET0 MAC address

OCOTP_MAC_ADDR1

9

1

0x650

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

OCOTP_MAC_ADDR2

9

2

0x660

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 8M Nano Security Reference Manual.

+
+

7.18.1. Reading Fuse Values in uBoot

+

You can read the content of a fuse using memory-mapped shadow registers. To +calculate the memory address, use the fuse Bank and Word in the following +formula:

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.18.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+
+

8. BSP Extensions

+
+

8.1. Chromium

+

Our BSP for the phyBOARD-Polis-i.MX 8M Nano supports Chromium. You can include it in the +phytec-headless-image with only a few steps.

+
+

8.1.1. Adding Chromium to Your local.conf

+

To include Chromium you have to add the following line into your local.conf. You +can find it in <yocto_dir>/build/conf/local.conf. This adds Chromium to your +next image build.

+
IMAGE_INSTALL_append = " chromium-ozone-wayland"
+
+
+
+

Note

+

Compiling Chromium takes a long time.

+
+
+
+

8.1.2. Get Chromium Running on the Target

+

To run Chromium, it needs a few arguments to use the hardware graphics +acceleration:

+
target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox
+
+
+

If you want to start Chromium via SSH, you must first define the display on +which Chromium will run. For example:

+
target$ DISPLAY=:0
+
+
+

After you have defined this, you can start it via virtual terminal on Weston as +shown above.

+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mn/pd23.1.0.html b/previews/271/bsp/imx8/imx8mn/pd23.1.0.html new file mode 100644 index 000000000..a55779a1a --- /dev/null +++ b/previews/271/bsp/imx8/imx8mn/pd23.1.0.html @@ -0,0 +1,4059 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 8M Nano BSP Manual

Document Title

i.MX 8M Nano BSP Manual

Document Type

BSP Manual

Yocto Manual

Kirkstone

Release Date

2024/01/10

Is Branch of

i.MX 8M Nano BSP Manual

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-NXP-i.MX8MM-PD23.1.0

Major

2023/12/12

Released

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +phyCORE-i.MX8M Nano Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads of our product.

+
+

1.1. Supported Hardware

+

The phyBOARD-Polis populated with the i.MX 8M Nano SoC is supported.

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-NXP-i.MX8MM-PD23.1.0 download. +If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware

+
+

1.1.1. phyBOARD-Polis Components

+ + + + + + +
+../../../_images/polis-front.jpg +
+

phyBOARD-Polis Components (top)

+
+
+
+../../../_images/polis-back.jpg + +
+

phyBOARD-Polis Components (bottom)

+
+
+
+
+
+
+
+

2. Getting Started

+

The phyCORE-i.MX8M Nano Kit is shipped with a pre-flashed SD card. It contains the +phytec-headless-image and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+

There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool dd. An +alternative way is to use PHYTEC’s system initialization program called +partup, which makes it especially easy to +format more complex systems. You can get prebuilt Linux binaries of partup from its release page. Also read +partup’s README for installation +instructions.

+
+

2.1. Get the Image

+

The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using dd, can be downloaded from the PHYTEC download server.

+

Get either the partup package or the WIC image from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.wic
+
+
+
+

Note

+

For eMMC, more complex partitioning schemes or even just large images, we +recommend using the partup package, as it is faster in writing than dd +and allows for a more flexible configuration of the target flash device.

+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card, you must have root privileges on your Linux +host PC. Be very careful when specifying the destination device! All files +on the selected device will be erased immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system on your host PC!

+
+
+

2.2.1. Finding the Correct Device

+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+

Unmount all those partitions, e.g.:

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

Now, the SD card is ready to be flashed with an image, using either partup, +dd or bmap-tools.

+
+
+

2.2.2. Using partup

+

Writing to an SD card with partup is done in a single command:

+
host:~$ sudo partup install phytec-headless-image-phyboard-polis-imx8mn-2.partup /dev/<your_device>
+
+
+

Make sure to replace <your_device> with your actual device name found previously.

+

Further usage of partup is explained at its official documentation website.

+
+

Note

+

partup has the advantage of allowing to clear specific raw areas in the +MMC user area, which is used in our provided partup packages to erase any +existing U-Boot environments. This is a known issue bmaptool does not +solve, as mentioned below.

+

Another key advantage of partup over other flashing tools is that it allows +configuring MMC specific parts, like writing to eMMC boot partitions, without +the need to call multiple other commands when writing.

+
+
+
+

2.2.3. Using bmap-tools

+

An alternative and also fast way to prepare an SD card is using +bmap-tools. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host:~$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host:~$ bmaptool copy phytec-headless-image-phyboard-polis-imx8mn-2.wic /dev/<your_device>
+
+
+

Replace <your_device> with your actual SD card’s device name found previously, +and make sure to place the file <IMAGENAME>-<MACHINE>.wic.bmap alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip.

+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.2.4. Using dd

+

After having unmounted all SD card’s partitions, you can create your bootable SD card.

+

Some PHYTEC BSPs produce uncompressed images (with filename-extension *.wic), +and some others produce compressed images (with filename-extension *.wic.xz).

+

To flash an uncompressed images (*.wic) use command below:

+
host:~$ sudo dd if=phytec-headless-image-phyboard-polis-imx8mn-2.wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Or to flash a compressed images (*.wic.xz) use that command:

+
host:~$ xzcat phytec-headless-image-phyboard-polis-imx8mn-2.wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Again, make sure to replace <your_device> with your actual device name found +previously.

+

The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

+
+
+
+

2.3. First Start-up

+ + + + + + + +
Bootmode Selection
+../../../_images/Nano_SD_BOOT.jpg + +
+

SD Card Boot

+
+
+
+
    +

  • Insert the SD card

    • +

  • Connect the target and the host with mirco USB on (X30) +debug USB

    • +

  • Power up the board

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 8M Nano BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (kirkstone).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (kirkstone).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-IMX8MM; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-vendor MACHINE=phyboard-polis-imx8mn-2 ./phyLinux init -p imx8mn -r BSP-Yocto-NXP-i.MX8MM-PD23.1.0
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the phyboard-polis-imx8mn-2 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx8mn.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, +lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY firmware images

    • +

  • imx-boot: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM +Trusted Firmware and DDR firmware. This is the final bootloader image which is +bootable.

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx8mn-phyboard-polis*.dtb: Kernel device tree file

    • +

  • imx8mn-phy*.dtbo: Kernel device tree overlay files

    • +

  • phytec-headless-image*.tar.gz: Root file system

    • +

  • phytec-headless-image*.wic: SD card image

    • +
+
+
+
+
+

4. Installing the OS

+
+

4.1. Bootmode Switch (S1)

+

The phyBOARD-Polis features a boot switch with six individually switchable ports to +select the phyCORE-i.MX 8M Nano default bootsource.

+

Hardware revision baseboard: 1532.2 and newer

+ + + + + + + + + + + + + +
Bootmode Selection
+../../../_images/Nano_eMMC_BOOT.png + +
+

eMMC (Default SoM boot)

+
+
+
+../../../_images/Nano_Serial_downloader_BOOT.png + +
+

USB Serial Downloader

+
+
+
+../../../_images/Nano_SD_BOOT.jpg + +
+

SD Card

+
+
+
+../../../_images/Nano_Fuse_BOOT.png + +
+

Internal Fuses

+
+
+
+../../../_images/Nano_QSPI_BOOT.png + +
+

SPI NOR

+
+
+

+ + + + + + + +
Switch between USB HOST/OTG using Pos5 of switch(S1)
+../../../_images/USB_HOST.jpg + +
+

USB HOST

+
+
+
+../../../_images/USB_OTG.png + +
+

USB OTG

+
+
+
+ + + + + + + +
Switch between UART1 RS485/RS232 using Pos4 of switch(S1)
+../../../_images/UART1_RS4851.png + +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS2321.jpg + +
+

UART1 RS232

+
+
+
+
+
+

4.2. Flash eMMC

+

For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see Setup Network Host.

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S1) is set to eMMC.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk2p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from Network

+

i.MX 8M Nano boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

4.2.1.1. Flash eMMC from Network in U-Boot on Target

+

These steps will show how to update the eMMC via a network.

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE.

+
+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Load your image via network to RAM:

+
    +

  • when using dhcp

    +
    u-boot=> dhcp phytec-headless-image-phyboard-polis-imx8mn-2.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.1 (1 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.1
+Filename 'phytec-headless-image-phyboard-polis-imx8mn-2.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • when using a static ip address (serverip and ipaddr must be set +additionally).

    +
    u-boot=> tftp ${loadaddr} phytec-headless-image-phyboard-polis-imx8mn-2.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-phyboard-polis-imx8mn-2.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
+
+
+
+

4.2.1.2. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Take a compressed or uncompressed image with accompanying block map on the host +and send it with ssh through the network to the eMMC of the target with a +one-line command:

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-headless-image-phyboard-polis-imx8mn-2.wic /tmp && bmaptool copy /tmp/phytec-headless-image-phyboard-polis-imx8mn-2.wic /dev/mmcblk2
+
+
+
+
+

4.2.1.3. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Show your available image files on the host:

+
host:~$ ls /srv/tftp
+phytec-headless-image-phyboard-polis-imx8mn-2.wic
+phytec-headless-image-phyboard-polis-imx8mn-2.wic.bmap
+
+
+

Send the image with the bmaptool command combined with ssh through the network +to the eMMC of your device:

+
host:~$ scp /srv/tftp/phytec-headless-image-phyboard-polis-imx8mn-2.wic root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-headless-image-phyboard-polis-imx8mn-2.wic /dev/mmcblk2"
+
+
+
+
+
+

4.2.2. Flash eMMC U-Boot image via Network from running U-Boot

+

Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.3. Flash eMMC from USB stick

+
+

4.2.3.1. Flash eMMC from USB stick in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE.

+
+

These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch (S1) to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied WIC image to the USB slot.

+

Load your image from the USB device to RAM:

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} *.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-headless-image-phyboard-polis-imx8mn-2.wic). Set the bootmode switch (S1) to SD Card.

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ ls /mnt
+phytec-headless-image-phyboard-polis-imx8mn-2.wic
+phytec-headless-image-phyboard-polis-imx8mn-2.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Nano eMMC (MMC device 2 without partition):

    +
    target:~$ bmaptool copy /mnt/phytec-headless-image-phyboard-polis-imx8mn-2.wic /dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Tip

    +

    Before this will work, you need to configure the bootmode switch (S1) to +eMMC.

    +
    +
    • +
+
+
+
+

4.2.4. Flash eMMC from SD Card

+

Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (*.wic) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see Resizing ext4 Root Filesystem.

+

Alternatively, flash a partup package to the SD card, as described in +Getting Started. This will ensure the full space of the SD card is used.

+
+

4.2.4.1. Flash eMMC from SD card in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE. If the +image file is too large use the Updating eMMC from SD card in +Linux on Target subsection.

+
+
    +

  • Flash an SD card with a working image and create a third ext4 partition. Copy +the WIC image (for example phytec-headless-image.wic) to this +partition.

    • +

  • Configure the bootmode switch (S1) to SD Card and insert the SD Card.

    • +

  • Power on the board and stop in U-Boot.

    • +

  • Load the image:

    +
    u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-phyboard-polis-imx8mn-2.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • Switch the mmc dev to eMMC:

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • Flash your WIC image (for example phytec-headless-image.wic) +from the SD card to eMMC. This will partition the card and copy imx-boot, +Image, dtb, dtbo, and root file system to eMMC.

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • Power off the board and change the bootmode switch (S1) to eMMC.

    • +
+
+
+

4.2.4.2. Flash eMMC from SD card in Linux on Target

+

You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card.

+
    +

  • Show your saved partup package or WIC image files on the SD card:

    +
    target:~$ ls
+phytec-headless-image-phyboard-polis-imx8mn-2.partup
+phytec-headless-image-phyboard-polis-imx8mn-2.wic
+phytec-headless-image-phyboard-polis-imx8mn-2.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Nano eMMC (MMC device 2 without +partition) using partup:

    +
    target:~$ partup install phytec-headless-image-phyboard-polis-imx8mn-2.partup /dev/mmcblk2
+
    +
    +

    Flashing the partup package has the advantage of using the full capacity of +the eMMC device, adjusting partitions accordingly.

    +
    +

    Note

    +

    Alternatively, bmaptool may be used instead:

    +
    target:~$ bmaptool copy phytec-headless-image-phyboard-polis-imx8mn-2.wic /dev/mmcblk2
+
    +
    +

    Keep in mind that the root partition does not make use of the full space when +flashing with bmaptool.

    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Warning

    +

    Before this will work, you need to configure the bootmode switch (S1) to eMMC.

    +
    +
    • +
+
+
+
+
+

4.3. Flash SPI NOR Flash

+

The phyCORE-i.MX8MN modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set bootmode switch (S1) to SPI NOR. The SPI Flash is usually quite small. +The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash populated. Only the +bootloader and the environment can be stored. The kernel, device tree, and file +system are taken from eMMC by default.

+

The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with:

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. Flash SPI NOR Flash from Network

+

The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-i.MX 8M Nano.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+
+

4.3.1.1. Flash SPI NOR from Network in U-Boot on Target

+

Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI NOR flash needs to be probed:

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • A specially formatted U-Boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image over tftp, erase and write the +bootloader to the flash:

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+

4.3.1.2. Flash SPI NOR from Network in kernel on Target

+
    +

  • Copy the image from the host to the target:

    +
    host:~$ scp imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • Find the number of blocks to erase of the U-boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the U-Boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+

4.3.2. Flash SPI NOR Flash from SD Card

+

The bootloader on SPI NOR flash can be also flashed with SD Card.

+
+

4.3.2.1. Flash SPI NOR from SD Card in U-Boot on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi to the first partition +on the SD Card.

    • +

  • Before reading and writing are possible, the SPI-NOR flash +needs to be probed:

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • A specially formatted U-boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image from the SD Card, erase and write +the bootloader to the flash:

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+

4.3.2.2. Flash SPI NOR from SD Card in kernel on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi to the first partition +on the SD Card.

    • +

  • Mount the SD Card:

    +
    target:~$ mount /dev/mmcblk1p1 /mnt
+
    +
    +
    • +

  • Find the number of blocks to erase of the U-Boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the u-boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A5 RAUC Update & Device Management Manual.

+
+
+
+

5. Development

+
+

5.1. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.1.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.2. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.2.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel image to your tftp directory:

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • Copy the devicetree to your tftp directory:

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • Copy all the overlays you want to use into your tftp directory:

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-headless-image-phyboard-polis-imx8mn-2.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.2.2. Set the bootenv.txt for Netboot

+

Create a bootenv.txt file in your tftp directory and write the following variables into it.

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> has to be replaced with the devicetree overlay filenames that you want to use. +Separate the filenames by spaces. For example:

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

Tip

+

All supported devicetree overlays are in the device tree chapter.

+
+
+
+

5.2.3. Network Settings on Target

+

To customize the targets ethernet configuration, please follow the description +here: Network Environment Customization

+
+
+

5.2.4. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.3.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/phyboard-polis-imx8mn-2/. For flashing a wic image to eMMC, +you will also need phytec-headless-image-phyboard-polis-imx8mn-2.wic.

+
+
+

5.3.3. Prepare Target

+

Set the bootmode switch (S1) to USB Serial Download. Also, connect USB port +X2 to your host.

+
+
+

5.3.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via (X30), as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.3.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-headless-image-phyboard-polis-imx8mn-2.wic
+
+
+
+
+
+

5.4. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone git://git.phytec.de/u-boot-imx)

+
+
+

5.4.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-imx and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • Our i.MX 8M Nano kernel is based on the linux-imx kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. Get the SDK

+

You can download the SDK here, or build it yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-headless-image # or another image
+
    +
    +
    • +
+

After a successful build the SDK installer is deployed to build/deploy*/sdk.

+
+
+

5.4.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-vendor-glibc-x86_64-phytec-headless-image-cortexa53-crypto-toolchain-4.0.13.sh
+host:~$ ./phytec-ampliphy-vendor-glibc-x86_64-phytec-headless-image-cortexa53-crypto-toolchain-4.0.13.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor/4.0.13):
+You are about to install the SDK to "/opt/ampliphy-vendor/4.0.13". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-vendor/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. U-Boot standalone build

+
+

5.5.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag used in this release is called v2022.04_2.2.2-phy5

    • +

  • Check out the needed U-Boot tag:

    +
    host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2022.04_2.2.2-phy5
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. Get the needed binaries

+

To build the bootloader, you need to copy these files to your u-boot-imx +build directory and rename them to fit with mkimage script:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx8mn.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +
+

If you already built our BSP with Yocto, you can get the +bl31-imx8mn.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: BSP Images

+

Or you can download the files here: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/imx-boot-tools/

+
+

Warning

+

Make sure you rename the files you need so that they are compatible with the +mkimage tool.

+
+
+
+

5.5.3. Build the bootloader

+
    +

  • build flash.bin (imx-boot):

    +
    host:~/u-boot-imx$ make phycore-imx8mn_defconfig
+host:~/u-boot-imx$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. Flash the bootloader to a block device

+

The flash.bin can be found at u-boot-imx/ directory and now can be +flashed. A chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

+

E.g. flash SD card:

+
host:~/u-boot-imx$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables +“BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+
+

5.6. Kernel standalone build

+
+

5.6.1. Setup sources

+
    +

  • The used linux-imx branch can be found in the release notes

    • +

  • The tag needed for this release is called v5.15.71_2.2.2-phy3

    • +

  • Check out the needed linux-imx tag:

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v5.15.71_2.2.2-phy3
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-imx$ make imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-imx/arch/arm64/boot/Image

    • +

  • The dtb can be found at +~/linux-imx/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. Copy Kernel to SD Card

+

When one-time boot via netboot is not sufficient, the kernel along with its +modules and the corresponding device tree blob may be copied directly to a +mounted SD card.

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. Accessing the Development states

+
+

5.7.1. Development state of current release

+

These release manifests exist to give you access to the development states +of the Yocto BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line:

+
host:~$ ./phyLinux init -p imx8mn -r BSP-Yocto-NXP-i.MX8MM-PD23.1.y
+
+
+

This will initialize a BSP that will track the latest development state of the +current release (BSP-Yocto-NXP-i.MX8MM-PD23.1.0). From now on repo sync in this folder +will pull all the latest changes from our Git repositories:

+
host:~$ repo sync
+
+
+
+
+

5.7.2. Development state of upcoming release

+

Also development states of upcoming releases can be accessed this way. +For this execute the following command and look for a release with a higher +PDXX.Y number than the latest one (BSP-Yocto-NXP-i.MX8MM-PD23.1.0) and .y at the +end:

+
host:~$ ./phyLinux init -p imx8mn
+
+
+
+
+
+

5.8. Accessing the Latest Upstream Support

+

We have a vanilla manifest that makes use of the Yocto master branches (not an +NXP release), Linux, and U-Boot. This can be used to test the latest upstream +kernel/U-Boot.

+
+

Note

+

The master manifest reflects the latest state of development. This tends to +be broken from time to time. We try to fix the master on a regular basis.

+
+
host:~$ ./phyLinux init -p imx8mn -r BSP-Yocto-Ampliphy-i.MX8MM-master
+
+
+
+
+

5.9. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.9.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-headless-image-phyboard-polis-imx8mn-2.wic image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-headless-image-phyboard-polis-imx8mn-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-headless-image-phyboard-polis-imx8mn-2.wic image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-headless-image-phyboard-polis-imx8mn-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 8M Nano BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 8M Nano SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Board.dts - include the module dtsi file. Devices that come from the i.MX 8M Nano +SoC but are just routed down to the carrier board and used there are included +in this dts.

    • +

  • Overlay.dtso - enable/disable features depending on optional hardware that +may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10)

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 8 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder arch/arm64/boot/dts/freescale/overlays.

+

Available overlays for phyboard-polis-imx8mn-2.conf are:

+
imx8mn-phyboard-polis-peb-eval-01.dtbo
+imx8mn-phyboard-polis-peb-av-010.dtbo
+imx8mn-phycore-rpmsg.dtbo
+imx8mn-phycore-no-eth.dtbo
+imx8mn-phycore-no-spiflash.dtbo
+imx8mn-vm016.dtbo
+imx8mn-vm016-fpdlink.dtbo
+imx8mn-vm017.dtbo
+imx8mn-vm017-fpdlink.dtbo
+imx8mn-dual-vm017-fpdlink.dtbo
+
+
+

The usage of overlays can be configured during runtime in Linux or U-Boot. +Overlays are applied during the boot process in the bootloader after the +boot command is called and before the kernel is loaded. The next sections +explain the configuration in more detail.

+
+

6.2.2.1. Set ${overlays} variable

+

The ${overlays} U-Boot environment variable contains a space-separated list +of overlays that will be applied during boot. Depending on the boot source the +overlays have to either be placed in the boot partition of eMMC/SD-Card or are +loaded over tftp. Overlays set in the $KERNEL_DEVICETREE Yocto machine variable +will be automatically added to the boot partition of the final WIC image.

+

The ${overlays} variable can be either set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=imx8mn-phyboard-polis-peb-eval-01.dtbo imx8mn-phyboard-polis-peb-av-010.dtbo
+
+
+

Changes will take effect after the next reboot. If no bootenv.txt file is +available the overlays variable can be set directly in the U-Boot environment.

+
u-boot=> setenv overlays imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> printenv overlays
+overlays=imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

If a user defined ${overlays} variable should be directly loaded from U-Boot +environment but there is still an external bootenv.txt available, the ${no_bootenv} +variable needs to be set as a flag:

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

More information about the external environment can be found in +U-boot External Environment subsection of the +device tree overlay section.

+

We use the ${overlays} variable for overlays describing expansion boards and +cameras that can not be detected during run time. To prevent applying overlays +listed in the ${overlays} variable during boot, the ${no_overlays} variable can +be set to 1 in the bootloader environment.

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+

6.2.2.2. Extension Command

+

The U-Boot extension command makes it possible to easily apply overlays that +have been detected and added to a list by the board code callback +extension_board_scan(). +Overlays applied this way disable components that are not populated on the SoM. +The detection is done with the EEPROM data (EEPROM SoM Detection) found on the +SoM i2c EEPROM.

+

It depends on the SoM variant if any device tree overlays will be applied. To check +if an overlay will be applied on the running SoM in U-Boot, run:

+
u-boot=> extension scan
+Found 1 extension board(s).
+u-boot=> extension list
+Extension 0: phyCORE-i.MX8MN no SPI flash
+        Manufacturer:           PHYTEC
+        Version:
+        Devicetree overlay:     imx8mn-phycore-no-spiflash.dtbo
+        Other information:      SPI flash not populated on SoM
+
+
+

If the EEPROM data is not available, no device tree overlays are applied.

+

To prevent running the extension command during boot the ${no_extensions} +variable can be set to 1 in the bootloader environment:

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot External Environment

+

During the start of the Linux Kernel the external environment bootenv.txt +text file will be loaded from the boot partition of an MMC device or via TFTP. +The main intention of this file is to store the ${overlays} variable. This makes +it easy to pre-define the overlays in Yocto depending on the used machine. The +content from the file is defined in the Yocto recipe bootenv found in +meta-phytec: +https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=kirkstone

+

Other variables can be set in this file, too. They will overwrite the existing +settings in the environment. But only variables evaluated after issuing the boot +command can be overwritten, such as ${nfsroot} or ${mmcargs}. Changing other +variables in that file will not have an effect. See the usage during netboot as +an example.

+

If the external environment can not be loaded the boot process will be anyway +continued with the values of the existing environment settings.

+
+
+

6.2.4. Change U-boot Environment from Linux on Target

+

Libubootenv is a tool included in our images to modify the U-Boot environment of +Linux on the target machine.

+

Print the U-Boot environment using the following command:

+
target:~$ fw_printenv
+
+
+

Modify a U-Boot environment variable using the following command:

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

Caution

+

Libubootenv takes the environment selected in a configuration file. The +environment to use is inserted there, and by default it is configured to use +the eMMC environment (known as the default used environment).

+

If the eMMC is not flashed or the eMMC environment is deleted, libubootenv +will not work. You should modify the /etc/fw_env.config file to match the +environment source that you want to use.

+
+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 8M Nano BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 8M Nano BSP Device Tree Concept to get an understanding +of our i.MX 8 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 8 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 8M Nano Pin Muxing

+

The i.MX 8M Nano SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 8M Nano terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 8M Nano Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx8mn-phyboard-polis.dts:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX     0x00
+                MX8MN_IOMUXC_SAI2_RXC_UART1_DCE_RX      0x00
+                MX8MN_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B  0x00
+                MX8MN_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B  0x00
+        >;
+};
+
+
+

The first part of the string MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad +(in this example SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the right) +defines different modes of the pad, for example, if internal pull resistors are +activated or not. In this case, the internal resistors are disabled.

+
+
+

7.2. RS232/RS485

+

The i.MX 8M Nano SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +bootmode switch (S1) needs to be set correctly:

+ + + + + + + +
Switch between UART1 RS485/RS232
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+

7.2.1. RS232

+
    +

  • Display the current settings of a terminal in a human-readable format:

    +
    target:~$ stty -a
+
    +
    +
    • +

  • Configuration of the UART interface can be done with stty. For example:

    +
    target:~$ stty -F /dev/ttymxc0 115200 crtscts raw -echo
+
    +
    +
    • +

  • With a simple echo and cat, basic communication can be tested. Example:

    +
    target:~$ echo 123 > /dev/ttymxc0
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

The host should print out “123”.

+
+
+

7.2.2. RS485

+
+

Hint

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

For easy testing, look at the linux-serial-test. This tool is called the IOCTL +for RS485 and sends a constant stream of data.

+
target:~$ linux-serial-test -p /dev/ttymxc0 -b 115200 --rs485 0
+
+
+

More information about the linux-serial-test tool and its parameters can be +found here: linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Documentation for calling the IOCTL within c-code is described in the Linux +kernel documentation: +https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection1.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see “test” printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final “count for this session”. There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+

The device tree representation for RS232 and RS485: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n220

+
+
+
+
+

7.3. Network

+

phyBOARD-Polis-i.MX 8M Nano provides one Gigabit Ethernet interface.

+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n50.

+

+
+

7.3.1. Network Environment Customization

+
+

7.3.1.1. U-boot network-environment

+
    +

  • To find the Ethernet settings in the target bootloader:

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • With your development host set to IP 192.168.3.10 and netmask 255.255.255.0, +the target should return:

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • If you need to make any changes:

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> should be one of ipaddr, netmask, gatewayip or serverip. +<value> will be the actual value of the chosen parameter.

    +
    • +

  • The changes you made are temporary for now. To save these:

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

Here you can also change the IP address to DHCP instead of using a static one.

+
    +

  • Configure:

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • Set up paths for TFTP and NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+

Tip

+

Variables like nfsroot and netargs can be overwritten by the U-boot External +Environment. For netboot, the external environment will be loaded from tftp. +For example, to locally set the nfsroot variable in a bootenv.txt file, +locate the tftproot directory:

+
nfsroot=/home/user/nfssrc
+
+
+

There is no need to store the info on the target. Please note that this does +not work for variables like ipaddr or serveraddr as they need to be already +set when the external environment is being loaded.

+
+
+
+

7.3.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. WLAN

+

For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. Connecting to a WLAN Network

+

First set the correct regulatory domain for your country:

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

You will see:

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

Set up the wireless interface:

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

Now you can scan for available networks:

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection.

+

To do so, add the network-credentials to the file /etc/wpa_supplicant.conf:

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

Now a connection can be established:

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

This should result in the following output:

+
...
+ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (kirkstone).

+

First, create the directory:

+
target:~$ mkdir -p /etc/systemd/network/
+
+
+

Then add the following configuration snippet in /etc/systemd/network/10-wlan0.network:

+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+

Now, restart the network daemon so that the configuration takes effect:

+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+
+

7.3.3. Bluetooth

+

Bluetooth is connected to UART2 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup.

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. Visibility

+

To activate visibility:

+
target:~$ hciconfig hci0 piscan
+
+
+

To disable visibility:

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. Connect

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

Note

+

If the connection fails with the error message: “Failed to connect: +org.bluez.Error.Failed” try restarting PulseAudio with:

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC Card

+

The i.MX 8M Nano supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n301

+

DT configuration for the eMMC interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n309

+
+
+

7.5. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 8M Nano is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw Multi-Level Cells (MLC) or Triple-Level +Cells (TLC) combined with a memory controller that handles ECC and wear +leveling. They are connected via an SD/MMC interface to the i.MX 8M Nano and are +represented as block devices in the Linux kernel like SD cards, flash drives, or +hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.5.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +or TLC. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background Operations +(BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • Enabling can be done with this command:

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.5.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 8M Nano SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.5.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
+
+

7.5.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC or TLC +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC used in NAND Flash, MLC or TLC have lower reliability and a higher +error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC or TLC +or mark these blocks as discard. The data on the device is lost and +will be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.5.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 8M Nano uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.5.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

The following table is for the offset of the i.MX 8M Nano SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.6. SPI Master

+

The i.MX 8M Nano controller has a FlexSPI and an ECSPI IP core included. The FlexSPI +host controller supports two SPI channels with up to 4 devices. Each channel +supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data +lines). The ECSPI controller supports 3 SPI interfaces with one dedicated chip +selected for each interface. As chip selects should be realized with GPIOs, more +than one device on each channel is possible.

+
+

7.6.1. SPI NOR Flash

+

phyCORE-i.MX 8M Nano is equipped with a QSPI NOR Flash which connects to the i.MX 8M Nano’s +FlexSPI interface. The QSPI NOR Flash is suitable for booting. Please see +different sections for flashing and bootmode setup. Due to limited space on the +SPI NOR Flash, only the bootloader is stored inside. By default, the kernel, +device tree, and rootfs are taken from eMMC.

+

The Bootloader does detect with the help of the EEPROM Introspection data if an +SPI flash is mounted or not. If no SPI flash is mounted a device tree overlay is +applied with the expansion command to disable the SPI flash device tree node +during boot. If no introspection data is available the SPI NOR flash node is +always enabled. Find more information in the device tree overlay section.

+

The bootloader also passes the SPI MTD partition table to Linux by fixing up the +device tree based on the mtdparts boot parameter. The default partition layout +in the BSP is set to:

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

This is a bootloader environment variable that is defined here and can be +changed during runtime. From Linux userspace, the NOR Flash partitions are +accessible via /dev/mtd<N> devices where <N> is the MTD device number associated +with the NOR flash partition to access. To find the correct MTD device number +for a partition, run on the target:

+
root@phyboard-polis-imx8mn-2:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

It lists all MTD devices and the corresponding partition names. The flash node +is defined inside of the SPI master node in the module DTS. The SPI node +contains all devices connected to this SPI bus which is in this case only the +SPI NOR Flash.

+

The definition of the SPI master node in the device tree can be found here:

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n78

+
+
+
+

7.7. GPIOs

+

The phyBOARD-Polis has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to i.MX 8M Nano pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal i.MX 8M Nano GPIO banks GPIO1 – GPIO5.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO5_07). <X> identifies the GPIO +bank and counts from 1 to 5, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 20 from chip0):

    +
    target:~$ gpioget gpiochip0 20
+
    +
    +
    • +

  • Set the value of GPIO 20 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset --mode=exit gpiochip0 20=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.7.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the defconfig you use in +arch/arm64/configs/ in the linux kernel sources. For our NXP based releases, +this could be for example imx8_phytec_distro.config:

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+

Pinmuxing of some GPIO pins in the device tree imx8mn-phyboard-polis.dts:

+
pinctrl_leds: leds1grp {
+        fsl,pins = <
+                MX8MN_IOMUXC_GPIO1_IO01_GPIO1_IO1       0x16
+                MX8MN_IOMUXC_GPIO1_IO14_GPIO1_IO14      0x16
+                MX8MN_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x16
+        >;
+};
+
+
+
+
+
+

7.8. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the phyBOARD-Polis.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n45

+
+
+

7.9. I²C Bus

+

The i.MX 8M Nano contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 8M Nano. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our phyBOARD-Polis.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C1 bus configuration (e.g. imx8mn-phycore-som.dtsi): +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n106

+

General I²C3 bus configuration (e.g. imx8mn-phyboard-polis.dts): +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n196

+
+
+

7.10. EEPROM

+

On the phyCORE-i.MX8MN there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues.

+
+

7.10.1. I2C EEPROM on phyCORE-i.MX8MN

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

The I2C EEPROM on the phyCORE-i.MX8MN SoM is connected to I2C address 0x51 on the I2C-0 +bus. It is possible to read and write directly to the device populated:

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the 4KiB EEPROM (bus: I2C-0 addr: 0x51) with zeros leaving out the EEPROM data use:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM Detection

+

The I2C EEPROM, populated on the phyCORE-i.MX8MN, has a separate ID page that is +addressable over I2C address 0x59 on bus 0 and a normal area that is addressable +over I2C address 0x51 on bus 0. PHYTEC uses this data area of 32 Bytes to store +information about the SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the EEPROM ID page data and the first 256 bytes of the normal area are +deleted, the bootloader will fall back to the phyCORE-i.MX8MN Kit RAM setup, which +is 1GiB RAM.

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

SoMs that are flashed with data format API revision 2 will print out information +about the module in the early stage.

+
+
+

7.10.3. Rescue EEPROM Data

+

The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area.

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1
+
+
+
+

Note

+

If you deleted both EEPROM spaces, please contact our support!

+
+

DT representation, e.g. in phyCORE-i.MX 8M Nano file imx8mn-phycore-som.dtsi can be +found in our PHYTEC git: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n259

+
+
+
+

7.11. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC Wakealarm

+

It is possible to issue an interrupt from the RTC to wake up the system. The +format uses the Unix epoch time, which is the number of seconds since UTC +midnight on 1 January 1970. To wake up the system after 4 minutes from suspend +to ram state, type:

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

Note

+

Internally the wake alarm time will be rounded up to the next minute since +the alarm function doesn’t support seconds.

+
+
+
+

7.11.2. RTC Parameters

+

RTCs have a few abilities which can be read/set with the help of hwclock +tool.

+
    +

  • We can check RTC supported features with:

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x11.
+
    +
    +

    What this value means is encoded in kernel, each set bit translates to:

    +
    #define RTC_FEATURE_ALARM              0
+#define RTC_FEATURE_ALARM_RES_MINUTE   1
+#define RTC_FEATURE_NEED_WEEK_DAY      2
+#define RTC_FEATURE_ALARM_RES_2S       3
+#define RTC_FEATURE_UPDATE_INTERRUPT   4
+#define RTC_FEATURE_CORRECTION         5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE 6
+#define RTC_FEATURE_CNT                7
+
    +
    +
    • +

  • We can check RTC BSM (Backup Switchover Mode) with:

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • We can set RTC BSM with:

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    What BSM values mean translates to these values:

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    Tip

    +

    You should set BSM mode to DSM or LSM for RTC to switch to backup power +source when the initial power source is not available. Check RV-3028 RTC +datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching +Mode) actually mean.

    +
    +
    • +
+

DT representation for I²C RTCs: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n267

+
+
+
+

7.12. USB Host Controller

+

The USB controller of the i.MX 8M Nano SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +‘HS’).

+

The i.MX 8M Nano SoC has a single USB controller core that is set to OTG mode. +To use the micro USB / OTG port dip switch S1 Pos5 has to be set to on.

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+
+
+

7.13. USB OTG

+

Most PHYTEC boards provide a USB OTG interface. USB OTG ports automatically act +as a USB device or USB host. The mode depends on the USB hardware attached to +the USB OTG port. If, for example, a USB mass storage device is attached to the +USB OTG port, the device will show up as /dev/sda.

+
+

7.13.1. USB Device

+

In order to connect the board’s USB device to a USB host port (for example a +PC), you need to configure the appropriate USB gadget. With USB configfs you can +define the parameters and functions of the USB gadget. The BSP includes +USB configfs support as a kernel module.

+
target:~$ modprobe libcomposite
+
+
+

Example:

+
    +

  • First, define the parameters such as the USB vendor and product IDs, and set +the information strings for the English (0x409) language:

    • +
+
+

Hint

+

To save time, copy these commands and execute them in a script

+
+
cd /sys/kernel/config/usb_gadget/
+mkdir g1
+cd g1/
+echo "0x1d6b" > idVendor
+echo "0x0104" > idProduct
+mkdir strings/0x409
+echo "0123456789" > strings/0x409/serialnumber
+echo "Foo Inc." > strings/0x409/manufacturer
+echo "Bar Gadget" > strings/0x409/product
+
+
+
    +

  • Next, create a file for the mass storage gadget:

    • +
+
target:~$ dd if=/dev/zero of=/tmp/file.img bs=1M count=64
+
+
+
    +

  • Now you should create the functions you want to use:

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir functions/acm.GS0
+mkdir functions/ecm.usb0
+mkdir functions/mass_storage.0
+echo /tmp/file.img > functions/mass_storage.0/lun.0/file
+
+
+
    +

  • acm: Serial gadget, creates serial interface like /dev/ttyGS0.

    • +

  • ecm: Ethernet gadget, creates ethernet interface, e.g. usb0

    • +

  • mass_storage: The host can partition, format, and mount the gadget mass +storage the same way as any other USB mass storage.

    • +
+
    +

  • Bind the defined functions to a configuration:

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir configs/c.1
+mkdir configs/c.1/strings/0x409
+echo "CDC ACM+ECM+MS" > configs/c.1/strings/0x409/configuration
+ln -s functions/acm.GS0 configs/c.1/
+ln -s functions/ecm.usb0 configs/c.1/
+ln -s functions/mass_storage.0 configs/c.1/
+
+
+
    +

  • Finally, start the USB gadget with the following commands:

    • +
+
target:~$ cd /sys/kernel/config/usb_gadget/g1
+target:~$ ls /sys/class/udc/
+ci_hdrc.0
+target:~$ echo "ci_hdrc.0" >UDC
+
+
+

If your system has more than one USB Device or OTG port, you can pass the right +one to the USB Device Controller (UDC).

+
    +

  • To stop the USB gadget and unbind the used functions, execute:

    • +
+
target:~$ echo "" > /sys/kernel/config/usb_gadget/g1/UDC
+
+
+

The USB interface is configured as host in the kernel device tree +imx8mn-phyboard-polis.dts. See: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n264

+
+
+
+

7.14. CAN FD

+

The phyBOARD-Polis has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
+

Hint

+

phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. +There are different interfaces involved, which limits the datarate +capabilities of CANFD.

+
+
+

Hint

+

On phyBOARD-Polis-i.MX8MN a terminating resistor can be enabled by setting +S5 to ON if required.

+
+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The two CAN interfaces should show up as +can0 and can1.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    The information for can0 will look like:

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+
+

Warning

+

The mcp2518fd SPI to CANfd supports only baudrates starting from 125kB/s. +Slower rates can be selected but may not work correctly.

+
+

Device Tree CAN configuration of imx8mn-phyboard-polis.dts: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n125

+
+
+

7.15. Power Management

+
+

7.15.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 8M Nano SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as ‘Dynamic Voltage and +Frequency Scaling’ (DVFS). The i.MX 8M Nano BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the i.MX 8 +variant used, several different frequencies are supported.

+
+

Tip

+

Although the DVFS framework provides frequency settings for each CPU core, a +change in the frequency settings of one CPU core always affects all other CPU +cores too. So all CPU cores always share the same DVFS setting. An individual +DVFS setting for each core is not possible.

+
+
    +

  • To get a complete list type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately +1,6 GHz, the result will be:

    +
    1200000 1600000
+
    +
    +
    • +

  • To ask for the current frequency type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

So-called governors are automatically selecting one of these frequencies in +accordance with their goals.

+
    +

  • List all governors available with the following command:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    The result will be:

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative is much like the ondemand governor. It differs in behavior in +that it gracefully increases and decreases the CPU speed rather than jumping +to max speed the moment there is any load on the CPU.

    • +

  • ondemand (default) switches between possible CPU core frequencies in +reference to the current system load. When the system load increases above a +specific limit, it increases the CPU core frequency immediately.

    • +

  • powersave always selects the lowest possible CPU core frequency.

    • +

  • performance always selects the highest possible CPU core frequency.

    • +

  • userspace allows the user or userspace program running as root to set a +specific frequency (e.g. to 1600000). Type:

    • +

  • In order to ask for the current governor, type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    You will normally get:

    +
    ondemand
+
    +
    +
    • +

  • Switching over to another governor (e.g. userspace) is done with:

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • Now you can set the speed:

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +Documentation/admin-guide/pm/cpufreq.rst.

+
+
+

7.15.2. CPU Core Management

+

The i.MX 8M Nano SoC can have multiple processor cores on the die. The i.MX 8M Nano, for +example, has 4 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    Here the system has four processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.15.3. Suspend to RAM

+

The phyCORE-i.MX8MN supports basic suspend and resume. Different wake-up sources can be +used. Suspend/resume is possible with:

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

To wake up with serial console run

+
target:~$ echo enabled > /sys/class/tty/ttymxc2/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.16. Thermal Management

+
+

7.16.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.16.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 8M Nano SoC platform. The i.MX 8 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Industrial +and Commercial.

+ + + + + + + + + + + + + + + + + +

Commercial

Industrial

passive (warning)

85°C

95°C

critical (shutdown)

90°C

100°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise, Fair Share, Bang Bang, and +Userspace. The default policy used in the BSP is step_wise. If the value of the +SoC temperature in the sysfs file temp is above trip_point_0, the CPU frequency +is set to the lowest CPU frequency. When the SoC temperature drops below +trip_point_0 again, the throttling is released.

+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+

7.16.3. GPIO Fan

+
+

Note

+

Only GPIO fan supported.

+
+

A GPIO fan can be connected to the phyBOARD-Polis-i.MX 8M Nano. The SoC only contains one +temperature sensor which is already used by the thermal frequency scaling. The +fan can not be controlled by the kernel. We use lmsensors with hwmon for this +instead. lmsensors reads the temperature periodically and enables or disables +the fan at a configurable threshold. For the phyBOARD-Polis-i.MX 8M Nano, this is 60°C.

+

The settings can be configured in the configuration file:

+
/etc/fancontrol
+
+
+

Fan control is started by a systemd service during boot. This can be disabled +with:

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.17. Watchdog

+

The PHYTEC i.MX 8M Nano modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.17.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.18. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 8M Nano provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 8M Nano Reference Manual). The following list is +an abstract from the i.MX 8M Nano Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x30350000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x30350000

Description

OCOTP_MAC_ADDR0

9

0

0x640

contains lower 32 bits +of ENET0 MAC address

OCOTP_MAC_ADDR1

9

1

0x650

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

OCOTP_MAC_ADDR2

9

2

0x660

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 8M Nano Security Reference Manual.

+
+

7.18.1. Reading Fuse Values in uBoot

+

You can read the content of a fuse using memory-mapped shadow registers. To +calculate the memory address, use the fuse Bank and Word in the following +formula:

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.18.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mp-libra-fpsc/head.html b/previews/271/bsp/imx8/imx8mp-libra-fpsc/head.html new file mode 100644 index 000000000..1eb10cace --- /dev/null +++ b/previews/271/bsp/imx8/imx8mp-libra-fpsc/head.html @@ -0,0 +1,4863 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + + + + + +

L-XXXXX.Xx i.MX 8M Plus FPSC +BSP ManualHead

Document Title

L-XXXXX.Xx i.MX 8M Plus FPSC +BSP Manual Head

Document Type

BSP Manual

Article Number

L-XXXXX.Xx

Yocto Manual

Release Date

XXXX/XX/XX

Is Branch of

L-XXXXX.Xx i.MX 8M Plus FPSC +BSP Manual Head

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +Libra i.MX 8M Plus FPSC Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads of our product.

+
+

1.1. Supported Hardware

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-NXP-i.MX8MP-PD24.1.0 download.

+

If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware

+
+

1.1.1. Libra Components

+
+../../../_images/Libra-front-components.jpg + +
+

Libra Components (top)

+
+
+
+../../../_images/Libra-back-components.jpg + +
+

Libra Components (bottom)

+
+
+
+
+
+
+

2. Getting Started

+

The Libra i.MX 8M Plus FPSC Kit is shipped with a pre-flashed SD card. It contains the +phytec-qt6demo-image and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+

There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool dd. An +alternative way is to use PHYTEC’s system initialization program called +partup, which makes it especially easy to +format more complex systems. You can get prebuilt Linux binaries of partup from its release page. Also read +partup’s README for installation +instructions.

+
+

2.1. Get the Image

+

The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using dd, can be downloaded from the PHYTEC download server.

+

Get either the partup package or the WIC image from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+
+

Note

+

For eMMC, more complex partitioning schemes or even just large images, we +recommend using the partup package, as it is faster in writing than dd +and allows for a more flexible configuration of the target flash device.

+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card, you must have root privileges on your Linux +host PC. Be very careful when specifying the destination device! All files +on the selected device will be erased immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system on your host PC!

+
+
+

2.2.1. Finding the Correct Device

+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+

Unmount all those partitions, e.g.:

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

Now, the SD card is ready to be flashed with an image, using either partup, +dd or bmap-tools.

+
+
+

2.2.2. Using bmap-tools

+

One way to prepare an SD card is using +bmap-tools. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host:~$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host:~$ bmaptool copy phytec-qt6demo-image-libra-imx8mp-1?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

Replace <your_device> with your actual SD card’s device name found previously, +and make sure to place the file <IMAGENAME>-<MACHINE>.wic.bmap alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip.

+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.2.3. Using partup

+

Writing to an SD card with partup is done in a single command:

+
host:~$ sudo partup install phytec-qt6demo-image-libra-imx8mp-1?(.rootfs).partup /dev/<your_device>
+
+
+

Make sure to replace <your_device> with your actual device name found previously.

+

Further usage of partup is explained at its official documentation website.

+
+

Warning

+

Host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to write partup packages created with Yocto Mickledore +or newer to SD-Card. This is due to a new default option in resize2fs which causes an +incompatibility. See release notes.

+
+
+

Note

+

partup has the advantage of allowing to clear specific raw areas in the +MMC user area, which is used in our provided partup packages to erase any +existing U-Boot environments. This is a known issue bmaptool does not +solve, as mentioned in the previous chapter.

+

Another key advantage of partup over other flashing tools is that it allows +configuring MMC specific parts, like writing to eMMC boot partitions, without +the need to call multiple other commands when writing.

+
+
+
+

2.2.4. Using dd

+

After having unmounted all SD card’s partitions, you can create your bootable SD card.

+

Some PHYTEC BSPs produce uncompressed images (with filename-extension *.wic), +and some others produce compressed images (with filename-extension *.wic.xz).

+

To flash an uncompressed images (*.wic) use command below:

+
host:~$ sudo dd if=phytec-qt6demo-image-libra-imx8mp-1?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Or to flash a compressed images (*.wic.xz) use that command:

+
host:~$ xzcat phytec-qt6demo-image-libra-imx8mp-1?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Again, make sure to replace <your_device> with your actual device name found +previously.

+

The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

+
+
+
+

2.3. First Start-up

+ +../../../_images/SD_Card_Boot1.png +
    +

  • Insert the SD card

    • +

  • Connect the target and the host with mirco USB on (X1) +debug USB

    • +

  • Power up the board

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (scarthgap).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (scarthgap).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-IMX8MP-FPSC; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-xwayland MACHINE=libra-imx8mp-1 ./phyLinux init -p imx8mp-fpsc -r BSP-Yocto-NXP-i.MX8MP-PD24.1.0
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the libra-imx8mp-1 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx8mp.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, +lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY firmware images

    • +

  • imx-boot: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM +Trusted Firmware and DDR firmware. This is the final bootloader image which is +bootable.

    • +

  • fitImage: Linux kernel FIT image

    • +

  • fitImage-its*.its

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx8mp-libra-rdk-fpsc*.dtb: Kernel device tree file

    • +

  • imx8mp-phy*.dtbo: Kernel device tree overlay files

    • +

  • phytec-qt6demo-image*.tar.gz: Root file system

    • +

  • phytec-qt6demo-image*.rootfs.wic.xz: compressed SD card image

    • +
+
+
+
+
+

4. Installing the OS

+
+

4.1. Bootmode Switch (S3)

+
+

Tip

+

Hardware revision baseboard: 1552.2

+
+

The Libra features a boot switch with four individually switchable ports to +select the phyCORE-i.MX 8M Plus default bootsource.

+ + + + + + + + + + + +
+../../../_images/eMMC1.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses1.png +
+

Internal Fuses

+
+
+
+../../../_images/SPI_NOR1.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download2.png +
+

USB Serial Download

+
+
+
+../../../_images/SD_Card_Boot1.png +
+

SD Card

+
+
+
+../../../_images/JTAG_Mode.png +
+

JTAG Mode

+
+
+
+
+
+

4.2. Flash eMMC

+

For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see Setup Network Host.

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S3) is set to eMMC.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk2p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from Network

+

i.MX 8M Plus boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

4.2.1.1. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Show your available image files on the host:

+
host:~$ ls /srv/tftp
+phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.xz
+phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.bmap
+
+
+

Send the image with the bmaptool command combined with ssh through the network +to the eMMC of your device:

+
host:~$ scp /srv/tftp/phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.xz /dev/mmcblk2"
+
+
+
+
+

4.2.1.2. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Take a compressed or decompressed image with the accompanying block map file +*.bmap on the host and send it with ssh through the network to the eMMC of +the target with a one-line command:

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.* /tmp && bmaptool copy /tmp/phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.xz /dev/mmcblk2
+
+
+
+
+

4.2.1.3. Flash eMMC from Network in U-Boot on Target

+

These steps will show how to update the eMMC via a network.

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE.

+
+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Uncompress your image

+
host:~$ unxz /srv/tftp/phytec-headless-image-libra-imx8mp-1.rootfs.wic.xz
+
+
+

Load your image via network to RAM:

+
    +

  • when using dhcp

    +
    u-boot=> dhcp phytec-headless-image-libra-imx8mp-1.rootfs.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.1 (1 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.1
+Filename 'phytec-headless-image-libra-imx8mp-1.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • when using a static ip address (serverip and ipaddr must be set +additionally).

    +
    u-boot=> tftp ${loadaddr} phytec-headless-image-libra-imx8mp-1.rootfs.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-libra-imx8mp-1.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
+
+
+
+
+

4.2.2. Flash eMMC U-Boot image via Network from running U-Boot

+

Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.3. Flash eMMC from USB stick

+
+

4.2.3.1. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-qt6demo-image-libra-imx8mp-1.|yocto-imageext|). Set the bootmode switch (S3) to SD Card.

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ ls /mnt
+phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.xz
+phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without partition):

    +
    target:~$ bmaptool copy /mnt/phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.xz /dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Tip

    +

    Before this will work, you need to configure the bootmode switch (S3) to +eMMC.

    +
    +
    • +
+
+
+

4.2.3.2. Flash eMMC from USB stick in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE.

+
+

These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch (S3) to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied uncompressed WIC image to +the USB slot.

+

Load your image from the USB device to RAM:

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 0x58000000 phytec-headless-image-|yocto-machinename|.rootfs.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write 0x58000000 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+
+

4.2.4. Flash eMMC from SD Card

+

Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (*.wic) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see Resizing ext4 Root Filesystem.

+

Alternatively, flash a partup package to the SD card, as described in +Getting Started. This will ensure the full space of the SD card is used.

+
+

4.2.4.1. Flash eMMC from SD card in Linux on Target

+

You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card.

+
    +

  • Show your saved partup package or WIC image files on the SD card:

    +
    target:~$ ls
+phytec-qt6demo-image-libra-imx8mp-1.rootfs.partup
+phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.xz
+phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without +partition) using partup:

    +
    target:~$ partup install phytec-qt6demo-image-libra-imx8mp-1.rootfs.partup /dev/mmcblk2
+
    +
    +

    Flashing the partup package has the advantage of using the full capacity of +the eMMC device, adjusting partitions accordingly.

    +
    +

    Note

    +

    Alternatively, bmaptool may be used instead:

    +
    target:~$ bmaptool copy phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.xz /dev/mmcblk2
+
    +
    +

    Keep in mind that the root partition does not make use of the full space when +flashing with bmaptool.

    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Warning

    +

    Before this will work, you need to configure the bootmode switch (S3) to eMMC.

    +
    +
    • +
+
+
+

4.2.4.2. Flash eMMC from SD card in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE. If the +image file is too large use the Updating eMMC from SD card in +Linux on Target subsection.

+
+
    +

  • Flash an SD card with a working image and create a third ext4 partition. Copy +the WIC image (for example phytec-qt6demo-image.rootfs.wic) to this +partition.

    • +

  • Configure the bootmode switch (S3) to SD Card and insert the SD Card.

    • +

  • Power on the board and stop in U-Boot.

    • +

  • Load the image:

    +
    u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-libra-imx8mp-1.rootfs.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • Switch the mmc dev to eMMC:

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • Flash your WIC image (for example phytec-qt6demo-image.rootfs.wic) +from the SD card to eMMC. This will partition the card and copy imx-boot, +Image, dtb, dtbo, and root file system to eMMC.

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • Power off the board and change the bootmode switch (S3) to eMMC.

    • +
+
+
+
+
+

4.3. Flash SPI NOR Flash

+

The phyCORE-i.MX8MP-FPSC modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set bootmode switch (S3) to SPI NOR. The SPI Flash is usually quite small. +The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash populated. Only the +bootloader and the environment can be stored. The kernel, device tree, and file +system are taken from eMMC by default.

+

The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with:

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. Flash SPI NOR Flash from Network

+

The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-i.MX 8M Plus.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+
+

4.3.1.1. Flash SPI NOR from Network in kernel on Target

+
    +

  • Copy the image from the host to the target:

    +
    host:~$ scp imx-boot-libra-imx8mp-1-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • Find the number of blocks to erase of the U-boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the U-Boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-libra-imx8mp-1-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.1.2. Flash SPI NOR from Network in U-Boot on Target

+

Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI NOR flash needs to be probed:

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • A specially formatted U-Boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image over tftp, erase and write the +bootloader to the flash:

    +
    u-boot=> tftp ${loadaddr} imx-boot-libra-imx8mp-1-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+

4.3.2. Flash SPI NOR Flash from SD Card

+

The bootloader on SPI NOR flash can be also flashed with SD Card.

+
+

4.3.2.1. Flash SPI NOR from SD Card in kernel on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-libra-imx8mp-1-fspi.bin-flash_evk_flexspi to the first partition +on the SD Card.

    • +

  • Mount the SD Card:

    +
    target:~$ mount /dev/mmcblk1p1 /mnt
+
    +
    +
    • +

  • Find the number of blocks to erase of the U-Boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the u-boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-libra-imx8mp-1-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.2.2. Flash SPI NOR from SD Card in U-Boot on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-libra-imx8mp-1-fspi.bin-flash_evk_flexspi to the first partition +on the SD Card.

    • +

  • Before reading and writing are possible, the SPI-NOR flash +needs to be probed:

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • A specially formatted U-boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image from the SD Card, erase and write +the bootloader to the flash:

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-libra-imx8mp-1-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A6 RAUC Update & Device Management Manual.

+
+
+

4.5. EFI Boot

+

Standardboot in U-Boot also supports booting distros over efi. By default the +U-Boot will search for a bootscript first, which is used to boot our Ampliphy +distro. If it does not find any bootscript, it will search for bootable efi +applications. So for booting over efi just make sure you don’t have our distro +installed.

+
+

4.5.1. Disable booting with efi

+

To disable booting with efi you have to set the doefiboot variable to 0. +Also make sure you do not have efi or efi_mgr specified in the +bootmeths environment variable.

+
u-boot=> setenv doefiboot 0
+u-boot=> env save; env save;
+
+
+
+
+

4.5.2. Switch to only efi boot

+

If you want to only boot with efi, you can set the bootmeths environment +variable to efi. Also make sure you have the doefiboot environment variable +set to 1.

+
u-boot=> setenv bootmeths efi
+u-boot=> env save; env save;
+
+
+
+
+

4.5.3. Installing a distro

+

With efi you can install and boot different distros like openSUSE, Fedora or +Debian. First you have to get the iso Image from their website. For example:

+

https://cdimage.debian.org/debian-cd/current/arm64/iso-dvd/

+

Then copy the .iso file to a usb stick for example. Make sure you select the +correct device:

+
sudo dd if=file.iso of=/dev/sdx bs=1M conv=fsync status=progress
+
+
+

Insert the USB stick into the board and boot it. GRUB will then prompt you with +a menu where you can select what to do. Here select install. Then you have to +click through the installation menu. This is relatively straightforward and +differs a bit for every distro. You can install the distro for example to emmc +(mmc 2) or sdcard (mmc 1). Make sure you do not overwrite +your U-Boot during the install. Best to choose a different medium to install to +than the U-Boot is stored on. Otherwise manual partitioning will be required. +The automatic partitioning will start at the beginning of the disk. To not +overwrite the U-Boot, use an offset of 4MiB at the beginning of the disk.

+

During the Installation of Debian you will be asked, if you want to Force the +GRUB installation to the EFI removable media path. Select no. Also select no, +when you will be asked if you want to update the NVRAM variables. Otherwise the +grub-dummy installation step will fail and you will be sent back to the +“Force GRUB installation” prompt.

+

After the installation is complete, reboot the board and remove the +installation medium (USB-stick). The board should then boot the distro you +installed.

+

If that does not happen, check if there is a boot option set for the distro. +The easiest way is with the eficonfig command.

+
u-boot=> eficonfig
+
+
+

That will open a menu. Then you can select Edit Boot Option. It will show +you the current boot options. If this is empty or you don’t find your distro, +select Add Boot Option to add a new one. For debian for example you only +need to set the description and the file. You can enter whatever you want into +the description field. When you select the file field, you can select the disc +you installed the distro on and partition number one. For example +“mmc 2:1” for emmc, or “mmc 1:1” for sdcard. The file you +need to select is at EFI/debian/grubaa64.efi. After that save, quit and +reset the board. The board should then boot into debian.

+
+
+
+
+

5. Development

+

Starting with this release, the boot behaviour in U-Boot changes. Before, kernel +and device tree came as separate blobs. Now, both will be included in a single +FIT image blob. Further, the logic for booting the PHYTEC ampliphy distributions +is moved to a boot script which itself is part of a separate FIT image blob. +To revert to the old style of booting, you may do

+
run legacyboot
+
+
+
+

Note

+

This way of booting is deprecated and will be removed in the next release. +By default, booting via this command will return an error as kernel and +device tree are missing in the boot partition.

+
+
+

5.1. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone git://git.phytec.de/u-boot-imx)

+
+
+

5.1.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-imx and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    https://github.com/phytec/linux-phytec-imx
+
    +
    +
    • +

  • Our i.MX 8M Plus kernel is based on the linux-phytec-imx kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.1.2. Get the SDK

+

You can download the SDK here, or build it yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

After a successful build the SDK installer is deployed to build/deploy*/sdk.

+
+
+

5.1.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.x.sh
+host:~$ ./phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.x.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-xwayland/5.0.x):
+You are about to install the SDK to "/opt/ampliphy-vendor-xwayland/5.0.x". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.1.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.1.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.2. U-Boot standalone build

+
+

5.2.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag used in this release is called v2024.04_2.0.0-phy7

    • +

  • Check out the needed U-Boot tag:

    +
    host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2024.04_2.0.0-phy7
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.2.2. Get the needed binaries

+

To build the bootloader, you need to copy these files to your u-boot-imx +build directory and rename them to fit with mkimage script:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx8mp-fpsc.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +
+

If you already built our BSP with Yocto, you can get the +bl31-imx8mp-fpsc.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: BSP Images

+

Or you can download the files here: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/

+
+

Warning

+

Make sure you rename the files you need so that they are compatible with the +mkimage tool.

+
+
+
+

5.2.3. Build the bootloader

+
    +

  • build flash.bin (imx-boot):

    +
    host:~/u-boot-imx$ make imx8mp-libra_defconfig
+host:~/u-boot-imx$ make flash.bin
+
    +
    +
    • +
+
+
+

5.2.4. Flash the bootloader to a block device

+

The flash.bin can be found at u-boot-imx/ directory and now can be +flashed. A chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

E.g. flash SD card:

+
host:~/u-boot-imx$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables +“BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+

5.2.5. Build U-Boot With a Fixed RAM Size

+

If you cannot boot your system anymore because the hardware introspection in the +EEPROM is damaged or deleted, you can create a flash.bin with a fixed ram size. +You should still contact support and flash the correct EEPROM data, as this +could lead to unexpected behavior.

+

Follow the steps to get the U-boot sources and check the correct branch in the +Build U-Boot section.

+

Edit the file configs/imx8mp-libra_defconfig:

+
CONFIG_TARGET_IMX8MP_LIBRA=y
+CONFIG_IMX8MP_LIBRA_RAM_SIZE_FIX=y
+# CONFIG_IMX8MP_LIBRA_RAM_SIZE_1GB=y
+# CONFIG_IMX8MP_LIBRA_RAM_SIZE_2GB=y
+# CONFIG_IMX8MP_LIBRA_RAM_SIZE_4GB=y
+
+
+

Choose the correct RAM size as populated on the board and uncomment the line for +this ram size. +After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+
+

5.3. Kernel standalone build

+

The kernel is packaged in a FIT image together with the device tree. U-Boot has +been adapted to be able to load a FIT image and boot the kernel contained in it. +As a result, the kernel Image has to packaged in a FIT image.

+
+

5.3.1. Setup sources

+
    +

  • The used linux-phytec-imx branch can be found in the release notes

    • +

  • The tag needed for this release is called v6.6.23-2.0.0-phy10

    • +

  • Check out the needed linux-phytec-imx tag:

    +
    host:~$ git clone https://github.com/phytec/linux-phytec-imx
+host:~$ cd ~/linux-phytec-imx/
+host:~/linux-phytec-imx$ git fetch --all --tags
+host:~/linux-phytec-imx$ git checkout tags/v6.6.23-2.0.0-phy10
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-phytec-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-phytec-imx$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.3.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-phytec-imx$ make imx8_phytec_defconfig
+host:~/linux-phytec-imx$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-phytec-imx/arch/arm64/boot/Image.gz

    • +

  • The dtb can be found at +~/linux-phytec-imx/arch/arm64/boot/dts/freescale/imx8mp-libra-rdk-fpsc.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-phytec-imx$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.3.3. Package the kernel in a FIT image

+

To simply replace the kernel, you will need an image tree source (.its) +file. If you already built our BSP with Yocto, you can get the its file from the +directory mentioned here: BSP Images Or you can download the file here: +https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/

+

Copy the .its file to the current working directory, create a link to the kernel +image and create the final fitImage with mkimage.

+
host:~/linux-phytec-imx$ cp /path/to/yocto/deploydir/fitimage-its*.its .
+                  && ln -s arch/arm64/boot/Image.gz linux.bin
+                  && uboot-mkimage -f fitImage-its*.its fitImage
+
+
+
+
+

5.3.4. Copy FIT image and kernel modules to SD Card

+

When one-time boot via netboot is not sufficient, the FIT image along with the +kernel modules may be copied directly to a mounted SD card.

+
host:~/linux-phytec-imx$ cp fitImage /path/to/sdcard/boot/
+host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.4. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.4.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.4.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy-ampliphy-vendor-xwayland/images/libra-imx8mp-1/. For flashing a wic image to eMMC, +you will also need phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.

+
+
+

5.4.3. Prepare Target

+

Set the bootmode switch (S3) to USB Serial Download. Also, connect USB port +X5 (upper connector) to your host.

+
+
+

5.4.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via (X1), as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.4.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.4.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic
+
+
+
+
+

5.4.7. Flashing SPI NOR Flash via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b qspi imx-boot-libra-imx8mp-1-fspi.bin-flash_evk_flexspi
+
+
+

This will update the U-Boot on SPI NOR Flash but not the environment. You may need to erase the old +environment so the default environment of the new U-Boot gets loaded:

+
u-boot=> env erase
+u-boot=> reset
+
+
+
+
+
+

5.5. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.5.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.5.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.5.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.6. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.6.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel fitimage to your tftp directory:

    +
    host:~$ cp fitImage /srv/tftp
+
    +
    +
    • +

  • Copy the bootscript to your tftp directory:

    +
    host:~$ cp boot.scr.uimg /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-libra-imx8mp-1.rootfs.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.6.2. Set the bootenv.txt for Netboot

+

Create a bootenv.txt file in your tftp directory and write the following variables into it.

+
nfsroot=/srv/nfs
+overlays=<overlayconfignames>
+
+
+

<overlayconfignames> has to be replaced with the devicetree overlay config names that you want to use. +Separate the config names by hashtag. For example:

+
overlays=conf-example-overlay1.dtbo#conf-example-overlay2.dtbo
+
+
+
+

Tip

+

All supported devicetree overlays are in the device tree chapter. Or can be printed with:

+
host:~$ dumpimage -l fitImage
+
+
+
+
+
+

5.6.3. Network Settings on Target

+

To customize the targets ethernet configuration, please follow the description +here: Network Environment Customization

+
+
+

5.6.4. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> setenv boot_targets ethernet
+u-boot=> bootflow scan -lb
+
    +
    +
    • +
+
+
+
+

5.7. Accessing the Development states

+
+

5.7.1. Development state of current release

+

These release manifests exist to give you access to the development states +of the Yocto BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line:

+
host:~$ ./phyLinux init -p imx8mp-fpsc -r BSP-Yocto-NXP-i.MX8MP-FPSC-PD25.1.y
+
+
+

This will initialize a BSP that will track the latest development state of the +current release (BSP-Yocto-NXP-i.MX8MP-PD24.1.0). From now on repo sync in this folder +will pull all the latest changes from our Git repositories:

+
host:~$ repo sync
+
+
+
+
+

5.7.2. Development state of upcoming release

+

Also development states of upcoming releases can be accessed this way. +For this execute the following command and look for a release with a higher +PDXX.Y number than the latest one (BSP-Yocto-NXP-i.MX8MP-PD24.1.0) and .y at the +end:

+
host:~$ ./phyLinux init -p imx8mp-fpsc
+
+
+
+
+
+

5.8. Accessing the Latest Upstream Support

+

We have a vanilla manifest that makes use of the Yocto master branches (not an +NXP release), Linux, and U-Boot. This can be used to test the latest upstream +kernel/U-Boot.

+
+

Note

+

The master manifest reflects the latest state of development. This tends to +be broken from time to time. We try to fix the master on a regular basis.

+
+
host:~$ ./phyLinux init -p imx8mp-fpsc -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.9.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-qt6demo-image-libra-imx8mp-1.wic image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-qt6demo-image-libra-imx8mp-1.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-qt6demo-image-libra-imx8mp-1.wic image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-libra-imx8mp-1.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+

5.10. Switch back to legacyboot

+
+

Warning

+

As we switched to standardboot with fitimage as default, legacyboot is +deprecated. We kept the option to switch back to legacyboot for this +release, but it will be removed in the future.

+
+
+

5.10.1. Changes in Yocto

+

By default, the fitImage and bootscript will be deployed into the wic.xz Image. +To switch back to legacyboot, you need to replace the fitImage and bootscript +for the kernel image and the devicetrees. They are still in the deploy +folder from the Yocto build, so you can manually copy them to the boot +partition on your device. Otherwise you can do the following changes in Yocto +to get the kernel and devicetrees deployed in the Image again.

+

First create the variable KERNEL_DEVICETREE_DEPLOY. This can be done for +example in the local.conf file in your build directory conf/local.conf. +The variable is basically a copy of the KERNEL_DEVICETREE variable that is +set in conf/machine/libra-imx8mp-1.conf in meta-phytec but the freescale +at the beginning needs to be removed, so that only the devicetree filename are +left. In the end it should look something like this:

+
KERNEL_DEVICETREE_DEPLOY = " \
+     imx8mp-phyboard-pollux-rdk.dtb \
+     imx8mp-phyboard-pollux-isp-csi1.dtbo \
+     imx8mp-phyboard-pollux-isp-csi2.dtbo \
+     imx8mp-phyboard-pollux-isi-csi1.dtbo \
+     imx8mp-phyboard-pollux-isi-csi2.dtbo \
+     imx8mp-phyboard-pollux-peb-av-10.dtbo \
+     imx8mp-phyboard-pollux-peb-wlbt-05.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2-fpdlink-port1.dtbo \
+     imx8mp-phycore-no-eth.dtbo \
+     imx8mp-phycore-no-rtc.dtbo \
+     imx8mp-phycore-no-spiflash.dtbo \
+     imx8mp-phycore-rpmsg.dtbo \
+"
+
+
+

Then add this line:

+
IMAGE_BOOT_FILES:mx8m-nxp-bsp:append = " Image oftree ${KERNEL_DEVICETREE_DEPLOY}"
+
+
+
+

Note

+

A clean might be required for this to work.

+
bitbake -c cleanall phytec-qt6demo-image
+
+
+
+

Then start the build:

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

5.10.2. Changes in U-Boot environment

+

To re-enable legacyboot set the following variable:

+
uboot=> setenv dolegacyboot 1
+uboot=> env save; env save;
+uboot=> boot
+
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 8M Plus SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Board.dts - include the module dtsi file. Devices that come from the i.MX 8M Plus +SoC but are just routed down to the carrier board and used there are included +in this dts.

    • +

  • Overlay.dtso - enable/disable features depending on optional hardware that +may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10)

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 8 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the folder arch/arm64/boot/dts/freescale/.

+

Available overlays for libra-imx8mp-1.conf are:

+
imx8mp-isi-csi1.dtbo
+imx8mp-isi-csi2.dtbo
+imx8mp-isp-csi1.dtbo
+imx8mp-isp-csi2.dtbo
+imx8mp-libra-peb-av-10.dtbo
+imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+imx8mp-phycore-no-eth.dtbo
+imx8mp-phycore-no-rtc.dtbo
+imx8mp-phycore-no-spiflash.dtbo
+imx8mp-phycore-rpmsg.dtbo
+imx8mp-vm016-csi1.dtbo
+imx8mp-vm016-csi1-fpdlink.dtbo
+imx8mp-vm016-csi2.dtbo
+imx8mp-vm016-csi2-fpdlink.dtbo
+imx8mp-vm017-csi1.dtbo
+imx8mp-vm017-csi1-fpdlink.dtbo
+imx8mp-vm017-csi2.dtbo
+imx8mp-vm017-csi2-fpdlink.dtbo
+
+
+

Otherwise you can show the content of a FIT image including all overlay +configs in the FIT image with this command in Linux:

+
host:~$ dumpimage -l /boot/fitImage
+
+
+

or in U-Boot:

+
u-boot=> load mmc ${mmcdev}:1 ${loadaddr} fitImage
+u-boot=> iminfo
+
+
+

The usage of overlays can be configured during runtime in Linux or U-Boot. +Overlays are applied during the boot process in the bootloader after the +boot command is called and before the kernel is loaded. The next sections +explain the configuration in more detail.

+
+

6.2.2.1. Set ${overlays} variable

+

The ${overlays} U-Boot environment variable contains a number-sign (#) +separated list of overlays that will be applied during boot. The overlays +listed in the overlays variable must be included in the FIT image. Overlays set +in the $KERNEL_DEVICETREE Yocto machine variable will automatically be added to +the FIT image.

+

The ${overlays} variable can either be set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +When desired to use the overlays variable as set manually in the U-Boot +environment, disable bootenv by setting env set no_bootenv 1 as the overlays +variable may be overwritten during the execution of the boot script. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=conf-imx8mp-libra-rdk-fpsc-peb-eval-01.dtbo#conf-imx8mp-libra-peb-av-10.dtbo
+
+
+

Changes will take effect after the next reboot. If no bootenv.txt file is +available the overlays variable can be set directly in the U-Boot environment.

+
u-boot=> setenv overlays conf-imx8mp-libra-peb-av-10.dtbo
+u-boot=> printenv overlays
+overlays=conf-imx8mp-libra-peb-av-10.dtbo
+u-boot=> boot
+
+
+

If a user defined ${overlays} variable should be directly loaded from U-Boot +environment but there is still an external bootenv.txt available, the ${no_bootenv} +variable needs to be set as a flag:

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays conf-imx8mp-libra-peb-av-10.dtbo
+u-boot=> boot
+
+
+

More information about the external environment can be found in +U-boot External Environment subsection of the +device tree overlay section.

+

We use the ${overlays} variable for overlays describing expansion boards and +cameras that can not be detected during run time. To prevent applying overlays +unset the overlays variable and set no_bootenv to anything other than 0.

+
u-boot=> env delete overlays
+u-boot=> env set no_bootenv 1
+
+
+

If desired to use the bootenv.txt file for setting U-Boot variables other than +overlays and having overlays disabled, remove the overlays definition line from +the bootenv.txt file instead of setting no_bootenv.

+
+
+

6.2.2.2. SoM Variants

+

Additional overlays are applied automatically to disable components that are not +populated on the SoM. The detection is done with the EEPROM data (EEPROM SoM +Detection) found on the SoM i2c EEPROM.

+

It depends on the SoM variant if any device tree overlays will be applied. To check +if an overlay will be applied on the running SoM in U-Boot, run:

+
u-boot=> env print fit_extensions
+
+
+

If the EEPROM data is not available, no device tree overlays are applied.

+

To prevent application of the SoM variant related overlays the +${no_extensions} variable can be set to 1 in the bootloader environment:

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot External Environment

+

During the start of the Linux Kernel the external environment bootenv.txt +text file will be loaded from the boot partition of an MMC device or via TFTP. +The main intention of this file is to store the ${overlays} variable. This makes +it easy to pre-define the overlays in Yocto depending on the used machine. The +content from the file is defined in the Yocto recipe bootenv found in +meta-phytec: +https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=scarthgap

+

Other variables can be set in this file, too. They will overwrite the existing +settings in the environment. But only variables evaluated after issuing the boot +command can be overwritten, such as ${nfsroot} or ${mmcargs}. Changing other +variables in that file will not have an effect. See the usage during netboot as +an example.

+

If the external environment can not be loaded the boot process will be anyway +continued with the values of the existing environment settings.

+
+
+

6.2.4. Change U-boot Environment from Linux on Target

+

Libubootenv is a tool included in our images to modify the U-Boot environment of +Linux on the target machine.

+

Print the U-Boot environment using the following command:

+
target:~$ fw_printenv
+
+
+

Modify a U-Boot environment variable using the following command:

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

Caution

+

Libubootenv takes the environment selected in a configuration file. The +environment to use is inserted there, and by default it is configured to use +the eMMC environment (known as the default used environment).

+

If the eMMC is not flashed or the eMMC environment is deleted, libubootenv +will not work. You should modify the /etc/fw_env.config file to match the +environment source that you want to use.

+
+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 8M Plus BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 8M Plus BSP Device Tree Concept to get an understanding +of our i.MX 8 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 8 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 8M Plus Pin Muxing

+

The i.MX 8M Plus SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 8M Plus terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 8M Plus Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx8mp-libra-rdk-fpsc.dts:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x140
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x140
+        >;
+};
+
+
+

The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled.

+

The device tree representation for UART1 pinmuxing: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L373

+
+
+

7.2. RS232/RS485

+

The phyCORE-i.MX 8M Plus supports up to 4 UART units. On the Libra, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector X2 at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers JP3 and +JP4 on the baseboard. For more information about the correct setup please +refer to the phyCORE-i.MX 8M Plus/Libra Hardware Manual section UARTs.

+

We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers JP3 and JP4 need to be set +correctly.

+
+

7.2.1. RS232

+
    +

  • Display the current settings of a terminal in a human-readable format:

    +
    target:~$ stty -a
+
    +
    +
    • +

  • Configuration of the UART interface can be done with stty. For example:

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • With a simple echo and cat, basic communication can be tested. Example:

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

The host should print out “123”.

+
+
+

7.2.2. RS485

+
+

Hint

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

For easy testing, look at the linux-serial-test. This tool is called the IOCTL +for RS485 and sends a constant stream of data.

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

More information about the linux-serial-test tool and its parameters can be +found here: linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Documentation for calling the IOCTL within c-code is described in the Linux +kernel documentation: +https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection2.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see “test” printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final “count for this session”. There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+
+
+

7.2.2.2. RS485 full-duplex

+

For full-duplex mode your connection setup should look like this:

+../../../_images/RS485_fullduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For full-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 1
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  true
+Bus termination enabled:  false
+
+
+

Also here you can do the echo test to see if sending and receiving works:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see “test” printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

To check if the full-duplex operation works, you need to use the +linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=114660, tx=118755, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=118755, tx=114660, rx err=0
+
+
+

In this example both targets will send and receive simultaneously. They will +receive for 15sec and send for 10sec. The receiver needs to receive a bit +longer, so that all sent messages will get received. Remember to start both +targets almost simultaneously. A small difference in start time is accounted +for with the -W 2 option. At the end the program will print the final +“count for this session”. There you can check that all transmitted frames were +received.

+

All the test examples are target to target, but can also be done with host to +target with a USB to rs485 converter. You may need to adjust the interfaces for +commands to work on the host then.

+

The device tree representation for RS232 and RS485: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L412

+
+
+
+
+

7.3. Network

+

Libra-i.MX 8M Plus provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board.

+
+

Warning

+

The naming convention of the Ethernet interfaces in the hardware (ethernet0 +and ethernet1) do not align with the network interfaces (eth0 and eth1) in +Linux. So, be aware of these differences:

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L50.

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the Libra can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L179.

+
+

7.3.1. Network Environment Customization

+
+

7.3.1.1. U-boot network-environment

+
    +

  • To find the Ethernet settings in the target bootloader:

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • With your development host set to IP 192.168.3.10 and netmask 255.255.255.0, +the target should return:

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • If you need to make any changes:

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> should be one of ipaddr, netmask, gatewayip or serverip. +<value> will be the actual value of the chosen parameter.

    +
    • +

  • The changes you made are temporary for now. To save these:

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

Here you can also change the IP address to DHCP instead of using a static one.

+
    +

  • Configure:

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • Set up paths for TFTP and NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+

Tip

+

Variables like nfsroot and netargs can be overwritten by the U-boot External +Environment. For netboot, the external environment will be loaded from tftp. +For example, to locally set the nfsroot variable in a bootenv.txt file, +locate the tftproot directory:

+
nfsroot=/home/user/nfssrc
+
+
+

There is no need to store the info on the target. Please note that this does +not work for variables like ipaddr or serveraddr as they need to be already +set when the external environment is being loaded.

+
+
+
+

7.3.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. WLAN

+

WLAN and Bluetooth on the Libra are provided by the PEB-WLBT-05 expansion card. +The PEB-WLBT-05 for Libra Quickstart Guide shows you how to install the +PEB-WLBT-05.

+
+

Tip

+

With the BSP Version PD22.1 and newer, the PEB-WLBT-05 overlay needs to be activated first, +otherwise the PEB-WLBT-05 won’t be recognized.

+
target:~$ vi /boot/bootenv.txt
+
+
+

Afterwards the bootenv.txt file should look like this (it can also contain other devicetree +overlays!):

+
overlays=conf-imx8mp-libra-peb-wlbt-05.dtbo
+
+
+

The changes will be applied after a reboot:

+
target:~$ reboot
+
+
+

For further information about devicetree overlays, read the device tree chapter.

+
+

For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. Connecting to a WLAN Network

+

First set the correct regulatory domain for your country:

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

You will see:

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

Set up the wireless interface:

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

Now you can scan for available networks:

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection.

+

To do so, add the network-credentials to the file /etc/wpa_supplicant.conf:

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

Now a connection can be established:

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

This should result in the following output:

+
Successfully initialized wpa_supplicant
+
+
+

The ip address is automatically configured over DHCP. For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (scarthgap).

+
+
+
+

7.3.3. Bluetooth

+

Bluetooth is supported on Libra with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section.

+

Bluetooth is connected to UART3 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup.

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. Visibility

+

To activate visibility:

+
target:~$ hciconfig hci0 piscan
+
+
+

To disable visibility:

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. Connect

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

Note

+

If the connection fails with the error message: “Failed to connect: +org.bluez.Error.Failed” try restarting PulseAudio with:

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC Card

+

The i.MX 8M Plus supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L422

+

DT configuration for the eMMC interface can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L214

+
+
+

7.5. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 8M Plus is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw Multi-Level Cells (MLC) or Triple-Level +Cells (TLC) combined with a memory controller that handles ECC and wear +leveling. They are connected via an SD/MMC interface to the i.MX 8M Plus and are +represented as block devices in the Linux kernel like SD cards, flash drives, or +hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.5.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +or TLC. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background Operations +(BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • Enabling can be done with this command:

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.5.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 8M Plus SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.5.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
+
+

7.5.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC or TLC +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC used in NAND Flash, MLC or TLC have lower reliability and a higher +error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC or TLC +or mark these blocks as discard. The data on the device is lost and +will be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.5.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 8M Plus uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.5.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

The following table is for the offset of the i.MX 8M Plus SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.6. SPI Master

+

The i.MX 8M Plus controller has a FlexSPI and an ECSPI IP core included. The FlexSPI +host controller supports two SPI channels with up to 4 devices. Each channel +supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data +lines). The ECSPI controller supports 3 SPI interfaces with one dedicated chip +selected for each interface. As chip selects should be realized with GPIOs, more +than one device on each channel is possible.

+
+

7.6.1. SPI NOR Flash

+

phyCORE-i.MX 8M Plus is equipped with a QSPI NOR Flash which connects to the i.MX 8M Plus’s +FlexSPI interface. The QSPI NOR Flash is suitable for booting. Please see +different sections for flashing and bootmode setup. Due to limited space on the +SPI NOR Flash, only the bootloader is stored inside. By default, the kernel, +device tree, and rootfs are taken from eMMC.

+

The Bootloader does detect with the help of the EEPROM Introspection data if an +SPI flash is mounted or not. If no SPI flash is mounted a device tree overlay is +applied with the expansion command to disable the SPI flash device tree node +during boot. If no introspection data is available the SPI NOR flash node is +always enabled. Find more information in the device tree overlay section.

+

The bootloader also passes the SPI MTD partition table to Linux by fixing up the +device tree based on the mtdparts boot parameter. The default partition layout +in the BSP is set to:

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

This is a bootloader environment variable that is defined here and can be +changed during runtime. From Linux userspace, the NOR Flash partitions are +accessible via /dev/mtd<N> devices where <N> is the MTD device number associated +with the NOR flash partition to access. To find the correct MTD device number +for a partition, run on the target:

+
root@libra-imx8mp-1:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

It lists all MTD devices and the corresponding partition names. The flash node +is defined inside of the SPI master node in the module DTS. The SPI node +contains all devices connected to this SPI bus which is in this case only the +SPI NOR Flash.

+

The definition of the SPI master node in the device tree can be found here:

+

https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L76

+
+
+
+

7.7. GPIOs

+

The Libra has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to i.MX 8M Plus pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal i.MX 8M Plus GPIO banks GPIO1 – GPIO5.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO5_07). <X> identifies the GPIO +bank and counts from 1 to 5, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo -c gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 20 from chip0):

    +
    target:~$ gpioget -c gpiochip0 20
+
    +
    +
    • +

  • Set the value of GPIO 20 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset -z -c gpiochip0 20=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <line=value>...
+
+Set values of GPIO lines.
+
+Lines are specified by name, or optionally by offset if the chip option
+is provided.
+Values may be '1' or '0', or equivalently 'active'/'inactive' or 'on'/'off'.
+
+The line output state is maintained until the process exits, but after that
+is not guaranteed.
+
+Options:
+      --banner            display a banner on successful startup
+  -b, --bias <bias>       specify the line bias
+                  Possible values: 'pull-down', 'pull-up', 'disabled'.
+                  (default is to leave bias unchanged)
+      --by-name           treat lines as names even if they would parse as an offset
+  -c, --chip <chip>       restrict scope to a particular chip
+  -C, --consumer <name>   consumer name applied to requested lines (default is 'gpioset')
+  -d, --drive <drive>     specify the line drive mode
+                  Possible values: 'push-pull', 'open-drain', 'open-source'.
+                  (default is 'push-pull')
+  -h, --help              display this help and exit
+  -l, --active-low        treat the line as active low
+  -p, --hold-period <period>
+                  the minimum time period to hold lines at the requested values
+  -s, --strict            abort if requested line names are not unique
+  -t, --toggle <period>[,period]...
+                  toggle the line(s) after the specified period(s)
+                  If the last period is non-zero then the sequence repeats.
+      --unquoted  don't quote line names
+  -v, --version           output version information and exit
+  -z, --daemonize set values then detach from the controlling terminal
+
+Chips:
+    A GPIO chip may be identified by number, name, or path.
+    e.g. '0', 'gpiochip0', and '/dev/gpiochip0' all refer to the same chip.
+
+Periods:
+    Periods are taken as milliseconds unless units are specified. e.g. 10us.
+    Supported units are 's', 'ms', and 'us'.
+
+*Note*
+    The state of a GPIO line controlled over the character device reverts to default
+    when the last process referencing the file descriptor representing the device file exits.
+    This means that it's wrong to run gpioset, have it exit and expect the line to continue
+    being driven high or low. It may happen if given pin is floating but it must be interpreted
+    as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.7.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the defconfig you use in +arch/arm64/configs/ in the linux kernel sources. For our NXP based releases, +this could be for example imx8_phytec_distro.config:

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+
+
+
+

7.8. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the Libra.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L255

+
+
+

7.9. I²C Bus

+

The i.MX 8M Plus contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 8M Plus. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our Libra.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C1 bus configuration (e.g. imx8mp-phycore-fpsc.dtsi): +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L113

+

General I²C2 bus configuration (e.g. imx8mp-libra-rdk-fpsc.dts) +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L239

+
+
+

7.10. EEPROM

+

On the phyCORE-i.MX8MP-FPSC there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues.

+
+

Note

+

If you deleted reserved EEPROM spaces, please contact our support!

+
+
+

7.10.1. I2C EEPROM on phyCORE-i.MX8MP-FPSC

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

The I2C EEPROM on the phyCORE-i.MX8MP-FPSC SoM is connected to I2C address 0x51 on the I2C-0 +bus. It is possible to read and write directly to the device populated:

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the 4KiB EEPROM (bus: I2C-0 addr: 0x51) with zeros leaving out the EEPROM data use:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM Detection

+

The I2C EEPROM, populated on the phyCORE-i.MX8MP-FPSC, has a separate ID page that is +addressable over I2C address 0x59 on bus 0 and a normal area that is addressable +over I2C address 0x51 on bus 0. PHYTEC uses this data area of 32 Bytes to store +information about the SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the EEPROM ID page data and the first 256 bytes of the normal area are +deleted, the bootloader will fall back to the phyCORE-i.MX8MP-FPSC Kit RAM setup, which +is 2GiB RAM.

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

SoMs that are flashed with data format API revision 2 will print out information +about the module in the early stage.

+

DT representation, e.g. in phyCORE-i.MX 8M Plus file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L201

+
+
+
+

7.11. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC Wakealarm

+

It is possible to issue an interrupt from the RTC to wake up the system. The +format uses the Unix epoch time, which is the number of seconds since UTC +midnight on 1 January 1970. To wake up the system after 4 minutes from suspend +to ram state, type:

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

Note

+

Internally the wake alarm time will be rounded up to the next minute since +the alarm function doesn’t support seconds.

+
+
+
+

7.11.2. RTC Parameters

+

RTCs have a few abilities which can be read/set with the help of hwclock +tool.

+
    +

  • We can check RTC supported features with:

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    What this value means is encoded in kernel, each set bit translates to:

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • We can check RTC BSM (Backup Switchover Mode) with:

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • We can set RTC BSM with:

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    What BSM values mean translates to these values:

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    Tip

    +

    You should set BSM mode to DSM or LSM for RTC to switch to backup power +source when the initial power source is not available. Check RV-3028 RTC +datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching +Mode) actually mean.

    +
    +
    • +
+

DT representation for I²C RTCs: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L208

+
+
+
+

7.12. USB Host Controller

+

The USB controller of the i.MX 8M Plus SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +‘SS’). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY.

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+

DT representation for USB Host: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L380

+
+
+

7.13. CAN FD

+

The Libra has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The two CAN interfaces should show up as +can0 and can1.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    The information for can0 will look like:

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+
+

Warning

+

The mcp2518fd SPI to CANfd supports only baudrates starting from 125kB/s. +Slower rates can be selected but may not work correctly.

+
+

Device Tree CAN configuration of imx8mp-libra-rdk-fpsc.dts: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L203

+
+
+

7.14. PCIe

+

The phyCORE-i.MX 8M Plus has one Mini-PCIe slot. In general, PCIe autodetects new +devices on the bus. After connecting the device and booting up the system, you +can use the command lspci to see all PCIe devices recognized.

+
    +

  • Type:

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • You will receive:

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

In this example, the PCIe device is the Intel Corporation WiFi Link 5100.

+

For PCIe devices, you have to enable the correct driver in the kernel +configuration. This WLAN card, for example, is manufactured by Intel. The +option for the driver, which must be enabled, is named CONFIG_IWLWIFI and can be +found under Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimat in +the kernel configuration.

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • The linux-imx is represented by: virtual/kernel

      • +
    +
    • +
+

For some devices like the WLAN card, additional binary firmware blobs are +needed. These firmware blobs have to be placed in /lib/firmware/ before the +device can be used.

+
    +

  • Type:

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • For example, if you try to bring up the network interface:

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • You will get the following output on the serial console:

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

Tip

+

Some PCIe devices, e.g. the Ethernet card, may function properly even if no +firmware blob is loaded from /lib/firmware/ and you received an error message +as shown in the first line of the output above. This is because some +manufacturers provide the firmware as a fallback on the card itself. In this +case, the behavior and output depend strongly on the manufacturer’s firmware.

+
+

Device Tree PCIe configuration of imx8mp-libra-rdk-fpsc.dts: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L345

+
+
+

7.15. Audio

+

Playback devices supported for Libra are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals.

+
+

Note

+

Using the PEB-AV-10 connector for display output along HDMI as audio output +is not supported. The audio output device must match the video output device.

+
+

To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices:

+
target:~$ aplay -L
+
+
+

Or type for recording devices:

+
target:~$ arecord -L
+
+
+
+

7.15.1. Alsamixer

+

To inspect the capabilities of your soundcard, call:

+
target:~$ alsamixer
+
+
+

You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. “MM” means the feature is muted +(both output, left & right), which can be toggled by hitting ‘m’. You can also +toggle by hitting ‘<’ for left and ‘>’ for right output. With the tab +key, you can switch between controls for playback and recording.

+
+
+

7.15.2. Restore default volumes

+

There are some default settings stored in /var/lib/alsa/asound.state. +You can save your current alsa settings with:

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

You can restore saved alsa settings with:

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.15.3. ALSA configuration

+

Our BSP comes with a ALSA configuration file /etc/asound.conf.

+

The ALSA configuration file can be edited as desired or deleted since it is not +required for ALSA to work properly.

+
target:~$ vi /etc/asound.conf
+
+
+

To set PEB-AV-10 as output, set playback.pcm from “dummy” to “pebav10”:

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

If the sound is not audible change playback devices to the software volume control +playback devices, set playback.pcm to the respective softvol playback device e.g. +“softvol_pebav10”. Use alsamixer controls to vary the volume levels.

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.15.4. Pulseaudio Configuration

+

For applications using Pulseaudio, check for available sinks:

+
target:~$ pactl list short sinks
+
+
+

To select the output device, type:

+
target:~$ pactl set-default-sink <sink_number>
+
+
+
+
+

7.15.5. Playback

+

Run speaker-test to check playback availability:

+
target:~$ speaker-test -c 2 -t wav
+
+
+

To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds:

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

To playback other formats like mp3 for example, you can use Gstreamer:

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.15.6. Capture

+

arecord is a command-line tool for capturing audio streams which use Line In as +the default input source. To select a different audio source you can +use alsamixer. For example, switch on Right PGA Mixer Mic3R and Left PGA Mixer +Mic3R in order to capture the audio from the microphone input of the +TLV320-Codec using the 3.5mm jack.

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

Hint

+

Since playback and capture share hardware interfaces, it is not possible to +use different sampling rates and formats for simultaneous playback and +capture operations.

+
+

Device Tree Audio configuration: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L58

+
+
+
+

7.16. Video

+
+

7.16.1. Videos with Gstreamer

+

One example video is installed by default in the BSP at /usr/share/qtphy/videos/. +Start the video playback with one of these commands:

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.17. Display

+

The Libra supports up to 3 different display outputs. Two can be used +simultaneously. The following table shows the required extensions and devicetree +overlays for the different interfaces.

+ + + + + + + + + + + + + + + + + + + + + +

Interface

Expansion

devicetree overlay

HDMI

Libra

no overlay needed (enabled by default)

LVDS0

PEB-AV-10

imx8mp-libra-peb-av-10.dtbo +(loaded by default)

LVDS1

Libra

disabled if PEB-AV-10 overlay is used

+
+

Note

+
    +

  • When changing Weston output, make sure to match the audio output as well.

    • +

  • LVDS0 (PEB-AV-10) and LVDS1 (onboard)can not be used at the same time.

    • +
+
+

HDMI is always enabled in the devicetree. The other interfaces can be enabled +with Device Tree Overlay.

+

The default-enabled Interfaces are HDMI and LVDS0 (PEB-AV-010). We support a +10’’ edt,etml1010g0dka display for the PEB-AV-10.

+
+

Note

+

The current display driver limits the pixel clock for a display connected to +LVDS to 74.25Mhz (or a divider of it). If this does not fit your display +requirements, please contact Support for further help.

+
+
+

7.17.1. Weston Configuration

+

In order to get an output from Weston on the correct display, it still needs to +be configured correctly. This will be done at /etc/xdg/weston/weston.ini.

+
+

7.17.1.1. Single Display

+

In our BSP, the default Weston output is set to HDMI.

+
[output]
+name=HDMI-A-1
+mode=preferred
+
+[output]
+name=LVDS-1
+mode=off
+
+
+

When using the LVDS0 (PEB-AV-10) as output, set the output mode to off for +HDMI-A-1 and for LVDS-1 to current.

+
[output]
+name=HDMI-A-1
+mode=off
+
+[output]
+name=LVDS-1
+mode=current
+
+
+

If you want to use LVDS1 (onboard) then you need to load no overlay. Remove the +imx8mp-phyboard-pollux-peb-av-xxx.dtbo from bootenv.txt.

+
+
+

7.17.1.2. Dual Display

+
+

Note

+

For dual and triple display output you can not use LVDS1 (onboard) and HDMI +together.

+
+

For dual display in dual view mode at HDMI and LVDS0 (PEB-AV-10), both modes +have to be set to the:

+
[output]
+name=HDMI-A-1
+mode=preferred
+
+[output]
+name=LVDS-1
+mode=current
+
+
+
+
+
+

7.17.2. Qt Demo

+

With the phytec-qt6demo-image, Weston starts during boot. Our Qt6 demo application named +“qtphy” can be stopped with:

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • To start the demo again, run:

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • To disable autostart of the demo, run:

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • To enable autostart of the demo, run:

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston can be stopped with:

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

Note

+

The Qt demo must be closed before Weston can be closed.

+
+
+
+

7.17.3. Backlight Control

+

If a display is connected to the PHYTEC board, you can control its backlight +with the Linux kernel sysfs interface. All available backlight devices in the +system can be found in the folder /sys/class/backlight. Reading the appropriate +files and writing to them allows you to control the backlight.

+
+

Note

+

Some boards with multiple display connectors might have multiple backlight +controls in /sys/class/backlight. For example: backlight0 and backlight1

+
+
    +

  • To get, for example, the maximum brightness level (max_brightness) execute:

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    Valid brightness values are 0 to <max_brightness>.

    +
    • +

  • To obtain the current brightness level, type:

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • Write to the file brightness to change the brightness:

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    turns the backlight off for example.

    +

    For documentation of all files, see +https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight.

    +
    • +
+

Device tree description of LVDS-1 and HDMI can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L294 +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L218

+

The device tree of LVDS-0 on PEB-AV-10 can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L133

+
+
+
+

7.18. Power Management

+
+

7.18.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 8M Plus SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as ‘Dynamic Voltage and +Frequency Scaling’ (DVFS). The i.MX 8M Plus BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the i.MX 8 +variant used, several different frequencies are supported.

+
+

Tip

+

Although the DVFS framework provides frequency settings for each CPU core, a +change in the frequency settings of one CPU core always affects all other CPU +cores too. So all CPU cores always share the same DVFS setting. An individual +DVFS setting for each core is not possible.

+
+
    +

  • To get a complete list type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately +1,6 GHz, the result will be:

    +
    1200000 1600000
+
    +
    +
    • +

  • To ask for the current frequency type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

So-called governors are automatically selecting one of these frequencies in +accordance with their goals.

+
    +

  • List all governors available with the following command:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    The result will be:

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative is much like the ondemand governor. It differs in behavior in +that it gracefully increases and decreases the CPU speed rather than jumping +to max speed the moment there is any load on the CPU.

    • +

  • ondemand (default) switches between possible CPU core frequencies in +reference to the current system load. When the system load increases above a +specific limit, it increases the CPU core frequency immediately.

    • +

  • powersave always selects the lowest possible CPU core frequency.

    • +

  • performance always selects the highest possible CPU core frequency.

    • +

  • userspace allows the user or userspace program running as root to set a +specific frequency (e.g. to 1600000). Type:

    • +

  • In order to ask for the current governor, type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    You will normally get:

    +
    ondemand
+
    +
    +
    • +

  • Switching over to another governor (e.g. userspace) is done with:

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • Now you can set the speed:

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +Documentation/admin-guide/pm/cpufreq.rst.

+
+
+

7.18.2. CPU Core Management

+

The i.MX 8M Plus SoC can have multiple processor cores on the die. The i.MX 8M Plus, for +example, has 4 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    Here the system has four processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.18.3. Suspend to RAM

+

The phyCORE-i.MX8MP-FPSC supports basic suspend and resume. Different wake-up sources can be +used. Suspend/resume is possible with:

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

To wake up with serial console run

+
target:~$ echo enabled > /sys/class/tty/ttymxc0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.19. Thermal Management

+
+

7.19.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.19.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 8M Plus SoC platform. The i.MX 8 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Industrial +and Commercial.

+ + + + + + + + + + + + + + + + + +

Commercial

Industrial

passive (warning)

85°C

95°C

critical (shutdown)

90°C

100°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise, Fair Share, Bang Bang, and +Userspace. The default policy used in the BSP is step_wise. If the value of the +SoC temperature in the sysfs file temp is above trip_point_0, the CPU frequency +is set to the lowest CPU frequency. When the SoC temperature drops below +trip_point_0 again, the throttling is released.

+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+

7.19.3. GPIO Fan

+
+

Note

+

Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan +to GPIO fan due to availability. The PWM fan will not be supported +anymore and will not function with the new release.

+
+

A GPIO fan can be connected to the Libra-i.MX 8M Plus. The SoC only contains one +temperature sensor which is already used by the thermal frequency scaling. The +fan can not be controlled by the kernel. We use lmsensors with hwmon for this +instead. lmsensors reads the temperature periodically and enables or disables +the fan at a configurable threshold. For the Libra-i.MX 8M Plus, this is 60°C.

+

The settings can be configured in the configuration file:

+
/etc/fancontrol
+
+
+

Fan control is started by a systemd service during boot. This can be disabled +with:

+
target:~$ systemctl disable fancontrol
+
+
+

The device tree description of GPIO Fan can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L35

+
+
+
+

7.20. Watchdog

+

The PHYTEC i.MX 8M Plus modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.20.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.21. snvs Power Key

+

The X_ONOFF pin connected to the ON/OFF button can be pressed long to trigger +Power OFF without SW intervention or used to wake up the system out of suspend. +With the snvs_pwrkey driver, the KEY_POWER event is also reported to userspace +when the button is pressed. On default, systemd is configured to ignore such +events. The function of Power OFF without SW intervention and the wake-up from +suspend are not configured. Triggering a power off with systemd when pushing the +ON/OFF button can be configured under /etc/systemd/logind.conf and set using:

+
HandlePowerKey=poweroff
+
+
+
+
+

7.22. NPU

+

The i.MX 8M Plus SoC contains a Neural Processing Unit up to 2.3 TOPS as an accelerator +for artificial intelligence operations. Refer to our latest phyCORE-i.MX 8M Plus AI Kit +Guide on the phyCORE-i.MX 8M Plus download section to get information about the +NPU: L-1015e.A1 phyCORE-i.MX 8M Plus AI Kit Guide

+
+
+

7.23. ISP

+

The i.MX 8M Plus SoC contains an Image Signal Processor (ISP). For more information see +Using the ISPs on the Libra i.MX 8M Plus documentation. This documentation is also +available in German.

+
+
+

7.24. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 8M Plus provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 8M Plus Reference Manual). The following list is +an abstract from the i.MX 8M Plus Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x30350000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x30350000

Description

OCOTP_MAC_ADDR0

9

0

0x640

contains lower 32 bits +of ENET0 MAC address

OCOTP_MAC_ADDR1

9

1

0x650

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

OCOTP_MAC_ADDR2

9

2

0x660

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 8M Plus Security Reference Manual.

+
+

7.24.1. Reading Fuse Values in uBoot

+

You can read the content of a fuse using memory-mapped shadow registers. To +calculate the memory address, use the fuse Bank and Word in the following +formula:

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.24.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+
+

8. i.MX 8M Plus M7 Core

+

In addition to the Cortex-A53 cores, there is a Cortex-M7 Core as MCU +integrated into the i.MX 8M Plus SoC. Our Yocto-Linux-BSP runs on the A53-Cores and +the M7 Core can be used as a secondary core for additional tasks using +bare-metal or RTOS firmware. +Both cores have access to the same peripherals and thus peripheral +usage needs to be limited either in the M7 Core’s firmware or the devicetree +for the Linux operating system. This section describes how to build firmware +examples and how to run them on Libra.

+

The Libra is currently supported by the NXP MCUXpresso SDK and by +The Zephyr Project. This section only describes the NXP MCUXpresso SDK because +the MCUXpresso SDK has more supported features at the moment.

+

If you want to use the M7 Core with The Zephyr Project, please refer to the +The Zephyr Project documentation:

+ +
+

8.1. Getting the Firmware Examples

+

The firmware can be built using the NXP MCUxpresso SDK with a compatible +compiler toolchain using command-line tools.

+
+

8.1.1. Getting the Sources

+

The MCUX SDK and the examples for the i.MX 8M Plus can be obtained from PHYTEC’s GitHub +page:

+ +
    +

  1. Initialize the MCUX SDK via west:

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    This will create a mcuxsdk directory with the mcux-sdk repository in it. +The mcux-sdk-phytec-examples repository will be automatically cloned into +the mcuxsdk directory. +The given argument <VERSION> is a the branch name of the mcux-sdk repository +that represents the MCUX SDK version. For the newest tested version +you can use 2.13.0.

    +
    +

    Note

    +

    west is a repository management tool and a part of the Zephyr +Project. +To install west, you can use pip. In this example west is installed in +a python virtual environment:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. Update the dependencies:

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    The directory examples-phytec contains all examples ported and tested +for Libra with version 2.13.0 of MCUX.

    +

    To build the firmware, a compiler toolchain and make/cmake are required. +The GNU Arm Embedded Toolchain may be available in your distribution’s +repositories, e.g. for Ubuntu.

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    The compiler toolchain can also be obtained directly from +https://developer.arm.com/. After the archive has been extracted, +the ARMGCC_DIR has to be added to the environment, e.g. for the +ARM toolchain 10-2020-q4-major release located in the home directory:

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. Building the Firmware

+

To build the PHYTEC samples an environment has to be sourced

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

The scripts to build the firmware are located in +<sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc. +There are scripts for each memory location the firmware is supposed to run in, +e.g.

+
host:~$ ./build_release.sh
+
+
+

to build the firmware for the M7 Core’s TCM. The output will be placed under +release/ in the armgcc directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+

To build the firmware for the DRAM, run the script build_ddr_release. +The script of the firmware that is supposed to run, e.g.

+
host:~$ ./build_ddr_release.sh
+
+
+

The output will be placed under ddr_release/ in the armgcc +directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+
+
+
+

8.2. Running M7 Core Examples

+

There are two ways to run the M7 Core with the built firmware, U-Boot and +Remoteproc within a running Linux.

+

To receive debug messages start your favorite terminal software (e.g. Minicom, +Tio, or Tera Term) on your host PC and configure it for 115200 baud, 8 data +bits, no parity, and 1 stop bit (8n1) with no handshake.

+

Once a micro-USB cable is connected to the USB-debug port on the Libra, two +ttyUSB devices are registered. One prints messages from A53-Core’s debug UART +and the other one from the M7 Core’s debug UART.

+
+

8.2.1. Running Examples from U-Boot

+

To load firmware using the bootloader U-Boot, the bootaux command can be used:

+
    +

  1. Prepare an SD Card with our Yocto-BSP

    2. +

  2. Copy the generated .bin file to the SD Cards first partition

    3. +

  3. Stop the autoboot by pressing any key

    4. +

  4. Type the command depending on the type of firmware:

    5. +
+

For firmware built to run in the M7 Core’s TCM:

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

For firmware built to run in the DRAM:

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

The program’s output should appear on the M7 Core’s debug UART.

+
+
+

8.2.2. Running Examples from Linux using Remoteproc

+

Remoteproc is a module that allows you to control the M7 Core from Linux +during runtime. Firmware built for TCM can be loaded and the execution started +or stopped. To use Remoteproc a devicetree overlay needs to be set:

+

Edit the bootenv.txt file located in the /boot directory on the target by +adding conf-imx8mp-phycore-fpsc-rpmsg.dtbo:

+
overlays=conf-imx8mp-phycore-fpsc-rpmsg.dtbo
+
+
+

Restart the target and execute in U-Boot:

+
u-boot=> run prepare_mcore
+
+
+

Firmware .elf files for the M7 Core can be found under /lib/firmware. +To load the firmware, type:

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

To load a different firmware, the M7 Core needs to be stopped:

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

Note

+

The samples found in /lib/firmware on the target come from NXP’s +Yocto layer meta-imx. +To use the samples you built yourself through MCUX SDK, please copy them +to /lib/firmware on the target after building them.

+
+
+ +
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.html b/previews/271/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.html new file mode 100644 index 000000000..c6d070833 --- /dev/null +++ b/previews/271/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.html @@ -0,0 +1,242 @@ + + + + + + + + + Libra i.MX 8M Plus FPSC Manuals — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

Libra i.MX 8M Plus FPSC Manuals

+ +
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mp/head.html b/previews/271/bsp/imx8/imx8mp/head.html new file mode 100644 index 000000000..ebab2d77c --- /dev/null +++ b/previews/271/bsp/imx8/imx8mp/head.html @@ -0,0 +1,4904 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + + + + + +

L-1017e.Ax i.MX 8M Plus BSP +ManualHead

Document Title

L-1017e.Ax i.MX 8M Plus BSP +Manual Head

Document Type

BSP Manual

Article Number

L-1017e.Ax

Yocto Manual

Release Date

XXXX/XX/XX

Is Branch of

L-1017e.Ax i.MX 8M Plus BSP +Manual Head

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +phyCORE-i.MX8M Plus Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads of our product.

+
+

1.1. Supported Hardware

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-NXP-i.MX8MP-PD24.1.0 download.

+

If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware

+
+

1.1.1. phyBOARD-Pollux Components

+
+../../../_images/phyBOARD-Pollux-front-components.jpg + +
+

phyBOARD-Pollux Components (top)

+
+
+
+../../../_images/phyBOARD-Pollux-back-components.jpg + +
+

phyBOARD-Pollux Components (bottom)

+
+
+
+
+
+
+

2. Getting Started

+

The phyCORE-i.MX8M Plus Kit is shipped with a pre-flashed SD card. It contains the +phytec-qt6demo-image and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+

There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool dd. An +alternative way is to use PHYTEC’s system initialization program called +partup, which makes it especially easy to +format more complex systems. You can get prebuilt Linux binaries of partup from its release page. Also read +partup’s README for installation +instructions.

+
+

2.1. Get the Image

+

The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using dd, can be downloaded from the PHYTEC download server.

+

Get either the partup package or the WIC image from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+
+

Note

+

For eMMC, more complex partitioning schemes or even just large images, we +recommend using the partup package, as it is faster in writing than dd +and allows for a more flexible configuration of the target flash device.

+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card, you must have root privileges on your Linux +host PC. Be very careful when specifying the destination device! All files +on the selected device will be erased immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system on your host PC!

+
+
+

2.2.1. Finding the Correct Device

+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+

Unmount all those partitions, e.g.:

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

Now, the SD card is ready to be flashed with an image, using either partup, +dd or bmap-tools.

+
+
+

2.2.2. Using bmap-tools

+

One way to prepare an SD card is using +bmap-tools. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host:~$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

Replace <your_device> with your actual SD card’s device name found previously, +and make sure to place the file <IMAGENAME>-<MACHINE>.wic.bmap alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip.

+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.2.3. Using partup

+

Writing to an SD card with partup is done in a single command:

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).partup /dev/<your_device>
+
+
+

Make sure to replace <your_device> with your actual device name found previously.

+

Further usage of partup is explained at its official documentation website.

+
+

Warning

+

Host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to write partup packages created with Yocto Mickledore +or newer to SD-Card. This is due to a new default option in resize2fs which causes an +incompatibility. See release notes.

+
+
+

Note

+

partup has the advantage of allowing to clear specific raw areas in the +MMC user area, which is used in our provided partup packages to erase any +existing U-Boot environments. This is a known issue bmaptool does not +solve, as mentioned in the previous chapter.

+

Another key advantage of partup over other flashing tools is that it allows +configuring MMC specific parts, like writing to eMMC boot partitions, without +the need to call multiple other commands when writing.

+
+
+
+

2.2.4. Using dd

+

After having unmounted all SD card’s partitions, you can create your bootable SD card.

+

Some PHYTEC BSPs produce uncompressed images (with filename-extension *.wic), +and some others produce compressed images (with filename-extension *.wic.xz).

+

To flash an uncompressed images (*.wic) use command below:

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Or to flash a compressed images (*.wic.xz) use that command:

+
host:~$ xzcat phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Again, make sure to replace <your_device> with your actual device name found +previously.

+

The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

+
+
+
+

2.3. First Start-up

+ +../../../_images/SD_Card_Boot2.png +
    +

  • Insert the SD card

    • +

  • Connect the target and the host with mirco USB on (X1) +debug USB

    • +

  • Power up the board

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (scarthgap).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (scarthgap).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-IMX8MP; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-xwayland MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD24.1.0
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the phyboard-pollux-imx8mp-3 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx8mp.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, +lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY firmware images

    • +

  • imx-boot: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM +Trusted Firmware and DDR firmware. This is the final bootloader image which is +bootable.

    • +

  • fitImage: Linux kernel FIT image

    • +

  • fitImage-its*.its

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx8mp-phyboard-pollux-rdk*.dtb: Kernel device tree file

    • +

  • imx8mp-phy*.dtbo: Kernel device tree overlay files

    • +

  • phytec-qt6demo-image*.tar.gz: Root file system

    • +

  • phytec-qt6demo-image*.rootfs.wic.xz: compressed SD card image

    • +
+
+
+
+
+

4. Installing the OS

+
+

4.1. Bootmode Switch (S3)

+
+

Tip

+

Hardware revision baseboard: 1552.2

+
+

The phyBOARD-Pollux features a boot switch with four individually switchable ports to +select the phyCORE-i.MX 8M Plus default bootsource.

+ + + + + + + + + + + +
+../../../_images/eMMC2.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses2.png +
+

Internal Fuses

+
+
+
+../../../_images/SPI_NOR2.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download3.png +
+

USB Serial Download

+
+
+
+../../../_images/SD_Card_Boot2.png +
+

SD Card

+
+
+
+../../../_images/Test_Mode.png +
+

Test Mode

+
+
+
+
+
+

4.2. Flash eMMC

+

For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see Setup Network Host.

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S3) is set to eMMC.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk2p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from Network

+

i.MX 8M Plus boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

4.2.1.1. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Show your available image files on the host:

+
host:~$ ls /srv/tftp
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
+
+

Send the image with the bmaptool command combined with ssh through the network +to the eMMC of your device:

+
host:~$ scp /srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2"
+
+
+
+
+

4.2.1.2. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Take a compressed or decompressed image with the accompanying block map file +*.bmap on the host and send it with ssh through the network to the eMMC of +the target with a one-line command:

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.* /tmp && bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
+
+
+
+

4.2.1.3. Flash eMMC from Network in U-Boot on Target

+

These steps will show how to update the eMMC via a network.

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE.

+
+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Uncompress your image

+
host:~$ unxz /srv/tftp/phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+

Load your image via network to RAM:

+
    +

  • when using dhcp

    +
    u-boot=> dhcp phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.1 (1 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.1
+Filename 'phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • when using a static ip address (serverip and ipaddr must be set +additionally).

    +
    u-boot=> tftp ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
+
+
+
+
+

4.2.2. Flash eMMC U-Boot image via Network from running U-Boot

+

Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.3. Flash eMMC from USB stick

+
+

4.2.3.1. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.|yocto-imageext|). Set the bootmode switch (S3) to SD Card.

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ ls /mnt
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without partition):

    +
    target:~$ bmaptool copy /mnt/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Tip

    +

    Before this will work, you need to configure the bootmode switch (S3) to +eMMC.

    +
    +
    • +
+
+
+

4.2.3.2. Flash eMMC from USB stick in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE.

+
+

These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch (S3) to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied uncompressed WIC image to +the USB slot.

+

Load your image from the USB device to RAM:

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 0x58000000 phytec-headless-image-|yocto-machinename|.rootfs.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write 0x58000000 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+
+

4.2.4. Flash eMMC from SD Card

+

Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (*.wic) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see Resizing ext4 Root Filesystem.

+

Alternatively, flash a partup package to the SD card, as described in +Getting Started. This will ensure the full space of the SD card is used.

+
+

4.2.4.1. Flash eMMC from SD card in Linux on Target

+

You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card.

+
    +

  • Show your saved partup package or WIC image files on the SD card:

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without +partition) using partup:

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup /dev/mmcblk2
+
    +
    +

    Flashing the partup package has the advantage of using the full capacity of +the eMMC device, adjusting partitions accordingly.

    +
    +

    Note

    +

    Alternatively, bmaptool may be used instead:

    +
    target:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
    +
    +

    Keep in mind that the root partition does not make use of the full space when +flashing with bmaptool.

    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Warning

    +

    Before this will work, you need to configure the bootmode switch (S3) to eMMC.

    +
    +
    • +
+
+
+

4.2.4.2. Flash eMMC from SD card in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE. If the +image file is too large use the Updating eMMC from SD card in +Linux on Target subsection.

+
+
    +

  • Flash an SD card with a working image and create a third ext4 partition. Copy +the WIC image (for example phytec-qt6demo-image.rootfs.wic) to this +partition.

    • +

  • Configure the bootmode switch (S3) to SD Card and insert the SD Card.

    • +

  • Power on the board and stop in U-Boot.

    • +

  • Load the image:

    +
    u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • Switch the mmc dev to eMMC:

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • Flash your WIC image (for example phytec-qt6demo-image.rootfs.wic) +from the SD card to eMMC. This will partition the card and copy imx-boot, +Image, dtb, dtbo, and root file system to eMMC.

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • Power off the board and change the bootmode switch (S3) to eMMC.

    • +
+
+
+
+
+

4.3. Flash SPI NOR Flash

+

The phyCORE-i.MX8MP modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set bootmode switch (S3) to SPI NOR. The SPI Flash is usually quite small. +The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash populated. Only the +bootloader and the environment can be stored. The kernel, device tree, and file +system are taken from eMMC by default.

+

The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with:

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. Flash SPI NOR Flash from Network

+

The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-i.MX 8M Plus.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+
+

4.3.1.1. Flash SPI NOR from Network in kernel on Target

+
    +

  • Copy the image from the host to the target:

    +
    host:~$ scp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • Find the number of blocks to erase of the U-boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the U-Boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.1.2. Flash SPI NOR from Network in U-Boot on Target

+

Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI NOR flash needs to be probed:

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • A specially formatted U-Boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image over tftp, erase and write the +bootloader to the flash:

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+

4.3.2. Flash SPI NOR Flash from SD Card

+

The bootloader on SPI NOR flash can be also flashed with SD Card.

+
+

4.3.2.1. Flash SPI NOR from SD Card in kernel on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi to the first partition +on the SD Card.

    • +

  • Mount the SD Card:

    +
    target:~$ mount /dev/mmcblk1p1 /mnt
+
    +
    +
    • +

  • Find the number of blocks to erase of the U-Boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the u-boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.2.2. Flash SPI NOR from SD Card in U-Boot on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi to the first partition +on the SD Card.

    • +

  • Before reading and writing are possible, the SPI-NOR flash +needs to be probed:

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • A specially formatted U-boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image from the SD Card, erase and write +the bootloader to the flash:

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A6 RAUC Update & Device Management Manual.

+
+
+

4.5. EFI Boot

+

Standardboot in U-Boot also supports booting distros over efi. By default the +U-Boot will search for a bootscript first, which is used to boot our Ampliphy +distro. If it does not find any bootscript, it will search for bootable efi +applications. So for booting over efi just make sure you don’t have our distro +installed.

+
+

4.5.1. Disable booting with efi

+

To disable booting with efi you have to set the doefiboot variable to 0. +Also make sure you do not have efi or efi_mgr specified in the +bootmeths environment variable.

+
u-boot=> setenv doefiboot 0
+u-boot=> env save; env save;
+
+
+
+
+

4.5.2. Switch to only efi boot

+

If you want to only boot with efi, you can set the bootmeths environment +variable to efi. Also make sure you have the doefiboot environment variable +set to 1.

+
u-boot=> setenv bootmeths efi
+u-boot=> env save; env save;
+
+
+
+
+

4.5.3. Installing a distro

+

With efi you can install and boot different distros like openSUSE, Fedora or +Debian. First you have to get the iso Image from their website. For example:

+

https://cdimage.debian.org/debian-cd/current/arm64/iso-dvd/

+

Then copy the .iso file to a usb stick for example. Make sure you select the +correct device:

+
sudo dd if=file.iso of=/dev/sdx bs=1M conv=fsync status=progress
+
+
+

Insert the USB stick into the board and boot it. GRUB will then prompt you with +a menu where you can select what to do. Here select install. Then you have to +click through the installation menu. This is relatively straightforward and +differs a bit for every distro. You can install the distro for example to emmc +(mmc 2) or sdcard (mmc 1). Make sure you do not overwrite +your U-Boot during the install. Best to choose a different medium to install to +than the U-Boot is stored on. Otherwise manual partitioning will be required. +The automatic partitioning will start at the beginning of the disk. To not +overwrite the U-Boot, use an offset of 4MiB at the beginning of the disk.

+

During the Installation of Debian you will be asked, if you want to Force the +GRUB installation to the EFI removable media path. Select no. Also select no, +when you will be asked if you want to update the NVRAM variables. Otherwise the +grub-dummy installation step will fail and you will be sent back to the +“Force GRUB installation” prompt.

+

After the installation is complete, reboot the board and remove the +installation medium (USB-stick). The board should then boot the distro you +installed.

+

If that does not happen, check if there is a boot option set for the distro. +The easiest way is with the eficonfig command.

+
u-boot=> eficonfig
+
+
+

That will open a menu. Then you can select Edit Boot Option. It will show +you the current boot options. If this is empty or you don’t find your distro, +select Add Boot Option to add a new one. For debian for example you only +need to set the description and the file. You can enter whatever you want into +the description field. When you select the file field, you can select the disc +you installed the distro on and partition number one. For example +“mmc 2:1” for emmc, or “mmc 1:1” for sdcard. The file you +need to select is at EFI/debian/grubaa64.efi. After that save, quit and +reset the board. The board should then boot into debian.

+
+
+
+
+

5. Development

+

Starting with this release, the boot behaviour in U-Boot changes. Before, kernel +and device tree came as separate blobs. Now, both will be included in a single +FIT image blob. Further, the logic for booting the PHYTEC ampliphy distributions +is moved to a boot script which itself is part of a separate FIT image blob. +To revert to the old style of booting, you may do

+
run legacyboot
+
+
+
+

Note

+

This way of booting is deprecated and will be removed in the next release. +By default, booting via this command will return an error as kernel and +device tree are missing in the boot partition.

+
+
+

5.1. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone git://git.phytec.de/u-boot-imx)

+
+
+

5.1.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-imx and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    https://github.com/phytec/linux-phytec-imx
+
    +
    +
    • +

  • Our i.MX 8M Plus kernel is based on the linux-phytec-imx kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.1.2. Get the SDK

+

You can download the SDK here, or build it yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

After a successful build the SDK installer is deployed to build/deploy*/sdk.

+
+
+

5.1.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.x.sh
+host:~$ ./phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.x.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-xwayland/5.0.x):
+You are about to install the SDK to "/opt/ampliphy-vendor-xwayland/5.0.x". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.1.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.1.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.2. U-Boot standalone build

+
+

5.2.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag used in this release is called v2024.04_2.0.0-phy7

    • +

  • Check out the needed U-Boot tag:

    +
    host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2024.04_2.0.0-phy7
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.2.2. Get the needed binaries

+

To build the bootloader, you need to copy these files to your u-boot-imx +build directory and rename them to fit with mkimage script:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx8mp.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +
+

If you already built our BSP with Yocto, you can get the +bl31-imx8mp.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: BSP Images

+

Or you can download the files here: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/

+
+

Warning

+

Make sure you rename the files you need so that they are compatible with the +mkimage tool.

+
+
+
+

5.2.3. Build the bootloader

+
    +

  • build flash.bin (imx-boot):

    +
    host:~/u-boot-imx$ make phycore-imx8mp_defconfig
+host:~/u-boot-imx$ make flash.bin
+
    +
    +
    • +
+
+
+

5.2.4. Flash the bootloader to a block device

+

The flash.bin can be found at u-boot-imx/ directory and now can be +flashed. A chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

E.g. flash SD card:

+
host:~/u-boot-imx$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables +“BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+

5.2.5. Build U-Boot With a Fixed RAM Size

+

If you cannot boot your system anymore because the hardware introspection in the +EEPROM is damaged or deleted, you can create a flash.bin with a fixed ram size. +You should still contact support and flash the correct EEPROM data, as this +could lead to unexpected behavior.

+

Follow the steps to get the U-boot sources and check the correct branch in the +Build U-Boot section.

+

Edit the file configs/phycore-imx8mp_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+
+
+

Choose the correct RAM size as populated on the board and uncomment the line for +this ram size. +After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+

5.2.6. Build U-Boot With a Fixed RAM Size and Frequency

+

Starting with PD23.1.0 NXP or PD24.1.2 mainline release, the phyCORE-i.MX 8M Plus SoMs +with revision 1549.3 and newer also support 2GHz RAM timings. These will be +enabled for supported boards automatically, but they can also be enabled or +disabled manually.

+

Edit the file configs/phycore-imx8mp_defconfig. +The fixed RAM size with 2GHz timings will be used:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+CONFIG_PHYCORE_IMX8MP_RAM_FREQ_FIX=y
+CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+
+
+

After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+

5.2.7. Build U-Boot With a Fixed RAM Frequency

+

Starting with PD24.1.2 mainline release or PD24.1.0 NXP release, U-Boot can +also be built with just fixed RAM Frequency while the RAM size will still be +used from EEPROM.

+

Edit the file configs/phycore-imx8mp_defconfig. +The RAM size from EEPROM with fixed frequency will be used:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_FREQ_FIX=y
+# CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+# CONFIG_PHYCORE_IMX8MP_USE_1_5GHZ_RAM_TIMINGS=y
+
+
+

After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+
+

5.3. Kernel standalone build

+

The kernel is packaged in a FIT image together with the device tree. U-Boot has +been adapted to be able to load a FIT image and boot the kernel contained in it. +As a result, the kernel Image has to packaged in a FIT image.

+
+

5.3.1. Setup sources

+
    +

  • The used linux-phytec-imx branch can be found in the release notes

    • +

  • The tag needed for this release is called v6.6.23-2.0.0-phy10

    • +

  • Check out the needed linux-phytec-imx tag:

    +
    host:~$ git clone https://github.com/phytec/linux-phytec-imx
+host:~$ cd ~/linux-phytec-imx/
+host:~/linux-phytec-imx$ git fetch --all --tags
+host:~/linux-phytec-imx$ git checkout tags/v6.6.23-2.0.0-phy10
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-phytec-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-phytec-imx$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.3.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-phytec-imx$ make imx8_phytec_defconfig
+host:~/linux-phytec-imx$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-phytec-imx/arch/arm64/boot/Image.gz

    • +

  • The dtb can be found at +~/linux-phytec-imx/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-phytec-imx$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.3.3. Package the kernel in a FIT image

+

To simply replace the kernel, you will need an image tree source (.its) +file. If you already built our BSP with Yocto, you can get the its file from the +directory mentioned here: BSP Images Or you can download the file here: +https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/

+

Copy the .its file to the current working directory, create a link to the kernel +image and create the final fitImage with mkimage.

+
host:~/linux-phytec-imx$ cp /path/to/yocto/deploydir/fitimage-its*.its .
+                  && ln -s arch/arm64/boot/Image.gz linux.bin
+                  && uboot-mkimage -f fitImage-its*.its fitImage
+
+
+
+
+

5.3.4. Copy FIT image and kernel modules to SD Card

+

When one-time boot via netboot is not sufficient, the FIT image along with the +kernel modules may be copied directly to a mounted SD card.

+
host:~/linux-phytec-imx$ cp fitImage /path/to/sdcard/boot/
+host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.4. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.4.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.4.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy-ampliphy-vendor-xwayland/images/phyboard-pollux-imx8mp-3/. For flashing a wic image to eMMC, +you will also need phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.

+
+
+

5.4.3. Prepare Target

+

Set the bootmode switch (S3) to USB Serial Download. Also, connect USB port +X5 (upper connector) to your host.

+
+
+

5.4.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via (X1), as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.4.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.4.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
+
+
+
+

5.4.7. Flashing SPI NOR Flash via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b qspi imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+
+
+

This will update the U-Boot on SPI NOR Flash but not the environment. You may need to erase the old +environment so the default environment of the new U-Boot gets loaded:

+
u-boot=> env erase
+u-boot=> reset
+
+
+
+
+
+

5.5. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.5.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.5.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.5.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.6. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.6.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel fitimage to your tftp directory:

    +
    host:~$ cp fitImage /srv/tftp
+
    +
    +
    • +

  • Copy the bootscript to your tftp directory:

    +
    host:~$ cp boot.scr.uimg /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.6.2. Set the bootenv.txt for Netboot

+

Create a bootenv.txt file in your tftp directory and write the following variables into it.

+
nfsroot=/srv/nfs
+overlays=<overlayconfignames>
+
+
+

<overlayconfignames> has to be replaced with the devicetree overlay config names that you want to use. +Separate the config names by hashtag. For example:

+
overlays=conf-example-overlay1.dtbo#conf-example-overlay2.dtbo
+
+
+
+

Tip

+

All supported devicetree overlays are in the device tree chapter. Or can be printed with:

+
host:~$ dumpimage -l fitImage
+
+
+
+
+
+

5.6.3. Network Settings on Target

+

To customize the targets ethernet configuration, please follow the description +here: Network Environment Customization

+
+
+

5.6.4. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> setenv boot_targets ethernet
+u-boot=> bootflow scan -lb
+
    +
    +
    • +
+
+
+
+

5.7. Accessing the Development states

+
+

5.7.1. Development state of current release

+

These release manifests exist to give you access to the development states +of the Yocto BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line:

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD24.1.y
+
+
+

This will initialize a BSP that will track the latest development state of the +current release (BSP-Yocto-NXP-i.MX8MP-PD24.1.0). From now on repo sync in this folder +will pull all the latest changes from our Git repositories:

+
host:~$ repo sync
+
+
+
+
+

5.7.2. Development state of upcoming release

+

Also development states of upcoming releases can be accessed this way. +For this execute the following command and look for a release with a higher +PDXX.Y number than the latest one (BSP-Yocto-NXP-i.MX8MP-PD24.1.0) and .y at the +end:

+
host:~$ ./phyLinux init -p imx8mp
+
+
+
+
+
+

5.8. Accessing the Latest Upstream Support

+

We have a vanilla manifest that makes use of the Yocto master branches (not an +NXP release), Linux, and U-Boot. This can be used to test the latest upstream +kernel/U-Boot.

+
+

Note

+

The master manifest reflects the latest state of development. This tends to +be broken from time to time. We try to fix the master on a regular basis.

+
+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.9.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+

5.10. Switch back to legacyboot

+
+

Warning

+

As we switched to standardboot with fitimage as default, legacyboot is +deprecated. We kept the option to switch back to legacyboot for this +release, but it will be removed in the future.

+
+
+

5.10.1. Changes in Yocto

+

By default, the fitImage and bootscript will be deployed into the wic.xz Image. +To switch back to legacyboot, you need to replace the fitImage and bootscript +for the kernel image and the devicetrees. They are still in the deploy +folder from the Yocto build, so you can manually copy them to the boot +partition on your device. Otherwise you can do the following changes in Yocto +to get the kernel and devicetrees deployed in the Image again.

+

First create the variable KERNEL_DEVICETREE_DEPLOY. This can be done for +example in the local.conf file in your build directory conf/local.conf. +The variable is basically a copy of the KERNEL_DEVICETREE variable that is +set in conf/machine/phyboard-pollux-imx8mp-3.conf in meta-phytec but the freescale +at the beginning needs to be removed, so that only the devicetree filename are +left. In the end it should look something like this:

+
KERNEL_DEVICETREE_DEPLOY = " \
+     imx8mp-phyboard-pollux-rdk.dtb \
+     imx8mp-phyboard-pollux-isp-csi1.dtbo \
+     imx8mp-phyboard-pollux-isp-csi2.dtbo \
+     imx8mp-phyboard-pollux-isi-csi1.dtbo \
+     imx8mp-phyboard-pollux-isi-csi2.dtbo \
+     imx8mp-phyboard-pollux-peb-av-10.dtbo \
+     imx8mp-phyboard-pollux-peb-wlbt-05.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2-fpdlink-port1.dtbo \
+     imx8mp-phycore-no-eth.dtbo \
+     imx8mp-phycore-no-rtc.dtbo \
+     imx8mp-phycore-no-spiflash.dtbo \
+     imx8mp-phycore-rpmsg.dtbo \
+"
+
+
+

Then add this line:

+
IMAGE_BOOT_FILES:mx8m-nxp-bsp:append = " Image oftree ${KERNEL_DEVICETREE_DEPLOY}"
+
+
+
+

Note

+

A clean might be required for this to work.

+
bitbake -c cleanall phytec-qt6demo-image
+
+
+
+

Then start the build:

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

5.10.2. Changes in U-Boot environment

+

To re-enable legacyboot set the following variable:

+
uboot=> setenv dolegacyboot 1
+uboot=> env save; env save;
+uboot=> boot
+
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 8M Plus SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Board.dts - include the module dtsi file. Devices that come from the i.MX 8M Plus +SoC but are just routed down to the carrier board and used there are included +in this dts.

    • +

  • Overlay.dtso - enable/disable features depending on optional hardware that +may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10)

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 8 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the folder arch/arm64/boot/dts/freescale/.

+

Available overlays for phyboard-pollux-imx8mp-3.conf are:

+
imx8mp-isi-csi1.dtbo
+imx8mp-isi-csi2.dtbo
+imx8mp-isp-csi1.dtbo
+imx8mp-isp-csi2.dtbo
+imx8mp-phyboard-pollux-peb-av-10.dtbo
+imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+imx8mp-phycore-no-eth.dtbo
+imx8mp-phycore-no-rtc.dtbo
+imx8mp-phycore-no-spiflash.dtbo
+imx8mp-phycore-rpmsg.dtbo
+imx8mp-vm016-csi1.dtbo
+imx8mp-vm016-csi1-fpdlink.dtbo
+imx8mp-vm016-csi2.dtbo
+imx8mp-vm016-csi2-fpdlink.dtbo
+imx8mp-vm017-csi1.dtbo
+imx8mp-vm017-csi1-fpdlink.dtbo
+imx8mp-vm017-csi2.dtbo
+imx8mp-vm017-csi2-fpdlink.dtbo
+
+
+

Otherwise you can show the content of a FIT image including all overlay +configs in the FIT image with this command in Linux:

+
host:~$ dumpimage -l /boot/fitImage
+
+
+

or in U-Boot:

+
u-boot=> load mmc ${mmcdev}:1 ${loadaddr} fitImage
+u-boot=> iminfo
+
+
+

The usage of overlays can be configured during runtime in Linux or U-Boot. +Overlays are applied during the boot process in the bootloader after the +boot command is called and before the kernel is loaded. The next sections +explain the configuration in more detail.

+
+

6.2.2.1. Set ${overlays} variable

+

The ${overlays} U-Boot environment variable contains a number-sign (#) +separated list of overlays that will be applied during boot. The overlays +listed in the overlays variable must be included in the FIT image. Overlays set +in the $KERNEL_DEVICETREE Yocto machine variable will automatically be added to +the FIT image.

+

The ${overlays} variable can either be set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +When desired to use the overlays variable as set manually in the U-Boot +environment, disable bootenv by setting env set no_bootenv 1 as the overlays +variable may be overwritten during the execution of the boot script. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=conf-imx8mp-phyboard-pollux-rdk-peb-eval-01.dtbo#conf-imx8mp-phyboard-pollux-peb-av-10.dtbo
+
+
+

Changes will take effect after the next reboot. If no bootenv.txt file is +available the overlays variable can be set directly in the U-Boot environment.

+
u-boot=> setenv overlays conf-imx8mp-phyboard-pollux-peb-av-10.dtbo
+u-boot=> printenv overlays
+overlays=conf-imx8mp-phyboard-pollux-peb-av-10.dtbo
+u-boot=> boot
+
+
+

If a user defined ${overlays} variable should be directly loaded from U-Boot +environment but there is still an external bootenv.txt available, the ${no_bootenv} +variable needs to be set as a flag:

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays conf-imx8mp-phyboard-pollux-peb-av-10.dtbo
+u-boot=> boot
+
+
+

More information about the external environment can be found in +U-boot External Environment subsection of the +device tree overlay section.

+

We use the ${overlays} variable for overlays describing expansion boards and +cameras that can not be detected during run time. To prevent applying overlays +unset the overlays variable and set no_bootenv to anything other than 0.

+
u-boot=> env delete overlays
+u-boot=> env set no_bootenv 1
+
+
+

If desired to use the bootenv.txt file for setting U-Boot variables other than +overlays and having overlays disabled, remove the overlays definition line from +the bootenv.txt file instead of setting no_bootenv.

+
+
+

6.2.2.2. SoM Variants

+

Additional overlays are applied automatically to disable components that are not +populated on the SoM. The detection is done with the EEPROM data (EEPROM SoM +Detection) found on the SoM i2c EEPROM.

+

It depends on the SoM variant if any device tree overlays will be applied. To check +if an overlay will be applied on the running SoM in U-Boot, run:

+
u-boot=> env print fit_extensions
+
+
+

If the EEPROM data is not available, no device tree overlays are applied.

+

To prevent application of the SoM variant related overlays the +${no_extensions} variable can be set to 1 in the bootloader environment:

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot External Environment

+

During the start of the Linux Kernel the external environment bootenv.txt +text file will be loaded from the boot partition of an MMC device or via TFTP. +The main intention of this file is to store the ${overlays} variable. This makes +it easy to pre-define the overlays in Yocto depending on the used machine. The +content from the file is defined in the Yocto recipe bootenv found in +meta-phytec: +https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=scarthgap

+

Other variables can be set in this file, too. They will overwrite the existing +settings in the environment. But only variables evaluated after issuing the boot +command can be overwritten, such as ${nfsroot} or ${mmcargs}. Changing other +variables in that file will not have an effect. See the usage during netboot as +an example.

+

If the external environment can not be loaded the boot process will be anyway +continued with the values of the existing environment settings.

+
+
+

6.2.4. Change U-boot Environment from Linux on Target

+

Libubootenv is a tool included in our images to modify the U-Boot environment of +Linux on the target machine.

+

Print the U-Boot environment using the following command:

+
target:~$ fw_printenv
+
+
+

Modify a U-Boot environment variable using the following command:

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

Caution

+

Libubootenv takes the environment selected in a configuration file. The +environment to use is inserted there, and by default it is configured to use +the eMMC environment (known as the default used environment).

+

If the eMMC is not flashed or the eMMC environment is deleted, libubootenv +will not work. You should modify the /etc/fw_env.config file to match the +environment source that you want to use.

+
+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 8M Plus BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 8M Plus BSP Device Tree Concept to get an understanding +of our i.MX 8 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 8 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 8M Plus Pin Muxing

+

The i.MX 8M Plus SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 8M Plus terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 8M Plus Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx8mp-phyboard-pollux-rdk.dts:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x140
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x140
+        >;
+};
+
+
+

The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled.

+

The device tree representation for UART1 pinmuxing: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L373

+
+
+

7.2. RS232/RS485

+

The phyCORE-i.MX 8M Plus supports up to 4 UART units. On the phyBOARD-Pollux, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector X2 at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers JP3 and +JP4 on the baseboard. For more information about the correct setup please +refer to the phyCORE-i.MX 8M Plus/phyBOARD-Pollux Hardware Manual section UARTs.

+

We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers JP3 and JP4 need to be set +correctly.

+
+

7.2.1. RS232

+
    +

  • Display the current settings of a terminal in a human-readable format:

    +
    target:~$ stty -a
+
    +
    +
    • +

  • Configuration of the UART interface can be done with stty. For example:

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • With a simple echo and cat, basic communication can be tested. Example:

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

The host should print out “123”.

+
+
+

7.2.2. RS485

+
+

Hint

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

For easy testing, look at the linux-serial-test. This tool is called the IOCTL +for RS485 and sends a constant stream of data.

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

More information about the linux-serial-test tool and its parameters can be +found here: linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Documentation for calling the IOCTL within c-code is described in the Linux +kernel documentation: +https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection3.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see “test” printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final “count for this session”. There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+
+
+

7.2.2.2. RS485 full-duplex

+

For full-duplex mode your connection setup should look like this:

+../../../_images/RS485_fullduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For full-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 1
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  true
+Bus termination enabled:  false
+
+
+

Also here you can do the echo test to see if sending and receiving works:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see “test” printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

To check if the full-duplex operation works, you need to use the +linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=114660, tx=118755, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=118755, tx=114660, rx err=0
+
+
+

In this example both targets will send and receive simultaneously. They will +receive for 15sec and send for 10sec. The receiver needs to receive a bit +longer, so that all sent messages will get received. Remember to start both +targets almost simultaneously. A small difference in start time is accounted +for with the -W 2 option. At the end the program will print the final +“count for this session”. There you can check that all transmitted frames were +received.

+

All the test examples are target to target, but can also be done with host to +target with a USB to rs485 converter. You may need to adjust the interfaces for +commands to work on the host then.

+

The device tree representation for RS232 and RS485: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L412

+
+
+
+
+

7.3. Network

+

phyBOARD-Pollux-i.MX 8M Plus provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board.

+
+

Warning

+

The naming convention of the Ethernet interfaces in the hardware (ethernet0 +and ethernet1) do not align with the network interfaces (eth0 and eth1) in +Linux. So, be aware of these differences:

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L50.

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Pollux can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L179.

+
+

7.3.1. Network Environment Customization

+
+

7.3.1.1. U-boot network-environment

+
    +

  • To find the Ethernet settings in the target bootloader:

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • With your development host set to IP 192.168.3.10 and netmask 255.255.255.0, +the target should return:

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • If you need to make any changes:

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> should be one of ipaddr, netmask, gatewayip or serverip. +<value> will be the actual value of the chosen parameter.

    +
    • +

  • The changes you made are temporary for now. To save these:

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

Here you can also change the IP address to DHCP instead of using a static one.

+
    +

  • Configure:

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • Set up paths for TFTP and NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+

Tip

+

Variables like nfsroot and netargs can be overwritten by the U-boot External +Environment. For netboot, the external environment will be loaded from tftp. +For example, to locally set the nfsroot variable in a bootenv.txt file, +locate the tftproot directory:

+
nfsroot=/home/user/nfssrc
+
+
+

There is no need to store the info on the target. Please note that this does +not work for variables like ipaddr or serveraddr as they need to be already +set when the external environment is being loaded.

+
+
+
+

7.3.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. WLAN

+

WLAN and Bluetooth on the phyBOARD-Pollux are provided by the PEB-WLBT-05 expansion card. +The PEB-WLBT-05 for phyBOARD-Pollux Quickstart Guide shows you how to install the +PEB-WLBT-05.

+
+

Tip

+

With the BSP Version PD22.1 and newer, the PEB-WLBT-05 overlay needs to be activated first, +otherwise the PEB-WLBT-05 won’t be recognized.

+
target:~$ vi /boot/bootenv.txt
+
+
+

Afterwards the bootenv.txt file should look like this (it can also contain other devicetree +overlays!):

+
overlays=conf-imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+
+
+

The changes will be applied after a reboot:

+
target:~$ reboot
+
+
+

For further information about devicetree overlays, read the device tree chapter.

+
+

For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. Connecting to a WLAN Network

+

First set the correct regulatory domain for your country:

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

You will see:

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

Set up the wireless interface:

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

Now you can scan for available networks:

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection.

+

To do so, add the network-credentials to the file /etc/wpa_supplicant.conf:

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

Now a connection can be established:

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

This should result in the following output:

+
Successfully initialized wpa_supplicant
+
+
+

The ip address is automatically configured over DHCP. For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (scarthgap).

+
+
+
+

7.3.3. Bluetooth

+

Bluetooth is supported on phyBOARD-Pollux with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section.

+

Bluetooth is connected to UART3 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup.

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. Visibility

+

To activate visibility:

+
target:~$ hciconfig hci0 piscan
+
+
+

To disable visibility:

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. Connect

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

Note

+

If the connection fails with the error message: “Failed to connect: +org.bluez.Error.Failed” try restarting PulseAudio with:

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC Card

+

The i.MX 8M Plus supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L422

+

DT configuration for the eMMC interface can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L214

+
+
+

7.5. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 8M Plus is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw Multi-Level Cells (MLC) or Triple-Level +Cells (TLC) combined with a memory controller that handles ECC and wear +leveling. They are connected via an SD/MMC interface to the i.MX 8M Plus and are +represented as block devices in the Linux kernel like SD cards, flash drives, or +hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.5.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +or TLC. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background Operations +(BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • Enabling can be done with this command:

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.5.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 8M Plus SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.5.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
+
+

7.5.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC or TLC +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC used in NAND Flash, MLC or TLC have lower reliability and a higher +error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC or TLC +or mark these blocks as discard. The data on the device is lost and +will be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.5.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 8M Plus uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.5.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

The following table is for the offset of the i.MX 8M Plus SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.6. SPI Master

+

The i.MX 8M Plus controller has a FlexSPI and an ECSPI IP core included. The FlexSPI +host controller supports two SPI channels with up to 4 devices. Each channel +supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data +lines). The ECSPI controller supports 3 SPI interfaces with one dedicated chip +selected for each interface. As chip selects should be realized with GPIOs, more +than one device on each channel is possible.

+
+

7.6.1. SPI NOR Flash

+

phyCORE-i.MX 8M Plus is equipped with a QSPI NOR Flash which connects to the i.MX 8M Plus’s +FlexSPI interface. The QSPI NOR Flash is suitable for booting. Please see +different sections for flashing and bootmode setup. Due to limited space on the +SPI NOR Flash, only the bootloader is stored inside. By default, the kernel, +device tree, and rootfs are taken from eMMC.

+

The Bootloader does detect with the help of the EEPROM Introspection data if an +SPI flash is mounted or not. If no SPI flash is mounted a device tree overlay is +applied with the expansion command to disable the SPI flash device tree node +during boot. If no introspection data is available the SPI NOR flash node is +always enabled. Find more information in the device tree overlay section.

+

The bootloader also passes the SPI MTD partition table to Linux by fixing up the +device tree based on the mtdparts boot parameter. The default partition layout +in the BSP is set to:

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

This is a bootloader environment variable that is defined here and can be +changed during runtime. From Linux userspace, the NOR Flash partitions are +accessible via /dev/mtd<N> devices where <N> is the MTD device number associated +with the NOR flash partition to access. To find the correct MTD device number +for a partition, run on the target:

+
root@phyboard-pollux-imx8mp-3:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

It lists all MTD devices and the corresponding partition names. The flash node +is defined inside of the SPI master node in the module DTS. The SPI node +contains all devices connected to this SPI bus which is in this case only the +SPI NOR Flash.

+

The definition of the SPI master node in the device tree can be found here:

+

https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L76

+
+
+
+

7.7. GPIOs

+

The phyBOARD-Pollux has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to i.MX 8M Plus pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal i.MX 8M Plus GPIO banks GPIO1 – GPIO5.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO5_07). <X> identifies the GPIO +bank and counts from 1 to 5, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo -c gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 20 from chip0):

    +
    target:~$ gpioget -c gpiochip0 20
+
    +
    +
    • +

  • Set the value of GPIO 20 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset -z -c gpiochip0 20=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <line=value>...
+
+Set values of GPIO lines.
+
+Lines are specified by name, or optionally by offset if the chip option
+is provided.
+Values may be '1' or '0', or equivalently 'active'/'inactive' or 'on'/'off'.
+
+The line output state is maintained until the process exits, but after that
+is not guaranteed.
+
+Options:
+      --banner            display a banner on successful startup
+  -b, --bias <bias>       specify the line bias
+                  Possible values: 'pull-down', 'pull-up', 'disabled'.
+                  (default is to leave bias unchanged)
+      --by-name           treat lines as names even if they would parse as an offset
+  -c, --chip <chip>       restrict scope to a particular chip
+  -C, --consumer <name>   consumer name applied to requested lines (default is 'gpioset')
+  -d, --drive <drive>     specify the line drive mode
+                  Possible values: 'push-pull', 'open-drain', 'open-source'.
+                  (default is 'push-pull')
+  -h, --help              display this help and exit
+  -l, --active-low        treat the line as active low
+  -p, --hold-period <period>
+                  the minimum time period to hold lines at the requested values
+  -s, --strict            abort if requested line names are not unique
+  -t, --toggle <period>[,period]...
+                  toggle the line(s) after the specified period(s)
+                  If the last period is non-zero then the sequence repeats.
+      --unquoted  don't quote line names
+  -v, --version           output version information and exit
+  -z, --daemonize set values then detach from the controlling terminal
+
+Chips:
+    A GPIO chip may be identified by number, name, or path.
+    e.g. '0', 'gpiochip0', and '/dev/gpiochip0' all refer to the same chip.
+
+Periods:
+    Periods are taken as milliseconds unless units are specified. e.g. 10us.
+    Supported units are 's', 'ms', and 'us'.
+
+*Note*
+    The state of a GPIO line controlled over the character device reverts to default
+    when the last process referencing the file descriptor representing the device file exits.
+    This means that it's wrong to run gpioset, have it exit and expect the line to continue
+    being driven high or low. It may happen if given pin is floating but it must be interpreted
+    as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.7.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the defconfig you use in +arch/arm64/configs/ in the linux kernel sources. For our NXP based releases, +this could be for example imx8_phytec_distro.config:

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+
+
+
+

7.8. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the phyBOARD-Pollux.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L255

+
+
+

7.9. I²C Bus

+

The i.MX 8M Plus contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 8M Plus. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our phyBOARD-Pollux.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C1 bus configuration (e.g. imx8mp-phycore-som.dtsi): +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L113

+

General I²C2 bus configuration (e.g. imx8mp-phyboard-pollux-rdk.dts) +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L239

+
+
+

7.10. EEPROM

+

On the phyCORE-i.MX8MP there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues.

+
+

Note

+

If you deleted reserved EEPROM spaces, please contact our support!

+
+
+

7.10.1. I2C EEPROM on phyCORE-i.MX8MP

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

The I2C EEPROM on the phyCORE-i.MX8MP SoM is connected to I2C address 0x51 on the I2C-0 +bus. It is possible to read and write directly to the device populated:

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the 4KiB EEPROM (bus: I2C-0 addr: 0x51) with zeros leaving out the EEPROM data use:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM Detection

+

The I2C EEPROM, populated on the phyCORE-i.MX8MP, has a separate ID page that is +addressable over I2C address 0x59 on bus 0 and a normal area that is addressable +over I2C address 0x51 on bus 0. PHYTEC uses this data area of 32 Bytes to store +information about the SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the EEPROM ID page data and the first 256 bytes of the normal area are +deleted, the bootloader will fall back to the phyCORE-i.MX8MP Kit RAM setup, which +is 2GiB RAM.

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

SoMs that are flashed with data format API revision 2 will print out information +about the module in the early stage.

+

DT representation, e.g. in phyCORE-i.MX 8M Plus file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L201

+
+
+
+

7.11. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC Wakealarm

+

It is possible to issue an interrupt from the RTC to wake up the system. The +format uses the Unix epoch time, which is the number of seconds since UTC +midnight on 1 January 1970. To wake up the system after 4 minutes from suspend +to ram state, type:

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

Note

+

Internally the wake alarm time will be rounded up to the next minute since +the alarm function doesn’t support seconds.

+
+
+
+

7.11.2. RTC Parameters

+

RTCs have a few abilities which can be read/set with the help of hwclock +tool.

+
    +

  • We can check RTC supported features with:

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    What this value means is encoded in kernel, each set bit translates to:

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • We can check RTC BSM (Backup Switchover Mode) with:

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • We can set RTC BSM with:

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    What BSM values mean translates to these values:

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    Tip

    +

    You should set BSM mode to DSM or LSM for RTC to switch to backup power +source when the initial power source is not available. Check RV-3028 RTC +datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching +Mode) actually mean.

    +
    +
    • +
+

DT representation for I²C RTCs: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L208

+
+
+
+

7.12. USB Host Controller

+

The USB controller of the i.MX 8M Plus SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +‘SS’). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY.

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+

DT representation for USB Host: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L380

+
+
+

7.13. CAN FD

+

The phyBOARD-Pollux has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The two CAN interfaces should show up as +can0 and can1.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    The information for can0 will look like:

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+
+

Warning

+

The mcp2518fd SPI to CANfd supports only baudrates starting from 125kB/s. +Slower rates can be selected but may not work correctly.

+
+

Device Tree CAN configuration of imx8mp-phyboard-pollux-rdk.dts: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L203

+
+
+

7.14. PCIe

+

The phyCORE-i.MX 8M Plus has one Mini-PCIe slot. In general, PCIe autodetects new +devices on the bus. After connecting the device and booting up the system, you +can use the command lspci to see all PCIe devices recognized.

+
    +

  • Type:

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • You will receive:

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

In this example, the PCIe device is the Intel Corporation WiFi Link 5100.

+

For PCIe devices, you have to enable the correct driver in the kernel +configuration. This WLAN card, for example, is manufactured by Intel. The +option for the driver, which must be enabled, is named CONFIG_IWLWIFI and can be +found under Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimat in +the kernel configuration.

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • The linux-imx is represented by: virtual/kernel

      • +
    +
    • +
+

For some devices like the WLAN card, additional binary firmware blobs are +needed. These firmware blobs have to be placed in /lib/firmware/ before the +device can be used.

+
    +

  • Type:

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • For example, if you try to bring up the network interface:

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • You will get the following output on the serial console:

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

Tip

+

Some PCIe devices, e.g. the Ethernet card, may function properly even if no +firmware blob is loaded from /lib/firmware/ and you received an error message +as shown in the first line of the output above. This is because some +manufacturers provide the firmware as a fallback on the card itself. In this +case, the behavior and output depend strongly on the manufacturer’s firmware.

+
+

Device Tree PCIe configuration of imx8mp-phyboard-pollux-rdk.dts: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L345

+
+
+

7.15. Audio

+

Playback devices supported for phyBOARD-Pollux are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals.

+
+

Note

+

Using the PEB-AV-10 connector for display output along HDMI as audio output +is not supported. The audio output device must match the video output device.

+
+

To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices:

+
target:~$ aplay -L
+
+
+

Or type for recording devices:

+
target:~$ arecord -L
+
+
+
+

7.15.1. Alsamixer

+

To inspect the capabilities of your soundcard, call:

+
target:~$ alsamixer
+
+
+

You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. “MM” means the feature is muted +(both output, left & right), which can be toggled by hitting ‘m’. You can also +toggle by hitting ‘<’ for left and ‘>’ for right output. With the tab +key, you can switch between controls for playback and recording.

+
+
+

7.15.2. Restore default volumes

+

There are some default settings stored in /var/lib/alsa/asound.state. +You can save your current alsa settings with:

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

You can restore saved alsa settings with:

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.15.3. ALSA configuration

+

Our BSP comes with a ALSA configuration file /etc/asound.conf.

+

The ALSA configuration file can be edited as desired or deleted since it is not +required for ALSA to work properly.

+
target:~$ vi /etc/asound.conf
+
+
+

To set PEB-AV-10 as output, set playback.pcm from “dummy” to “pebav10”:

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

If the sound is not audible change playback devices to the software volume control +playback devices, set playback.pcm to the respective softvol playback device e.g. +“softvol_pebav10”. Use alsamixer controls to vary the volume levels.

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.15.4. Pulseaudio Configuration

+

For applications using Pulseaudio, check for available sinks:

+
target:~$ pactl list short sinks
+
+
+

To select the output device, type:

+
target:~$ pactl set-default-sink <sink_number>
+
+
+
+
+

7.15.5. Playback

+

Run speaker-test to check playback availability:

+
target:~$ speaker-test -c 2 -t wav
+
+
+

To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds:

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

To playback other formats like mp3 for example, you can use Gstreamer:

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.15.6. Capture

+

arecord is a command-line tool for capturing audio streams which use Line In as +the default input source. To select a different audio source you can +use alsamixer. For example, switch on Right PGA Mixer Mic3R and Left PGA Mixer +Mic3R in order to capture the audio from the microphone input of the +TLV320-Codec using the 3.5mm jack.

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

Hint

+

Since playback and capture share hardware interfaces, it is not possible to +use different sampling rates and formats for simultaneous playback and +capture operations.

+
+

Device Tree Audio configuration: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L58

+
+
+
+

7.16. Video

+
+

7.16.1. Videos with Gstreamer

+

One example video is installed by default in the BSP at /usr/share/qtphy/videos/. +Start the video playback with one of these commands:

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.17. Display

+

The phyBOARD-Pollux supports up to 3 different display outputs. Two can be used +simultaneously. The following table shows the required extensions and devicetree +overlays for the different interfaces.

+ + + + + + + + + + + + + + + + + + + + + +

Interface

Expansion

devicetree overlay

HDMI

phyBOARD-Pollux

no overlay needed (enabled by default)

LVDS0

PEB-AV-10

imx8mp-phyboard-pollux-peb-av-10.dtbo +(loaded by default)

LVDS1

phyBOARD-Pollux

disabled if PEB-AV-10 overlay is used

+
+

Note

+
    +

  • When changing Weston output, make sure to match the audio output as well.

    • +

  • LVDS0 (PEB-AV-10) and LVDS1 (onboard)can not be used at the same time.

    • +
+
+

HDMI is always enabled in the devicetree. The other interfaces can be enabled +with Device Tree Overlay.

+

The default-enabled Interfaces are HDMI and LVDS0 (PEB-AV-010). We support a +10’’ edt,etml1010g0dka display for the PEB-AV-10.

+
+

Note

+

The current display driver limits the pixel clock for a display connected to +LVDS to 74.25Mhz (or a divider of it). If this does not fit your display +requirements, please contact Support for further help.

+
+
+

7.17.1. Weston Configuration

+

In order to get an output from Weston on the correct display, it still needs to +be configured correctly. This will be done at /etc/xdg/weston/weston.ini.

+
+

7.17.1.1. Single Display

+

In our BSP, the default Weston output is set to HDMI.

+
[output]
+name=HDMI-A-1
+mode=preferred
+
+[output]
+name=LVDS-1
+mode=off
+
+
+

When using the LVDS0 (PEB-AV-10) as output, set the output mode to off for +HDMI-A-1 and for LVDS-1 to current.

+
[output]
+name=HDMI-A-1
+mode=off
+
+[output]
+name=LVDS-1
+mode=current
+
+
+

If you want to use LVDS1 (onboard) then you need to load no overlay. Remove the +imx8mp-phyboard-pollux-peb-av-xxx.dtbo from bootenv.txt.

+
+
+

7.17.1.2. Dual Display

+
+

Note

+

For dual and triple display output you can not use LVDS1 (onboard) and HDMI +together.

+
+

For dual display in dual view mode at HDMI and LVDS0 (PEB-AV-10), both modes +have to be set to the:

+
[output]
+name=HDMI-A-1
+mode=preferred
+
+[output]
+name=LVDS-1
+mode=current
+
+
+
+
+
+

7.17.2. Qt Demo

+

With the phytec-qt6demo-image, Weston starts during boot. Our Qt6 demo application named +“qtphy” can be stopped with:

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • To start the demo again, run:

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • To disable autostart of the demo, run:

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • To enable autostart of the demo, run:

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston can be stopped with:

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

Note

+

The Qt demo must be closed before Weston can be closed.

+
+
+
+

7.17.3. Backlight Control

+

If a display is connected to the PHYTEC board, you can control its backlight +with the Linux kernel sysfs interface. All available backlight devices in the +system can be found in the folder /sys/class/backlight. Reading the appropriate +files and writing to them allows you to control the backlight.

+
+

Note

+

Some boards with multiple display connectors might have multiple backlight +controls in /sys/class/backlight. For example: backlight0 and backlight1

+
+
    +

  • To get, for example, the maximum brightness level (max_brightness) execute:

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    Valid brightness values are 0 to <max_brightness>.

    +
    • +

  • To obtain the current brightness level, type:

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • Write to the file brightness to change the brightness:

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    turns the backlight off for example.

    +

    For documentation of all files, see +https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight.

    +
    • +
+

Device tree description of LVDS-1 and HDMI can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L294 +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L218

+

The device tree of LVDS-0 on PEB-AV-10 can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L133

+
+
+
+

7.18. Power Management

+
+

7.18.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 8M Plus SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as ‘Dynamic Voltage and +Frequency Scaling’ (DVFS). The i.MX 8M Plus BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the i.MX 8 +variant used, several different frequencies are supported.

+
+

Tip

+

Although the DVFS framework provides frequency settings for each CPU core, a +change in the frequency settings of one CPU core always affects all other CPU +cores too. So all CPU cores always share the same DVFS setting. An individual +DVFS setting for each core is not possible.

+
+
    +

  • To get a complete list type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately +1,6 GHz, the result will be:

    +
    1200000 1600000
+
    +
    +
    • +

  • To ask for the current frequency type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

So-called governors are automatically selecting one of these frequencies in +accordance with their goals.

+
    +

  • List all governors available with the following command:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    The result will be:

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative is much like the ondemand governor. It differs in behavior in +that it gracefully increases and decreases the CPU speed rather than jumping +to max speed the moment there is any load on the CPU.

    • +

  • ondemand (default) switches between possible CPU core frequencies in +reference to the current system load. When the system load increases above a +specific limit, it increases the CPU core frequency immediately.

    • +

  • powersave always selects the lowest possible CPU core frequency.

    • +

  • performance always selects the highest possible CPU core frequency.

    • +

  • userspace allows the user or userspace program running as root to set a +specific frequency (e.g. to 1600000). Type:

    • +

  • In order to ask for the current governor, type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    You will normally get:

    +
    ondemand
+
    +
    +
    • +

  • Switching over to another governor (e.g. userspace) is done with:

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • Now you can set the speed:

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +Documentation/admin-guide/pm/cpufreq.rst.

+
+
+

7.18.2. CPU Core Management

+

The i.MX 8M Plus SoC can have multiple processor cores on the die. The i.MX 8M Plus, for +example, has 4 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    Here the system has four processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.18.3. Suspend to RAM

+

The phyCORE-i.MX8MP supports basic suspend and resume. Different wake-up sources can be +used. Suspend/resume is possible with:

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

To wake up with serial console run

+
target:~$ echo enabled > /sys/class/tty/ttymxc0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.19. Thermal Management

+
+

7.19.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.19.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 8M Plus SoC platform. The i.MX 8 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Industrial +and Commercial.

+ + + + + + + + + + + + + + + + + +

Commercial

Industrial

passive (warning)

85°C

95°C

critical (shutdown)

90°C

100°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise, Fair Share, Bang Bang, and +Userspace. The default policy used in the BSP is step_wise. If the value of the +SoC temperature in the sysfs file temp is above trip_point_0, the CPU frequency +is set to the lowest CPU frequency. When the SoC temperature drops below +trip_point_0 again, the throttling is released.

+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+

7.19.3. GPIO Fan

+
+

Note

+

Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan +to GPIO fan due to availability. The PWM fan will not be supported +anymore and will not function with the new release.

+
+

A GPIO fan can be connected to the phyBOARD-Pollux-i.MX 8M Plus. The SoC only contains one +temperature sensor which is already used by the thermal frequency scaling. The +fan can not be controlled by the kernel. We use lmsensors with hwmon for this +instead. lmsensors reads the temperature periodically and enables or disables +the fan at a configurable threshold. For the phyBOARD-Pollux-i.MX 8M Plus, this is 60°C.

+

The settings can be configured in the configuration file:

+
/etc/fancontrol
+
+
+

Fan control is started by a systemd service during boot. This can be disabled +with:

+
target:~$ systemctl disable fancontrol
+
+
+

The device tree description of GPIO Fan can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L35

+
+
+
+

7.20. Watchdog

+

The PHYTEC i.MX 8M Plus modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.20.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.21. snvs Power Key

+

The X_ONOFF pin connected to the ON/OFF button can be pressed long to trigger +Power OFF without SW intervention or used to wake up the system out of suspend. +With the snvs_pwrkey driver, the KEY_POWER event is also reported to userspace +when the button is pressed. On default, systemd is configured to ignore such +events. The function of Power OFF without SW intervention and the wake-up from +suspend are not configured. Triggering a power off with systemd when pushing the +ON/OFF button can be configured under /etc/systemd/logind.conf and set using:

+
HandlePowerKey=poweroff
+
+
+
+
+

7.22. NPU

+

The i.MX 8M Plus SoC contains a Neural Processing Unit up to 2.3 TOPS as an accelerator +for artificial intelligence operations. Refer to our latest phyCORE-i.MX 8M Plus AI Kit +Guide on the phyCORE-i.MX 8M Plus download section to get information about the +NPU: L-1015e.A1 phyCORE-i.MX 8M Plus AI Kit Guide

+
+
+

7.23. ISP

+

The i.MX 8M Plus SoC contains an Image Signal Processor (ISP). For more information see +Using the ISPs on the phyBOARD-Pollux i.MX 8M Plus documentation. This documentation is also +available in German.

+
+
+

7.24. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 8M Plus provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 8M Plus Reference Manual). The following list is +an abstract from the i.MX 8M Plus Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x30350000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x30350000

Description

OCOTP_MAC_ADDR0

9

0

0x640

contains lower 32 bits +of ENET0 MAC address

OCOTP_MAC_ADDR1

9

1

0x650

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

OCOTP_MAC_ADDR2

9

2

0x660

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 8M Plus Security Reference Manual.

+
+

7.24.1. Reading Fuse Values in uBoot

+

You can read the content of a fuse using memory-mapped shadow registers. To +calculate the memory address, use the fuse Bank and Word in the following +formula:

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.24.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+
+

8. i.MX 8M Plus M7 Core

+

In addition to the Cortex-A53 cores, there is a Cortex-M7 Core as MCU +integrated into the i.MX 8M Plus SoC. Our Yocto-Linux-BSP runs on the A53-Cores and +the M7 Core can be used as a secondary core for additional tasks using +bare-metal or RTOS firmware. +Both cores have access to the same peripherals and thus peripheral +usage needs to be limited either in the M7 Core’s firmware or the devicetree +for the Linux operating system. This section describes how to build firmware +examples and how to run them on phyBOARD-Pollux.

+

The phyBOARD-Pollux is currently supported by the NXP MCUXpresso SDK and by +The Zephyr Project. This section only describes the NXP MCUXpresso SDK because +the MCUXpresso SDK has more supported features at the moment.

+

If you want to use the M7 Core with The Zephyr Project, please refer to the +The Zephyr Project documentation:

+ +
+

8.1. Getting the Firmware Examples

+

The firmware can be built using the NXP MCUxpresso SDK with a compatible +compiler toolchain using command-line tools.

+
+

8.1.1. Getting the Sources

+

The MCUX SDK and the examples for the i.MX 8M Plus can be obtained from PHYTEC’s GitHub +page:

+ +
    +

  1. Initialize the MCUX SDK via west:

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    This will create a mcuxsdk directory with the mcux-sdk repository in it. +The mcux-sdk-phytec-examples repository will be automatically cloned into +the mcuxsdk directory. +The given argument <VERSION> is a the branch name of the mcux-sdk repository +that represents the MCUX SDK version. For the newest tested version +you can use 2.13.0.

    +
    +

    Note

    +

    west is a repository management tool and a part of the Zephyr +Project. +To install west, you can use pip. In this example west is installed in +a python virtual environment:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. Update the dependencies:

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    The directory examples-phytec contains all examples ported and tested +for phyBOARD-Pollux with version 2.13.0 of MCUX.

    +

    To build the firmware, a compiler toolchain and make/cmake are required. +The GNU Arm Embedded Toolchain may be available in your distribution’s +repositories, e.g. for Ubuntu.

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    The compiler toolchain can also be obtained directly from +https://developer.arm.com/. After the archive has been extracted, +the ARMGCC_DIR has to be added to the environment, e.g. for the +ARM toolchain 10-2020-q4-major release located in the home directory:

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. Building the Firmware

+

To build the PHYTEC samples an environment has to be sourced

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

The scripts to build the firmware are located in +<sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc. +There are scripts for each memory location the firmware is supposed to run in, +e.g.

+
host:~$ ./build_release.sh
+
+
+

to build the firmware for the M7 Core’s TCM. The output will be placed under +release/ in the armgcc directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+

To build the firmware for the DRAM, run the script build_ddr_release. +The script of the firmware that is supposed to run, e.g.

+
host:~$ ./build_ddr_release.sh
+
+
+

The output will be placed under ddr_release/ in the armgcc +directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+
+
+
+

8.2. Running M7 Core Examples

+

There are two ways to run the M7 Core with the built firmware, U-Boot and +Remoteproc within a running Linux.

+

To receive debug messages start your favorite terminal software (e.g. Minicom, +Tio, or Tera Term) on your host PC and configure it for 115200 baud, 8 data +bits, no parity, and 1 stop bit (8n1) with no handshake.

+

Once a micro-USB cable is connected to the USB-debug port on the phyBOARD-Pollux, two +ttyUSB devices are registered. One prints messages from A53-Core’s debug UART +and the other one from the M7 Core’s debug UART.

+
+

8.2.1. Running Examples from U-Boot

+

To load firmware using the bootloader U-Boot, the bootaux command can be used:

+
    +

  1. Prepare an SD Card with our Yocto-BSP

    2. +

  2. Copy the generated .bin file to the SD Cards first partition

    3. +

  3. Stop the autoboot by pressing any key

    4. +

  4. Type the command depending on the type of firmware:

    5. +
+

For firmware built to run in the M7 Core’s TCM:

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

For firmware built to run in the DRAM:

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

The program’s output should appear on the M7 Core’s debug UART.

+
+
+

8.2.2. Running Examples from Linux using Remoteproc

+

Remoteproc is a module that allows you to control the M7 Core from Linux +during runtime. Firmware built for TCM can be loaded and the execution started +or stopped. To use Remoteproc a devicetree overlay needs to be set:

+

Edit the bootenv.txt file located in the /boot directory on the target by +adding conf-imx8mp-phycore-rpmsg.dtbo:

+
overlays=conf-imx8mp-phycore-rpmsg.dtbo
+
+
+

Restart the target and execute in U-Boot:

+
u-boot=> run prepare_mcore
+
+
+

Firmware .elf files for the M7 Core can be found under /lib/firmware. +To load the firmware, type:

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

To load a different firmware, the M7 Core needs to be stopped:

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

Note

+

The samples found in /lib/firmware on the target come from NXP’s +Yocto layer meta-imx. +To use the samples you built yourself through MCUX SDK, please copy them +to /lib/firmware on the target after building them.

+
+
+ +
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mp/imx8mp.html b/previews/271/bsp/imx8/imx8mp/imx8mp.html new file mode 100644 index 000000000..9c2c8d2af --- /dev/null +++ b/previews/271/bsp/imx8/imx8mp/imx8mp.html @@ -0,0 +1,856 @@ + + + + + + + + + i.MX 8M Plus Manuals — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

i.MX 8M Plus Manuals

+ +
+

Mainline HEAD

+
+

Table of Contents

+ +
+
+
+

BSP-Yocto-NXP-i.MX8MP-PD24.1.0

+
+

Table of Contents

+ +
+
+
+

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2

+
+

Table of Contents

+ +
+
+
+

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1

+
+

Table of Contents

+ +
+
+
+

BSP-Yocto-NXP-i.MX8MP-PD23.1.0

+
+

Table of Contents

+ +
+
+
+

BSP-Yocto-NXP-i.MX8MP-PD22.1.2

+
+

Table of Contents

+ +
+
+
+

BSP-Yocto-NXP-i.MX8MP-PD22.1.1

+
+

Table of Contents

+ +
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mp/mainline-head.html b/previews/271/bsp/imx8/imx8mp/mainline-head.html new file mode 100644 index 000000000..37a51511f --- /dev/null +++ b/previews/271/bsp/imx8/imx8mp/mainline-head.html @@ -0,0 +1,3518 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + + + + + +

L-XXXXX.Xx i.MX 8M Plus BSP +ManualHead

Document Title

L-XXXXX.Xx i.MX 8M Plus BSP +Mainline Manual Head

Document Type

BSP Manual

Article Number

L-XXXXX.Xx

Yocto Manual

Release Date

XXXX/XX/XX

Is Branch of

L-XXXXX.Xx i.MX 8M Plus BSP +Mainline Manual Head

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +phyCORE-i.MX8M Plus Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads of our product.

+
+

1.1. Supported Hardware

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 download.

+

If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware

+
+

1.1.1. phyBOARD-Pollux Components

+
+../../../_images/phyBOARD-Pollux-front-components.jpg + +
+

phyBOARD-Pollux Components (top)

+
+
+
+../../../_images/phyBOARD-Pollux-back-components.jpg + +
+

phyBOARD-Pollux Components (bottom)

+
+
+
+
+
+
+

2. Getting Started

+

The phyCORE-i.MX8M Plus Kit is shipped with a pre-flashed SD card. It contains the +phytec-qt6demo-image and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+

There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool dd. An +alternative way is to use PHYTEC’s system initialization program called +partup, which makes it especially easy to +format more complex systems. You can get prebuilt Linux binaries of partup from its release page. Also read +partup’s README for installation +instructions.

+
+

2.1. Get the Image

+

The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using dd, can be downloaded from the PHYTEC download server.

+

Get either the partup package or the WIC image from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+
+

Note

+

For eMMC, more complex partitioning schemes or even just large images, we +recommend using the partup package, as it is faster in writing than dd +and allows for a more flexible configuration of the target flash device.

+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card, you must have root privileges on your Linux +host PC. Be very careful when specifying the destination device! All files +on the selected device will be erased immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system on your host PC!

+
+
+

2.2.1. Finding the Correct Device

+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+

Unmount all those partitions, e.g.:

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

Now, the SD card is ready to be flashed with an image, using either partup, +dd or bmap-tools.

+
+
+

2.2.2. Using bmap-tools

+

One way to prepare an SD card is using +bmap-tools. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host:~$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

Replace <your_device> with your actual SD card’s device name found previously, +and make sure to place the file <IMAGENAME>-<MACHINE>.wic.bmap alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip.

+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.2.3. Using partup

+

Writing to an SD card with partup is done in a single command:

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).partup /dev/<your_device>
+
+
+

Make sure to replace <your_device> with your actual device name found previously.

+

Further usage of partup is explained at its official documentation website.

+
+

Warning

+

Host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to write partup packages created with Yocto Mickledore +or newer to SD-Card. This is due to a new default option in resize2fs which causes an +incompatibility. See release notes.

+
+
+

Note

+

partup has the advantage of allowing to clear specific raw areas in the +MMC user area, which is used in our provided partup packages to erase any +existing U-Boot environments. This is a known issue bmaptool does not +solve, as mentioned in the previous chapter.

+

Another key advantage of partup over other flashing tools is that it allows +configuring MMC specific parts, like writing to eMMC boot partitions, without +the need to call multiple other commands when writing.

+
+
+
+

2.2.4. Using dd

+

After having unmounted all SD card’s partitions, you can create your bootable SD card.

+

Some PHYTEC BSPs produce uncompressed images (with filename-extension *.wic), +and some others produce compressed images (with filename-extension *.wic.xz).

+

To flash an uncompressed images (*.wic) use command below:

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Or to flash a compressed images (*.wic.xz) use that command:

+
host:~$ xzcat phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Again, make sure to replace <your_device> with your actual device name found +previously.

+

The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

+
+
+
+

2.3. First Start-up

+ +../../../_images/SD_Card_Boot2.png +
    +

  • Insert the SD card

    • +

  • Connect the target and the host with mirco USB on (X1) +debug USB

    • +

  • Power up the board

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (scarthgap).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (scarthgap).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-IMX8MP; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-xwayland MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the phyboard-pollux-imx8mp-3 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx8mp.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_pmu_train_1d_dmem_202006.bin, +lpddr4_pmu_train_1d_imem_202006.bin, +lpddr4_pmu_train_2d_dmem_202006.bin, +lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY firmware images

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx8mp-phyboard-pollux-rdk*.dtb: Kernel device tree file

    • +

  • phytec-qt6demo-image*.tar.gz: Root file system

    • +

  • phytec-qt6demo-image*.wic.xz: SD card image

    • +
+
+
+
+
+

4. Installing the OS

+

For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see Setup Network Host.

+
+

4.1. Bootmode Switch (S3)

+
+

Tip

+

Hardware revision baseboard: 1552.2

+
+

The phyBOARD-Pollux features a boot switch with four individually switchable ports to +select the phyCORE-i.MX 8M Plus default bootsource.

+ + + + + + + + + + + +
+../../../_images/eMMC2.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses2.png +
+

Internal Fuses

+
+
+
+../../../_images/SPI_NOR2.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download3.png +
+

USB Serial Download

+
+
+
+../../../_images/SD_Card_Boot2.png +
+

SD Card

+
+
+
+../../../_images/Test_Mode.png +
+

Test Mode

+
+
+
+
+
+

4.2. Flash eMMC

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S3) is set to eMMC.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk2p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from Network

+

i.MX 8M Plus boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

4.2.1.1. Flash eMMC from Network in U-Boot on Target

+

These steps will show how to update the eMMC via a network.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+
+

Tip

+

This step only works if the size of the image file is less than 1,28GB due to +limited RAM space available in the Bootloader.

+
+
    +

  • Uncompress your image:

    • +
+
host:~$ unxz /srv/tftp/phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+
    +

  • Load your image via network to RAM:

    +
    u-boot=> dhcp ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.11 (101 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • Write the image to the eMMC:

    +
    u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +
+
+
+

4.2.1.2. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Take a compressed or decompressed image with the accompanying block map file +*.bmap on the host and send it with ssh through the network to the eMMC of +the target with a one-line command:

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.* /tmp && bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
+
+
+
+

4.2.1.3. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Show your available image files on the host:

+
host:~$ ls /srv/tftp
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
+
+

Send the image with the bmaptool command combined with ssh through the network +to the eMMC of your device:

+
host:~$ scp /srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2"
+
+
+
+
+
+

4.2.2. Flash eMMC U-Boot image via Network from running U-Boot

+

Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> dhcp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.3. Flash eMMC from USB stick

+
+

4.2.3.1. Flash eMMC from USB stick in U-Boot on Target

+
+

Note

+

Only the lower USB-A port is configured for storage devices and only +this port will work when trying to access a storage device in U-Boot.

+
+
+

Tip

+

This step only works if the size of the image file is less than 1,28GB due to +limited RAM space available in the Bootloader.

+
+

These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch (S3) to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied uncompressed WIC image to +the USB slot.

+

Load your image from the USB device to RAM:

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz). Set the bootmode switch (S3) to SD Card.

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ ls /mnt
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without partition):

    +
    target:~$ bmaptool copy /mnt/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Tip

    +

    Before this will work, you need to configure the bootmode switch (S3) to +eMMC.

    +
    +
    • +
+
+
+
+

4.2.4. Flash eMMC from SD Card

+

Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (*.wic) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see Resizing ext4 Root Filesystem.

+

Alternatively, flash a partup package to the SD card, as described in +Getting Started. This will ensure the full space of the SD card is used.

+
+

4.2.4.1. Flash eMMC from SD card in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1,28GB due to +limited RAM space available in the Bootloader.

+
+
    +

  • Flash an SD card with a working image and create a third ext4 partition. Copy +the WIC image (for example phytec-qt6demo-image.rootfs.wic) to this partition.

    • +

  • Configure the bootmode switch (S3) to SD Card and insert the SD Card.

    • +

  • Power on the board and stop in U-Boot.

    • +

  • Load the image:

    +
    u-boot=> mmc dev 1
+u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • Switch the mmc dev to eMMC:

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • Flash your WIC image (for example phytec-qt6demo-image.roots.wic) +from the SD card to eMMC. This will partition the card and copy imx-boot, +Image, dtb, dtbo, and root file system to eMMC.

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • Power off the board and change the bootmode switch (S3) to eMMC.

    • +
+
+
+

4.2.4.2. Flash eMMC from SD card in Linux on Target

+

You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card.

+
    +

  • Show your saved partup package or WIC image files on the SD card:

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without +partition) using partup:

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup /dev/mmcblk2
+
    +
    +

    Flashing the partup package has the advantage of using the full capacity of +the eMMC device, adjusting partitions accordingly.

    +
    +

    Note

    +

    Alternatively, bmaptool may be used instead:

    +
    target:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
    +
    +

    Keep in mind that the root partition does not make use of the full space when +flashing with bmaptool.

    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Warning

    +

    Before this will work, you need to configure the bootmode switch (S3) to eMMC.

    +
    +
    • +
+
+
+
+
+

4.3. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A6 RAUC Update & Device Management Manual.

+
+
+
+

5. Development

+
+

5.1. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.1.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.2. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.2.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel image to your tftp directory:

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • Copy the devicetree to your tftp directory:

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.2.2. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.3.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy-ampliphy-xwayland/images/phyboard-pollux-imx8mp-3/. For flashing a wic image to eMMC, +you will also need phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic

+
+
+

5.3.3. Prepare Target

+

Set the bootmode switch (S3) to USB Serial Download. Also, connect USB port +X5 (upper connector) to your host.

+
+
+

5.3.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via (X1), as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.3.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
+
+
+
+
+

5.4. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone https://github.com/phytec/u-boot-phytec.git)

+
+
+

5.4.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    https://github.com/phytec/u-boot-phytec.git
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-phytec and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    https://github.com/phytec/linux-phytec.git
+
    +
    +
    • +

  • Our i.MX 8M Plus kernel is based on the linux-phytec kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
recipes-kernel/linux/linux-phytec_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-phytec_*.bb
+
+
+
+
+
+

5.4.2. Get the SDK

+

You can download the SDK here, or build it yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

After a successful build the SDK installer is deployed to build/deploy*/sdk.

+
+
+

5.4.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.1.sh
+host:~$ ./phytec-ampliphy-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.1.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-xwayland/5.0.1):
+You are about to install the SDK to "/opt/ampliphy-xwayland/5.0.1". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-xwayland/5.0.1/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. U-Boot standalone build

+
+

5.5.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone https://github.com/phytec/u-boot-phytec.git
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag used in this release is called v2024.01-phy4

    • +

  • Check out the needed U-Boot tag:

    +
    host:~$ cd ~/u-boot-phytec/
+host:~/u-boot-phytec$ git fetch --all --tags
+host:~/u-boot-phytec$ git checkout tags/v2024.01-phy4
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/u-boot-phytec$ source /opt/ampliphy-xwayland/5.0.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. Get the needed binaries

+

To build the bootloader, you need to copy these files to your u-boot-phytec +build directory and rename them to fit with mkimage script:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx8mp.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +
+

If you already built our BSP with Yocto, you can get the +bl31-imx8mp.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: BSP Images

+

Or you can download the files here: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/

+
+

Warning

+

Make sure you rename the files you need so that they are compatible with the +mkimage tool.

+
+
+
+

5.5.3. Build the bootloader

+
    +

  • build flash.bin (imx-boot):

    +
    host:~/u-boot-phytec$ make phycore-imx8mp_defconfig
+host:~/u-boot-phytec$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. Flash the bootloader to a block device

+

The flash.bin can be found at u-boot-phytec/ directory and now can be +flashed. A chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

E.g. flash SD card:

+
host:~/u-boot-phytec$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables +“BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+

5.5.5. Build U-Boot With a Fixed RAM Size

+

If you cannot boot your system anymore because the hardware introspection in the +EEPROM is damaged or deleted, you can create a flash.bin with a fixed ram size. +You should still contact support and flash the correct EEPROM data, as this +could lead to unexpected behavior.

+

Follow the steps to get the U-boot sources and check the correct branch in the +Build U-Boot section.

+

Edit the file configs/phycore-imx8mp_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+
+
+

Choose the correct RAM size as populated on the board and uncomment the line for +this ram size. +After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+

5.5.6. Build U-Boot With a Fixed RAM Size and Frequency

+

Starting with PD23.1.0 NXP or PD24.1.2 mainline release, the phyCORE-i.MX 8M Plus SoMs +with revision 1549.3 and newer also support 2GHz RAM timings. These will be +enabled for supported boards automatically, but they can also be enabled or +disabled manually.

+

Edit the file configs/phycore-imx8mp_defconfig. +The fixed RAM size with 2GHz timings will be used:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+CONFIG_PHYCORE_IMX8MP_RAM_FREQ_FIX=y
+CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+
+
+

After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+

5.5.7. Build U-Boot With a Fixed RAM Frequency

+

Starting with PD24.1.2 mainline release or PD24.1.0 NXP release, U-Boot can +also be built with just fixed RAM Frequency while the RAM size will still be +used from EEPROM.

+

Edit the file configs/phycore-imx8mp_defconfig. +The RAM size from EEPROM with fixed frequency will be used:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_FREQ_FIX=y
+# CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+# CONFIG_PHYCORE_IMX8MP_USE_1_5GHZ_RAM_TIMINGS=y
+
+
+

After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+
+

5.6. Kernel standalone build

+
+

5.6.1. Setup sources

+
    +

  • The used linux-phytec branch can be found in the release notes

    • +

  • The tag needed for this release is called v6.6.21-phy1

    • +

  • Check out the needed linux-phytec tag:

    +
    host:~$ git clone https://github.com/phytec/linux-phytec.git
+host:~$ cd ~/linux-phytec/
+host:~/linux-phytec$ git fetch --all --tags
+host:~/linux-phytec$ git checkout tags/v6.6.21-phy1
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-phytec$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-phytec$ source /opt/ampliphy-xwayland/5.0.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-phytec$ make defconfig
+host:~/linux-phytec$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-phytec$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-phytec/arch/arm64/boot/Image

    • +

  • The dtb can be found at +~/linux-phytec/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-phytec$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. Copy Kernel to SD Card

+

When one-time boot via netboot is not sufficient, the kernel along with its +modules and the corresponding device tree blob may be copied directly to a +mounted SD card.

+
host:~/linux-phytec$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-phytec$ cp arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb /path/to/sdcard/boot/oftree
+host:~/linux-phytec$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. Accessing the Development states

+
+

5.7.1. Development state of current release

+

These release manifests exist to give you access to the development states +of the Yocto BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line:

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2
+
+
+

This will initialize a BSP that will track the latest development state of the +current release (BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2). From now on repo sync in this folder +will pull all the latest changes from our Git repositories:

+
host:~$ repo sync
+
+
+
+
+

5.7.2. Development state of upcoming release

+

Also development states of upcoming releases can be accessed this way. +For this execute the following command and look for a release with a higher +PDXX.Y number than the latest one (BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2) and .y at the +end:

+
host:~$ ./phyLinux init -p imx8mp
+
+
+
+
+
+

5.8. Accessing the Latest Upstream Support

+

We have a vanilla manifest that makes use of the Yocto master branches (not an +NXP release), Linux, and U-Boot. This can be used to test the latest upstream +kernel/U-Boot.

+
+

Note

+

The master manifest reflects the latest state of development. This tends to +be broken from time to time. We try to fix the master on a regular basis.

+
+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.9.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 8M Plus SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Board.dts - include the module dtsi file. Devices that come from the i.MX 8M Plus +SoC but are just routed down to the carrier board and used there are included +in this dts.

    • +

  • Overlay.dtso - enable/disable features depending on optional hardware that +may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10)

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 8 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the folder arch/arm64/boot/dts/freescale/.

+

Available overlays for phyboard-pollux-imx8mp-3.conf are:

+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 8M Plus BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 8M Plus BSP Device Tree Concept to get an understanding +of our i.MX 8 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 8 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 8M Plus Pin Muxing

+

The i.MX 8M Plus SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 8M Plus terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 8M Plus Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx8mp-phyboard-pollux-rdk.dts:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x140
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x140
+        >;
+};
+
+
+

The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled.

+

The device tree representation for UART1 pinmuxing: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L387

+
+
+

7.2. RS232/RS485

+

The phyCORE-i.MX 8M Plus supports up to 4 UART units. On the phyBOARD-Pollux, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector X2 at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers JP3 and +JP4 on the baseboard. For more information about the correct setup please +refer to the phyCORE-i.MX 8M Plus/phyBOARD-Pollux Hardware Manual section UARTs.

+

We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers JP3 and JP4 need to be set +correctly.

+
+

7.2.1. RS232

+
    +

  • Display the current settings of a terminal in a human-readable format:

    +
    target:~$ stty -a
+
    +
    +
    • +

  • Configuration of the UART interface can be done with stty. For example:

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • With a simple echo and cat, basic communication can be tested. Example:

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

The host should print out “123”.

+
+
+

7.2.2. RS485

+
+

Hint

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

For easy testing, look at the linux-serial-test. This tool is called the IOCTL +for RS485 and sends a constant stream of data.

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

More information about the linux-serial-test tool and its parameters can be +found here: linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Documentation for calling the IOCTL within c-code is described in the Linux +kernel documentation: +https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection3.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see “test” printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final “count for this session”. There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+
+
+

7.2.2.2. RS485 full-duplex

+

For full-duplex mode your connection setup should look like this:

+../../../_images/RS485_fullduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For full-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 1
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  true
+Bus termination enabled:  false
+
+
+

Also here you can do the echo test to see if sending and receiving works:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see “test” printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

To check if the full-duplex operation works, you need to use the +linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=114660, tx=118755, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=118755, tx=114660, rx err=0
+
+
+

In this example both targets will send and receive simultaneously. They will +receive for 15sec and send for 10sec. The receiver needs to receive a bit +longer, so that all sent messages will get received. Remember to start both +targets almost simultaneously. A small difference in start time is accounted +for with the -W 2 option. At the end the program will print the final +“count for this session”. There you can check that all transmitted frames were +received.

+

All the test examples are target to target, but can also be done with host to +target with a USB to rs485 converter. You may need to adjust the interfaces for +commands to work on the host then.

+

The device tree representation for RS232 and RS485: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L251

+
+
+
+
+

7.3. Network

+

phyBOARD-Pollux-i.MX 8M Plus provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board.

+
+

Warning

+

The naming convention of the Ethernet interfaces in the hardware (ethernet0 +and ethernet1) do not align with the network interfaces (eth0 and eth1) in +Linux. So, be aware of these differences:

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L41.

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Pollux can be found here: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L106

+
+

7.3.1. Network Environment Customization

+
+

7.3.1.1. U-boot network-environment

+
    +

  • We currently use dynamic IP addresses in U-Boot. This is enabled by this variable:

    +
    +
    u-boot=> printenv ip_dyn
+ip_dyn=yes
+
    +
    +
    +
    • +

  • Set up path for NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+
+

7.3.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+
+

7.4. SD/MMC Card

+

The i.MX 8M Plus supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://github.com/phytec/linux-phytec//blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L261

+

DT configuration for the eMMC interface can be found here: +https://github.com/phytec/linux-phytec//blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L181

+
+
+

7.5. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 8M Plus is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw Multi-Level Cells (MLC) or Triple-Level +Cells (TLC) combined with a memory controller that handles ECC and wear +leveling. They are connected via an SD/MMC interface to the i.MX 8M Plus and are +represented as block devices in the Linux kernel like SD cards, flash drives, or +hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.5.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +or TLC. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background Operations +(BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • Enabling can be done with this command:

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.5.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 8M Plus SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.5.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
+
+

7.5.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC or TLC +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC used in NAND Flash, MLC or TLC have lower reliability and a higher +error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC or TLC +or mark these blocks as discard. The data on the device is lost and +will be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.5.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 8M Plus uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.5.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

The following table is for the offset of the i.MX 8M Plus SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.6. SPI Master

+

The i.MX 8M Plus controller has a FlexSPI and an ECSPI IP core included. The FlexSPI +host controller supports two SPI channels with up to 4 devices. Each channel +supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data +lines). The ECSPI controller supports 3 SPI interfaces with one dedicated chip +selected for each interface. As chip selects should be realized with GPIOs, more +than one device on each channel is possible.

+

The definition of the SPI master node in the device tree can be found here: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L67

+
+
+

7.7. GPIOs

+

The phyBOARD-Pollux has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to i.MX 8M Plus pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal i.MX 8M Plus GPIO banks GPIO1 – GPIO5.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO5_07). <X> identifies the GPIO +bank and counts from 1 to 5, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo -c gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 20 from chip0):

    +
    target:~$ gpioget -c gpiochip0 20
+
    +
    +
    • +

  • Set the value of GPIO 20 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset -z -c gpiochip0 20=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <line=value>...
+
+Set values of GPIO lines.
+
+Lines are specified by name, or optionally by offset if the chip option
+is provided.
+Values may be '1' or '0', or equivalently 'active'/'inactive' or 'on'/'off'.
+
+The line output state is maintained until the process exits, but after that
+is not guaranteed.
+
+Options:
+      --banner            display a banner on successful startup
+  -b, --bias <bias>       specify the line bias
+                  Possible values: 'pull-down', 'pull-up', 'disabled'.
+                  (default is to leave bias unchanged)
+      --by-name           treat lines as names even if they would parse as an offset
+  -c, --chip <chip>       restrict scope to a particular chip
+  -C, --consumer <name>   consumer name applied to requested lines (default is 'gpioset')
+  -d, --drive <drive>     specify the line drive mode
+                  Possible values: 'push-pull', 'open-drain', 'open-source'.
+                  (default is 'push-pull')
+  -h, --help              display this help and exit
+  -l, --active-low        treat the line as active low
+  -p, --hold-period <period>
+                  the minimum time period to hold lines at the requested values
+  -s, --strict            abort if requested line names are not unique
+  -t, --toggle <period>[,period]...
+                  toggle the line(s) after the specified period(s)
+                  If the last period is non-zero then the sequence repeats.
+      --unquoted  don't quote line names
+  -v, --version           output version information and exit
+  -z, --daemonize set values then detach from the controlling terminal
+
+Chips:
+    A GPIO chip may be identified by number, name, or path.
+    e.g. '0', 'gpiochip0', and '/dev/gpiochip0' all refer to the same chip.
+
+Periods:
+    Periods are taken as milliseconds unless units are specified. e.g. 10us.
+    Supported units are 's', 'ms', and 'us'.
+
+*Note*
+    The state of a GPIO line controlled over the character device reverts to default
+    when the last process referencing the file descriptor representing the device file exits.
+    This means that it's wrong to run gpioset, have it exit and expect the line to continue
+    being driven high or low. It may happen if given pin is floating but it must be interpreted
+    as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.7.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the defconfig you use in +arch/arm64/configs/ in the linux kernel sources. For our NXP based releases, +this could be for example imx8_phytec_distro.config:

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+
+
+
+

7.8. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the phyBOARD-Pollux.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L160

+
+
+

7.9. I²C Bus

+

The i.MX 8M Plus contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 8M Plus. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our phyBOARD-Pollux.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C1 bus configuration (e.g. imx8mp-phycore-som.dtsi): +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L81

+

General I²C2 bus configuration (e.g. imx8mp-phyboard-pollux-rdk.dts) +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L145

+
+
+

7.10. EEPROM

+

On the phyCORE-i.MX8MP there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues.

+
+

Note

+

If you deleted reserved EEPROM spaces, please contact our support!

+
+
+

7.10.1. I2C EEPROM on phyCORE-i.MX8MP

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

The I2C EEPROM on the phyCORE-i.MX8MP SoM is connected to I2C address 0x51 on the I2C-0 +bus. It is possible to read and write directly to the device populated:

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the 4KiB EEPROM (bus: I2C-0 addr: 0x51) with zeros leaving out the EEPROM data use:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM Detection

+

The I2C EEPROM, populated on the phyCORE-i.MX8MP, has a separate ID page that is +addressable over I2C address 0x59 on bus 0 and a normal area that is addressable +over I2C address 0x51 on bus 0. PHYTEC uses this data area of 32 Bytes to store +information about the SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the EEPROM ID page data and the first 256 bytes of the normal area are +deleted, the bootloader will fall back to the phyCORE-i.MX8MP Kit RAM setup, which +is 2GiB RAM.

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

SoMs that are flashed with data format API revision 2 will print out information +about the module in the early stage.

+

DT representation, e.g. in phyCORE-i.MX 8M Plus file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L169

+
+
+
+

7.11. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC Parameters

+

RTCs have a few abilities which can be read/set with the help of hwclock +tool.

+
    +

  • We can check RTC supported features with:

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    What this value means is encoded in kernel, each set bit translates to:

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • We can check RTC BSM (Backup Switchover Mode) with:

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • We can set RTC BSM with:

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    What BSM values mean translates to these values:

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    Tip

    +

    You should set BSM mode to DSM or LSM for RTC to switch to backup power +source when the initial power source is not available. Check RV-3028 RTC +datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching +Mode) actually mean.

    +
    +
    • +
+

DT representation for I²C RTCs: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L175

+
+
+
+

7.12. USB Host Controller

+

The USB controller of the i.MX 8M Plus SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +‘SS’). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY.

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+

DT representation for USB Host: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L220

+
+
+

7.13. CAN FD

+

The phyBOARD-Pollux has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The two CAN interfaces should show up as +can0 and can1.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    The information for can0 will look like:

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+
+

Warning

+

The mcp2518fd SPI to CANfd supports only baudrates starting from 125kB/s. +Slower rates can be selected but may not work correctly.

+
+

Device Tree CAN configuration of imx8mp-phyboard-pollux-rdk.dts: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L130

+
+
+

7.14. Video

+
+

7.14.1. Videos with Gstreamer

+

One example video is installed by default in the BSP at /usr/share/qtphy/videos/. +Start the video playback with one of these commands:

+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink fullscreen=true
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+

Note

+

The mainline BSP currently only supports software rendering.

+
+
+
+
+

7.15. Display

+

The phyBOARD-Pollux supports LVDS output via the LVDS1 connector on the carrier board. The +LVDS interface is enabled by default.

+
+

7.15.1. Weston Configuration

+

Weston will work without any additional configuration. Configuration options are +done at /etc/xdg/weston/weston.ini.

+

Device tree description of LVDS can be found here: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L182

+
+
+

7.15.2. Qt Demo

+

With the phytec-qt6demo-image, Weston starts during boot. Our Qt6 demo application named +“qtphy” can be stopped with:

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • To start the demo again, run:

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • To disable autostart of the demo, run:

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • To enable autostart of the demo, run:

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston can be stopped with:

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

Note

+

The Qt demo must be closed before Weston can be closed.

+
+
+
+

7.15.3. Backlight Control

+

If a display is connected to the PHYTEC board, you can control its backlight +with the Linux kernel sysfs interface. All available backlight devices in the +system can be found in the folder /sys/class/backlight. Reading the appropriate +files and writing to them allows you to control the backlight.

+
+

Note

+

Some boards with multiple display connectors might have multiple backlight +controls in /sys/class/backlight. For example: backlight0 and backlight1

+
+
    +

  • To get, for example, the maximum brightness level (max_brightness) execute:

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    Valid brightness values are 0 to <max_brightness>.

    +
    • +

  • To obtain the current brightness level, type:

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • Write to the file brightness to change the brightness:

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    turns the backlight off for example.

    +

    For documentation of all files, see +https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight.

    +
    • +
+
+

Note

+

We noticed some visible backlight flickering on brightness level 1 (probably +due to frequency problems with the hardware).

+
+
+
+
+

7.16. Power Management

+
+

7.16.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 8M Plus SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as ‘Dynamic Voltage and +Frequency Scaling’ (DVFS). The i.MX 8M Plus BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the i.MX 8 +variant used, several different frequencies are supported.

+
+

Tip

+

Although the DVFS framework provides frequency settings for each CPU core, a +change in the frequency settings of one CPU core always affects all other CPU +cores too. So all CPU cores always share the same DVFS setting. An individual +DVFS setting for each core is not possible.

+
+
    +

  • To get a complete list type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately +1,6 GHz, the result will be:

    +
    1200000 1600000
+
    +
    +
    • +

  • To ask for the current frequency type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

So-called governors are automatically selecting one of these frequencies in +accordance with their goals.

+
    +

  • List all governors available with the following command:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    The result will be:

    +
    ondemand userspace performance schedutil
+
    +
    +
    • +

  • ondemand (default) switches between possible CPU core frequencies in +reference to the current system load. When the system load increases above a +specific limit, it increases the CPU core frequency immediately.

    • +

  • performance always selects the highest possible CPU core frequency.

    • +

  • userspace allows the user or userspace program running as root to set a +specific frequency (e.g. to 1600000). Type:

    • +

  • In order to ask for the current governor, type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    You will normally get:

    +
    schedutil
+
    +
    +
    • +

  • Switching over to another governor (e.g. userspace) is done with:

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • Now you can set the speed:

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +Documentation/admin-guide/pm/cpufreq.rst.

+
+
+

7.16.2. CPU Core Management

+

The i.MX 8M Plus SoC can have multiple processor cores on the die. The i.MX 8M Plus, for +example, has 4 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    Here the system has four processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+
+

7.17. Thermal Management

+
+

7.17.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.17.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 8M Plus SoC platform. The i.MX 8 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Industrial +and Commercial.

+ + + + + + + + + + + + + + + + + +

Commercial

Industrial

passive (warning)

85°C

95°C

critical (shutdown)

90°C

100°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise, Fair Share, Bang Bang, and +Userspace. The default policy used in the BSP is step_wise. If the value of the +SoC temperature in the sysfs file temp is above trip_point_0, the CPU frequency +is set to the lowest CPU frequency. When the SoC temperature drops below +trip_point_0 again, the throttling is released.

+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+
+

7.18. Watchdog

+

The PHYTEC i.MX 8M Plus modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.18.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.19. snvs Power Key

+

The X_ONOFF pin connected to the ON/OFF button can be pressed long to trigger +Power OFF without SW intervention. With the snvs_pwrkey driver, the KEY_POWER +event is also reported to userspace when the button is pressed. On default, systemd +is configured to ignore such events. The function of Power OFF without SW +intervention are not configured. Triggering a power off with systemd when pushing +the ON/OFF button can be configured under /etc/systemd/logind.conf and set using:

+
HandlePowerKey=poweroff
+
+
+
+
+

7.20. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 8M Plus provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 8M Plus Reference Manual). The following list is +an abstract from the i.MX 8M Plus Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x30350000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x30350000

Description

OCOTP_MAC_ADDR0

9

0

0x640

contains lower 32 bits +of ENET0 MAC address

OCOTP_MAC_ADDR1

9

1

0x650

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

OCOTP_MAC_ADDR2

9

2

0x660

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 8M Plus Security Reference Manual.

+
+

7.20.1. Reading Fuse Values in uBoot

+

You can read the content of a fuse using memory-mapped shadow registers. To +calculate the memory address, use the fuse Bank and Word in the following +formula:

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.20.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mp/pd22.1.1.html b/previews/271/bsp/imx8/imx8mp/pd22.1.1.html new file mode 100644 index 000000000..6fb62e5a7 --- /dev/null +++ b/previews/271/bsp/imx8/imx8mp/pd22.1.1.html @@ -0,0 +1,4604 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 8M Plus BSP Manual

Document Title

i.MX 8M Plus BSP Manual

Document Type

BSP Manual

Yocto Manual

Release Date

2023/05/25

Is Branch of

i.MX 8M Plus BSP Manual

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-NXP-i.MX8MP-PD22.1.1

Minor

2023/05/23

Released

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +phyCORE-i.MX8M Plus Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads of our product.

+
+

1.1. Supported Hardware

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-NXP-i.MX8MP-PD22.1.1 download.

+

If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware

+
+

1.1.1. phyBOARD-Pollux Components

+
+../../../_images/phyBOARD-Pollux-front-components.jpg + +
+

phyBOARD-Pollux Components (top)

+
+
+
+../../../_images/phyBOARD-Pollux-back-components.jpg + +
+

phyBOARD-Pollux Components (bottom)

+
+
+
+
+
+
+

2. Getting Started

+

The phyCORE-i.MX8M Plus Kit is shipped with a pre-flashed SD card. It contains the +phytec-qt5demo-image and can be used directly as a boot source. The eMMC is +programmed with only a U-boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+
+

2.1. Get the Image

+

The WIC image contains all BSP files in several, correctly pre-formatted +partitions and can be copied to an SD card easily using the single Linux +command dd. It can be built by Yocto or downloaded from the PHYTEC download +server.

+

Get the WIC file from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card with the dd command, you must have root +privileges. Be very careful when specifying the destination device with +dd! All files on the selected destination device will be erased +immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system!

+
+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. Unmount any mounted partitions before +you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+
    +

  • Unmount all partitions, e.g.:

    +
    host$ sudo umount /dev/sde1
+
    +
    +
    • +

  • After having unmounted all partitions, you can create your bootable SD card:

    +
    host$ sudo dd if=<IMAGENAME>-<MACHINE>.wic of=/dev/sdX bs=1M conv=fsync status=progress
+
    +
    +

    Again, make sure to replace /dev/sdX with your actual device name found +previously.

    +

    The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

    +
    • +
+

An alternative and much faster way to prepare an SD card can be done by using +bmap-tools from Intel. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host$ bmaptool copy <IMAGENAME>-<MACHINE>.wic /dev/<your_device>
+
+
+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.3. First Start-up

+ +../../../_images/SD_Card_Boot2.png +
    +

  • Insert the SD card

    • +

  • Connect the target and the host with mirco USB on (X1) +debug USB

    • +

  • Power up the board

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: L-813e.A12 Yocto Reference Manual (Hardknott).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +L-813e.A12 Yocto Reference Manual (Hardknott).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-IMX8MP; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-xwayland MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD22.1.1
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-qt5demo-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the phyboard-pollux-imx8mp-3 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx8mp.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, +lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY firmware images

    • +

  • imx-boot: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM +Trusted Firmware and DDR firmware. This is the final bootloader image which is +bootable.

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx8mp-phyboard-pollux-rdk*.dtb: Kernel device tree file

    • +

  • imx8mp-phy*.dtbo: Kernel device tree overlay files

    • +

  • phytec-qt5demo-image*.tar.gz: Root file system

    • +

  • phytec-qt5demo-image*.wic: SD card image

    • +
+
+
+
+
+

4. Installing the OS

+
+

4.1. Bootmode Switch (S3)

+
+

Tip

+

Hardware revision baseboard: 1552.2

+
+

The phyBOARD-Pollux features a boot switch with four individually switchable ports to +select the phyCORE-i.MX 8M Plus default bootsource.

+ + + + + + + + + + + +
+../../../_images/eMMC2.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses2.png +
+

Internal Fuses

+
+
+
+../../../_images/SPI_NOR2.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download3.png +
+

USB Serial Download

+
+
+
+../../../_images/SD_Card_Boot2.png +
+

SD Card

+
+
+
+../../../_images/Test_Mode.png +
+

Test Mode

+
+
+
+
+
+

4.2. Flash eMMC

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S3) is set to Default SOM boot.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk2p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from Network

+

i.MX 8M Plus boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

4.2.1.1. Flash eMMC from Network in u-boot on Target

+

These steps will show how to update the eMMC via a network. However, they only +work if the size of the image file is less than 1GB. If the image file is +larger, go to the section Format SD Card. Configure the bootmode switch (S3) to boot +from SD Card and put in an SD card. Power on the board and stop in U-Boot +prompt.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+
    +

  • Load your image via network to RAM:

    +
    u-boot=> tftp ${loadaddr} phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • Write the image to the eMMC:

    +
    u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +
+
+
+

4.2.1.2. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host.

+
+

Take a compressed or uncompressed image on the host and send it with ssh through +the network (then uncompress it, if necessary) to the eMMC of the target with a +one-line command:

+
target:~$ ssh <USER>@192.168.3.10 "dd if=<path_to_file>/phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic" | dd of=/dev/mmcblk2
+
+
+
+
+

4.2.1.3. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host.

+
+

Show your available image files on the host:

+
host:~$ ls
+phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
+
+

Send the image with the command dd command combined with ssh through the network +to the eMMC of your device:

+
host:~$ dd if=phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2"
+
+
+
+
+
+

4.2.2. Flash eMMC u-boot image via Network from running u-boot

+

Update the standalone u-boot image imx-boot is also possible from u-boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host.

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.3. Flash eMMC from USB

+
+

4.2.3.1. Flash eMMC from USB in u-boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in Bootloader after enabling the OPTEE.

+
+

These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch to bootmode switch (S3) and put in an SD card. Power on the board +and stop in u-boot prompt. Insert a USB device with the copied WIC image +to the USB slot.

+

Load your image from the USB device to RAM:

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} *.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic). Set the bootmode switch to +bootmode switch (S3).

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ cd /mnt
+target:~$ ls
+phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
    +
    +
    • +

  • Show list of available MMC devices:

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • The eMMC device can be recognized by the fact that it contains two boot +partitions: (mmcblk2boot0; mmcblk2boot1)

    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without partition):

    +
    target:~$ dd if=phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic of=/dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    • +
+
+

Warning

+

Before this will work, you need to configure the multi-port switch +to Default SOM Boot to bootmode switch (S3).

+
+
+
+
+

4.2.4. Flash eMMC from SD Card

+

Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (*.wic) located on the SD card. +Because the image file is quite large, you have to enlarge your SD card to use +its full space (if it was not enlarged before). To enlarge your SD card, see +Resizing ext4 Root Filesystem.

+
+

4.2.4.1. Flash eMMC from SD card in u-boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in Bootloader after enabling the OPTEE. If the +image file is too large use the Updating eMMC from SD card in +Linux on Target subsection.

+
+
    +

  • Flash an SD card with a working image and create a third FAT partition. Copy +the WIC image (for example phytec-qt5demo-image.wic) to this +partition.

    • +

  • Configure the bootmode switch to boot from the SD Card and insert the SD +card.

    • +

  • Power on the board and stop in u-boot.

    • +

  • Flash your WIC image (for example phytec-qt5demo-image.wic) +from the SD card to eMMC. This will partition the card and copy imx-boot, +Image, dtb, dtbo, and root file system to eMMC.

    • +

  • Load the image:

    +
    u-boot=> fatload mmc 1:3 ${loadaddr} phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • Switch the mmc dev:

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc0(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • Power off the board and change the multi-port switch to Default SOM Boot to +boot from eMMC.

    • +
+
+
+

4.2.4.2. Flash eMMC from SD card in Linux on Target

+

You can also flash the eMMC on Linux. You only need a complete image saved on +the SD card (e.g. phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic).

+
    +

  • Show your saved image files on the SD card:

    +
    target:~$ ls
+phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
    +
    +
    • +

  • Show list of available MMC devices:

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • The eMMC device can be recognized by the fact that it contains two boot +partitions: (mmcblk2boot0; mmcblk2boot1)

    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without +partition):

    +
    target:~$ dd if=phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic of=/dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    • +
+
+

Warning

+

Before this will work, you need to configure the bootmode switch (S3) to Default +SOM Boot to boot from eMMC.

+
+
+
+
+
+

4.3. Flash SPI NOR Flash

+

The phyCORE-i.MX8MP modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set bootmode switch (S3) to QSPI boot to boot from QSPI. The SPI Flash is +usually quite small. The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash +populated. Only the bootloader and the environment can be stored. The kernel, +device tree, and file system are taken from eMMC by default.

+

The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with:

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. Flash SPI NOR Flash from Network

+

The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-i.MX 8M Plus.

+
+

Tip

+

A working network is necessary! Setup Network Host.

+
+
+

4.3.1.1. Flash SPI NOR from Network in u-boot on Target

+

Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI-NOR flash needs to be probed:

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • A specially formatted u-boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image over tftp, erase and write the +bootloader to the flash:

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+

Warning

+

Erasing the complete SPI NOR flash when it is fully written will take quite +some time. This can trigger the watchdog to reset. Due to this, erase the +full flash in Linux.

+
+
+
+

4.3.1.2. Flash SPI NOR from Network in kernel on Target

+
    +

  • Copy the image from the host to the target:

    +
    host:~$ scp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • Find the number of erase blocks of the U-boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the u-boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+

4.3.2. Flash SPI NOR Flash from SD Card

+

The bootloader on SPI NOR flash can be also flashed with SD Card.

+
+

4.3.2.1. Flash SPI NOR from SD Card in u-boot on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi to the FAT partition +on the SD Card. Before reading and writing are possible, the SPI-NOR flash +needs to be probed:

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • A specially formatted U-boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image from the SD Card, erase and write +the bootloader to the flash:

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+

Warning

+

Erasing the complete SPI NOR flash when it is fully written will take quite +some time. This can trigger the watchdog to reset. Due to this, erase the +full flash in Linux.

+
+
+
+

4.3.2.2. Flash SPI NOR from SD Card in kernel on Target

+
    +

  • Mount the SD Card:

    +
    host:~$ mount /dev/mmcblkp1 /mnt
+
    +
    +
    • +

  • Find the number of erase blocks of the u-boot partition:

    +
    target:~$  mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the u-boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A3 RAUC Update & Device Management Manual.

+
+
+
+

5. Development

+
+

5.1. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.1.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.2. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.2.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel image to your tftp directory:

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • Copy the devicetree to your tftp directory:

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • Copy all the overlays you want to use into your tftp directory:

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-qt5demo-image-phyboard-pollux-imx8mp-3.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.2.2. Set the bootenv.txt for Netboot

+

Create a bootenv.txt file in your tftp directory and write the following variables into it.

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> has to be replaced with the devicetree overlay filenames that you want to use. +Separate the filenames by spaces. For example:

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

Tip

+

All supported devicetree overlays are in the device tree chapter.

+
+
+
+

5.2.3. Network Settings on Target

+

To customize the targets ethernet configuration, please follow the description +here: Network Environment Customization

+
+
+

5.2.4. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.3.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/phyboard-pollux-imx8mp-3/. For flashing a wic image to eMMC, +you will also need phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic.

+
+
+

5.3.3. Prepare Target

+

Set the bootmode switch (S3) to USB Serial Download. Also, connect USB port +X5 (upper connector) to your host.

+
+
+

5.3.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via (X1), as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.3.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
+
+
+
+
+

5.4. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone git://git.phytec.de/u-boot-imx)

+
+
+

5.4.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-imx and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • Our i.MX 8M Plus kernel is based on the linux-imx kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. Get the SDK

+

You can download the SDK here, or build it yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt5demo-image # or another image
+
    +
    +
    • +
+

After a successful build the SDK installer is deployed to build/deploy*/sdk.

+
+
+

5.4.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt5demo-image-cortexa53-crypto-toolchain-BSP-Yocto-NXP-i.MX8MP-PD22.1.1.sh
+host:~$ ./phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt5demo-image-cortexa53-crypto-toolchain-BSP-Yocto-NXP-i.MX8MP-PD22.1.1.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.1):
+You are about to install the SDK to "/opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.1". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. U-Boot standalone build

+
+

5.5.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag needed at this release is called v2021.04_2.2.0-phy13

    • +

  • Check out the needed U-Boot tag:

    • +
+
host:~$ cd ~/u-boot-imx/
+host:~$ git fetch --all --tags
+host:~$ git checkout tags/v2021.04_2.2.0-phy13
+
+
+
    +

  • Technically, you can now build the U-Boot, but practically there are some +further steps necessary:

    +
      +

    • Create your own development branch:

      +
      host:~$ git switch --create <new-branch>
+
      +
      +
      +

      Note

      +

      You can name your development branch as you like, this is just an example.

      +
      +
      • +
    +
    • +

  • Set up a build environment:

    +
    host:~$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +

  • Set this environment variable before building the Image:

    +
    host:~$ export ATF_LOAD_ADDR=0x970000
+
    +
    +
    • +
+
+
+

5.5.2. Get the needed binaries

+

To build the bootloader, you need to copy these files to your u-boot-imx +build directory and rename them to fit with mkimage script:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx8mp.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +
+

If you already built our BSP with Yocto, you can get the +bl31-imx8mp.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: BSP Images

+

Or you can download the files here: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/

+
+

Warning

+

Make sure you rename the files you need so that they are compatible with the +mkimage tool.

+
+
+
+

5.5.3. Build the bootloader

+
    +

  • build flash.bin (imx-boot):

    +
    host:~$ make phycore-imx8mp_defconfig
+host:~$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. Flash the bootloader to a block device

+

The flash.bin can be found at u-boot-imx/ directory and now can be flashed. A +chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

E.g. flash SD card:

+
host:~$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables “BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+

5.5.5. Build U-Boot With a Fixed RAM Size

+

If you cannot boot your system anymore because the hardware introspection in the +EEPROM is damaged or deleted, you can create a flash.bin with a fixed ram size. +You should still contact support and flash the correct EEPROM data, as this +could lead to unexpected behavior.

+

Follow the steps to get the U-boot sources and check the correct branch in the +Build U-Boot section.

+

Edit the file configs/phycore-imx8mp_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+
+
+

Choose the correct RAM size as populated on the board and uncomment the line for +this ram size. +After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+
+

5.6. Kernel standalone build

+
+

5.6.1. Setup sources

+
    +

  • The used linux-imx branch can be found in the release notes

    • +

  • The tag needed for this release is called v5.10.72_2.2.0-phy17

    • +

  • Check out the needed linux-imx tag:

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v5.10.72_2.2.0-phy17
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-imx$ make imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-imx/arch/arm64/boot/Image

    • +

  • The dtb can be found at +~/linux-imx/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. Copy Kernel to SD Card

+

When one-time boot via netboot is not sufficient, the kernel along with its +modules and the corresponding device tree blob may be copied directly to a +mounted SD card.

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. Accessing the Development states

+
+

5.7.1. Development state of current release

+

These release manifests exist to give you access to the development states +of the Yocto BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line:

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD22.1.y
+
+
+

This will initialize a BSP that will track the latest development state of the +current release (BSP-Yocto-NXP-i.MX8MP-PD22.1.1). From now on repo sync in this folder +will pull all the latest changes from our Git repositories:

+
host:~$ repo sync
+
+
+
+
+

5.7.2. Development state of upcoming release

+

Also development states of upcoming releases can be accessed this way. +For this execute the following command and look for a release with a higher +PDXX.Y number than the latest one (BSP-Yocto-NXP-i.MX8MP-PD22.1.1) and .y at the +end:

+
host:~$ ./phyLinux init -p imx8mp
+
+
+
+
+
+

5.8. Accessing the Latest Upstream Support

+

We have a vanilla manifest that makes use of the Yocto master branches (not an +NXP release), Linux, and U-Boot. This can be used to test the latest upstream +kernel/U-Boot.

+
+

Note

+

The master manifest reflects the latest state of development. This tends to +be broken from time to time. We try to fix the master on a regular basis.

+
+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.9.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 8M Plus SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Carrierboard.dtsi - Devices that come from the i.MX 8M Plus SoC but are just routed +down to the carrier board and used there are included in this dtsi.

    • +

  • Board.dts - include the carrier board and module dtsi files. There may also +be some hardware configuration nodes enabled on the carrier board or the +module (i.e. the Board .dts shows the special characteristics of the board +configuration). For example, there are phyCORE-i.MX 8M Plus SOMs which may or may not +have a MIPI DSI to LVDS converter mounted. The converter is enabled (if +available) in the Board .dts and not in the Module .dtsi

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 8 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder arch/arm64/boot/dts/freescale/overlays.

+

Available overlays for phyboard-pollux-imx8mp-3.conf are:

+
imx8mp-isi-csi1.dtbo
+imx8mp-isi-csi2.dtbo
+imx8mp-isp-csi1.dtbo
+imx8mp-isp-csi2.dtbo
+imx8mp-phyboard-pollux-peb-av-010.dtbo
+imx8mp-phyboard-pollux-peb-av-012.dtbo
+imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+imx8mp-phycore-no-eth.dtbo
+imx8mp-phycore-no-rtc.dtbo
+imx8mp-phycore-no-spiflash.dtbo
+imx8mp-phycore-rpmsg.dtbo
+imx8mp-vm016-csi1.dtbo
+imx8mp-vm016-csi1-fpdlink.dtbo
+imx8mp-vm016-csi2.dtbo
+imx8mp-vm016-csi2-fpdlink.dtbo
+imx8mp-vm017-csi1.dtbo
+imx8mp-vm017-csi1-fpdlink.dtbo
+imx8mp-vm017-csi2.dtbo
+imx8mp-vm017-csi2-fpdlink.dtbo
+
+
+
+

Hint

+

There is one more overlay available for phyboard-pollux-imx8mp-2.conf: +imx8mp-phyboard-pollux-1552.1.dtbo

+
+

The usage of overlays can be configured during runtime in Linux or U-Boot. +Overlays are applied during the boot process in the bootloader after the +boot command is called and before the kernel is loaded. The next sections +explain the configuration in more detail.

+
+

6.2.2.1. Set ${overlays} variable

+

The ${overlays} U-Boot environment variable contains a space-separated list +of overlays that will be applied during boot. Depending on the boot source the +overlays have to either be placed in the boot partition of eMMC/SD-Card or are +loaded over tftp. Overlays set in the $KERNEL_DEVICETREE Yocto machine variable +will be automatically added to the boot partition of the final WIC image.

+

The ${overlays} variable can be either set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=imx8mp-phyboard-pollux-rdk-peb-eval-01.dtbo imx8mp-phyboard-pollux-peb-av-010.dtbo
+
+
+

Changes will take effect after the next reboot. If no bootenv.txt file is +available the overlays variable can be set directly in the U-Boot environment.

+
u-boot=> setenv overlays imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> printenv overlays
+overlays=imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> boot
+
+
+

If a user defined ${overlays} variable should be directly loaded from U-Boot +environment but there is still an external bootenv.txt available, the ${no_bootenv} +variable needs to be set as a flag:

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> boot
+
+
+

More information about the external environment can be found in +U-boot External Environment subsection of the +device tree overlay section.

+

We use the ${overlays} variable for overlays describing expansion boards and +cameras that can not be detected during run time. To prevent applying overlays +listed in the ${overlays} variable during boot, the ${no_overlays} variable can +be set to 1 in the bootloader environment.

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+

6.2.2.2. Extension Command

+

The U-Boot extension command makes it possible to easily apply overlays that +have been detected and added to a list by the board code callback +extension_board_scan(). +Overlays applied this way disable components that are not populated on the SoM. +The detection is done with the EEPROM data (EEPROM SoM Detection) found on the +SoM i2c EEPROM.

+

It depends on the SoM variant if any device tree overlays will be applied. To check +if an overlay will be applied on the running SoM in U-Boot, run:

+
u-boot=> extension scan
+Found 1 extension board(s).
+u-boot=> extension list
+Extension 0: phyCORE-i.MX8MP no SPI flash
+        Manufacturer:           PHYTEC
+        Version:
+        Devicetree overlay:     imx8mp-phycore-no-spiflash.dtbo
+        Other information:      SPI flash not populated on SoM
+
+
+

If the EEPROM data is not available, no device tree overlays are applied.

+

To prevent running the extension command during boot the ${no_extensions} +variable can be set to 1 in the bootloader environment:

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot External Environment

+

During the start of the Linux Kernel the external environment bootenv.txt +text file will be loaded from the boot partition of an MMC device or via TFTP. +The main intention of this file is to store the ${overlays} variable. This makes +it easy to pre-define the overlays in Yocto depending on the used machine. The +content from the file is defined in the Yocto recipe bootenv found in +meta-phytec: +https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=hardknott

+

Other variables can be set in this file, too. They will overwrite the existing +settings in the environment. But only variables evaluated after issuing the boot +command can be overwritten, such as ${nfsroot} or ${mmcargs}. Changing other +variables in that file will not have an effect. See the usage during netboot as +an example.

+

If the external environment can not be loaded the boot process will be anyway +continued with the values of the existing environment settings.

+
+
+

6.2.4. Change U-boot Environment from Linux on Target

+

Libubootenv is a tool included in our images to modify the U-Boot environment of +Linux on the target machine.

+

Print the U-Boot environment using the following command:

+
target:~$ fw_printenv
+
+
+

Modify a U-Boot environment variable using the following command:

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

Caution

+

Libubootenv takes the environment selected in a configuration file. The +environment to use is inserted there, and by default it is configured to use +the eMMC environment (known as the default used environment).

+

If the eMMC is not flashed or the eMMC environment is deleted, libubootenv +will not work. You should modify the /etc/fw_env.config file to match the +environment source that you want to use.

+
+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 8M Plus BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 8M Plus BSP Device Tree Concept to get an understanding +of our i.MX 8 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 8 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 8M Plus Pin Muxing

+

The i.MX 8M Plus SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 8M Plus terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 8M Plus Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx8mp-phyboard-pollux.dtsi:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x49
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x49
+        >;
+};
+
+
+

The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled.

+
+
+

7.2. RS232/RS485

+

The phyCORE-i.MX 8M Plus supports up to 4 UART units. On the phyBOARD-Pollux, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector X2 at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers JP3 and +JP4 on the baseboard. For more information about the correct setup please +refer to the phyCORE-i.MX 8M Plus/phyBOARD-Pollux Hardware Manual section UARTs.

+

We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers JP3 and JP4 need to be set +correctly.

+
+

7.2.1. RS232

+
    +

  • Display the current settings of a terminal in a human-readable format:

    +
    target:~$ stty -a
+
    +
    +
    • +

  • Configuration of the UART interface can be done with stty. For example:

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • With a simple echo and cat, basic communication can be tested. Example:

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

The host should print out “123”.

+
+
+

7.2.2. RS485

+
+

Hint

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

For easy testing, look at the linux-serial-test. This tool is called the IOCTL +for RS485 and sends a constant stream of data.

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

More information about the linux-serial-test tool and its parameters can be +found here: linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Documentation for calling the IOCTL within c-code is described in the Linux +kernel documentation: +https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+

The device tree representation for RS232 and RS485: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n331

+
+
+
+

7.3. Network

+

phyBOARD-Pollux-i.MX 8M Plus provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board.

+
+

Warning

+

The naming convention of the Ethernet interfaces in the hardware (ethernet0 +and ethernet1) do not align with the network interfaces (eth0 and eth1) in +Linux. So, be aware of these differences:

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n41.

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Pollux can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n141.

+
+

7.3.1. Network Environment Customization

+
+

7.3.1.1. U-boot network-environment

+
    +

  • To find the Ethernet settings in the target bootloader:

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • With your development host set to IP 192.168.3.10 and netmask 255.255.255.0, +the target should return:

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • If you need to make any changes:

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> should be one of ipaddr, netmask, gatewayip or serverip. +<value> will be the actual value of the chosen parameter.

    +
    • +

  • The changes you made are temporary for now. To save these:

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

Here you can also change the IP address to DHCP instead of using a static one.

+
    +

  • Configure:

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • Set up paths for TFTP and NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+

Tip

+

Variables like nfsroot and netargs can be overwritten by the U-boot External +Environment. For netboot, the external environment will be loaded from tftp. +For example, to locally set the nfsroot variable in a bootenv.txt file, +locate the tftproot directory:

+
nfsroot=/home/user/nfssrc
+
+
+

There is no need to store the info on the target. Please note that this does +not work for variables like ipaddr or serveraddr as they need to be already +set when the external environment is being loaded.

+
+
+
+

7.3.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. WLAN

+

WLAN and Bluetooth on the phyBOARD-Pollux are provided by the PEB-WLBT-05 expansion card. +The PEB-WLBT-05 for phyBOARD-Pollux Quickstart Guide shows you how to install the +PEB-WLBT-05.

+
+

Tip

+

With the BSP Version PD22.1 and newer, the PEB-WLBT-05 overlay needs to be activated first, +otherwise the PEB-WLBT-05 won’t be recognized.

+
target:~$ vi /boot/bootenv.txt
+
+
+

Afterwards the bootenv.txt file should look like this (it can also contain other devicetree +overlays!):

+
overlays=imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+
+
+

The changes will be applied after a reboot:

+
target:~$ reboot
+
+
+

For further information about devicetree overlays, read the device tree chapter.

+
+

For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. Connecting to a WLAN Network

+

First set the correct regulatory domain for your country:

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

You will see:

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

Set up the wireless interface:

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

Now you can scan for available networks:

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection.

+

To do so, add the network-credentials to the file /etc/wpa_supplicant.conf:

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

Now a connection can be established:

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

This should result in the following output:

+
...
+ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section Changing the Network Configuration in the L-813e.A12 Yocto Reference Manual (Hardknott).

+

First, create the directory:

+
target:~$ mkdir -p /etc/systemd/network/
+
+
+

Then add the following configuration snippet in /etc/systemd/network/10-wlan0.network:

+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+

Now, restart the network daemon so that the configuration takes effect:

+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+
+

7.3.3. Bluetooth

+

Bluetooth is supported on phyBOARD-Pollux with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section.

+

Bluetooth is connected to UART3 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup.

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. Visibility

+

To activate visibility:

+
target:~$ hciconfig hci0 piscan
+
+
+

To disable visibility:

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. Connect

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+

Bluetooth is connected to UART3 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup.

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+
+

7.3.3.3. Visibility

+

To activate visibility:

+
target:~$ hciconfig hci0 piscan
+
+
+

To disable visibility:

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.4. Connect

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

Note

+

If the connection fails with the error message: “Failed to connect: +org.bluez.Error.Failed” try restarting PulseAudio with:

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC Card

+

The i.MX 8M Plus supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n367

+

DT configuration for the eMMC interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n220

+
+
+

7.5. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 8M Plus is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw MLC memory cells combined with a memory +controller that handles ECC and wear leveling. They are connected via an SD/MMC +interface to the i.MX 8M Plus and are represented as block devices in the Linux kernel +like SD cards, flash drives, or hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.5.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +cells. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background +Operations (BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+

The userspace tool mmc does not currently support enabling automatic BKOPS +features.

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops enable /dev/mmcblk2
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.5.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 8M Plus SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n> <partition> <device>
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.5.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
    +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+
+
+

7.5.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC memory cells +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC memory cells used in NAND Flash, MLC memory cells have lower +reliability and a higher error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC memory +cells or mark these blocks as discard. The data on the device is lost and will +be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.5.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 8M Plus uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.5.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

The following table is for the offset of the i.MX 8M Plus SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.6. SPI Master

+

The i.MX 8M Plus controller has a FlexSPI and an ECSPI IP core included. The FlexSPI +host controller supports two SPI channels with up to 4 devices. Each channel +supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data +lines). The ECSPI controller supports 3 SPI interfaces with one dedicated chip +selected for each interface. As chip selects should be realized with GPIOs, more +than one device on each channel is possible.

+
+

7.6.1. SPI NOR Flash

+

phyCORE-i.MX 8M Plus is equipped with a QSPI NOR Flash which connects to the i.MX 8M Plus’s +FlexSPI interface. The QSPI NOR Flash is suitable for booting. Please see +different sections for flashing and bootmode setup. Due to limited space on the +SPI NOR Flash, only the bootloader is stored inside. By default, the kernel, +device tree, and rootfs are taken from eMMC.

+

The Bootloader does detect with the help of the EEPROM Introspection data if an +SPI flash is mounted or not. If no SPI flash is mounted a device tree overlay is +applied with the expansion command to disable the SPI flash device tree node +during boot. If no introspection data is available the SPI NOR flash node is +always enabled. Find more information in the device tree overlay section.

+

The bootloader also passes the SPI MTD partition table to Linux by fixing up the +device tree based on the mtdparts boot parameter. The default partition layout +in the BSP is set to:

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

This is a bootloader environment variable that is defined here and can be +changed during runtime. From Linux userspace, the NOR Flash partitions are +accessible via /dev/mtd<N> devices where <N> is the MTD device number associated +with the NOR flash partition to access. To find the correct MTD device number +for a partition, run on the target:

+
root@phyboard-pollux-imx8mp-3:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

It lists all MTD devices and the corresponding partition names. The flash node +is defined inside of the SPI master node in the module DTS. The SPI node +contains all devices connected to this SPI bus which is in this case only the +SPI NOR Flash.

+

The definition of the SPI master node in the device tree can be found here:

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n72

+
+
+
+

7.7. GPIOs

+

The phyBOARD-Pollux has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to i.MX 8M Plus pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal i.MX 8M Plus GPIO banks GPIO1 – GPIO5.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO5_07). <X> identifies the GPIO +bank and counts from 1 to 5, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 20 from chip0):

    +
    target:~$ gpioget gpiochip0 20
+
    +
    +
    • +

  • Set the value of GPIO 20 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset --mode=exit gpiochip0 20=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.7.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the defconfig you use in +arch/arm64/configs/ in the linux kernel sources. For our NXP based releases, +this could be for example imx8_phytec_distro.config:

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+
+
+
+

7.8. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+mmc1::@    mmc2::@    user-led1@ user-led2@ user-led3@
+
+
+

Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the phyBOARD-Pollux.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 255 > /sys/class/leds/user-led1/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/user-led1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n216

+
+
+

7.9. I²C Bus

+

The i.MX 8M Plus contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 8M Plus. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our phyBOARD-Pollux.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C1 bus configuration (e.g. imx8mp-phycore-som.dtsi): +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n105

+

General I²C2 bus configuration (e.g. imx8mp-phyboard-pollux-rdk.dts) +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n201

+
+
+

7.10. EEPROM

+

On the phyCORE-i.MX8MP there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues.

+
+

7.10.1. I2C EEPROM on phyCORE-i.MX8MP

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

The I2C EEPROM on the phyCORE-i.MX8MP SoM is connected to I2C address 0x51 on the I2C-0 +bus. It is possible to read and write directly to the device populated:

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the 4KiB EEPROM (bus: I2C-0 addr: 0x51) with zeros leaving out the EEPROM data use:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM Detection

+

The I2C EEPROM, populated on the phyCORE-i.MX8MP, has a separate ID page that is +addressable over I2C address 0x59 on bus 0 and a normal area that is addressable +over I2C address 0x51 on bus 0. PHYTEC uses this data area of 32 Bytes to store +information about the SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the EEPROM ID page data and the first 256 bytes of the normal area are +deleted, the bootloader will fall back to the phyCORE-i.MX8MP Kit RAM setup, which +is 2GiB RAM.

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

SoMs that are flashed with data format API revision 2 will print out information +about the module in the early stage.

+
+
+

7.10.3. Rescue EEPROM Data

+

The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area.

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1
+
+
+
+

Note

+

If you deleted both EEPROM spaces, please contact our support!

+
+

DT representation, e.g. in phyCORE-i.MX 8M Plus file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n201

+
+
+
+

7.11. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC Wakealarm

+

It is possible to issue an interrupt from the RTC to wake up the system. The +format uses the Unix epoch time, which is the number of seconds since UTC +midnight on 1 January 1970. To wake up the system after 4 minutes from suspend +to ram state, type:

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

Note

+

Internally the wake alarm time will be rounded up to the next minute since +the alarm function doesn’t support seconds.

+
+

DT representation for I²C RTCs: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n207

+
+
+
+

7.12. USB Host Controller

+

The USB controller of the i.MX 8M Plus SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +‘SS’). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY.

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+

DT representation for USB Host: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n341

+
+
+

7.13. CAN FD

+

The phyBOARD-Pollux has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The two CAN interfaces should show up as +can0 and can1.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    The information for can0 will look like:

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+
+

Warning

+

The mcp2518fd SPI to CANfd supports only baudrates starting from 125kB/s. +Slower rates can be selected but may not work correctly.

+
+

Device Tree CAN configuration of imx8mp-phyboard-pollux.dtsi: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n165

+
+
+

7.14. PCIe

+

The phyCORE-i.MX 8M Plus has one Mini-PCIe slot. In general, PCIe autodetects new +devices on the bus. After connecting the device and booting up the system, you +can use the command lspci to see all PCIe devices recognized.

+
    +

  • Type:

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • You will receive:

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

In this example, the PCIe device is the Intel Corporation WiFi Link 5100.

+

For PCIe devices, you have to enable the correct driver in the kernel +configuration. This WLAN card, for example, is manufactured by Intel. The +option for the driver, which must be enabled, is named CONFIG_IWLWIFI and can be +found under Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimat in +the kernel configuration.

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • The linux-imx is represented by: virtual/kernel

      • +
    +
    • +
+

For some devices like the WLAN card, additional binary firmware blobs are +needed. These firmware blobs have to be placed in /lib/firmware/ before the +device can be used.

+
    +

  • Type:

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • For example, if you try to bring up the network interface:

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • You will get the following output on the serial console:

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

Tip

+

Some PCIe devices, e.g. the Ethernet card, may function properly even if no +firmware blob is loaded from /lib/firmware/ and you received an error message +as shown in the first line of the output above. This is because some +manufacturers provide the firmware as a fallback on the card itself. In this +case, the behavior and output depend strongly on the manufacturer’s firmware.

+
+

Device Tree PCIe configuration of imx8mm-phyboard-polis.dtsi: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n277

+
+
+

7.15. Audio

+

Playback devices supported for phyBOARD-Pollux are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals.

+
+

Note

+

Using the PEB-AV-10 connector for display output along HDMI as audio output +is not supported. The audio output device must match the video output device.

+
+

To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices:

+
target:~$ aplay -L
+
+
+

Or type for recording devices:

+
target:~$ arecord -L
+
+
+
+

7.15.1. Alsamixer

+

To inspect the capabilities of your soundcard, call:

+
target:~$ alsamixer
+
+
+

You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. “MM” means the feature is muted +(both output, left & right), which can be toggled by hitting m. You can also +toggle by hitting ‘<’ for left and ‘>’ for right output. With the tab +key, you can switch between controls for playback and recording.

+
+
+

7.15.2. ALSA configuration

+

Our BSP comes with a ALSA configuration file /etc/asound.conf.

+

The ALSA configuration file can be edited as desired or deleted since it is not +required for ALSA to work properly.

+
target:~$ vi /etc/asound.conf
+
+
+

To set PEB-AV-10 as output, set playback.pcm from “dummy” to “pebav10”:

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

If the sound is not audible change playback devices to the software volume control +playback devices, set playback.pcm to the respective softvol playback device either +“softvol_hdmi” or “softvol_pebav10”. Use alsamixer controls to vary the volume levels.

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_hdmi"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.15.3. Pulseaudio Configuration

+

For applications using Pulseaudio, check for available sinks:

+
target:~$ pactl list short sinks
+0   alsa_output.platform-snd_dummy.0.stereo-fallback    module-alsa-card.c  s16le 2ch 44100Hz   SUSPENDED
+1   alsa_output.platform-sound-peb-av-10.stereo-fallback    module-alsa-card.c  s16le 2ch 44100Hz   SUSPENDED
+
+
+

To select PEB-AV-10, type:

+
target:~$ pactl set-default-sink 1
+
+
+
+
+

7.15.4. Playback

+

Run speaker-test to check playback availability:

+
target:~$ speaker-test -c 2 -t wav
+
+
+

To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds:

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

To playback other formats like mp3 for example, you can use Gstreamer:

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.15.5. Capture

+

arecord is a command-line tool for capturing audio streams which use Line In as +the default input source. To select a different audio source you can +use alsamixer. For example, switch on Right PGA Mixer Mic3R and Left PGA Mixer +Mic3R in order to capture the audio from the microphone input of the +TLV320-Codec using the 3.5mm jack.

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

Hint

+

Since playback and capture share hardware interfaces, it is not possible to +use different sampling rates and formats for simultaneous playback and +capture operations.

+
+

Device Tree Audio configuration: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.10.72_2.2.0-phy17#n57

+
+
+
+

7.16. Video

+
+

7.16.1. Videos with Gstreamer

+

The video is installed by default in the BSP:

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/phytec-qtdemo/videos/caminandes.webm
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=<video.mp4> \
+\! qtdemux  \! h264parse \! queue \! vpudec \! waylandsink async=false enable-last-sample=false \
+qos=false sync=false
+
+
+
    +

  • Or:

    • +
+
target:~$ gplay-1.0 /usr/share/phytec-qtdemo/videos/caminandes.webm
+
+
+
+
+

7.16.2. kmssink Plugin ID Evaluation

+

The kmssink plugin needs a connector ID. To get the connector ID, you can use +the tool modetest.

+
target:~$ modetest -c imx-drm
+
+
+

The output will show something like:

+
Connectors:
+id  encoder status      name        size (mm)   modes   encoders
+35  34  connected   LVDS-1          216x135     1   34
+  modes:
+    index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
+  #0 1280x800 59.07 1280 1380 1399 1440 800 804 808 823 70000 flags: phsync, pvsync; type: preferred, driver
+  props:
+    1 EDID:
+        flags: immutable blob
+        blobs:
+
+        value:
+    2 DPMS:
+        flags: enum
+        enums: On=0 Standby=1 Suspend=2 Off=3
+        value: 0
+    5 link-status:
+        flags: enum
+        enums: Good=0 Bad=1
+        value: 0
+    6 non-desktop:
+        flags: immutable range
+        values: 0 1
+        value: 0
+    4 TILE:
+        flags: immutable blob
+        blobs:
+
+        value:
+
+
+
+
+
+

7.17. Display

+

The phyBOARD-Pollux supports up to 4 different display outputs. Three can be used +simultaneously. The following table shows the required extensions and devicetree +overlays for the different interfaces.

+ + + + + + + + + + + + + + + + + + + + + + + + + +

Interface

Expansion

devicetree overlay

HDMI

phyBOARD-Pollux

no overlay needed (enabled by default)

LVDS0

PEB-AV-10

imx8mp-phyboard-pollux-peb-av-010.dtbo +(loaded by default)

LVDS1

phyBOARD-Pollux

disabled if PEB-AV-10 overlay is used

MIPI

PEB-AV-12 (MIPI to LVDS)

imx8mp-phyboard-pollux-peb-av-012.dtbo

+
+

Note

+
    +

  • HDMI will not work if LVDS1 (onboard) is enabled.

    • +

  • When changing Weston output, make sure to match the audio output as well.

    • +

  • LVDS0 (PEB-AV-10) and LVDS1 (onboard)can not be used at the same time.

    • +
+
+

HDMI is always enabled in the devicetree. The other interfaces can be enabled +with Device Tree Overlay.

+

The default-enabled Interfaces are HDMI and LVDS0 (PEB-AV-010). We support a +10’’ edt,etml1010g0dka display for the PEB-AV-10 and PEB-AV-12.

+
+

Note

+

The current display driver limits the pixel clock for a display connected to +LVDS to 74.25Mhz (or a divider of it). If this does not fit your display +requirements, please contact Support for further help.

+
+
+

7.17.1. Weston Configuration

+

In order to get an output from Weston on the correct display, it still needs to +be configured correctly. This will be done at /etc/xdg/weston/weston.ini.

+
+

7.17.1.1. Single Display

+

In our BSP, the default Weston output is set to HDMI.

+
[output]
+name=HDMI-A-1
+mode=current
+
+
+
+
+
+

7.17.2. Qt Demo

+

With the phytec-qt5demo-image, Weston starts during boot. The phytec-qt5demo can be +stopped with:

+
target:~$ systemctl stop phytec-qtdemo
+
+
+
    +

  • To start the demo again, run:

    +
    target:~$ systemctl start phytec-qtdemo
+
    +
    +
    • +

  • To disable autostart of the demo run:

    +
    target:~$ systemctl disable phytec-qtdemo
+
    +
    +
    • +

  • To enable autostart of the demo, run:

    +
    target:~$ systemctl enable phytec-qtdemo
+
    +
    +
    • +

  • Weston can be stopped with:

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

Note

+

The Qt demo must be closed before Weston can be closed.

+
+
+
+

7.17.3. Backlight Control

+

If a display is connected to the PHYTEC board, you can control its backlight +with the Linux kernel sysfs interface. All available backlight devices in the +system can be found in the folder /sys/class/backlight. Reading the appropriate +files and writing to them allows you to control the backlight.

+
+

Note

+

Some boards with multiple display connectors might have multiple backlight +controls in /sys/class/backlight. For example: backlight0 and backlight1

+
+
    +

  • To get, for example, the maximum brightness level (max_brightness) execute:

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    Valid brightness values are 0 to <max_brightness>.

    +
    • +

  • To obtain the current brightness level, type:

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • Write to the file brightness to change the brightness:

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    turns the backlight off for example.

    +

    For documentation of all files, see +https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight.

    +
    • +
+

Device tree description of LVDS-1 and HDMI can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n255 +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n180

+

The device tree of LVDS-0 on PEB-AV-10 can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.10.72_2.2.0-phy17#n132

+
+
+
+

7.18. Power Management

+
+

7.18.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 8M Plus SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as ‘Dynamic Voltage and +Frequency Scaling’ (DVFS). The i.MX 8M Plus BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the i.MX 8 +variant used, several different frequencies are supported.

+
+

Tip

+

Although the DVFS framework provides frequency settings for each CPU core, a +change in the frequency settings of one CPU core always affects all other CPU +cores too. So all CPU cores always share the same DVFS setting. An individual +DVFS setting for each core is not possible.

+
+
    +

  • To get a complete list type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately +1,6 GHz, the result will be:

    +
    1200000 1600000
+
    +
    +
    • +

  • To ask for the current frequency type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

So-called governors are automatically selecting one of these frequencies in +accordance with their goals.

+
    +

  • List all governors available with the following command:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    The result will be:

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative is much like the ondemand governor. It differs in behavior in +that it gracefully increases and decreases the CPU speed rather than jumping +to max speed the moment there is any load on the CPU.

    • +

  • ondemand (default) switches between possible CPU core frequencies in +reference to the current system load. When the system load increases above a +specific limit, it increases the CPU core frequency immediately.

    • +

  • powersave always selects the lowest possible CPU core frequency.

    • +

  • performance always selects the highest possible CPU core frequency.

    • +

  • userspace allows the user or userspace program running as root to set a +specific frequency (e.g. to 1600000). Type:

    • +

  • In order to ask for the current governor, type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    You will normally get:

    +
    ondemand
+
    +
    +
    • +

  • Switching over to another governor (e.g. userspace) is done with:

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • Now you can set the speed:

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +Documentation/admin-guide/pm/cpufreq.rst.

+
+
+

7.18.2. CPU Core Management

+

The i.MX 8M Plus SoC can have multiple processor cores on the die. The i.MX 8M Plus, for +example, has 4 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    Here the system has four processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.18.3. Suspend to RAM

+

The phyCORE-i.MX8MP supports basic suspend and resume. Different wake-up sources can be +used. Suspend/resume is possible with:

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

To wake up with serial console run

+
target:~$ echo enabled > /sys/class/tty/ttymxc0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.19. Thermal Management

+
+

7.19.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.19.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 8M Plus SoC platform. The i.MX 8 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Industrial +and Commercial.

+ + + + + + + + + + + + + + + + + +

Commercial

Industrial

passive (warning)

85°C

95°C

critical (shutdown)

90°C

100°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise, Fair Share, Bang Bang, and +Userspace. The default policy used in the BSP is step_wise. If the value of the +SoC temperature in the sysfs file temp is above trip_point_0, the CPU frequency +is set to the lowest CPU frequency. When the SoC temperature drops below +trip_point_0 again, the throttling is released.

+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+

7.19.3. GPIO Fan

+
+

Note

+

Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan +to GPIO fan due to availability. The PWM fan will not be supported +anymore and will not function with the new release.

+
+

A GPIO fan can be connected to the phyBOARD-Pollux-i.MX 8M Plus. The SoC only contains one +temperature sensor which is already used by the thermal frequency scaling. The +fan can not be controlled by the kernel. We use lmsensors with hwmon for this +instead. lmsensors reads the temperature periodically and enables or disables +the fan at a configurable threshold. For the phyBOARD-Pollux-i.MX 8M Plus, this is 60°C.

+

The settings can be configured in the configuration file:

+
/etc/fancontrol
+
+
+

Fan control is started by a systemd service during boot. This can be disabled +with:

+
target:~$ systemctl disable fancontrol
+
+
+

The device tree description of GPIO Fan can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n26

+
+
+
+

7.20. Watchdog

+

The PHYTEC i.MX 8M Plus modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.20.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.21. snvs Power Key

+

The X_ONOFF pin connected to the ON/OFF button can be pressed long to trigger +Power OFF without SW intervention or used to wake up the system out of suspend. +With the snvs_pwrkey driver, the KEY_POWER event is also reported to userspace +when the button is pressed. On default, systemd is configured to ignore such +events. The function of Power OFF without SW intervention and the wake-up from +suspend are not configured. Triggering a power off with systemd when pushing the +ON/OFF button can be configured under /etc/systemd/logind.conf and set using:

+
HandlePowerKey=poweroff
+
+
+
+
+

7.22. NPU

+

The i.MX 8M Plus SoC contains a Neural Processing Unit up to 2.3 TOPS as an accelerator +for artificial intelligence operations. Refer to our latest phyCORE-i.MX 8M Plus AI Kit +Guide on the phyCORE-i.MX 8M Plus download section to get information about the +NPU: L-1015e.A0 phyCORE-i.MX 8M Plus AI Kit Guide

+
+

7.22.1. NXP Examples for eIQ

+

NXP provides a set of machine learning examples for eIQ using Python3. To add a +pre-configured machine learning package group, add to your local.conf and build +your BSP:

+
IMAGE_INSTALL_append = " packagegroup-imx-ml python3-pip python3-requests opencv"
+
+
+

This will require about 1GB of additional space on the SD Card. Instructions +on how to install and use the NXP examples can be found at +https://community.nxp.com/t5/Blogs/PyeIQ-3-x-Release-User-Guide/ba-p/1305998.

+
+

Hint

+

The installation of the eiq examples with pip3 requires an internet +connection.

+
+
+

Note

+

On some Ubuntu 20.04 hosts, cmake uses the host’s Python 3 instead of Python +3.7 from Yocto when building python3-pybind11. (see +https://community.nxp.com/t5/i-MX-Processors/Yocto-L5-4-70-2-3-0-build-image-failed/m-p/1219619)

+

As a workaround edit, the python3-pybind11 recipe by:

+
$ devtool edit-recipe python3-pybind11
+
+
+

and add to the file:

+
EXTRA_OECMAKE += "-DPYTHON_EXECUTABLE=${RECIPE_SYSROOT_NATIVE}/usr/bin/python3-native/python3.7"
+
+
+
+
+
+
+

7.23. ISP

+

The i.MX 8M Plus SoC contains an Image Signal Processor (ISP). For more information see +Using the ISPs on the phyBOARD-Pollux i.MX 8M Plus documentation. This documentation is also +available in German.

+
+
+

7.24. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 8M Plus provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 8M Plus Reference Manual). The following list is +an abstract from the i.MX 8M Plus Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x30350000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x30350000

Description

OCOTP_MAC_ADDR0

9

0

0x640

contains lower 32 bits +of ENET0 MAC address

OCOTP_MAC_ADDR1

9

1

0x650

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

OCOTP_MAC_ADDR2

9

2

0x660

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 8M Plus Security Reference Manual.

+
+

7.24.1. Reading Fuse Values in uBoot

+

You can read the content of a fuse using memory-mapped shadow registers. To +calculate the memory address, use the fuse Bank and Word in the following +formula:

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.24.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+

Reading the registers using /dev/mem will cause the system to hang unless the +ocotp_root_clk is enabled. To enable this clock permanent, add to the device +tree:

+
&clk {
+        init-on-array = <IMX8MP_CLK_OCOTP_ROOT>;
+};
+
+
+
+
+
+
+

8. i.MX 8M Plus M7 Core

+

In addition to the Cortex-A53 cores, there is a Cortex-M7 Core as MCU +integrated into the i.MX 8M Plus SoC. Our Yocto-Linux-BSP runs on the A53-Cores and +the M7 Core can be used as a secondary core for additional tasks using +bare-metal or RTOS firmware. +Both cores have access to the same peripherals and thus peripheral +usage needs to be limited either in the M7 Core’s firmware or the devicetree +for the Linux operating system. This section describes how to build firmware +examples and how to run them on phyBOARD-Pollux.

+

The phyBOARD-Pollux is currently supported by the NXP MCUXpresso SDK and by +The Zephyr Project. This section only describes the NXP MCUXpresso SDK because +the MCUXpresso SDK has more supported features at the moment.

+

If you want to use the M7 Core with The Zephyr Project, please refer to the +The Zephyr Project documentation:

+ +
+

8.1. Getting the Firmware Examples

+

The firmware can be built using the NXP MCUxpresso SDK with a compatible +compiler toolchain using command-line tools.

+
+

8.1.1. Getting the Sources

+

The MCUX SDK and the examples for the i.MX 8M Plus can be obtained from PHYTEC’s GitHub +page:

+ +
    +

  1. Initialize the MCUX SDK via west:

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    This will create a mcuxsdk directory with the mcux-sdk repository in it. +The mcux-sdk-phytec-examples repository will be automatically cloned into +the mcuxsdk directory. +The given argument <VERSION> is a the branch name of the mcux-sdk repository +that represents the MCUX SDK version. For the newest tested version +you can use 2.13.0.

    +
    +

    Note

    +

    west is a repository management tool and a part of the Zephyr +Project. +To install west, you can use pip. In this example west is installed in +a python virtual environment:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. Update the dependencies:

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    The directory examples-phytec contains all examples ported and tested +for phyBOARD-Pollux with version 2.13.0 of MCUX.

    +

    To build the firmware, a compiler toolchain and make/cmake are required. +The GNU Arm Embedded Toolchain may be available in your distribution’s +repositories, e.g. for Ubuntu.

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    The compiler toolchain can also be obtained directly from +https://developer.arm.com/. After the archive has been extracted, +the ARMGCC_DIR has to be added to the environment, e.g. for the +ARM toolchain 10-2020-q4-major release located in the home directory:

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. Building the Firmware

+

To build the PHYTEC samples an environment has to be sourced

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

The scripts to build the firmware are located in +<sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc. +There are scripts for each memory location the firmware is supposed to run in, +e.g.

+
host:~$ ./build_release.sh
+
+
+

to build the firmware for the M7 Core’s TCM. The output will be placed under +release/ in the armgcc directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+

To build the firmware for the DRAM, run the script build_ddr_release. +The script of the firmware that is supposed to run, e.g.

+
host:~$ ./build_ddr_release.sh
+
+
+

The output will be placed under ddr_release/ in the armgcc +directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+
+
+
+

8.2. Running M7 Core Examples

+

There are two ways to run the M7 Core with the built firmware, U-Boot and +Remoteproc within a running Linux.

+

To receive debug messages start your favorite terminal software (e.g. Minicom, +Tio, or Tera Term) on your host PC and configure it for 115200 baud, 8 data +bits, no parity, and 1 stop bit (8n1) with no handshake.

+

Once a micro-USB cable is connected to the USB-debug port on the phyBOARD-Pollux, two +ttyUSB devices are registered. One prints messages from A53-Core’s debug UART +and the other one from the M7 Core’s debug UART.

+
+

8.2.1. Running Examples from U-Boot

+

To load firmware using the bootloader U-Boot, the bootaux command can be used:

+
    +

  1. Prepare an SD Card with our Yocto-BSP

    2. +

  2. Copy the generated .bin file to the SD Cards first partition

    3. +

  3. Stop the autoboot by pressing any key

    4. +

  4. Type the command depending on the type of firmware:

    5. +
+

For firmware built to run in the M7 Core’s TCM:

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

For firmware built to run in the DRAM:

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

The program’s output should appear on the M7 Core’s debug UART.

+
+
+

8.2.2. Running Examples from Linux using Remoteproc

+

Remoteproc is a module that allows you to control the M7 Core from Linux +during runtime. Firmware built for TCM can be loaded and the execution started +or stopped. To use Remoteproc a devicetree overlay needs to be set:

+

Edit the bootenv.txt file located in the /boot directory on the target by +adding imx8mp-phycore-rpmsg.dtbo:

+
overlays=imx8mp-phycore-rpmsg.dtbo
+
+
+

Restart the target and execute in U-Boot:

+
u-boot=> run prepare_mcore
+
+
+

Firmware .elf files for the M7 Core can be found under /lib/firmware. +To load the firmware, type:

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

To load a different firmware, the M7 Core needs to be stopped:

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

Note

+

The samples found in /lib/firmware on the target come from NXP’s +Yocto layer meta-imx. +To use the samples you built yourself through MCUX SDK, please copy them +to /lib/firmware on the target after building them.

+
+
+ +
+
+
+

9. BSP Extensions

+
+

9.1. Chromium

+

Our BSP for the phyBOARD-Pollux-i.MX 8M Plus supports Chromium. You can include it in the +phytec-qt5demo-image with only a few steps.

+
+

9.1.1. Adding Chromium to Your local.conf

+

To include Chromium you have to add the following line into your local.conf. You +can find it in <yocto_dir>/build/conf/local.conf. This adds Chromium to your +next image build.

+
IMAGE_INSTALL_append = " chromium-ozone-wayland"
+
+
+
+

Note

+

Compiling Chromium takes a long time.

+
+
+
+

9.1.2. Get Chromium Running on the Target

+

To run Chromium, it needs a few arguments to use the hardware graphics +acceleration:

+
target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox
+
+
+

If you want to start Chromium via SSH, you must first define the display on +which Chromium will run. For example:

+
target$ DISPLAY=:0
+
+
+

After you have defined this, you can start it via virtual terminal on Weston as +shown above.

+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mp/pd22.1.2.html b/previews/271/bsp/imx8/imx8mp/pd22.1.2.html new file mode 100644 index 000000000..008865402 --- /dev/null +++ b/previews/271/bsp/imx8/imx8mp/pd22.1.2.html @@ -0,0 +1,4560 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + +

i.MX 8M Plus BSP Manual

Document Title

i.MX 8M Plus BSP Manual

Document Type

BSP Manual

Yocto Manual

Release Date

2024/08/05

Is Branch of

i.MX 8M Plus BSP Manual

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-NXP-i.MX8MP-PD22.1.2

Minor

2024/08/05

Released

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +phyCORE-i.MX8M Plus Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads of our product.

+
+

1.1. Supported Hardware

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-NXP-i.MX8MP-PD22.1.2 download.

+

If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware

+
+

Note

+

When the PCM-070 does not have the X1 extension connector populated, some +Software features described here do not work. These are Wirless LAN, PCIe, +CSI (cameras), PEB-AV-12, CAN, USB-OTG.

+
+
+

1.1.1. phyBOARD-Pollux Components

+
+../../../_images/phyBOARD-Pollux-front-components.jpg + +
+

phyBOARD-Pollux Components (top)

+
+
+
+../../../_images/phyBOARD-Pollux-back-components.jpg + +
+

phyBOARD-Pollux Components (bottom)

+
+
+
+
+
+
+

2. Getting Started

+

The phyCORE-i.MX8M Plus Kit is shipped with a pre-flashed SD card. It contains the +phytec-qt5demo-image and can be used directly as a boot source. The eMMC is +programmed with only a U-boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+
+

2.1. Get the Image

+

The WIC image contains all BSP files in several, correctly pre-formatted +partitions and can be copied to an SD card easily using the single Linux +command dd. It can be built by Yocto or downloaded from the PHYTEC download +server.

+

Get the WIC file from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.2/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card with the dd command, you must have root +privileges. Be very careful when specifying the destination device with +dd! All files on the selected destination device will be erased +immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system!

+
+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. Unmount any mounted partitions before +you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+
    +

  • Unmount all partitions, e.g.:

    +
    host$ sudo umount /dev/sde1
+
    +
    +
    • +

  • After having unmounted all partitions, you can create your bootable SD card:

    +
    host$ sudo dd if=<IMAGENAME>-<MACHINE>.wic of=/dev/sdX bs=1M conv=fsync status=progress
+
    +
    +

    Again, make sure to replace /dev/sdX with your actual device name found +previously.

    +

    The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

    +
    • +
+

An alternative and much faster way to prepare an SD card can be done by using +bmap-tools from Intel. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host$ bmaptool copy <IMAGENAME>-<MACHINE>.wic /dev/<your_device>
+
+
+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.3. First Start-up

+ +../../../_images/SD_Card_Boot2.png +
    +

  • Insert the SD card

    • +

  • Connect the target and the host with mirco USB on (X1) +debug USB

    • +

  • Power up the board

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: L-813e.A12 Yocto Reference Manual (Hardknott).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +L-813e.A12 Yocto Reference Manual (Hardknott).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-IMX8MP; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-xwayland MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD22.1.2
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-qt5demo-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the phyboard-pollux-imx8mp-3 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx8mp.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, +lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY firmware images

    • +

  • imx-boot: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM +Trusted Firmware and DDR firmware. This is the final bootloader image which is +bootable.

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx8mp-phyboard-pollux-rdk*.dtb: Kernel device tree file

    • +

  • imx8mp-phy*.dtbo: Kernel device tree overlay files

    • +

  • phytec-qt5demo-image*.tar.gz: Root file system

    • +

  • phytec-qt5demo-image*.wic: SD card image

    • +
+
+
+
+
+

4. Installing the OS

+
+

4.1. Bootmode Switch (S3)

+
+

Tip

+

Hardware revision baseboard: 1552.2

+
+

The phyBOARD-Pollux features a boot switch with four individually switchable ports to +select the phyCORE-i.MX 8M Plus default bootsource.

+ + + + + + + + + + + +
+../../../_images/eMMC2.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses2.png +
+

Internal Fuses

+
+
+
+../../../_images/SPI_NOR2.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download3.png +
+

USB Serial Download

+
+
+
+../../../_images/SD_Card_Boot2.png +
+

SD Card

+
+
+
+../../../_images/Test_Mode.png +
+

Test Mode

+
+
+
+
+
+

4.2. Flash eMMC

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S3) is set to Default SOM boot.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk2p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from Network

+

i.MX 8M Plus boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

4.2.1.1. Flash eMMC from Network in u-boot on Target

+

These steps will show how to update the eMMC via a network. However, they only +work if the size of the image file is less than 1GB. If the image file is +larger, go to the section Format SD Card. Configure the bootmode switch (S3) to boot +from SD Card and put in an SD card. Power on the board and stop in U-Boot +prompt.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+
    +

  • Load your image via network to RAM:

    +
    u-boot=> tftp ${loadaddr} phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • Write the image to the eMMC:

    +
    u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +
+
+
+

4.2.1.2. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host.

+
+

Take a compressed or uncompressed image on the host and send it with ssh through +the network (then uncompress it, if necessary) to the eMMC of the target with a +one-line command:

+
target:~$ ssh <USER>@192.168.3.10 "dd if=<path_to_file>/phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic" | dd of=/dev/mmcblk2
+
+
+
+
+

4.2.1.3. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host.

+
+

Show your available image files on the host:

+
host:~$ ls
+phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
+
+

Send the image with the command dd command combined with ssh through the network +to the eMMC of your device:

+
host:~$ dd if=phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2"
+
+
+
+
+
+

4.2.2. Flash eMMC u-boot image via Network from running u-boot

+

Update the standalone u-boot image imx-boot is also possible from u-boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host.

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.3. Flash eMMC from USB

+
+

4.2.3.1. Flash eMMC from USB in u-boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in Bootloader after enabling the OPTEE.

+
+

These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch to bootmode switch (S3) and put in an SD card. Power on the board +and stop in u-boot prompt. Insert a USB device with the copied WIC image +to the USB slot.

+

Load your image from the USB device to RAM:

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} *.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic). Set the bootmode switch to +bootmode switch (S3).

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ cd /mnt
+target:~$ ls
+phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
    +
    +
    • +

  • Show list of available MMC devices:

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • The eMMC device can be recognized by the fact that it contains two boot +partitions: (mmcblk2boot0; mmcblk2boot1)

    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without partition):

    +
    target:~$ dd if=phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic of=/dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    • +
+
+

Warning

+

Before this will work, you need to configure the multi-port switch +to Default SOM Boot to bootmode switch (S3).

+
+
+
+
+

4.2.4. Flash eMMC from SD Card

+

Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (*.wic) located on the SD card. +Because the image file is quite large, you have to enlarge your SD card to use +its full space (if it was not enlarged before). To enlarge your SD card, see +Resizing ext4 Root Filesystem.

+
+

4.2.4.1. Flash eMMC from SD card in u-boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in Bootloader after enabling the OPTEE. If the +image file is too large use the Updating eMMC from SD card in +Linux on Target subsection.

+
+
    +

  • Flash an SD card with a working image and create a third FAT partition. Copy +the WIC image (for example phytec-qt5demo-image.wic) to this +partition.

    • +

  • Configure the bootmode switch to boot from the SD Card and insert the SD +card.

    • +

  • Power on the board and stop in u-boot.

    • +

  • Flash your WIC image (for example phytec-qt5demo-image.wic) +from the SD card to eMMC. This will partition the card and copy imx-boot, +Image, dtb, dtbo, and root file system to eMMC.

    • +

  • Load the image:

    +
    u-boot=> fatload mmc 1:3 ${loadaddr} phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • Switch the mmc dev:

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc0(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • Power off the board and change the multi-port switch to Default SOM Boot to +boot from eMMC.

    • +
+
+
+

4.2.4.2. Flash eMMC from SD card in Linux on Target

+

You can also flash the eMMC on Linux. You only need a complete image saved on +the SD card (e.g. phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic).

+
    +

  • Show your saved image files on the SD card:

    +
    target:~$ ls
+phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
    +
    +
    • +

  • Show list of available MMC devices:

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • The eMMC device can be recognized by the fact that it contains two boot +partitions: (mmcblk2boot0; mmcblk2boot1)

    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without +partition):

    +
    target:~$ dd if=phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic of=/dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    • +
+
+

Warning

+

Before this will work, you need to configure the bootmode switch (S3) to Default +SOM Boot to boot from eMMC.

+
+
+
+
+
+

4.3. Flash SPI NOR Flash

+

The phyCORE-i.MX8MP modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set bootmode switch (S3) to QSPI boot to boot from QSPI. The SPI Flash is +usually quite small. The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash +populated. Only the bootloader and the environment can be stored. The kernel, +device tree, and file system are taken from eMMC by default.

+

The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with:

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. Flash SPI NOR Flash from Network

+

The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-i.MX 8M Plus.

+
+

Tip

+

A working network is necessary! Setup Network Host.

+
+
+

4.3.1.1. Flash SPI NOR from Network in u-boot on Target

+

Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI-NOR flash needs to be probed:

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • A specially formatted u-boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image over tftp, erase and write the +bootloader to the flash:

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+

Warning

+

Erasing the complete SPI NOR flash when it is fully written will take quite +some time. This can trigger the watchdog to reset. Due to this, erase the +full flash in Linux.

+
+
+
+

4.3.1.2. Flash SPI NOR from Network in kernel on Target

+
    +

  • Copy the image from the host to the target:

    +
    host:~$ scp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • Find the number of erase blocks of the U-boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the u-boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+

4.3.2. Flash SPI NOR Flash from SD Card

+

The bootloader on SPI NOR flash can be also flashed with SD Card.

+
+

4.3.2.1. Flash SPI NOR from SD Card in u-boot on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi to the FAT partition +on the SD Card. Before reading and writing are possible, the SPI-NOR flash +needs to be probed:

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • A specially formatted U-boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image from the SD Card, erase and write +the bootloader to the flash:

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+

Warning

+

Erasing the complete SPI NOR flash when it is fully written will take quite +some time. This can trigger the watchdog to reset. Due to this, erase the +full flash in Linux.

+
+
+
+

4.3.2.2. Flash SPI NOR from SD Card in kernel on Target

+
    +

  • Mount the SD Card:

    +
    host:~$ mount /dev/mmcblkp1 /mnt
+
    +
    +
    • +

  • Find the number of erase blocks of the u-boot partition:

    +
    target:~$  mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the u-boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A3 RAUC Update & Device Management Manual.

+
+
+
+

5. Development

+
+

5.1. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.1.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.2. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.2.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel image to your tftp directory:

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • Copy the devicetree to your tftp directory:

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • Copy all the overlays you want to use into your tftp directory:

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-qt5demo-image-phyboard-pollux-imx8mp-3.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.2.2. Set the bootenv.txt for Netboot

+

Create a bootenv.txt file in your tftp directory and write the following variables into it.

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> has to be replaced with the devicetree overlay filenames that you want to use. +Separate the filenames by spaces. For example:

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

Tip

+

All supported devicetree overlays are in the device tree chapter.

+
+
+
+

5.2.3. Network Settings on Target

+

To customize the targets ethernet configuration, please follow the description +here: Network Environment Customization

+
+
+

5.2.4. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.3.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/phyboard-pollux-imx8mp-3/. For flashing a wic image to eMMC, +you will also need phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic.

+
+
+

5.3.3. Prepare Target

+

Set the bootmode switch (S3) to USB Serial Download. Also, connect USB port +X5 (upper connector) to your host.

+
+
+

5.3.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via (X1), as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.3.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
+
+
+
+
+

5.4. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone git://git.phytec.de/u-boot-imx)

+
+
+

5.4.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-imx and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • Our i.MX 8M Plus kernel is based on the linux-imx kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. Get the SDK

+

You can download the SDK here, or build it yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt5demo-image # or another image
+
    +
    +
    • +
+

After a successful build the SDK installer is deployed to build/deploy*/sdk.

+
+
+

5.4.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt5demo-image-cortexa53-crypto-toolchain-BSP-Yocto-NXP-i.MX8MP-PD22.1.2.sh
+host:~$ ./phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt5demo-image-cortexa53-crypto-toolchain-BSP-Yocto-NXP-i.MX8MP-PD22.1.2.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.2):
+You are about to install the SDK to "/opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.2". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.2/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. U-Boot standalone build

+
+

5.5.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag needed at this release is called v2021.04_2.2.0-phy17

    • +

  • Check out the needed U-Boot tag:

    • +
+
host:~$ cd ~/u-boot-imx/
+host:~$ git fetch --all --tags
+host:~$ git checkout tags/v2021.04_2.2.0-phy17
+
+
+
    +

  • Technically, you can now build the U-Boot, but practically there are some +further steps necessary:

    +
      +

    • Create your own development branch:

      +
      host:~$ git switch --create <new-branch>
+
      +
      +
      +

      Note

      +

      You can name your development branch as you like, this is just an example.

      +
      +
      • +
    +
    • +

  • Set up a build environment:

    +
    host:~$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.2/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +

  • Set this environment variable before building the Image:

    +
    host:~$ export ATF_LOAD_ADDR=0x970000
+
    +
    +
    • +
+
+
+

5.5.2. Get the needed binaries

+

To build the bootloader, you need to copy these files to your u-boot-imx +build directory and rename them to fit with mkimage script:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx8mp.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +
+

If you already built our BSP with Yocto, you can get the +bl31-imx8mp.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: BSP Images

+

Or you can download the files here: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.2/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/

+
+

Warning

+

Make sure you rename the files you need so that they are compatible with the +mkimage tool.

+
+
+
+

5.5.3. Build the bootloader

+
    +

  • build flash.bin (imx-boot):

    +
    host:~$ make phycore-imx8mp_defconfig
+host:~$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. Flash the bootloader to a block device

+

The flash.bin can be found at u-boot-imx/ directory and now can be flashed. A +chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

E.g. flash SD card:

+
host:~$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables “BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+

5.5.5. Build U-Boot With a Fixed RAM Size

+

If you cannot boot your system anymore because the hardware introspection in the +EEPROM is damaged or deleted, you can create a flash.bin with a fixed ram size. +You should still contact support and flash the correct EEPROM data, as this +could lead to unexpected behavior.

+

Follow the steps to get the U-boot sources and check the correct branch in the +Build U-Boot section.

+

Edit the file configs/phycore-imx8mp_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB_2GHZ=y
+
+
+

Choose the correct RAM size as populated on the board and uncomment the line for +this ram size. For Article number 0F8443I, use […]_4GB_2GHZ, for +0F5443I, use […]_4GB. +After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+
+

5.6. Kernel standalone build

+
+

5.6.1. Setup sources

+
    +

  • The used linux-imx branch can be found in the release notes

    • +

  • The tag needed for this release is called v5.10.72_2.2.0-phy18

    • +

  • Check out the needed linux-imx tag:

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v5.10.72_2.2.0-phy18
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.2/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-imx$ make imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-imx/arch/arm64/boot/Image

    • +

  • The dtb can be found at +~/linux-imx/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. Copy Kernel to SD Card

+

When one-time boot via netboot is not sufficient, the kernel along with its +modules and the corresponding device tree blob may be copied directly to a +mounted SD card.

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. Accessing the Development states

+
+

5.7.1. Development state of current release

+

These release manifests exist to give you access to the development states +of the Yocto BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line:

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD22.1.y
+
+
+

This will initialize a BSP that will track the latest development state of the +current release (BSP-Yocto-NXP-i.MX8MP-PD22.1.2). From now on repo sync in this folder +will pull all the latest changes from our Git repositories:

+
host:~$ repo sync
+
+
+
+
+

5.7.2. Development state of upcoming release

+

Also development states of upcoming releases can be accessed this way. +For this execute the following command and look for a release with a higher +PDXX.Y number than the latest one (BSP-Yocto-NXP-i.MX8MP-PD22.1.2) and .y at the +end:

+
host:~$ ./phyLinux init -p imx8mp
+
+
+
+
+
+

5.8. Accessing the Latest Upstream Support

+

We have a vanilla manifest that makes use of the Yocto master branches (not an +NXP release), Linux, and U-Boot. This can be used to test the latest upstream +kernel/U-Boot.

+
+

Note

+

The master manifest reflects the latest state of development. This tends to +be broken from time to time. We try to fix the master on a regular basis.

+
+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.9.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 8M Plus SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Carrierboard.dtsi - Devices that come from the i.MX 8M Plus SoC but are just routed +down to the carrier board and used there are included in this dtsi.

    • +

  • Board.dts - include the carrier board and module dtsi files. There may also +be some hardware configuration nodes enabled on the carrier board or the +module (i.e. the Board .dts shows the special characteristics of the board +configuration). For example, there are phyCORE-i.MX 8M Plus SOMs which may or may not +have a MIPI DSI to LVDS converter mounted. The converter is enabled (if +available) in the Board .dts and not in the Module .dtsi

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 8 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder arch/arm64/boot/dts/freescale/overlays.

+

Available overlays for phyboard-pollux-imx8mp-3.conf are:

+
imx8mp-isi-csi1.dtbo
+imx8mp-isi-csi2.dtbo
+imx8mp-isp-csi1.dtbo
+imx8mp-isp-csi2.dtbo
+imx8mp-phyboard-pollux-peb-av-010.dtbo
+imx8mp-phyboard-pollux-peb-av-012.dtbo
+imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+imx8mp-phycore-no-eth.dtbo
+imx8mp-phycore-no-rtc.dtbo
+imx8mp-phycore-no-spiflash.dtbo
+imx8mp-phycore-rpmsg.dtbo
+imx8mp-vm016-csi1.dtbo
+imx8mp-vm016-csi1-fpdlink.dtbo
+imx8mp-vm016-csi2.dtbo
+imx8mp-vm016-csi2-fpdlink.dtbo
+imx8mp-vm017-csi1.dtbo
+imx8mp-vm017-csi1-fpdlink.dtbo
+imx8mp-vm017-csi2.dtbo
+imx8mp-vm017-csi2-fpdlink.dtbo
+
+
+
+

Hint

+

There is one more overlay available for phyboard-pollux-imx8mp-2.conf: +imx8mp-phyboard-pollux-1552.1.dtbo

+
+

The usage of overlays can be configured during runtime in Linux or U-Boot. +Overlays are applied during the boot process in the bootloader after the +boot command is called and before the kernel is loaded. The next sections +explain the configuration in more detail.

+
+

6.2.2.1. Set ${overlays} variable

+

The ${overlays} U-Boot environment variable contains a space-separated list +of overlays that will be applied during boot. Depending on the boot source the +overlays have to either be placed in the boot partition of eMMC/SD-Card or are +loaded over tftp. Overlays set in the $KERNEL_DEVICETREE Yocto machine variable +will be automatically added to the boot partition of the final WIC image.

+

The ${overlays} variable can be either set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=imx8mp-phyboard-pollux-rdk-peb-eval-01.dtbo imx8mp-phyboard-pollux-peb-av-010.dtbo
+
+
+

Changes will take effect after the next reboot. If no bootenv.txt file is +available the overlays variable can be set directly in the U-Boot environment.

+
u-boot=> setenv overlays imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> printenv overlays
+overlays=imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> boot
+
+
+

If a user defined ${overlays} variable should be directly loaded from U-Boot +environment but there is still an external bootenv.txt available, the ${no_bootenv} +variable needs to be set as a flag:

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> boot
+
+
+

More information about the external environment can be found in +U-boot External Environment subsection of the +device tree overlay section.

+

We use the ${overlays} variable for overlays describing expansion boards and +cameras that can not be detected during run time. To prevent applying overlays +listed in the ${overlays} variable during boot, the ${no_overlays} variable can +be set to 1 in the bootloader environment.

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+

6.2.2.2. Extension Command

+

The U-Boot extension command makes it possible to easily apply overlays that +have been detected and added to a list by the board code callback +extension_board_scan(). +Overlays applied this way disable components that are not populated on the SoM. +The detection is done with the EEPROM data (EEPROM SoM Detection) found on the +SoM i2c EEPROM.

+

It depends on the SoM variant if any device tree overlays will be applied. To check +if an overlay will be applied on the running SoM in U-Boot, run:

+
u-boot=> extension scan
+Found 1 extension board(s).
+u-boot=> extension list
+Extension 0: phyCORE-i.MX8MP no SPI flash
+        Manufacturer:           PHYTEC
+        Version:
+        Devicetree overlay:     imx8mp-phycore-no-spiflash.dtbo
+        Other information:      SPI flash not populated on SoM
+
+
+

If the EEPROM data is not available, no device tree overlays are applied.

+

To prevent running the extension command during boot the ${no_extensions} +variable can be set to 1 in the bootloader environment:

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot External Environment

+

During the start of the Linux Kernel the external environment bootenv.txt +text file will be loaded from the boot partition of an MMC device or via TFTP. +The main intention of this file is to store the ${overlays} variable. This makes +it easy to pre-define the overlays in Yocto depending on the used machine. The +content from the file is defined in the Yocto recipe bootenv found in +meta-phytec: +https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=hardknott

+

Other variables can be set in this file, too. They will overwrite the existing +settings in the environment. But only variables evaluated after issuing the boot +command can be overwritten, such as ${nfsroot} or ${mmcargs}. Changing other +variables in that file will not have an effect. See the usage during netboot as +an example.

+

If the external environment can not be loaded the boot process will be anyway +continued with the values of the existing environment settings.

+
+
+

6.2.4. Change U-boot Environment from Linux on Target

+

Libubootenv is a tool included in our images to modify the U-Boot environment of +Linux on the target machine.

+

Print the U-Boot environment using the following command:

+
target:~$ fw_printenv
+
+
+

Modify a U-Boot environment variable using the following command:

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

Caution

+

Libubootenv takes the environment selected in a configuration file. The +environment to use is inserted there, and by default it is configured to use +the eMMC environment (known as the default used environment).

+

If the eMMC is not flashed or the eMMC environment is deleted, libubootenv +will not work. You should modify the /etc/fw_env.config file to match the +environment source that you want to use.

+
+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 8M Plus BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 8M Plus BSP Device Tree Concept to get an understanding +of our i.MX 8 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 8 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 8M Plus Pin Muxing

+

The i.MX 8M Plus SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 8M Plus terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 8M Plus Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx8mp-phyboard-pollux.dtsi:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x49
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x49
+        >;
+};
+
+
+

The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled.

+
+
+

7.2. RS232/RS485

+

The phyCORE-i.MX 8M Plus supports up to 4 UART units. On the phyBOARD-Pollux, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector X2 at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers JP3 and +JP4 on the baseboard. For more information about the correct setup please +refer to the phyCORE-i.MX 8M Plus/phyBOARD-Pollux Hardware Manual section UARTs.

+

We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers JP3 and JP4 need to be set +correctly.

+
+

7.2.1. RS232

+
    +

  • Display the current settings of a terminal in a human-readable format:

    +
    target:~$ stty -a
+
    +
    +
    • +

  • Configuration of the UART interface can be done with stty. For example:

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • With a simple echo and cat, basic communication can be tested. Example:

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

The host should print out “123”.

+
+
+

7.2.2. RS485

+
+

Hint

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

For easy testing, look at the linux-serial-test. This tool is called the IOCTL +for RS485 and sends a constant stream of data.

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

More information about the linux-serial-test tool and its parameters can be +found here: linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Documentation for calling the IOCTL within c-code is described in the Linux +kernel documentation: +https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+

The device tree representation for RS232 and RS485: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n331

+
+
+
+

7.3. Network

+

phyBOARD-Pollux-i.MX 8M Plus provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board.

+
+

Warning

+

The naming convention of the Ethernet interfaces in the hardware (ethernet0 +and ethernet1) do not align with the network interfaces (eth0 and eth1) in +Linux. So, be aware of these differences:

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n41.

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Pollux can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n141.

+
+

7.3.1. Network Environment Customization

+
+

7.3.1.1. U-boot network-environment

+
    +

  • To find the Ethernet settings in the target bootloader:

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • With your development host set to IP 192.168.3.10 and netmask 255.255.255.0, +the target should return:

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • If you need to make any changes:

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> should be one of ipaddr, netmask, gatewayip or serverip. +<value> will be the actual value of the chosen parameter.

    +
    • +

  • The changes you made are temporary for now. To save these:

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

Here you can also change the IP address to DHCP instead of using a static one.

+
    +

  • Configure:

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • Set up paths for TFTP and NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+

Tip

+

Variables like nfsroot and netargs can be overwritten by the U-boot External +Environment. For netboot, the external environment will be loaded from tftp. +For example, to locally set the nfsroot variable in a bootenv.txt file, +locate the tftproot directory:

+
nfsroot=/home/user/nfssrc
+
+
+

There is no need to store the info on the target. Please note that this does +not work for variables like ipaddr or serveraddr as they need to be already +set when the external environment is being loaded.

+
+
+
+

7.3.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. WLAN

+

WLAN and Bluetooth on the phyBOARD-Pollux are provided by the PEB-WLBT-05 expansion card. +The PEB-WLBT-05 for phyBOARD-Pollux Quickstart Guide shows you how to install the +PEB-WLBT-05.

+
+

Tip

+

With the BSP Version PD22.1 and newer, the PEB-WLBT-05 overlay needs to be activated first, +otherwise the PEB-WLBT-05 won’t be recognized.

+
target:~$ vi /boot/bootenv.txt
+
+
+

Afterwards the bootenv.txt file should look like this (it can also contain other devicetree +overlays!):

+
overlays=imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+
+
+

The changes will be applied after a reboot:

+
target:~$ reboot
+
+
+

For further information about devicetree overlays, read the device tree chapter.

+
+

For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. Connecting to a WLAN Network

+

First set the correct regulatory domain for your country:

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

You will see:

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

Set up the wireless interface:

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

Now you can scan for available networks:

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection.

+

To do so, add the network-credentials to the file /etc/wpa_supplicant.conf:

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

Now a connection can be established:

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

This should result in the following output:

+
...
+ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section Changing the Network Configuration in the L-813e.A12 Yocto Reference Manual (Hardknott).

+

First, create the directory:

+
target:~$ mkdir -p /etc/systemd/network/
+
+
+

Then add the following configuration snippet in /etc/systemd/network/10-wlan0.network:

+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+

Now, restart the network daemon so that the configuration takes effect:

+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+
+

7.3.3. Bluetooth

+

Bluetooth is supported on phyBOARD-Pollux with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section.

+

Bluetooth is connected to UART3 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup.

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. Visibility

+

To activate visibility:

+
target:~$ hciconfig hci0 piscan
+
+
+

To disable visibility:

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. Connect

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

Note

+

If the connection fails with the error message: “Failed to connect: +org.bluez.Error.Failed” try restarting PulseAudio with:

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC Card

+

The i.MX 8M Plus supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n367

+

DT configuration for the eMMC interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n220

+
+
+

7.5. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 8M Plus is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw MLC memory cells combined with a memory +controller that handles ECC and wear leveling. They are connected via an SD/MMC +interface to the i.MX 8M Plus and are represented as block devices in the Linux kernel +like SD cards, flash drives, or hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.5.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +cells. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background +Operations (BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+

The userspace tool mmc does not currently support enabling automatic BKOPS +features.

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops enable /dev/mmcblk2
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.5.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 8M Plus SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n> <partition> <device>
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.5.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
    +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+
+
+

7.5.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC memory cells +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC memory cells used in NAND Flash, MLC memory cells have lower +reliability and a higher error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC memory +cells or mark these blocks as discard. The data on the device is lost and will +be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.5.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 8M Plus uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.5.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

The following table is for the offset of the i.MX 8M Plus SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.6. SPI Master

+

The i.MX 8M Plus controller has a FlexSPI and an ECSPI IP core included. The FlexSPI +host controller supports two SPI channels with up to 4 devices. Each channel +supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data +lines). The ECSPI controller supports 3 SPI interfaces with one dedicated chip +selected for each interface. As chip selects should be realized with GPIOs, more +than one device on each channel is possible.

+
+

7.6.1. SPI NOR Flash

+

phyCORE-i.MX 8M Plus is equipped with a QSPI NOR Flash which connects to the i.MX 8M Plus’s +FlexSPI interface. The QSPI NOR Flash is suitable for booting. Please see +different sections for flashing and bootmode setup. Due to limited space on the +SPI NOR Flash, only the bootloader is stored inside. By default, the kernel, +device tree, and rootfs are taken from eMMC.

+

The Bootloader does detect with the help of the EEPROM Introspection data if an +SPI flash is mounted or not. If no SPI flash is mounted a device tree overlay is +applied with the expansion command to disable the SPI flash device tree node +during boot. If no introspection data is available the SPI NOR flash node is +always enabled. Find more information in the device tree overlay section.

+

The bootloader also passes the SPI MTD partition table to Linux by fixing up the +device tree based on the mtdparts boot parameter. The default partition layout +in the BSP is set to:

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

This is a bootloader environment variable that is defined here and can be +changed during runtime. From Linux userspace, the NOR Flash partitions are +accessible via /dev/mtd<N> devices where <N> is the MTD device number associated +with the NOR flash partition to access. To find the correct MTD device number +for a partition, run on the target:

+
root@phyboard-pollux-imx8mp-3:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

It lists all MTD devices and the corresponding partition names. The flash node +is defined inside of the SPI master node in the module DTS. The SPI node +contains all devices connected to this SPI bus which is in this case only the +SPI NOR Flash.

+

The definition of the SPI master node in the device tree can be found here:

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n72

+
+
+
+

7.7. GPIOs

+

The phyBOARD-Pollux has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to i.MX 8M Plus pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal i.MX 8M Plus GPIO banks GPIO1 – GPIO5.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO5_07). <X> identifies the GPIO +bank and counts from 1 to 5, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 20 from chip0):

    +
    target:~$ gpioget gpiochip0 20
+
    +
    +
    • +

  • Set the value of GPIO 20 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset --mode=exit gpiochip0 20=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.7.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the defconfig you use in +arch/arm64/configs/ in the linux kernel sources. For our NXP based releases, +this could be for example imx8_phytec_distro.config:

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+
+
+
+

7.8. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+mmc1::@    mmc2::@    user-led1@ user-led2@ user-led3@
+
+
+

Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the phyBOARD-Pollux.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 255 > /sys/class/leds/user-led1/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/user-led1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n216

+
+
+

7.9. I²C Bus

+

The i.MX 8M Plus contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 8M Plus. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our phyBOARD-Pollux.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C1 bus configuration (e.g. imx8mp-phycore-som.dtsi): +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n105

+

General I²C2 bus configuration (e.g. imx8mp-phyboard-pollux-rdk.dts) +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n201

+
+
+

7.10. EEPROM

+

On the phyCORE-i.MX8MP there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues.

+
+

7.10.1. I2C EEPROM on phyCORE-i.MX8MP

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

The I2C EEPROM on the phyCORE-i.MX8MP SoM is connected to I2C address 0x51 on the I2C-0 +bus. It is possible to read and write directly to the device populated:

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the 4KiB EEPROM (bus: I2C-0 addr: 0x51) with zeros leaving out the EEPROM data use:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM Detection

+

The I2C EEPROM, populated on the phyCORE-i.MX8MP, has a separate ID page that is +addressable over I2C address 0x59 on bus 0 and a normal area that is addressable +over I2C address 0x51 on bus 0. PHYTEC uses this data area of 32 Bytes to store +information about the SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the EEPROM ID page data and the first 256 bytes of the normal area are +deleted, the bootloader will fall back to the phyCORE-i.MX8MP Kit RAM setup, which +is 2GiB RAM.

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

SoMs that are flashed with data format API revision 2 will print out information +about the module in the early stage.

+
+
+

7.10.3. Rescue EEPROM Data

+

The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area.

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1
+
+
+
+

Note

+

If you deleted both EEPROM spaces, please contact our support!

+
+

DT representation, e.g. in phyCORE-i.MX 8M Plus file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n201

+
+
+
+

7.11. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC Wakealarm

+

It is possible to issue an interrupt from the RTC to wake up the system. The +format uses the Unix epoch time, which is the number of seconds since UTC +midnight on 1 January 1970. To wake up the system after 4 minutes from suspend +to ram state, type:

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

Note

+

Internally the wake alarm time will be rounded up to the next minute since +the alarm function doesn’t support seconds.

+
+

DT representation for I²C RTCs: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n207

+
+
+
+

7.12. USB Host Controller

+

The USB controller of the i.MX 8M Plus SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +‘SS’). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY.

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+

DT representation for USB Host: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n341

+
+
+

7.13. CAN FD

+

The phyBOARD-Pollux has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The two CAN interfaces should show up as +can0 and can1.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    The information for can0 will look like:

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+
+

Warning

+

The mcp2518fd SPI to CANfd supports only baudrates starting from 125kB/s. +Slower rates can be selected but may not work correctly.

+
+

Device Tree CAN configuration of imx8mp-phyboard-pollux.dtsi: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n165

+
+
+

7.14. PCIe

+

The phyCORE-i.MX 8M Plus has one Mini-PCIe slot. In general, PCIe autodetects new +devices on the bus. After connecting the device and booting up the system, you +can use the command lspci to see all PCIe devices recognized.

+
    +

  • Type:

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • You will receive:

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

In this example, the PCIe device is the Intel Corporation WiFi Link 5100.

+

For PCIe devices, you have to enable the correct driver in the kernel +configuration. This WLAN card, for example, is manufactured by Intel. The +option for the driver, which must be enabled, is named CONFIG_IWLWIFI and can be +found under Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimat in +the kernel configuration.

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • The linux-imx is represented by: virtual/kernel

      • +
    +
    • +
+

For some devices like the WLAN card, additional binary firmware blobs are +needed. These firmware blobs have to be placed in /lib/firmware/ before the +device can be used.

+
    +

  • Type:

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • For example, if you try to bring up the network interface:

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • You will get the following output on the serial console:

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

Tip

+

Some PCIe devices, e.g. the Ethernet card, may function properly even if no +firmware blob is loaded from /lib/firmware/ and you received an error message +as shown in the first line of the output above. This is because some +manufacturers provide the firmware as a fallback on the card itself. In this +case, the behavior and output depend strongly on the manufacturer’s firmware.

+
+

Device Tree PCIe configuration of imx8mm-phyboard-polis.dtsi: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n277

+
+
+

7.15. Audio

+

Playback devices supported for phyBOARD-Pollux are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals.

+
+

Note

+

Using the PEB-AV-10 connector for display output along HDMI as audio output +is not supported. The audio output device must match the video output device.

+
+

To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices:

+
target:~$ aplay -L
+
+
+

Or type for recording devices:

+
target:~$ arecord -L
+
+
+
+

7.15.1. Alsamixer

+

To inspect the capabilities of your soundcard, call:

+
target:~$ alsamixer
+
+
+

You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. “MM” means the feature is muted +(both output, left & right), which can be toggled by hitting m. You can also +toggle by hitting ‘<’ for left and ‘>’ for right output. With the tab +key, you can switch between controls for playback and recording.

+
+
+

7.15.2. ALSA configuration

+

Our BSP comes with a ALSA configuration file /etc/asound.conf.

+

The ALSA configuration file can be edited as desired or deleted since it is not +required for ALSA to work properly.

+
target:~$ vi /etc/asound.conf
+
+
+

To set PEB-AV-10 as output, set playback.pcm from “dummy” to “pebav10”:

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

If the sound is not audible change playback devices to the software volume control +playback devices, set playback.pcm to the respective softvol playback device either +“softvol_hdmi” or “softvol_pebav10”. Use alsamixer controls to vary the volume levels.

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_hdmi"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.15.3. Pulseaudio Configuration

+

For applications using Pulseaudio, check for available sinks:

+
target:~$ pactl list short sinks
+0   alsa_output.platform-snd_dummy.0.stereo-fallback    module-alsa-card.c  s16le 2ch 44100Hz   SUSPENDED
+1   alsa_output.platform-sound-peb-av-10.stereo-fallback    module-alsa-card.c  s16le 2ch 44100Hz   SUSPENDED
+
+
+

To select PEB-AV-10, type:

+
target:~$ pactl set-default-sink 1
+
+
+
+
+

7.15.4. Playback

+

Run speaker-test to check playback availability:

+
target:~$ speaker-test -c 2 -t wav
+
+
+

To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds:

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

To playback other formats like mp3 for example, you can use Gstreamer:

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.15.5. Capture

+

arecord is a command-line tool for capturing audio streams which use Line In as +the default input source. To select a different audio source you can +use alsamixer. For example, switch on Right PGA Mixer Mic3R and Left PGA Mixer +Mic3R in order to capture the audio from the microphone input of the +TLV320-Codec using the 3.5mm jack.

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

Hint

+

Since playback and capture share hardware interfaces, it is not possible to +use different sampling rates and formats for simultaneous playback and +capture operations.

+
+

Device Tree Audio configuration: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.10.72_2.2.0-phy18#n57

+
+
+
+

7.16. Video

+
+

7.16.1. Videos with Gstreamer

+

The video is installed by default in the BSP:

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/phytec-qtdemo/videos/caminandes.webm
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=<video.mp4> \
+\! qtdemux  \! h264parse \! queue \! vpudec \! waylandsink async=false enable-last-sample=false \
+qos=false sync=false
+
+
+
    +

  • Or:

    • +
+
target:~$ gplay-1.0 /usr/share/phytec-qtdemo/videos/caminandes.webm
+
+
+
+
+

7.16.2. kmssink Plugin ID Evaluation

+

The kmssink plugin needs a connector ID. To get the connector ID, you can use +the tool modetest.

+
target:~$ modetest -c imx-drm
+
+
+

The output will show something like:

+
Connectors:
+id  encoder status      name        size (mm)   modes   encoders
+35  34  connected   LVDS-1          216x135     1   34
+  modes:
+    index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
+  #0 1280x800 59.07 1280 1380 1399 1440 800 804 808 823 70000 flags: phsync, pvsync; type: preferred, driver
+  props:
+    1 EDID:
+        flags: immutable blob
+        blobs:
+
+        value:
+    2 DPMS:
+        flags: enum
+        enums: On=0 Standby=1 Suspend=2 Off=3
+        value: 0
+    5 link-status:
+        flags: enum
+        enums: Good=0 Bad=1
+        value: 0
+    6 non-desktop:
+        flags: immutable range
+        values: 0 1
+        value: 0
+    4 TILE:
+        flags: immutable blob
+        blobs:
+
+        value:
+
+
+
+
+
+

7.17. Display

+

The phyBOARD-Pollux supports up to 4 different display outputs. Three can be used +simultaneously. The following table shows the required extensions and devicetree +overlays for the different interfaces.

+ + + + + + + + + + + + + + + + + + + + + + + + + +

Interface

Expansion

devicetree overlay

HDMI

phyBOARD-Pollux

no overlay needed (enabled by default)

LVDS0

PEB-AV-10

imx8mp-phyboard-pollux-peb-av-010.dtbo +(loaded by default)

LVDS1

phyBOARD-Pollux

disabled if PEB-AV-10 overlay is used

MIPI

PEB-AV-12 (MIPI to LVDS)

imx8mp-phyboard-pollux-peb-av-012.dtbo

+
+

Note

+
    +

  • HDMI will not work if LVDS1 (onboard) is enabled.

    • +

  • When changing Weston output, make sure to match the audio output as well.

    • +

  • LVDS0 (PEB-AV-10) and LVDS1 (onboard)can not be used at the same time.

    • +
+
+

HDMI is always enabled in the devicetree. The other interfaces can be enabled +with Device Tree Overlay.

+

The default-enabled Interfaces are HDMI and LVDS0 (PEB-AV-010). We support a +10’’ edt,etml1010g0dka display for the PEB-AV-10 and PEB-AV-12.

+
+

Note

+

The current display driver limits the pixel clock for a display connected to +LVDS to 74.25Mhz (or a divider of it). If this does not fit your display +requirements, please contact Support for further help.

+
+
+

7.17.1. Weston Configuration

+

In order to get an output from Weston on the correct display, it still needs to +be configured correctly. This will be done at /etc/xdg/weston/weston.ini.

+
+

7.17.1.1. Single Display

+

In our BSP, the default Weston output is set to HDMI.

+
[output]
+name=HDMI-A-1
+mode=current
+
+
+
+
+
+

7.17.2. Qt Demo

+

With the phytec-qt5demo-image, Weston starts during boot. The phytec-qt5demo can be +stopped with:

+
target:~$ systemctl stop phytec-qtdemo
+
+
+
    +

  • To start the demo again, run:

    +
    target:~$ systemctl start phytec-qtdemo
+
    +
    +
    • +

  • To disable autostart of the demo run:

    +
    target:~$ systemctl disable phytec-qtdemo
+
    +
    +
    • +

  • To enable autostart of the demo, run:

    +
    target:~$ systemctl enable phytec-qtdemo
+
    +
    +
    • +

  • Weston can be stopped with:

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

Note

+

The Qt demo must be closed before Weston can be closed.

+
+
+
+

7.17.3. Backlight Control

+

If a display is connected to the PHYTEC board, you can control its backlight +with the Linux kernel sysfs interface. All available backlight devices in the +system can be found in the folder /sys/class/backlight. Reading the appropriate +files and writing to them allows you to control the backlight.

+
+

Note

+

Some boards with multiple display connectors might have multiple backlight +controls in /sys/class/backlight. For example: backlight0 and backlight1

+
+
    +

  • To get, for example, the maximum brightness level (max_brightness) execute:

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    Valid brightness values are 0 to <max_brightness>.

    +
    • +

  • To obtain the current brightness level, type:

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • Write to the file brightness to change the brightness:

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    turns the backlight off for example.

    +

    For documentation of all files, see +https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight.

    +
    • +
+

Device tree description of LVDS-1 and HDMI can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n255 +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n180

+

The device tree of LVDS-0 on PEB-AV-10 can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.10.72_2.2.0-phy18#n132

+
+
+
+

7.18. Power Management

+
+

7.18.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 8M Plus SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as ‘Dynamic Voltage and +Frequency Scaling’ (DVFS). The i.MX 8M Plus BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the i.MX 8 +variant used, several different frequencies are supported.

+
+

Tip

+

Although the DVFS framework provides frequency settings for each CPU core, a +change in the frequency settings of one CPU core always affects all other CPU +cores too. So all CPU cores always share the same DVFS setting. An individual +DVFS setting for each core is not possible.

+
+
    +

  • To get a complete list type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately +1,6 GHz, the result will be:

    +
    1200000 1600000
+
    +
    +
    • +

  • To ask for the current frequency type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

So-called governors are automatically selecting one of these frequencies in +accordance with their goals.

+
    +

  • List all governors available with the following command:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    The result will be:

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative is much like the ondemand governor. It differs in behavior in +that it gracefully increases and decreases the CPU speed rather than jumping +to max speed the moment there is any load on the CPU.

    • +

  • ondemand (default) switches between possible CPU core frequencies in +reference to the current system load. When the system load increases above a +specific limit, it increases the CPU core frequency immediately.

    • +

  • powersave always selects the lowest possible CPU core frequency.

    • +

  • performance always selects the highest possible CPU core frequency.

    • +

  • userspace allows the user or userspace program running as root to set a +specific frequency (e.g. to 1600000). Type:

    • +

  • In order to ask for the current governor, type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    You will normally get:

    +
    ondemand
+
    +
    +
    • +

  • Switching over to another governor (e.g. userspace) is done with:

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • Now you can set the speed:

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +Documentation/admin-guide/pm/cpufreq.rst.

+
+
+

7.18.2. CPU Core Management

+

The i.MX 8M Plus SoC can have multiple processor cores on the die. The i.MX 8M Plus, for +example, has 4 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    Here the system has four processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.18.3. Suspend to RAM

+

The phyCORE-i.MX8MP supports basic suspend and resume. Different wake-up sources can be +used. Suspend/resume is possible with:

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

To wake up with serial console run

+
target:~$ echo enabled > /sys/class/tty/ttymxc0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.19. Thermal Management

+
+

7.19.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.19.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 8M Plus SoC platform. The i.MX 8 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Industrial +and Commercial.

+ + + + + + + + + + + + + + + + + +

Commercial

Industrial

passive (warning)

85°C

95°C

critical (shutdown)

90°C

100°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise, Fair Share, Bang Bang, and +Userspace. The default policy used in the BSP is step_wise. If the value of the +SoC temperature in the sysfs file temp is above trip_point_0, the CPU frequency +is set to the lowest CPU frequency. When the SoC temperature drops below +trip_point_0 again, the throttling is released.

+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+

7.19.3. GPIO Fan

+
+

Note

+

Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan +to GPIO fan due to availability. The PWM fan will not be supported +anymore and will not function with the new release.

+
+

A GPIO fan can be connected to the phyBOARD-Pollux-i.MX 8M Plus. The SoC only contains one +temperature sensor which is already used by the thermal frequency scaling. The +fan can not be controlled by the kernel. We use lmsensors with hwmon for this +instead. lmsensors reads the temperature periodically and enables or disables +the fan at a configurable threshold. For the phyBOARD-Pollux-i.MX 8M Plus, this is 60°C.

+

The settings can be configured in the configuration file:

+
/etc/fancontrol
+
+
+

Fan control is started by a systemd service during boot. This can be disabled +with:

+
target:~$ systemctl disable fancontrol
+
+
+

The device tree description of GPIO Fan can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n26

+
+
+
+

7.20. Watchdog

+

The PHYTEC i.MX 8M Plus modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.20.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.21. snvs Power Key

+

The X_ONOFF pin connected to the ON/OFF button can be pressed long to trigger +Power OFF without SW intervention or used to wake up the system out of suspend. +With the snvs_pwrkey driver, the KEY_POWER event is also reported to userspace +when the button is pressed. On default, systemd is configured to ignore such +events. The function of Power OFF without SW intervention and the wake-up from +suspend are not configured. Triggering a power off with systemd when pushing the +ON/OFF button can be configured under /etc/systemd/logind.conf and set using:

+
HandlePowerKey=poweroff
+
+
+
+
+

7.22. NPU

+

The i.MX 8M Plus SoC contains a Neural Processing Unit up to 2.3 TOPS as an accelerator +for artificial intelligence operations. Refer to our latest phyCORE-i.MX 8M Plus AI Kit +Guide on the phyCORE-i.MX 8M Plus download section to get information about the +NPU: L-1015e.A0 phyCORE-i.MX 8M Plus AI Kit Guide

+
+

7.22.1. NXP Examples for eIQ

+

NXP provides a set of machine learning examples for eIQ using Python3. To add a +pre-configured machine learning package group, add to your local.conf and build +your BSP:

+
IMAGE_INSTALL_append = " packagegroup-imx-ml python3-pip python3-requests opencv"
+
+
+

This will require about 1GB of additional space on the SD Card. Instructions +on how to install and use the NXP examples can be found at +https://community.nxp.com/t5/Blogs/PyeIQ-3-x-Release-User-Guide/ba-p/1305998.

+
+

Hint

+

The installation of the eiq examples with pip3 requires an internet +connection.

+
+
+

Note

+

On some Ubuntu 20.04 hosts, cmake uses the host’s Python 3 instead of Python +3.7 from Yocto when building python3-pybind11. (see +https://community.nxp.com/t5/i-MX-Processors/Yocto-L5-4-70-2-3-0-build-image-failed/m-p/1219619)

+

As a workaround edit, the python3-pybind11 recipe by:

+
$ devtool edit-recipe python3-pybind11
+
+
+

and add to the file:

+
EXTRA_OECMAKE += "-DPYTHON_EXECUTABLE=${RECIPE_SYSROOT_NATIVE}/usr/bin/python3-native/python3.7"
+
+
+
+
+
+
+

7.23. ISP

+

The i.MX 8M Plus SoC contains an Image Signal Processor (ISP). For more information see +Using the ISPs on the phyBOARD-Pollux i.MX 8M Plus documentation. This documentation is also +available in German.

+
+
+

7.24. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 8M Plus provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 8M Plus Reference Manual). The following list is +an abstract from the i.MX 8M Plus Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x30350000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x30350000

Description

OCOTP_MAC_ADDR0

9

0

0x640

contains lower 32 bits +of ENET0 MAC address

OCOTP_MAC_ADDR1

9

1

0x650

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

OCOTP_MAC_ADDR2

9

2

0x660

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 8M Plus Security Reference Manual.

+
+

7.24.1. Reading Fuse Values in uBoot

+

You can read the content of a fuse using memory-mapped shadow registers. To +calculate the memory address, use the fuse Bank and Word in the following +formula:

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.24.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+

Reading the registers using /dev/mem will cause the system to hang unless the +ocotp_root_clk is enabled. To enable this clock permanent, add to the device +tree:

+
&clk {
+        init-on-array = <IMX8MP_CLK_OCOTP_ROOT>;
+};
+
+
+
+
+
+
+

8. i.MX 8M Plus M7 Core

+

In addition to the Cortex-A53 cores, there is a Cortex-M7 Core as MCU +integrated into the i.MX 8M Plus SoC. Our Yocto-Linux-BSP runs on the A53-Cores and +the M7 Core can be used as a secondary core for additional tasks using +bare-metal or RTOS firmware. +Both cores have access to the same peripherals and thus peripheral +usage needs to be limited either in the M7 Core’s firmware or the devicetree +for the Linux operating system. This section describes how to build firmware +examples and how to run them on phyBOARD-Pollux.

+

The phyBOARD-Pollux is currently supported by the NXP MCUXpresso SDK and by +The Zephyr Project. This section only describes the NXP MCUXpresso SDK because +the MCUXpresso SDK has more supported features at the moment.

+

If you want to use the M7 Core with The Zephyr Project, please refer to the +The Zephyr Project documentation:

+ +
+

8.1. Getting the Firmware Examples

+

The firmware can be built using the NXP MCUxpresso SDK with a compatible +compiler toolchain using command-line tools.

+
+

8.1.1. Getting the Sources

+

The MCUX SDK and the examples for the i.MX 8M Plus can be obtained from PHYTEC’s GitHub +page:

+ +
    +

  1. Initialize the MCUX SDK via west:

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    This will create a mcuxsdk directory with the mcux-sdk repository in it. +The mcux-sdk-phytec-examples repository will be automatically cloned into +the mcuxsdk directory. +The given argument <VERSION> is a the branch name of the mcux-sdk repository +that represents the MCUX SDK version. For the newest tested version +you can use 2.13.0.

    +
    +

    Note

    +

    west is a repository management tool and a part of the Zephyr +Project. +To install west, you can use pip. In this example west is installed in +a python virtual environment:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. Update the dependencies:

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    The directory examples-phytec contains all examples ported and tested +for phyBOARD-Pollux with version 2.13.0 of MCUX.

    +

    To build the firmware, a compiler toolchain and make/cmake are required. +The GNU Arm Embedded Toolchain may be available in your distribution’s +repositories, e.g. for Ubuntu.

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    The compiler toolchain can also be obtained directly from +https://developer.arm.com/. After the archive has been extracted, +the ARMGCC_DIR has to be added to the environment, e.g. for the +ARM toolchain 10-2020-q4-major release located in the home directory:

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. Building the Firmware

+

To build the PHYTEC samples an environment has to be sourced

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

The scripts to build the firmware are located in +<sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc. +There are scripts for each memory location the firmware is supposed to run in, +e.g.

+
host:~$ ./build_release.sh
+
+
+

to build the firmware for the M7 Core’s TCM. The output will be placed under +release/ in the armgcc directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+

To build the firmware for the DRAM, run the script build_ddr_release. +The script of the firmware that is supposed to run, e.g.

+
host:~$ ./build_ddr_release.sh
+
+
+

The output will be placed under ddr_release/ in the armgcc +directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+
+
+
+

8.2. Running M7 Core Examples

+

There are two ways to run the M7 Core with the built firmware, U-Boot and +Remoteproc within a running Linux.

+

To receive debug messages start your favorite terminal software (e.g. Minicom, +Tio, or Tera Term) on your host PC and configure it for 115200 baud, 8 data +bits, no parity, and 1 stop bit (8n1) with no handshake.

+

Once a micro-USB cable is connected to the USB-debug port on the phyBOARD-Pollux, two +ttyUSB devices are registered. One prints messages from A53-Core’s debug UART +and the other one from the M7 Core’s debug UART.

+
+

8.2.1. Running Examples from U-Boot

+

To load firmware using the bootloader U-Boot, the bootaux command can be used:

+
    +

  1. Prepare an SD Card with our Yocto-BSP

    2. +

  2. Copy the generated .bin file to the SD Cards first partition

    3. +

  3. Stop the autoboot by pressing any key

    4. +

  4. Type the command depending on the type of firmware:

    5. +
+

For firmware built to run in the M7 Core’s TCM:

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

For firmware built to run in the DRAM:

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

The program’s output should appear on the M7 Core’s debug UART.

+
+
+

8.2.2. Running Examples from Linux using Remoteproc

+

Remoteproc is a module that allows you to control the M7 Core from Linux +during runtime. Firmware built for TCM can be loaded and the execution started +or stopped. To use Remoteproc a devicetree overlay needs to be set:

+

Edit the bootenv.txt file located in the /boot directory on the target by +adding imx8mp-phycore-rpmsg.dtbo:

+
overlays=imx8mp-phycore-rpmsg.dtbo
+
+
+

Restart the target and execute in U-Boot:

+
u-boot=> run prepare_mcore
+
+
+

Firmware .elf files for the M7 Core can be found under /lib/firmware. +To load the firmware, type:

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

To load a different firmware, the M7 Core needs to be stopped:

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

Note

+

The samples found in /lib/firmware on the target come from NXP’s +Yocto layer meta-imx. +To use the samples you built yourself through MCUX SDK, please copy them +to /lib/firmware on the target after building them.

+
+
+ +
+
+
+

9. BSP Extensions

+
+

9.1. Chromium

+

Our BSP for the phyBOARD-Pollux-i.MX 8M Plus supports Chromium. You can include it in the +phytec-qt5demo-image with only a few steps.

+
+

9.1.1. Adding Chromium to Your local.conf

+

To include Chromium you have to add the following line into your local.conf. You +can find it in <yocto_dir>/build/conf/local.conf. This adds Chromium to your +next image build.

+
IMAGE_INSTALL_append = " chromium-ozone-wayland"
+
+
+
+

Note

+

Compiling Chromium takes a long time.

+
+
+
+

9.1.2. Get Chromium Running on the Target

+

To run Chromium, it needs a few arguments to use the hardware graphics +acceleration:

+
target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox
+
+
+

If you want to start Chromium via SSH, you must first define the display on +which Chromium will run. For example:

+
target$ DISPLAY=:0
+
+
+

After you have defined this, you can start it via virtual terminal on Weston as +shown above.

+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mp/pd23.1.0.html b/previews/271/bsp/imx8/imx8mp/pd23.1.0.html new file mode 100644 index 000000000..98476336b --- /dev/null +++ b/previews/271/bsp/imx8/imx8mp/pd23.1.0.html @@ -0,0 +1,4747 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 8M Plus BSP Manual

Document Title

i.MX 8M Plus BSP Manual

Document Type

BSP Manual

Yocto Manual

Kirkstone

Release Date

2024/01/10

Is Branch of

i.MX 8M Plus BSP Manual

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-NXP-i.MX8MP-PD23.1.0

Major

2023/12/12

Released

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +phyCORE-i.MX8M Plus Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads of our product.

+
+

1.1. Supported Hardware

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-NXP-i.MX8MP-PD23.1.0 download.

+

If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware

+
+

1.1.1. phyBOARD-Pollux Components

+
+../../../_images/phyBOARD-Pollux-front-components.jpg + +
+

phyBOARD-Pollux Components (top)

+
+
+
+../../../_images/phyBOARD-Pollux-back-components.jpg + +
+

phyBOARD-Pollux Components (bottom)

+
+
+
+
+
+
+

2. Getting Started

+

The phyCORE-i.MX8M Plus Kit is shipped with a pre-flashed SD card. It contains the +phytec-qt6demo-image and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+

There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool dd. An +alternative way is to use PHYTEC’s system initialization program called +partup, which makes it especially easy to +format more complex systems. You can get prebuilt Linux binaries of partup from its release page. Also read +partup’s README for installation +instructions.

+
+

2.1. Get the Image

+

The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using dd, can be downloaded from the PHYTEC download server.

+

Get either the partup package or the WIC image from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic
+
+
+
+

Note

+

For eMMC, more complex partitioning schemes or even just large images, we +recommend using the partup package, as it is faster in writing than dd +and allows for a more flexible configuration of the target flash device.

+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card, you must have root privileges on your Linux +host PC. Be very careful when specifying the destination device! All files +on the selected device will be erased immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system on your host PC!

+
+
+

2.2.1. Finding the Correct Device

+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+

Unmount all those partitions, e.g.:

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

Now, the SD card is ready to be flashed with an image, using either partup, +dd or bmap-tools.

+
+
+

2.2.2. Using partup

+

Writing to an SD card with partup is done in a single command:

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3.partup /dev/<your_device>
+
+
+

Make sure to replace <your_device> with your actual device name found previously.

+

Further usage of partup is explained at its official documentation website.

+
+

Note

+

partup has the advantage of allowing to clear specific raw areas in the +MMC user area, which is used in our provided partup packages to erase any +existing U-Boot environments. This is a known issue bmaptool does not +solve, as mentioned below.

+

Another key advantage of partup over other flashing tools is that it allows +configuring MMC specific parts, like writing to eMMC boot partitions, without +the need to call multiple other commands when writing.

+
+
+
+

2.2.3. Using bmap-tools

+

An alternative and also fast way to prepare an SD card is using +bmap-tools. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host:~$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /dev/<your_device>
+
+
+

Replace <your_device> with your actual SD card’s device name found previously, +and make sure to place the file <IMAGENAME>-<MACHINE>.wic.bmap alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip.

+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.2.4. Using dd

+

After having unmounted all SD card’s partitions, you can create your bootable SD card.

+

Some PHYTEC BSPs produce uncompressed images (with filename-extension *.wic), +and some others produce compressed images (with filename-extension *.wic.xz).

+

To flash an uncompressed images (*.wic) use command below:

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Or to flash a compressed images (*.wic.xz) use that command:

+
host:~$ xzcat phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Again, make sure to replace <your_device> with your actual device name found +previously.

+

The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

+
+
+
+

2.3. First Start-up

+ +../../../_images/SD_Card_Boot2.png +
    +

  • Insert the SD card

    • +

  • Connect the target and the host with mirco USB on (X1) +debug USB

    • +

  • Power up the board

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (kirkstone).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (kirkstone).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-IMX8MP; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-xwayland MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD23.1.0
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the phyboard-pollux-imx8mp-3 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx8mp.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, +lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY firmware images

    • +

  • imx-boot: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM +Trusted Firmware and DDR firmware. This is the final bootloader image which is +bootable.

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx8mp-phyboard-pollux-rdk*.dtb: Kernel device tree file

    • +

  • imx8mp-phy*.dtbo: Kernel device tree overlay files

    • +

  • phytec-qt6demo-image*.tar.gz: Root file system

    • +

  • phytec-qt6demo-image*.wic: SD card image

    • +
+
+
+
+
+

4. Installing the OS

+
+

4.1. Bootmode Switch (S3)

+
+

Tip

+

Hardware revision baseboard: 1552.2

+
+

The phyBOARD-Pollux features a boot switch with four individually switchable ports to +select the phyCORE-i.MX 8M Plus default bootsource.

+ + + + + + + + + + + +
+../../../_images/eMMC2.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses2.png +
+

Internal Fuses

+
+
+
+../../../_images/SPI_NOR2.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download3.png +
+

USB Serial Download

+
+
+
+../../../_images/SD_Card_Boot2.png +
+

SD Card

+
+
+
+../../../_images/Test_Mode.png +
+

Test Mode

+
+
+
+
+
+

4.2. Flash eMMC

+

For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see Setup Network Host.

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S3) is set to eMMC.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk2p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from Network

+

i.MX 8M Plus boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

4.2.1.1. Flash eMMC from Network in U-Boot on Target

+

These steps will show how to update the eMMC via a network.

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE.

+
+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Load your image via network to RAM:

+
    +

  • when using dhcp

    +
    u-boot=> dhcp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.1 (1 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.1
+Filename 'phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • when using a static ip address (serverip and ipaddr must be set +additionally).

    +
    u-boot=> tftp ${loadaddr} phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
+
+
+
+

4.2.1.2. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Take a compressed or uncompressed image with accompanying block map on the host +and send it with ssh through the network to the eMMC of the target with a +one-line command:

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic.* /tmp && bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /dev/mmcblk2
+
+
+
+
+

4.2.1.3. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Show your available image files on the host:

+
host:~$ ls /srv/tftp
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic.bmap
+
+
+

Send the image with the bmaptool command combined with ssh through the network +to the eMMC of your device:

+
host:~$ scp /srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /dev/mmcblk2"
+
+
+
+
+
+

4.2.2. Flash eMMC U-Boot image via Network from running U-Boot

+

Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.3. Flash eMMC from USB stick

+
+

4.2.3.1. Flash eMMC from USB stick in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE.

+
+

These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch (S3) to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied WIC image to the USB slot.

+

Load your image from the USB device to RAM:

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} *.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic). Set the bootmode switch (S3) to SD Card.

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ ls /mnt
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without partition):

    +
    target:~$ bmaptool copy /mnt/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Tip

    +

    Before this will work, you need to configure the bootmode switch (S3) to +eMMC.

    +
    +
    • +
+
+
+
+

4.2.4. Flash eMMC from SD Card

+

Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (*.wic) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see Resizing ext4 Root Filesystem.

+

Alternatively, flash a partup package to the SD card, as described in +Getting Started. This will ensure the full space of the SD card is used.

+
+

4.2.4.1. Flash eMMC from SD card in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE. If the +image file is too large use the Updating eMMC from SD card in +Linux on Target subsection.

+
+
    +

  • Flash an SD card with a working image and create a third ext4 partition. Copy +the WIC image (for example phytec-qt6demo-image.wic) to this +partition.

    • +

  • Configure the bootmode switch (S3) to SD Card and insert the SD Card.

    • +

  • Power on the board and stop in U-Boot.

    • +

  • Load the image:

    +
    u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • Switch the mmc dev to eMMC:

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • Flash your WIC image (for example phytec-qt6demo-image.wic) +from the SD card to eMMC. This will partition the card and copy imx-boot, +Image, dtb, dtbo, and root file system to eMMC.

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • Power off the board and change the bootmode switch (S3) to eMMC.

    • +
+
+
+

4.2.4.2. Flash eMMC from SD card in Linux on Target

+

You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card.

+
    +

  • Show your saved partup package or WIC image files on the SD card:

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.partup
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without +partition) using partup:

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3.partup /dev/mmcblk2
+
    +
    +

    Flashing the partup package has the advantage of using the full capacity of +the eMMC device, adjusting partitions accordingly.

    +
    +

    Note

    +

    Alternatively, bmaptool may be used instead:

    +
    target:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /dev/mmcblk2
+
    +
    +

    Keep in mind that the root partition does not make use of the full space when +flashing with bmaptool.

    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Warning

    +

    Before this will work, you need to configure the bootmode switch (S3) to eMMC.

    +
    +
    • +
+
+
+
+
+

4.3. Flash SPI NOR Flash

+

The phyCORE-i.MX8MP modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set bootmode switch (S3) to SPI NOR. The SPI Flash is usually quite small. +The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash populated. Only the +bootloader and the environment can be stored. The kernel, device tree, and file +system are taken from eMMC by default.

+

The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with:

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. Flash SPI NOR Flash from Network

+

The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-i.MX 8M Plus.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+
+

4.3.1.1. Flash SPI NOR from Network in U-Boot on Target

+

Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI NOR flash needs to be probed:

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • A specially formatted U-Boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image over tftp, erase and write the +bootloader to the flash:

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+

4.3.1.2. Flash SPI NOR from Network in kernel on Target

+
    +

  • Copy the image from the host to the target:

    +
    host:~$ scp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • Find the number of blocks to erase of the U-boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the U-Boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+

4.3.2. Flash SPI NOR Flash from SD Card

+

The bootloader on SPI NOR flash can be also flashed with SD Card.

+
+

4.3.2.1. Flash SPI NOR from SD Card in U-Boot on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi to the first partition +on the SD Card.

    • +

  • Before reading and writing are possible, the SPI-NOR flash +needs to be probed:

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • A specially formatted U-boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image from the SD Card, erase and write +the bootloader to the flash:

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+

4.3.2.2. Flash SPI NOR from SD Card in kernel on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi to the first partition +on the SD Card.

    • +

  • Mount the SD Card:

    +
    target:~$ mount /dev/mmcblk1p1 /mnt
+
    +
    +
    • +

  • Find the number of blocks to erase of the U-Boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the u-boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A5 RAUC Update & Device Management Manual.

+
+
+
+

5. Development

+
+

5.1. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.1.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.2. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.2.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel image to your tftp directory:

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • Copy the devicetree to your tftp directory:

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • Copy all the overlays you want to use into your tftp directory:

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-pollux-imx8mp-3.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.2.2. Set the bootenv.txt for Netboot

+

Create a bootenv.txt file in your tftp directory and write the following variables into it.

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> has to be replaced with the devicetree overlay filenames that you want to use. +Separate the filenames by spaces. For example:

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

Tip

+

All supported devicetree overlays are in the device tree chapter.

+
+
+
+

5.2.3. Network Settings on Target

+

To customize the targets ethernet configuration, please follow the description +here: Network Environment Customization

+
+
+

5.2.4. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.3.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/phyboard-pollux-imx8mp-3/. For flashing a wic image to eMMC, +you will also need phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic.

+
+
+

5.3.3. Prepare Target

+

Set the bootmode switch (S3) to USB Serial Download. Also, connect USB port +X5 (upper connector) to your host.

+
+
+

5.3.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via (X1), as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.3.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic
+
+
+
+
+
+

5.4. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone git://git.phytec.de/u-boot-imx)

+
+
+

5.4.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-imx and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • Our i.MX 8M Plus kernel is based on the linux-imx kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. Get the SDK

+

You can download the SDK here, or build it yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

After a successful build the SDK installer is deployed to build/deploy*/sdk.

+
+
+

5.4.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-4.0.13.sh
+host:~$ ./phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-4.0.13.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-xwayland/4.0.13):
+You are about to install the SDK to "/opt/ampliphy-vendor-xwayland/4.0.13". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-vendor-xwayland/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. U-Boot standalone build

+
+

5.5.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag used in this release is called v2022.04_2.2.2-phy5

    • +

  • Check out the needed U-Boot tag:

    +
    host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2022.04_2.2.2-phy5
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor-xwayland/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. Get the needed binaries

+

To build the bootloader, you need to copy these files to your u-boot-imx +build directory and rename them to fit with mkimage script:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx8mp.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +
+

If you already built our BSP with Yocto, you can get the +bl31-imx8mp.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: BSP Images

+

Or you can download the files here: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/

+
+

Warning

+

Make sure you rename the files you need so that they are compatible with the +mkimage tool.

+
+
+
+

5.5.3. Build the bootloader

+
    +

  • build flash.bin (imx-boot):

    +
    host:~/u-boot-imx$ make phycore-imx8mp_defconfig
+host:~/u-boot-imx$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. Flash the bootloader to a block device

+

The flash.bin can be found at u-boot-imx/ directory and now can be +flashed. A chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

E.g. flash SD card:

+
host:~/u-boot-imx$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables +“BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+

5.5.5. Build U-Boot With a Fixed RAM Size

+

If you cannot boot your system anymore because the hardware introspection in the +EEPROM is damaged or deleted, you can create a flash.bin with a fixed ram size. +You should still contact support and flash the correct EEPROM data, as this +could lead to unexpected behavior.

+

Follow the steps to get the U-boot sources and check the correct branch in the +Build U-Boot section.

+

Edit the file configs/phycore-imx8mp_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+
+
+

Choose the correct RAM size as populated on the board and uncomment the line for +this ram size. +After saving the changes, follow the remaining steps from Build U-Boot.

+

Starting with PD23.1.0 release, the phyCORE-i.MX 8M Plus SoMs with revision 1549.3 and +newer also support 2GHz RAM timings. These will be enabled for supported boards +automatically, but they can also be enabled or disabled manually.

+

Edit the file configs/phycore-imx8mp_defconfig. +The fixed RAM size with 2GHz timings will be used:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+
+
+

Choose the correct RAM size as populated on the board and uncomment the line +for this ram size. When not specifying the +CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS option, the 1.5GHz timings will +be chosen by default. After saving the changes, follow the remaining steps from +Build U-Boot.

+
+
+
+

5.6. Kernel standalone build

+
+

5.6.1. Setup sources

+
    +

  • The used linux-imx branch can be found in the release notes

    • +

  • The tag needed for this release is called v5.15.71_2.2.2-phy3

    • +

  • Check out the needed linux-imx tag:

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v5.15.71_2.2.2-phy3
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor-xwayland/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-imx$ make imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-imx/arch/arm64/boot/Image

    • +

  • The dtb can be found at +~/linux-imx/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. Copy Kernel to SD Card

+

When one-time boot via netboot is not sufficient, the kernel along with its +modules and the corresponding device tree blob may be copied directly to a +mounted SD card.

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. Accessing the Development states

+
+

5.7.1. Development state of current release

+

These release manifests exist to give you access to the development states +of the Yocto BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line:

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD23.1.y
+
+
+

This will initialize a BSP that will track the latest development state of the +current release (BSP-Yocto-NXP-i.MX8MP-PD23.1.0). From now on repo sync in this folder +will pull all the latest changes from our Git repositories:

+
host:~$ repo sync
+
+
+
+
+

5.7.2. Development state of upcoming release

+

Also development states of upcoming releases can be accessed this way. +For this execute the following command and look for a release with a higher +PDXX.Y number than the latest one (BSP-Yocto-NXP-i.MX8MP-PD23.1.0) and .y at the +end:

+
host:~$ ./phyLinux init -p imx8mp
+
+
+
+
+
+

5.8. Accessing the Latest Upstream Support

+

We have a vanilla manifest that makes use of the Yocto master branches (not an +NXP release), Linux, and U-Boot. This can be used to test the latest upstream +kernel/U-Boot.

+
+

Note

+

The master manifest reflects the latest state of development. This tends to +be broken from time to time. We try to fix the master on a regular basis.

+
+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.9.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 8M Plus SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Board.dts - include the module dtsi file. Devices that come from the i.MX 8M Plus +SoC but are just routed down to the carrier board and used there are included +in this dts.

    • +

  • Overlay.dtso - enable/disable features depending on optional hardware that +may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10)

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 8 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder arch/arm64/boot/dts/freescale/overlays.

+

Available overlays for phyboard-pollux-imx8mp-3.conf are:

+
imx8mp-isi-csi1.dtbo
+imx8mp-isi-csi2.dtbo
+imx8mp-isp-csi1.dtbo
+imx8mp-isp-csi2.dtbo
+imx8mp-phyboard-pollux-peb-av-010.dtbo
+imx8mp-phyboard-pollux-peb-av-012.dtbo
+imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+imx8mp-phycore-no-eth.dtbo
+imx8mp-phycore-no-rtc.dtbo
+imx8mp-phycore-no-spiflash.dtbo
+imx8mp-phycore-rpmsg.dtbo
+imx8mp-vm016-csi1.dtbo
+imx8mp-vm016-csi1-fpdlink.dtbo
+imx8mp-vm016-csi2.dtbo
+imx8mp-vm016-csi2-fpdlink.dtbo
+imx8mp-vm017-csi1.dtbo
+imx8mp-vm017-csi1-fpdlink.dtbo
+imx8mp-vm017-csi2.dtbo
+imx8mp-vm017-csi2-fpdlink.dtbo
+
+
+

The usage of overlays can be configured during runtime in Linux or U-Boot. +Overlays are applied during the boot process in the bootloader after the +boot command is called and before the kernel is loaded. The next sections +explain the configuration in more detail.

+
+

6.2.2.1. Set ${overlays} variable

+

The ${overlays} U-Boot environment variable contains a space-separated list +of overlays that will be applied during boot. Depending on the boot source the +overlays have to either be placed in the boot partition of eMMC/SD-Card or are +loaded over tftp. Overlays set in the $KERNEL_DEVICETREE Yocto machine variable +will be automatically added to the boot partition of the final WIC image.

+

The ${overlays} variable can be either set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=imx8mp-phyboard-pollux-rdk-peb-eval-01.dtbo imx8mp-phyboard-pollux-peb-av-010.dtbo
+
+
+

Changes will take effect after the next reboot. If no bootenv.txt file is +available the overlays variable can be set directly in the U-Boot environment.

+
u-boot=> setenv overlays imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> printenv overlays
+overlays=imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> boot
+
+
+

If a user defined ${overlays} variable should be directly loaded from U-Boot +environment but there is still an external bootenv.txt available, the ${no_bootenv} +variable needs to be set as a flag:

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> boot
+
+
+

More information about the external environment can be found in +U-boot External Environment subsection of the +device tree overlay section.

+

We use the ${overlays} variable for overlays describing expansion boards and +cameras that can not be detected during run time. To prevent applying overlays +listed in the ${overlays} variable during boot, the ${no_overlays} variable can +be set to 1 in the bootloader environment.

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+

6.2.2.2. Extension Command

+

The U-Boot extension command makes it possible to easily apply overlays that +have been detected and added to a list by the board code callback +extension_board_scan(). +Overlays applied this way disable components that are not populated on the SoM. +The detection is done with the EEPROM data (EEPROM SoM Detection) found on the +SoM i2c EEPROM.

+

It depends on the SoM variant if any device tree overlays will be applied. To check +if an overlay will be applied on the running SoM in U-Boot, run:

+
u-boot=> extension scan
+Found 1 extension board(s).
+u-boot=> extension list
+Extension 0: phyCORE-i.MX8MP no SPI flash
+        Manufacturer:           PHYTEC
+        Version:
+        Devicetree overlay:     imx8mp-phycore-no-spiflash.dtbo
+        Other information:      SPI flash not populated on SoM
+
+
+

If the EEPROM data is not available, no device tree overlays are applied.

+

To prevent running the extension command during boot the ${no_extensions} +variable can be set to 1 in the bootloader environment:

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot External Environment

+

During the start of the Linux Kernel the external environment bootenv.txt +text file will be loaded from the boot partition of an MMC device or via TFTP. +The main intention of this file is to store the ${overlays} variable. This makes +it easy to pre-define the overlays in Yocto depending on the used machine. The +content from the file is defined in the Yocto recipe bootenv found in +meta-phytec: +https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=kirkstone

+

Other variables can be set in this file, too. They will overwrite the existing +settings in the environment. But only variables evaluated after issuing the boot +command can be overwritten, such as ${nfsroot} or ${mmcargs}. Changing other +variables in that file will not have an effect. See the usage during netboot as +an example.

+

If the external environment can not be loaded the boot process will be anyway +continued with the values of the existing environment settings.

+
+
+

6.2.4. Change U-boot Environment from Linux on Target

+

Libubootenv is a tool included in our images to modify the U-Boot environment of +Linux on the target machine.

+

Print the U-Boot environment using the following command:

+
target:~$ fw_printenv
+
+
+

Modify a U-Boot environment variable using the following command:

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

Caution

+

Libubootenv takes the environment selected in a configuration file. The +environment to use is inserted there, and by default it is configured to use +the eMMC environment (known as the default used environment).

+

If the eMMC is not flashed or the eMMC environment is deleted, libubootenv +will not work. You should modify the /etc/fw_env.config file to match the +environment source that you want to use.

+
+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 8M Plus BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 8M Plus BSP Device Tree Concept to get an understanding +of our i.MX 8 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 8 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 8M Plus Pin Muxing

+

The i.MX 8M Plus SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 8M Plus terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 8M Plus Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx8mp-phyboard-pollux-rdk.dts:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x140
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x140
+        >;
+};
+
+
+

The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled.

+

The device tree representation for UART1 pinmuxing: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n536

+
+
+

7.2. RS232/RS485

+

The phyCORE-i.MX 8M Plus supports up to 4 UART units. On the phyBOARD-Pollux, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector X2 at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers JP3 and +JP4 on the baseboard. For more information about the correct setup please +refer to the phyCORE-i.MX 8M Plus/phyBOARD-Pollux Hardware Manual section UARTs.

+

We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers JP3 and JP4 need to be set +correctly.

+
+

7.2.1. RS232

+
    +

  • Display the current settings of a terminal in a human-readable format:

    +
    target:~$ stty -a
+
    +
    +
    • +

  • Configuration of the UART interface can be done with stty. For example:

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • With a simple echo and cat, basic communication can be tested. Example:

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

The host should print out “123”.

+
+
+

7.2.2. RS485

+
+

Hint

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

For easy testing, look at the linux-serial-test. This tool is called the IOCTL +for RS485 and sends a constant stream of data.

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

More information about the linux-serial-test tool and its parameters can be +found here: linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Documentation for calling the IOCTL within c-code is described in the Linux +kernel documentation: +https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection3.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see “test” printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final “count for this session”. There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+
+
+

7.2.2.2. RS485 full-duplex

+

For full-duplex mode your connection setup should look like this:

+../../../_images/RS485_fullduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For full-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 1
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  true
+Bus termination enabled:  false
+
+
+

Also here you can do the echo test to see if sending and receiving works:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see “test” printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

To check if the full-duplex operation works, you need to use the +linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=114660, tx=118755, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=118755, tx=114660, rx err=0
+
+
+

In this example both targets will send and receive simultaneously. They will +receive for 15sec and send for 10sec. The receiver needs to receive a bit +longer, so that all sent messages will get received. Remember to start both +targets almost simultaneously. A small difference in start time is accounted +for with the -W 2 option. At the end the program will print the final +“count for this session”. There you can check that all transmitted frames were +received.

+

All the test examples are target to target, but can also be done with host to +target with a USB to rs485 converter. You may need to adjust the interfaces for +commands to work on the host then.

+

The device tree representation for RS232 and RS485: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n341

+
+
+
+
+

7.3. Network

+

phyBOARD-Pollux-i.MX 8M Plus provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board.

+
+

Warning

+

The naming convention of the Ethernet interfaces in the hardware (ethernet0 +and ethernet1) do not align with the network interfaces (eth0 and eth1) in +Linux. So, be aware of these differences:

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n50.

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Pollux can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n150.

+
+

7.3.1. Network Environment Customization

+
+

7.3.1.1. U-boot network-environment

+
    +

  • To find the Ethernet settings in the target bootloader:

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • With your development host set to IP 192.168.3.10 and netmask 255.255.255.0, +the target should return:

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • If you need to make any changes:

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> should be one of ipaddr, netmask, gatewayip or serverip. +<value> will be the actual value of the chosen parameter.

    +
    • +

  • The changes you made are temporary for now. To save these:

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

Here you can also change the IP address to DHCP instead of using a static one.

+
    +

  • Configure:

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • Set up paths for TFTP and NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+

Tip

+

Variables like nfsroot and netargs can be overwritten by the U-boot External +Environment. For netboot, the external environment will be loaded from tftp. +For example, to locally set the nfsroot variable in a bootenv.txt file, +locate the tftproot directory:

+
nfsroot=/home/user/nfssrc
+
+
+

There is no need to store the info on the target. Please note that this does +not work for variables like ipaddr or serveraddr as they need to be already +set when the external environment is being loaded.

+
+
+
+

7.3.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. WLAN

+

WLAN and Bluetooth on the phyBOARD-Pollux are provided by the PEB-WLBT-05 expansion card. +The PEB-WLBT-05 for phyBOARD-Pollux Quickstart Guide shows you how to install the +PEB-WLBT-05.

+
+

Tip

+

With the BSP Version PD22.1 and newer, the PEB-WLBT-05 overlay needs to be activated first, +otherwise the PEB-WLBT-05 won’t be recognized.

+
target:~$ vi /boot/bootenv.txt
+
+
+

Afterwards the bootenv.txt file should look like this (it can also contain other devicetree +overlays!):

+
overlays=imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+
+
+

The changes will be applied after a reboot:

+
target:~$ reboot
+
+
+

For further information about devicetree overlays, read the device tree chapter.

+
+

For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. Connecting to a WLAN Network

+

First set the correct regulatory domain for your country:

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

You will see:

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

Set up the wireless interface:

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

Now you can scan for available networks:

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection.

+

To do so, add the network-credentials to the file /etc/wpa_supplicant.conf:

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

Now a connection can be established:

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

This should result in the following output:

+
...
+ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (kirkstone).

+

First, create the directory:

+
target:~$ mkdir -p /etc/systemd/network/
+
+
+

Then add the following configuration snippet in /etc/systemd/network/10-wlan0.network:

+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+

Now, restart the network daemon so that the configuration takes effect:

+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+
+

7.3.3. Bluetooth

+

Bluetooth is supported on phyBOARD-Pollux with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section.

+

Bluetooth is connected to UART3 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup.

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. Visibility

+

To activate visibility:

+
target:~$ hciconfig hci0 piscan
+
+
+

To disable visibility:

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. Connect

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

Note

+

If the connection fails with the error message: “Failed to connect: +org.bluez.Error.Failed” try restarting PulseAudio with:

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC Card

+

The i.MX 8M Plus supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n380

+

DT configuration for the eMMC interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n223

+
+
+

7.5. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 8M Plus is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw Multi-Level Cells (MLC) or Triple-Level +Cells (TLC) combined with a memory controller that handles ECC and wear +leveling. They are connected via an SD/MMC interface to the i.MX 8M Plus and are +represented as block devices in the Linux kernel like SD cards, flash drives, or +hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.5.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +or TLC. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background Operations +(BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • Enabling can be done with this command:

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.5.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 8M Plus SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.5.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
+
+

7.5.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC or TLC +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC used in NAND Flash, MLC or TLC have lower reliability and a higher +error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC or TLC +or mark these blocks as discard. The data on the device is lost and +will be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.5.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 8M Plus uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.5.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

The following table is for the offset of the i.MX 8M Plus SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.6. SPI Master

+

The i.MX 8M Plus controller has a FlexSPI and an ECSPI IP core included. The FlexSPI +host controller supports two SPI channels with up to 4 devices. Each channel +supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data +lines). The ECSPI controller supports 3 SPI interfaces with one dedicated chip +selected for each interface. As chip selects should be realized with GPIOs, more +than one device on each channel is possible.

+
+

7.6.1. SPI NOR Flash

+

phyCORE-i.MX 8M Plus is equipped with a QSPI NOR Flash which connects to the i.MX 8M Plus’s +FlexSPI interface. The QSPI NOR Flash is suitable for booting. Please see +different sections for flashing and bootmode setup. Due to limited space on the +SPI NOR Flash, only the bootloader is stored inside. By default, the kernel, +device tree, and rootfs are taken from eMMC.

+

The Bootloader does detect with the help of the EEPROM Introspection data if an +SPI flash is mounted or not. If no SPI flash is mounted a device tree overlay is +applied with the expansion command to disable the SPI flash device tree node +during boot. If no introspection data is available the SPI NOR flash node is +always enabled. Find more information in the device tree overlay section.

+

The bootloader also passes the SPI MTD partition table to Linux by fixing up the +device tree based on the mtdparts boot parameter. The default partition layout +in the BSP is set to:

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

This is a bootloader environment variable that is defined here and can be +changed during runtime. From Linux userspace, the NOR Flash partitions are +accessible via /dev/mtd<N> devices where <N> is the MTD device number associated +with the NOR flash partition to access. To find the correct MTD device number +for a partition, run on the target:

+
root@phyboard-pollux-imx8mp-3:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

It lists all MTD devices and the corresponding partition names. The flash node +is defined inside of the SPI master node in the module DTS. The SPI node +contains all devices connected to this SPI bus which is in this case only the +SPI NOR Flash.

+

The definition of the SPI master node in the device tree can be found here:

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n76

+
+
+
+

7.7. GPIOs

+

The phyBOARD-Pollux has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to i.MX 8M Plus pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal i.MX 8M Plus GPIO banks GPIO1 – GPIO5.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO5_07). <X> identifies the GPIO +bank and counts from 1 to 5, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 20 from chip0):

    +
    target:~$ gpioget gpiochip0 20
+
    +
    +
    • +

  • Set the value of GPIO 20 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset --mode=exit gpiochip0 20=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.7.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the defconfig you use in +arch/arm64/configs/ in the linux kernel sources. For our NXP based releases, +this could be for example imx8_phytec_distro.config:

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+
+
+
+

7.8. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the phyBOARD-Pollux.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n229

+
+
+

7.9. I²C Bus

+

The i.MX 8M Plus contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 8M Plus. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our phyBOARD-Pollux.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C1 bus configuration (e.g. imx8mp-phycore-som.dtsi): +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n110

+

General I²C2 bus configuration (e.g. imx8mp-phyboard-pollux-rdk.dts) +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n212

+
+
+

7.10. EEPROM

+

On the phyCORE-i.MX8MP there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issue.

+
+

7.10.1. I2C EEPROM on phyCORE-i.MX8MP

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

The I2C EEPROM on the phyCORE-i.MX8MP SoM is connected to I2C address 0x51 on the I2C-0 +bus. It is possible to read and write directly to the device populated:

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the 4KiB EEPROM (bus: I2C-0 addr: 0x51) with zeros leaving out the EEPROM data use:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM Detection

+

The I2C EEPROM, populated on the phyCORE-i.MX8MP, has a separate ID page that is +addressable over I2C address 0x59 on bus 0 and a normal area that is addressable +over I2C address 0x51 on bus 0. PHYTEC uses this data area of 32 Bytes to store +information about the SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the EEPROM ID page data and the first 256 bytes of the normal area are +deleted, the bootloader will fall back to the phyCORE-i.MX8MP Kit RAM setup, which +is 2GiB RAM.

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

SoMs that are flashed with data format API revision 2 will print out information +about the module in the early stage.

+
+
+

7.10.3. Rescue EEPROM Data

+

The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area.

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1
+
+
+
+

Note

+

If you deleted both EEPROM spaces, please contact our support!

+
+

DT representation, e.g. in phyCORE-i.MX 8M Plus file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n199

+
+
+
+

7.11. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC Wakealarm

+

It is possible to issue an interrupt from the RTC to wake up the system. The +format uses the Unix epoch time, which is the number of seconds since UTC +midnight on 1 January 1970. To wake up the system after 4 minutes from suspend +to ram state, type:

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

Note

+

Internally the wake alarm time will be rounded up to the next minute since +the alarm function doesn’t support seconds.

+
+
+
+

7.11.2. RTC Parameters

+

RTCs have a few abilities which can be read/set with the help of hwclock +tool.

+
    +

  • We can check RTC supported features with:

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x11.
+
    +
    +

    What this value means is encoded in kernel, each set bit translates to:

    +
    #define RTC_FEATURE_ALARM              0
+#define RTC_FEATURE_ALARM_RES_MINUTE   1
+#define RTC_FEATURE_NEED_WEEK_DAY      2
+#define RTC_FEATURE_ALARM_RES_2S       3
+#define RTC_FEATURE_UPDATE_INTERRUPT   4
+#define RTC_FEATURE_CORRECTION         5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE 6
+#define RTC_FEATURE_CNT                7
+
    +
    +
    • +

  • We can check RTC BSM (Backup Switchover Mode) with:

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • We can set RTC BSM with:

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    What BSM values mean translates to these values:

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    Tip

    +

    You should set BSM mode to DSM or LSM for RTC to switch to backup power +source when the initial power source is not available. Check RV-3028 RTC +datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching +Mode) actually mean.

    +
    +
    • +
+

DT representation for I²C RTCs: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n207

+
+
+
+

7.12. USB Host Controller

+

The USB controller of the i.MX 8M Plus SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +‘SS’). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY.

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+

DT representation for USB Host: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n351

+
+
+

7.13. CAN FD

+

The phyBOARD-Pollux has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The two CAN interfaces should show up as +can0 and can1.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    The information for can0 will look like:

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+
+

Warning

+

The mcp2518fd SPI to CANfd supports only baudrates starting from 125kB/s. +Slower rates can be selected but may not work correctly.

+
+

Device Tree CAN configuration of imx8mp-phyboard-pollux-rdk.dts: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n175

+
+
+

7.14. PCIe

+

The phyCORE-i.MX 8M Plus has one Mini-PCIe slot. In general, PCIe autodetects new +devices on the bus. After connecting the device and booting up the system, you +can use the command lspci to see all PCIe devices recognized.

+
    +

  • Type:

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • You will receive:

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

In this example, the PCIe device is the Intel Corporation WiFi Link 5100.

+

For PCIe devices, you have to enable the correct driver in the kernel +configuration. This WLAN card, for example, is manufactured by Intel. The +option for the driver, which must be enabled, is named CONFIG_IWLWIFI and can be +found under Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimat in +the kernel configuration.

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • The linux-imx is represented by: virtual/kernel

      • +
    +
    • +
+

For some devices like the WLAN card, additional binary firmware blobs are +needed. These firmware blobs have to be placed in /lib/firmware/ before the +device can be used.

+
    +

  • Type:

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • For example, if you try to bring up the network interface:

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • You will get the following output on the serial console:

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

Tip

+

Some PCIe devices, e.g. the Ethernet card, may function properly even if no +firmware blob is loaded from /lib/firmware/ and you received an error message +as shown in the first line of the output above. This is because some +manufacturers provide the firmware as a fallback on the card itself. In this +case, the behavior and output depend strongly on the manufacturer’s firmware.

+
+

Device Tree PCIe configuration of imx8mp-phyboard-pollux-rdk.dts: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n287

+
+
+

7.15. Audio

+

Playback devices supported for phyBOARD-Pollux are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals.

+
+

Note

+

Using the PEB-AV-10 connector for display output along HDMI as audio output +is not supported. The audio output device must match the video output device.

+
+

To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices:

+
target:~$ aplay -L
+
+
+

Or type for recording devices:

+
target:~$ arecord -L
+
+
+
+

7.15.1. Alsamixer

+

To inspect the capabilities of your soundcard, call:

+
target:~$ alsamixer
+
+
+

You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. “MM” means the feature is muted +(both output, left & right), which can be toggled by hitting ‘m’. You can also +toggle by hitting ‘<’ for left and ‘>’ for right output. With the tab +key, you can switch between controls for playback and recording.

+
+
+

7.15.2. Restore default volumes

+

There are some default settings stored in /var/lib/alsa/asound.state. +You can save your current alsa settings with:

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

You can restore saved alsa settings with:

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.15.3. ALSA configuration

+

Our BSP comes with a ALSA configuration file /etc/asound.conf.

+

The ALSA configuration file can be edited as desired or deleted since it is not +required for ALSA to work properly.

+
target:~$ vi /etc/asound.conf
+
+
+

To set PEB-AV-10 as output, set playback.pcm from “dummy” to “pebav10”:

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

If the sound is not audible change playback devices to the software volume control +playback devices, set playback.pcm to the respective softvol playback device e.g. +“softvol_pebav10”. Use alsamixer controls to vary the volume levels.

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.15.4. Pulseaudio Configuration

+

For applications using Pulseaudio, check for available sinks:

+
target:~$ pactl list short sinks
+
+
+

To select the output device, type:

+
target:~$ pactl set-default-sink <sink_number>
+
+
+
+
+

7.15.5. Playback

+

Run speaker-test to check playback availability:

+
target:~$ speaker-test -c 2 -t wav
+
+
+

To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds:

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

To playback other formats like mp3 for example, you can use Gstreamer:

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.15.6. Capture

+

arecord is a command-line tool for capturing audio streams which use Line In as +the default input source. To select a different audio source you can +use alsamixer. For example, switch on Right PGA Mixer Mic3R and Left PGA Mixer +Mic3R in order to capture the audio from the microphone input of the +TLV320-Codec using the 3.5mm jack.

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

Hint

+

Since playback and capture share hardware interfaces, it is not possible to +use different sampling rates and formats for simultaneous playback and +capture operations.

+
+

Device Tree Audio configuration: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.15.71_2.2.2-phy3#n58

+
+
+
+

7.16. Video

+
+

7.16.1. Videos with Gstreamer

+

One example video is installed by default in the BSP at /usr/share/qtphy/videos/. +Start the video playback with one of these commands:

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.17. Display

+

The phyBOARD-Pollux supports up to 4 different display outputs. Three can be used +simultaneously. The following table shows the required extensions and devicetree +overlays for the different interfaces.

+ + + + + + + + + + + + + + + + + + + + + + + + + +

Interface

Expansion

devicetree overlay

HDMI

phyBOARD-Pollux

no overlay needed (enabled by default)

LVDS0

PEB-AV-10

imx8mp-phyboard-pollux-peb-av-010.dtbo +(loaded by default)

LVDS1

phyBOARD-Pollux

disabled if PEB-AV-10 overlay is used

MIPI

PEB-AV-12 (MIPI to LVDS)

imx8mp-phyboard-pollux-peb-av-012.dtbo

+
+

Note

+
    +

  • When changing Weston output, make sure to match the audio output as well.

    • +

  • LVDS0 (PEB-AV-10) and LVDS1 (onboard)can not be used at the same time.

    • +
+
+

HDMI is always enabled in the devicetree. The other interfaces can be enabled +with Device Tree Overlay.

+

The default-enabled Interfaces are HDMI and LVDS0 (PEB-AV-010). We support a +10’’ edt,etml1010g0dka display for the PEB-AV-10 and PEB-AV-012.

+
+

Note

+

The current display driver limits the pixel clock for a display connected to +LVDS to 74.25Mhz (or a divider of it). If this does not fit your display +requirements, please contact Support for further help.

+
+
+

7.17.1. Weston Configuration

+

In order to get an output from Weston on the correct display, it still needs to +be configured correctly. This will be done at /etc/xdg/weston/weston.ini.

+
+

7.17.1.1. Single Display

+

In our BSP, the default Weston output is set to HDMI.

+
[output]
+name=HDMI-A-1
+mode=current
+
+[output]
+name=LVDS-1
+mode=off
+
+
+

When using the LVDS0 (PEB-AV-10) as output, set the output mode to off for +HDMI-A-1 and for LVDS-1 to current.

+
[output]
+name=HDMI-A-1
+mode=off
+
+[output]
+name=LVDS-1
+mode=current
+
+
+

If you want to use LVDS1 (onboard) then you need to load no overlay. Remove the +imx8mp-phyboard-pollux-peb-av-xxx.dtbo from bootenv.txt.

+
+
+

7.17.1.2. Dual Display

+
+

Note

+

For dual and triple display output you can not use LVDS1 (onboard) and HDMI +together.

+
+

For dual display in dual view mode at HDMI and LVDS0 (PEB-AV-10), both modes +have to be set to the:

+
[output]
+name=HDMI-A-1
+mode=current
+
+[output]
+name=LVDS-1
+mode=current
+
+
+

For dual display at LVDS0 (PEB-AV-010) and MIPI (PEB-AV-012), both dtbos need to +be loaded at the bootenv.txt and the weston.ini should look like this:

+
[output]
+name=HDMI-A-1
+mode=off
+
+[output]
+name=LVDS-1
+mode=current
+
+
+
+
+

7.17.1.3. Triple Display

+

Three outputs: HDMI, LVDS-1 (PEB-AV-10), and LVDS-2 (PEB-AV-12). Remember to +load both dtbos for LVDS interfaces.

+
[output]
+name=HDMI-A-1
+mode=current
+
+[output]
+name=LVDS-1
+mode=current
+
+[output]
+name=LVDS-2
+mode=current
+
+
+
+
+
+

7.17.2. Qt Demo

+

With the phytec-qt6demo-image, Weston starts during boot. Our Qt6 demo application named +“qtphy” can be stopped with:

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • To start the demo again, run:

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • To disable autostart of the demo, run:

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • To enable autostart of the demo, run:

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston can be stopped with:

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

Note

+

The Qt demo must be closed before Weston can be closed.

+
+
+
+

7.17.3. Backlight Control

+

If a display is connected to the PHYTEC board, you can control its backlight +with the Linux kernel sysfs interface. All available backlight devices in the +system can be found in the folder /sys/class/backlight. Reading the appropriate +files and writing to them allows you to control the backlight.

+
+

Note

+

Some boards with multiple display connectors might have multiple backlight +controls in /sys/class/backlight. For example: backlight0 and backlight1

+
+
    +

  • To get, for example, the maximum brightness level (max_brightness) execute:

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    Valid brightness values are 0 to <max_brightness>.

    +
    • +

  • To obtain the current brightness level, type:

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • Write to the file brightness to change the brightness:

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    turns the backlight off for example.

    +

    For documentation of all files, see +https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight.

    +
    • +
+

Device tree description of LVDS-1 and HDMI can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n264 +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n191

+

The device tree of LVDS-0 on PEB-AV-10 can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.15.71_2.2.2-phy3#n133

+
+
+
+

7.18. Power Management

+
+

7.18.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 8M Plus SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as ‘Dynamic Voltage and +Frequency Scaling’ (DVFS). The i.MX 8M Plus BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the i.MX 8 +variant used, several different frequencies are supported.

+
+

Tip

+

Although the DVFS framework provides frequency settings for each CPU core, a +change in the frequency settings of one CPU core always affects all other CPU +cores too. So all CPU cores always share the same DVFS setting. An individual +DVFS setting for each core is not possible.

+
+
    +

  • To get a complete list type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately +1,6 GHz, the result will be:

    +
    1200000 1600000
+
    +
    +
    • +

  • To ask for the current frequency type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

So-called governors are automatically selecting one of these frequencies in +accordance with their goals.

+
    +

  • List all governors available with the following command:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    The result will be:

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative is much like the ondemand governor. It differs in behavior in +that it gracefully increases and decreases the CPU speed rather than jumping +to max speed the moment there is any load on the CPU.

    • +

  • ondemand (default) switches between possible CPU core frequencies in +reference to the current system load. When the system load increases above a +specific limit, it increases the CPU core frequency immediately.

    • +

  • powersave always selects the lowest possible CPU core frequency.

    • +

  • performance always selects the highest possible CPU core frequency.

    • +

  • userspace allows the user or userspace program running as root to set a +specific frequency (e.g. to 1600000). Type:

    • +

  • In order to ask for the current governor, type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    You will normally get:

    +
    ondemand
+
    +
    +
    • +

  • Switching over to another governor (e.g. userspace) is done with:

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • Now you can set the speed:

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +Documentation/admin-guide/pm/cpufreq.rst.

+
+
+

7.18.2. CPU Core Management

+

The i.MX 8M Plus SoC can have multiple processor cores on the die. The i.MX 8M Plus, for +example, has 4 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    Here the system has four processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.18.3. Suspend to RAM

+

The phyCORE-i.MX8MP supports basic suspend and resume. Different wake-up sources can be +used. Suspend/resume is possible with:

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

To wake up with serial console run

+
target:~$ echo enabled > /sys/class/tty/ttymxc0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.19. Thermal Management

+
+

7.19.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.19.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 8M Plus SoC platform. The i.MX 8 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Industrial +and Commercial.

+ + + + + + + + + + + + + + + + + +

Commercial

Industrial

passive (warning)

85°C

95°C

critical (shutdown)

90°C

100°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise, Fair Share, Bang Bang, and +Userspace. The default policy used in the BSP is step_wise. If the value of the +SoC temperature in the sysfs file temp is above trip_point_0, the CPU frequency +is set to the lowest CPU frequency. When the SoC temperature drops below +trip_point_0 again, the throttling is released.

+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+

7.19.3. GPIO Fan

+
+

Note

+

Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan +to GPIO fan due to availability. The PWM fan will not be supported +anymore and will not function with the new release.

+
+

A GPIO fan can be connected to the phyBOARD-Pollux-i.MX 8M Plus. The SoC only contains one +temperature sensor which is already used by the thermal frequency scaling. The +fan can not be controlled by the kernel. We use lmsensors with hwmon for this +instead. lmsensors reads the temperature periodically and enables or disables +the fan at a configurable threshold. For the phyBOARD-Pollux-i.MX 8M Plus, this is 60°C.

+

The settings can be configured in the configuration file:

+
/etc/fancontrol
+
+
+

Fan control is started by a systemd service during boot. This can be disabled +with:

+
target:~$ systemctl disable fancontrol
+
+
+

The device tree description of GPIO Fan can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n33

+
+
+
+

7.20. Watchdog

+

The PHYTEC i.MX 8M Plus modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.20.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.21. snvs Power Key

+

The X_ONOFF pin connected to the ON/OFF button can be pressed long to trigger +Power OFF without SW intervention or used to wake up the system out of suspend. +With the snvs_pwrkey driver, the KEY_POWER event is also reported to userspace +when the button is pressed. On default, systemd is configured to ignore such +events. The function of Power OFF without SW intervention and the wake-up from +suspend are not configured. Triggering a power off with systemd when pushing the +ON/OFF button can be configured under /etc/systemd/logind.conf and set using:

+
HandlePowerKey=poweroff
+
+
+
+
+

7.22. NPU

+

The i.MX 8M Plus SoC contains a Neural Processing Unit up to 2.3 TOPS as an accelerator +for artificial intelligence operations. Refer to our latest phyCORE-i.MX 8M Plus AI Kit +Guide on the phyCORE-i.MX 8M Plus download section to get information about the +NPU: L-1015e.A1 phyCORE-i.MX 8M Plus AI Kit Guide

+
+
+

7.23. ISP

+

The i.MX 8M Plus SoC contains an Image Signal Processor (ISP). For more information see +Using the ISPs on the phyBOARD-Pollux i.MX 8M Plus documentation. This documentation is also +available in German.

+
+
+

7.24. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 8M Plus provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 8M Plus Reference Manual). The following list is +an abstract from the i.MX 8M Plus Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x30350000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x30350000

Description

OCOTP_MAC_ADDR0

9

0

0x640

contains lower 32 bits +of ENET0 MAC address

OCOTP_MAC_ADDR1

9

1

0x650

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

OCOTP_MAC_ADDR2

9

2

0x660

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 8M Plus Security Reference Manual.

+
+

7.24.1. Reading Fuse Values in uBoot

+

You can read the content of a fuse using memory-mapped shadow registers. To +calculate the memory address, use the fuse Bank and Word in the following +formula:

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.24.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+
+

8. i.MX 8M Plus M7 Core

+

In addition to the Cortex-A53 cores, there is a Cortex-M7 Core as MCU +integrated into the i.MX 8M Plus SoC. Our Yocto-Linux-BSP runs on the A53-Cores and +the M7 Core can be used as a secondary core for additional tasks using +bare-metal or RTOS firmware. +Both cores have access to the same peripherals and thus peripheral +usage needs to be limited either in the M7 Core’s firmware or the devicetree +for the Linux operating system. This section describes how to build firmware +examples and how to run them on phyBOARD-Pollux.

+

The phyBOARD-Pollux is currently supported by the NXP MCUXpresso SDK and by +The Zephyr Project. This section only describes the NXP MCUXpresso SDK because +the MCUXpresso SDK has more supported features at the moment.

+

If you want to use the M7 Core with The Zephyr Project, please refer to the +The Zephyr Project documentation:

+ +
+

8.1. Getting the Firmware Examples

+

The firmware can be built using the NXP MCUxpresso SDK with a compatible +compiler toolchain using command-line tools.

+
+

8.1.1. Getting the Sources

+

The MCUX SDK and the examples for the i.MX 8M Plus can be obtained from PHYTEC’s GitHub +page:

+ +
    +

  1. Initialize the MCUX SDK via west:

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    This will create a mcuxsdk directory with the mcux-sdk repository in it. +The mcux-sdk-phytec-examples repository will be automatically cloned into +the mcuxsdk directory. +The given argument <VERSION> is a the branch name of the mcux-sdk repository +that represents the MCUX SDK version. For the newest tested version +you can use 2.13.0.

    +
    +

    Note

    +

    west is a repository management tool and a part of the Zephyr +Project. +To install west, you can use pip. In this example west is installed in +a python virtual environment:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. Update the dependencies:

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    The directory examples-phytec contains all examples ported and tested +for phyBOARD-Pollux with version 2.13.0 of MCUX.

    +

    To build the firmware, a compiler toolchain and make/cmake are required. +The GNU Arm Embedded Toolchain may be available in your distribution’s +repositories, e.g. for Ubuntu.

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    The compiler toolchain can also be obtained directly from +https://developer.arm.com/. After the archive has been extracted, +the ARMGCC_DIR has to be added to the environment, e.g. for the +ARM toolchain 10-2020-q4-major release located in the home directory:

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. Building the Firmware

+

To build the PHYTEC samples an environment has to be sourced

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

The scripts to build the firmware are located in +<sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc. +There are scripts for each memory location the firmware is supposed to run in, +e.g.

+
host:~$ ./build_release.sh
+
+
+

to build the firmware for the M7 Core’s TCM. The output will be placed under +release/ in the armgcc directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+

To build the firmware for the DRAM, run the script build_ddr_release. +The script of the firmware that is supposed to run, e.g.

+
host:~$ ./build_ddr_release.sh
+
+
+

The output will be placed under ddr_release/ in the armgcc +directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+
+
+
+

8.2. Running M7 Core Examples

+

There are two ways to run the M7 Core with the built firmware, U-Boot and +Remoteproc within a running Linux.

+

To receive debug messages start your favorite terminal software (e.g. Minicom, +Tio, or Tera Term) on your host PC and configure it for 115200 baud, 8 data +bits, no parity, and 1 stop bit (8n1) with no handshake.

+

Once a micro-USB cable is connected to the USB-debug port on the phyBOARD-Pollux, two +ttyUSB devices are registered. One prints messages from A53-Core’s debug UART +and the other one from the M7 Core’s debug UART.

+
+

8.2.1. Running Examples from U-Boot

+

To load firmware using the bootloader U-Boot, the bootaux command can be used:

+
    +

  1. Prepare an SD Card with our Yocto-BSP

    2. +

  2. Copy the generated .bin file to the SD Cards first partition

    3. +

  3. Stop the autoboot by pressing any key

    4. +

  4. Type the command depending on the type of firmware:

    5. +
+

For firmware built to run in the M7 Core’s TCM:

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

For firmware built to run in the DRAM:

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

The program’s output should appear on the M7 Core’s debug UART.

+
+
+

8.2.2. Running Examples from Linux using Remoteproc

+

Remoteproc is a module that allows you to control the M7 Core from Linux +during runtime. Firmware built for TCM can be loaded and the execution started +or stopped. To use Remoteproc a devicetree overlay needs to be set:

+

Edit the bootenv.txt file located in the /boot directory on the target by +adding imx8mp-phycore-rpmsg.dtbo:

+
overlays=imx8mp-phycore-rpmsg.dtbo
+
+
+

Restart the target and execute in U-Boot:

+
u-boot=> run prepare_mcore
+
+
+

Firmware .elf files for the M7 Core can be found under /lib/firmware. +To load the firmware, type:

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

To load a different firmware, the M7 Core needs to be stopped:

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

Note

+

The samples found in /lib/firmware on the target come from NXP’s +Yocto layer meta-imx. +To use the samples you built yourself through MCUX SDK, please copy them +to /lib/firmware on the target after building them.

+
+
+ +
+
+
+

9. BSP Extensions

+
+

9.1. Chromium

+

Our BSP for the phyBOARD-Pollux-i.MX 8M Plus supports Chromium. You can include it in the +phytec-qt6demo-image with only a few steps.

+
+

9.1.1. Adding Chromium to Your local.conf

+

To include Chromium you have to add the following line into your local.conf. You +can find it in <yocto_dir>/build/conf/local.conf. This adds Chromium to your +next image build.

+
IMAGE_INSTALL:append = " chromium-ozone-wayland"
+
+
+
+

Note

+

Compiling Chromium takes a long time.

+
+
+
+

9.1.2. Get Chromium Running on the Target

+

To run Chromium, it needs a few arguments to use the hardware graphics +acceleration:

+
target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox
+
+
+

If you want to start Chromium via SSH, you must first define the display on +which Chromium will run. For example:

+
target$ DISPLAY=:0
+
+
+

After you have defined this, you can start it via virtual terminal on Weston as +shown above.

+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mp/pd24.1.0_nxp.html b/previews/271/bsp/imx8/imx8mp/pd24.1.0_nxp.html new file mode 100644 index 000000000..7fcbabbac --- /dev/null +++ b/previews/271/bsp/imx8/imx8mp/pd24.1.0_nxp.html @@ -0,0 +1,4904 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + + + + + +

PD24.1.0 NXP i.MX 8M Plus BSP +Manual

Document Title

PD24.1.0 NXP i.MX 8M Plus BSP +Manual

Document Type

BSP Manual

Article Number

PD24.1.0 NXP

Yocto Manual

Scarthgap

Release Date

2024/11/08

Is Branch of

PD24.1.0 NXP i.MX 8M Plus BSP +Manual

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-NXP-i.MX8MP-PD24.1.0

Major

2024/11/06

Released

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +phyCORE-i.MX8M Plus Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads of our product.

+
+

1.1. Supported Hardware

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-NXP-i.MX8MP-PD24.1.0 download.

+

If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware

+
+

1.1.1. phyBOARD-Pollux Components

+
+../../../_images/phyBOARD-Pollux-front-components.jpg + +
+

phyBOARD-Pollux Components (top)

+
+
+
+../../../_images/phyBOARD-Pollux-back-components.jpg + +
+

phyBOARD-Pollux Components (bottom)

+
+
+
+
+
+
+

2. Getting Started

+

The phyCORE-i.MX8M Plus Kit is shipped with a pre-flashed SD card. It contains the +phytec-qt6demo-image and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+

There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool dd. An +alternative way is to use PHYTEC’s system initialization program called +partup, which makes it especially easy to +format more complex systems. You can get prebuilt Linux binaries of partup from its release page. Also read +partup’s README for installation +instructions.

+
+

2.1. Get the Image

+

The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using dd, can be downloaded from the PHYTEC download server.

+

Get either the partup package or the WIC image from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+
+

Note

+

For eMMC, more complex partitioning schemes or even just large images, we +recommend using the partup package, as it is faster in writing than dd +and allows for a more flexible configuration of the target flash device.

+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card, you must have root privileges on your Linux +host PC. Be very careful when specifying the destination device! All files +on the selected device will be erased immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system on your host PC!

+
+
+

2.2.1. Finding the Correct Device

+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+

Unmount all those partitions, e.g.:

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

Now, the SD card is ready to be flashed with an image, using either partup, +dd or bmap-tools.

+
+
+

2.2.2. Using bmap-tools

+

One way to prepare an SD card is using +bmap-tools. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host:~$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

Replace <your_device> with your actual SD card’s device name found previously, +and make sure to place the file <IMAGENAME>-<MACHINE>.wic.bmap alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip.

+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.2.3. Using partup

+

Writing to an SD card with partup is done in a single command:

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).partup /dev/<your_device>
+
+
+

Make sure to replace <your_device> with your actual device name found previously.

+

Further usage of partup is explained at its official documentation website.

+
+

Warning

+

Host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to write partup packages created with Yocto Mickledore +or newer to SD-Card. This is due to a new default option in resize2fs which causes an +incompatibility. See release notes.

+
+
+

Note

+

partup has the advantage of allowing to clear specific raw areas in the +MMC user area, which is used in our provided partup packages to erase any +existing U-Boot environments. This is a known issue bmaptool does not +solve, as mentioned in the previous chapter.

+

Another key advantage of partup over other flashing tools is that it allows +configuring MMC specific parts, like writing to eMMC boot partitions, without +the need to call multiple other commands when writing.

+
+
+
+

2.2.4. Using dd

+

After having unmounted all SD card’s partitions, you can create your bootable SD card.

+

Some PHYTEC BSPs produce uncompressed images (with filename-extension *.wic), +and some others produce compressed images (with filename-extension *.wic.xz).

+

To flash an uncompressed images (*.wic) use command below:

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Or to flash a compressed images (*.wic.xz) use that command:

+
host:~$ xzcat phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Again, make sure to replace <your_device> with your actual device name found +previously.

+

The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

+
+
+
+

2.3. First Start-up

+ +../../../_images/SD_Card_Boot2.png +
    +

  • Insert the SD card

    • +

  • Connect the target and the host with mirco USB on (X1) +debug USB

    • +

  • Power up the board

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (scarthgap).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (scarthgap).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-IMX8MP; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-xwayland MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD24.1.0
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the phyboard-pollux-imx8mp-3 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx8mp.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, +lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY firmware images

    • +

  • imx-boot: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM +Trusted Firmware and DDR firmware. This is the final bootloader image which is +bootable.

    • +

  • fitImage: Linux kernel FIT image

    • +

  • fitImage-its*.its

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx8mp-phyboard-pollux-rdk*.dtb: Kernel device tree file

    • +

  • imx8mp-phy*.dtbo: Kernel device tree overlay files

    • +

  • phytec-qt6demo-image*.tar.gz: Root file system

    • +

  • phytec-qt6demo-image*.rootfs.wic.xz: compressed SD card image

    • +
+
+
+
+
+

4. Installing the OS

+
+

4.1. Bootmode Switch (S3)

+
+

Tip

+

Hardware revision baseboard: 1552.2

+
+

The phyBOARD-Pollux features a boot switch with four individually switchable ports to +select the phyCORE-i.MX 8M Plus default bootsource.

+ + + + + + + + + + + +
+../../../_images/eMMC2.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses2.png +
+

Internal Fuses

+
+
+
+../../../_images/SPI_NOR2.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download3.png +
+

USB Serial Download

+
+
+
+../../../_images/SD_Card_Boot2.png +
+

SD Card

+
+
+
+../../../_images/Test_Mode.png +
+

Test Mode

+
+
+
+
+
+

4.2. Flash eMMC

+

For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see Setup Network Host.

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S3) is set to eMMC.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk2p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from Network

+

i.MX 8M Plus boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

4.2.1.1. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Show your available image files on the host:

+
host:~$ ls /srv/tftp
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
+
+

Send the image with the bmaptool command combined with ssh through the network +to the eMMC of your device:

+
host:~$ scp /srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2"
+
+
+
+
+

4.2.1.2. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Take a compressed or decompressed image with the accompanying block map file +*.bmap on the host and send it with ssh through the network to the eMMC of +the target with a one-line command:

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.* /tmp && bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
+
+
+
+

4.2.1.3. Flash eMMC from Network in U-Boot on Target

+

These steps will show how to update the eMMC via a network.

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE.

+
+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Uncompress your image

+
host:~$ unxz /srv/tftp/phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+

Load your image via network to RAM:

+
    +

  • when using dhcp

    +
    u-boot=> dhcp phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.1 (1 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.1
+Filename 'phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • when using a static ip address (serverip and ipaddr must be set +additionally).

    +
    u-boot=> tftp ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
+
+
+
+
+

4.2.2. Flash eMMC U-Boot image via Network from running U-Boot

+

Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.3. Flash eMMC from USB stick

+
+

4.2.3.1. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.|yocto-imageext|). Set the bootmode switch (S3) to SD Card.

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ ls /mnt
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without partition):

    +
    target:~$ bmaptool copy /mnt/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Tip

    +

    Before this will work, you need to configure the bootmode switch (S3) to +eMMC.

    +
    +
    • +
+
+
+

4.2.3.2. Flash eMMC from USB stick in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE.

+
+

These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch (S3) to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied uncompressed WIC image to +the USB slot.

+

Load your image from the USB device to RAM:

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 0x58000000 phytec-headless-image-|yocto-machinename|.rootfs.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write 0x58000000 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+
+

4.2.4. Flash eMMC from SD Card

+

Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (*.wic) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see Resizing ext4 Root Filesystem.

+

Alternatively, flash a partup package to the SD card, as described in +Getting Started. This will ensure the full space of the SD card is used.

+
+

4.2.4.1. Flash eMMC from SD card in Linux on Target

+

You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card.

+
    +

  • Show your saved partup package or WIC image files on the SD card:

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without +partition) using partup:

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup /dev/mmcblk2
+
    +
    +

    Flashing the partup package has the advantage of using the full capacity of +the eMMC device, adjusting partitions accordingly.

    +
    +

    Note

    +

    Alternatively, bmaptool may be used instead:

    +
    target:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
    +
    +

    Keep in mind that the root partition does not make use of the full space when +flashing with bmaptool.

    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Warning

    +

    Before this will work, you need to configure the bootmode switch (S3) to eMMC.

    +
    +
    • +
+
+
+

4.2.4.2. Flash eMMC from SD card in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE. If the +image file is too large use the Updating eMMC from SD card in +Linux on Target subsection.

+
+
    +

  • Flash an SD card with a working image and create a third ext4 partition. Copy +the WIC image (for example phytec-qt6demo-image.rootfs.wic) to this +partition.

    • +

  • Configure the bootmode switch (S3) to SD Card and insert the SD Card.

    • +

  • Power on the board and stop in U-Boot.

    • +

  • Load the image:

    +
    u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • Switch the mmc dev to eMMC:

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • Flash your WIC image (for example phytec-qt6demo-image.rootfs.wic) +from the SD card to eMMC. This will partition the card and copy imx-boot, +Image, dtb, dtbo, and root file system to eMMC.

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • Power off the board and change the bootmode switch (S3) to eMMC.

    • +
+
+
+
+
+

4.3. Flash SPI NOR Flash

+

The phyCORE-i.MX8MP modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set bootmode switch (S3) to SPI NOR. The SPI Flash is usually quite small. +The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash populated. Only the +bootloader and the environment can be stored. The kernel, device tree, and file +system are taken from eMMC by default.

+

The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with:

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. Flash SPI NOR Flash from Network

+

The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-i.MX 8M Plus.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+
+

4.3.1.1. Flash SPI NOR from Network in kernel on Target

+
    +

  • Copy the image from the host to the target:

    +
    host:~$ scp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • Find the number of blocks to erase of the U-boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the U-Boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.1.2. Flash SPI NOR from Network in U-Boot on Target

+

Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI NOR flash needs to be probed:

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • A specially formatted U-Boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image over tftp, erase and write the +bootloader to the flash:

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+

4.3.2. Flash SPI NOR Flash from SD Card

+

The bootloader on SPI NOR flash can be also flashed with SD Card.

+
+

4.3.2.1. Flash SPI NOR from SD Card in kernel on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi to the first partition +on the SD Card.

    • +

  • Mount the SD Card:

    +
    target:~$ mount /dev/mmcblk1p1 /mnt
+
    +
    +
    • +

  • Find the number of blocks to erase of the U-Boot partition:

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • Erase the u-boot partition and flash it:

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.2.2. Flash SPI NOR from SD Card in U-Boot on Target

+
    +

  • Copy the SPI NOR flash U-boot image +imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi to the first partition +on the SD Card.

    • +

  • Before reading and writing are possible, the SPI-NOR flash +needs to be probed:

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • A specially formatted U-boot image for the SPI NOR flash is used. Ensure you +use the correct image file. Load the image from the SD Card, erase and write +the bootloader to the flash:

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • Erase the environment partition as well. This way, the environment can be +written after booting from SPI NOR flash:

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A6 RAUC Update & Device Management Manual.

+
+
+

4.5. EFI Boot

+

Standardboot in U-Boot also supports booting distros over efi. By default the +U-Boot will search for a bootscript first, which is used to boot our Ampliphy +distro. If it does not find any bootscript, it will search for bootable efi +applications. So for booting over efi just make sure you don’t have our distro +installed.

+
+

4.5.1. Disable booting with efi

+

To disable booting with efi you have to set the doefiboot variable to 0. +Also make sure you do not have efi or efi_mgr specified in the +bootmeths environment variable.

+
u-boot=> setenv doefiboot 0
+u-boot=> env save; env save;
+
+
+
+
+

4.5.2. Switch to only efi boot

+

If you want to only boot with efi, you can set the bootmeths environment +variable to efi. Also make sure you have the doefiboot environment variable +set to 1.

+
u-boot=> setenv bootmeths efi
+u-boot=> env save; env save;
+
+
+
+
+

4.5.3. Installing a distro

+

With efi you can install and boot different distros like openSUSE, Fedora or +Debian. First you have to get the iso Image from their website. For example:

+

https://cdimage.debian.org/debian-cd/current/arm64/iso-dvd/

+

Then copy the .iso file to a usb stick for example. Make sure you select the +correct device:

+
sudo dd if=file.iso of=/dev/sdx bs=1M conv=fsync status=progress
+
+
+

Insert the USB stick into the board and boot it. GRUB will then prompt you with +a menu where you can select what to do. Here select install. Then you have to +click through the installation menu. This is relatively straightforward and +differs a bit for every distro. You can install the distro for example to emmc +(mmc 2) or sdcard (mmc 1). Make sure you do not overwrite +your U-Boot during the install. Best to choose a different medium to install to +than the U-Boot is stored on. Otherwise manual partitioning will be required. +The automatic partitioning will start at the beginning of the disk. To not +overwrite the U-Boot, use an offset of 4MiB at the beginning of the disk.

+

During the Installation of Debian you will be asked, if you want to Force the +GRUB installation to the EFI removable media path. Select no. Also select no, +when you will be asked if you want to update the NVRAM variables. Otherwise the +grub-dummy installation step will fail and you will be sent back to the +“Force GRUB installation” prompt.

+

After the installation is complete, reboot the board and remove the +installation medium (USB-stick). The board should then boot the distro you +installed.

+

If that does not happen, check if there is a boot option set for the distro. +The easiest way is with the eficonfig command.

+
u-boot=> eficonfig
+
+
+

That will open a menu. Then you can select Edit Boot Option. It will show +you the current boot options. If this is empty or you don’t find your distro, +select Add Boot Option to add a new one. For debian for example you only +need to set the description and the file. You can enter whatever you want into +the description field. When you select the file field, you can select the disc +you installed the distro on and partition number one. For example +“mmc 2:1” for emmc, or “mmc 1:1” for sdcard. The file you +need to select is at EFI/debian/grubaa64.efi. After that save, quit and +reset the board. The board should then boot into debian.

+
+
+
+
+

5. Development

+

Starting with this release, the boot behaviour in U-Boot changes. Before, kernel +and device tree came as separate blobs. Now, both will be included in a single +FIT image blob. Further, the logic for booting the PHYTEC ampliphy distributions +is moved to a boot script which itself is part of a separate FIT image blob. +To revert to the old style of booting, you may do

+
run legacyboot
+
+
+
+

Note

+

This way of booting is deprecated and will be removed in the next release. +By default, booting via this command will return an error as kernel and +device tree are missing in the boot partition.

+
+
+

5.1. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone git://git.phytec.de/u-boot-imx)

+
+
+

5.1.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-imx and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    https://github.com/phytec/linux-phytec-imx
+
    +
    +
    • +

  • Our i.MX 8M Plus kernel is based on the linux-phytec-imx kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.1.2. Get the SDK

+

You can download the SDK here, or build it yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

After a successful build the SDK installer is deployed to build/deploy*/sdk.

+
+
+

5.1.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.x.sh
+host:~$ ./phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.x.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-xwayland/5.0.x):
+You are about to install the SDK to "/opt/ampliphy-vendor-xwayland/5.0.x". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.1.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.1.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.2. U-Boot standalone build

+
+

5.2.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag used in this release is called v2024.04_2.0.0-phy7

    • +

  • Check out the needed U-Boot tag:

    +
    host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2024.04_2.0.0-phy7
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.2.2. Get the needed binaries

+

To build the bootloader, you need to copy these files to your u-boot-imx +build directory and rename them to fit with mkimage script:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx8mp.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +
+

If you already built our BSP with Yocto, you can get the +bl31-imx8mp.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: BSP Images

+

Or you can download the files here: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/

+
+

Warning

+

Make sure you rename the files you need so that they are compatible with the +mkimage tool.

+
+
+
+

5.2.3. Build the bootloader

+
    +

  • build flash.bin (imx-boot):

    +
    host:~/u-boot-imx$ make phycore-imx8mp_defconfig
+host:~/u-boot-imx$ make flash.bin
+
    +
    +
    • +
+
+
+

5.2.4. Flash the bootloader to a block device

+

The flash.bin can be found at u-boot-imx/ directory and now can be +flashed. A chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

E.g. flash SD card:

+
host:~/u-boot-imx$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables +“BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+

5.2.5. Build U-Boot With a Fixed RAM Size

+

If you cannot boot your system anymore because the hardware introspection in the +EEPROM is damaged or deleted, you can create a flash.bin with a fixed ram size. +You should still contact support and flash the correct EEPROM data, as this +could lead to unexpected behavior.

+

Follow the steps to get the U-boot sources and check the correct branch in the +Build U-Boot section.

+

Edit the file configs/phycore-imx8mp_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+
+
+

Choose the correct RAM size as populated on the board and uncomment the line for +this ram size. +After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+

5.2.6. Build U-Boot With a Fixed RAM Size and Frequency

+

Starting with PD23.1.0 NXP or PD24.1.2 mainline release, the phyCORE-i.MX 8M Plus SoMs +with revision 1549.3 and newer also support 2GHz RAM timings. These will be +enabled for supported boards automatically, but they can also be enabled or +disabled manually.

+

Edit the file configs/phycore-imx8mp_defconfig. +The fixed RAM size with 2GHz timings will be used:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+CONFIG_PHYCORE_IMX8MP_RAM_FREQ_FIX=y
+CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+
+
+

After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+

5.2.7. Build U-Boot With a Fixed RAM Frequency

+

Starting with PD24.1.2 mainline release or PD24.1.0 NXP release, U-Boot can +also be built with just fixed RAM Frequency while the RAM size will still be +used from EEPROM.

+

Edit the file configs/phycore-imx8mp_defconfig. +The RAM size from EEPROM with fixed frequency will be used:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_FREQ_FIX=y
+# CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+# CONFIG_PHYCORE_IMX8MP_USE_1_5GHZ_RAM_TIMINGS=y
+
+
+

After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+
+

5.3. Kernel standalone build

+

The kernel is packaged in a FIT image together with the device tree. U-Boot has +been adapted to be able to load a FIT image and boot the kernel contained in it. +As a result, the kernel Image has to packaged in a FIT image.

+
+

5.3.1. Setup sources

+
    +

  • The used linux-phytec-imx branch can be found in the release notes

    • +

  • The tag needed for this release is called v6.6.23-2.0.0-phy10

    • +

  • Check out the needed linux-phytec-imx tag:

    +
    host:~$ git clone https://github.com/phytec/linux-phytec-imx
+host:~$ cd ~/linux-phytec-imx/
+host:~/linux-phytec-imx$ git fetch --all --tags
+host:~/linux-phytec-imx$ git checkout tags/v6.6.23-2.0.0-phy10
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-phytec-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-phytec-imx$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.3.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-phytec-imx$ make imx8_phytec_defconfig
+host:~/linux-phytec-imx$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-phytec-imx/arch/arm64/boot/Image.gz

    • +

  • The dtb can be found at +~/linux-phytec-imx/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-phytec-imx$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.3.3. Package the kernel in a FIT image

+

To simply replace the kernel, you will need an image tree source (.its) +file. If you already built our BSP with Yocto, you can get the its file from the +directory mentioned here: BSP Images Or you can download the file here: +https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/

+

Copy the .its file to the current working directory, create a link to the kernel +image and create the final fitImage with mkimage.

+
host:~/linux-phytec-imx$ cp /path/to/yocto/deploydir/fitimage-its*.its .
+                  && ln -s arch/arm64/boot/Image.gz linux.bin
+                  && uboot-mkimage -f fitImage-its*.its fitImage
+
+
+
+
+

5.3.4. Copy FIT image and kernel modules to SD Card

+

When one-time boot via netboot is not sufficient, the FIT image along with the +kernel modules may be copied directly to a mounted SD card.

+
host:~/linux-phytec-imx$ cp fitImage /path/to/sdcard/boot/
+host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.4. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.4.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.4.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy-ampliphy-vendor-xwayland/images/phyboard-pollux-imx8mp-3/. For flashing a wic image to eMMC, +you will also need phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.

+
+
+

5.4.3. Prepare Target

+

Set the bootmode switch (S3) to USB Serial Download. Also, connect USB port +X5 (upper connector) to your host.

+
+
+

5.4.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via (X1), as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.4.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.4.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
+
+
+
+

5.4.7. Flashing SPI NOR Flash via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b qspi imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+
+
+

This will update the U-Boot on SPI NOR Flash but not the environment. You may need to erase the old +environment so the default environment of the new U-Boot gets loaded:

+
u-boot=> env erase
+u-boot=> reset
+
+
+
+
+
+

5.5. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.5.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.5.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.5.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.6. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.6.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel fitimage to your tftp directory:

    +
    host:~$ cp fitImage /srv/tftp
+
    +
    +
    • +

  • Copy the bootscript to your tftp directory:

    +
    host:~$ cp boot.scr.uimg /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.6.2. Set the bootenv.txt for Netboot

+

Create a bootenv.txt file in your tftp directory and write the following variables into it.

+
nfsroot=/srv/nfs
+overlays=<overlayconfignames>
+
+
+

<overlayconfignames> has to be replaced with the devicetree overlay config names that you want to use. +Separate the config names by hashtag. For example:

+
overlays=conf-example-overlay1.dtbo#conf-example-overlay2.dtbo
+
+
+
+

Tip

+

All supported devicetree overlays are in the device tree chapter. Or can be printed with:

+
host:~$ dumpimage -l fitImage
+
+
+
+
+
+

5.6.3. Network Settings on Target

+

To customize the targets ethernet configuration, please follow the description +here: Network Environment Customization

+
+
+

5.6.4. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> setenv boot_targets ethernet
+u-boot=> bootflow scan -lb
+
    +
    +
    • +
+
+
+
+

5.7. Accessing the Development states

+
+

5.7.1. Development state of current release

+

These release manifests exist to give you access to the development states +of the Yocto BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line:

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD24.1.y
+
+
+

This will initialize a BSP that will track the latest development state of the +current release (BSP-Yocto-NXP-i.MX8MP-PD24.1.0). From now on repo sync in this folder +will pull all the latest changes from our Git repositories:

+
host:~$ repo sync
+
+
+
+
+

5.7.2. Development state of upcoming release

+

Also development states of upcoming releases can be accessed this way. +For this execute the following command and look for a release with a higher +PDXX.Y number than the latest one (BSP-Yocto-NXP-i.MX8MP-PD24.1.0) and .y at the +end:

+
host:~$ ./phyLinux init -p imx8mp
+
+
+
+
+
+

5.8. Accessing the Latest Upstream Support

+

We have a vanilla manifest that makes use of the Yocto master branches (not an +NXP release), Linux, and U-Boot. This can be used to test the latest upstream +kernel/U-Boot.

+
+

Note

+

The master manifest reflects the latest state of development. This tends to +be broken from time to time. We try to fix the master on a regular basis.

+
+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.9.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+

5.10. Switch back to legacyboot

+
+

Warning

+

As we switched to standardboot with fitimage as default, legacyboot is +deprecated. We kept the option to switch back to legacyboot for this +release, but it will be removed in the future.

+
+
+

5.10.1. Changes in Yocto

+

By default, the fitImage and bootscript will be deployed into the wic.xz Image. +To switch back to legacyboot, you need to replace the fitImage and bootscript +for the kernel image and the devicetrees. They are still in the deploy +folder from the Yocto build, so you can manually copy them to the boot +partition on your device. Otherwise you can do the following changes in Yocto +to get the kernel and devicetrees deployed in the Image again.

+

First create the variable KERNEL_DEVICETREE_DEPLOY. This can be done for +example in the local.conf file in your build directory conf/local.conf. +The variable is basically a copy of the KERNEL_DEVICETREE variable that is +set in conf/machine/phyboard-pollux-imx8mp-3.conf in meta-phytec but the freescale +at the beginning needs to be removed, so that only the devicetree filename are +left. In the end it should look something like this:

+
KERNEL_DEVICETREE_DEPLOY = " \
+     imx8mp-phyboard-pollux-rdk.dtb \
+     imx8mp-phyboard-pollux-isp-csi1.dtbo \
+     imx8mp-phyboard-pollux-isp-csi2.dtbo \
+     imx8mp-phyboard-pollux-isi-csi1.dtbo \
+     imx8mp-phyboard-pollux-isi-csi2.dtbo \
+     imx8mp-phyboard-pollux-peb-av-10.dtbo \
+     imx8mp-phyboard-pollux-peb-wlbt-05.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2-fpdlink-port1.dtbo \
+     imx8mp-phycore-no-eth.dtbo \
+     imx8mp-phycore-no-rtc.dtbo \
+     imx8mp-phycore-no-spiflash.dtbo \
+     imx8mp-phycore-rpmsg.dtbo \
+"
+
+
+

Then add this line:

+
IMAGE_BOOT_FILES:mx8m-nxp-bsp:append = " Image oftree ${KERNEL_DEVICETREE_DEPLOY}"
+
+
+
+

Note

+

A clean might be required for this to work.

+
bitbake -c cleanall phytec-qt6demo-image
+
+
+
+

Then start the build:

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

5.10.2. Changes in U-Boot environment

+

To re-enable legacyboot set the following variable:

+
uboot=> setenv dolegacyboot 1
+uboot=> env save; env save;
+uboot=> boot
+
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 8M Plus SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Board.dts - include the module dtsi file. Devices that come from the i.MX 8M Plus +SoC but are just routed down to the carrier board and used there are included +in this dts.

    • +

  • Overlay.dtso - enable/disable features depending on optional hardware that +may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10)

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 8 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the folder arch/arm64/boot/dts/freescale/.

+

Available overlays for phyboard-pollux-imx8mp-3.conf are:

+
imx8mp-isi-csi1.dtbo
+imx8mp-isi-csi2.dtbo
+imx8mp-isp-csi1.dtbo
+imx8mp-isp-csi2.dtbo
+imx8mp-phyboard-pollux-peb-av-10.dtbo
+imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+imx8mp-phycore-no-eth.dtbo
+imx8mp-phycore-no-rtc.dtbo
+imx8mp-phycore-no-spiflash.dtbo
+imx8mp-phycore-rpmsg.dtbo
+imx8mp-vm016-csi1.dtbo
+imx8mp-vm016-csi1-fpdlink.dtbo
+imx8mp-vm016-csi2.dtbo
+imx8mp-vm016-csi2-fpdlink.dtbo
+imx8mp-vm017-csi1.dtbo
+imx8mp-vm017-csi1-fpdlink.dtbo
+imx8mp-vm017-csi2.dtbo
+imx8mp-vm017-csi2-fpdlink.dtbo
+
+
+

Otherwise you can show the content of a FIT image including all overlay +configs in the FIT image with this command in Linux:

+
host:~$ dumpimage -l /boot/fitImage
+
+
+

or in U-Boot:

+
u-boot=> load mmc ${mmcdev}:1 ${loadaddr} fitImage
+u-boot=> iminfo
+
+
+

The usage of overlays can be configured during runtime in Linux or U-Boot. +Overlays are applied during the boot process in the bootloader after the +boot command is called and before the kernel is loaded. The next sections +explain the configuration in more detail.

+
+

6.2.2.1. Set ${overlays} variable

+

The ${overlays} U-Boot environment variable contains a number-sign (#) +separated list of overlays that will be applied during boot. The overlays +listed in the overlays variable must be included in the FIT image. Overlays set +in the $KERNEL_DEVICETREE Yocto machine variable will automatically be added to +the FIT image.

+

The ${overlays} variable can either be set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +When desired to use the overlays variable as set manually in the U-Boot +environment, disable bootenv by setting env set no_bootenv 1 as the overlays +variable may be overwritten during the execution of the boot script. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=conf-imx8mp-phyboard-pollux-rdk-peb-eval-01.dtbo#conf-imx8mp-phyboard-pollux-peb-av-10.dtbo
+
+
+

Changes will take effect after the next reboot. If no bootenv.txt file is +available the overlays variable can be set directly in the U-Boot environment.

+
u-boot=> setenv overlays conf-imx8mp-phyboard-pollux-peb-av-10.dtbo
+u-boot=> printenv overlays
+overlays=conf-imx8mp-phyboard-pollux-peb-av-10.dtbo
+u-boot=> boot
+
+
+

If a user defined ${overlays} variable should be directly loaded from U-Boot +environment but there is still an external bootenv.txt available, the ${no_bootenv} +variable needs to be set as a flag:

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays conf-imx8mp-phyboard-pollux-peb-av-10.dtbo
+u-boot=> boot
+
+
+

More information about the external environment can be found in +U-boot External Environment subsection of the +device tree overlay section.

+

We use the ${overlays} variable for overlays describing expansion boards and +cameras that can not be detected during run time. To prevent applying overlays +unset the overlays variable and set no_bootenv to anything other than 0.

+
u-boot=> env delete overlays
+u-boot=> env set no_bootenv 1
+
+
+

If desired to use the bootenv.txt file for setting U-Boot variables other than +overlays and having overlays disabled, remove the overlays definition line from +the bootenv.txt file instead of setting no_bootenv.

+
+
+

6.2.2.2. SoM Variants

+

Additional overlays are applied automatically to disable components that are not +populated on the SoM. The detection is done with the EEPROM data (EEPROM SoM +Detection) found on the SoM i2c EEPROM.

+

It depends on the SoM variant if any device tree overlays will be applied. To check +if an overlay will be applied on the running SoM in U-Boot, run:

+
u-boot=> env print fit_extensions
+
+
+

If the EEPROM data is not available, no device tree overlays are applied.

+

To prevent application of the SoM variant related overlays the +${no_extensions} variable can be set to 1 in the bootloader environment:

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot External Environment

+

During the start of the Linux Kernel the external environment bootenv.txt +text file will be loaded from the boot partition of an MMC device or via TFTP. +The main intention of this file is to store the ${overlays} variable. This makes +it easy to pre-define the overlays in Yocto depending on the used machine. The +content from the file is defined in the Yocto recipe bootenv found in +meta-phytec: +https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=scarthgap

+

Other variables can be set in this file, too. They will overwrite the existing +settings in the environment. But only variables evaluated after issuing the boot +command can be overwritten, such as ${nfsroot} or ${mmcargs}. Changing other +variables in that file will not have an effect. See the usage during netboot as +an example.

+

If the external environment can not be loaded the boot process will be anyway +continued with the values of the existing environment settings.

+
+
+

6.2.4. Change U-boot Environment from Linux on Target

+

Libubootenv is a tool included in our images to modify the U-Boot environment of +Linux on the target machine.

+

Print the U-Boot environment using the following command:

+
target:~$ fw_printenv
+
+
+

Modify a U-Boot environment variable using the following command:

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

Caution

+

Libubootenv takes the environment selected in a configuration file. The +environment to use is inserted there, and by default it is configured to use +the eMMC environment (known as the default used environment).

+

If the eMMC is not flashed or the eMMC environment is deleted, libubootenv +will not work. You should modify the /etc/fw_env.config file to match the +environment source that you want to use.

+
+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 8M Plus BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 8M Plus BSP Device Tree Concept to get an understanding +of our i.MX 8 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 8 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 8M Plus Pin Muxing

+

The i.MX 8M Plus SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 8M Plus terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 8M Plus Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx8mp-phyboard-pollux-rdk.dts:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x140
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x140
+        >;
+};
+
+
+

The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled.

+

The device tree representation for UART1 pinmuxing: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L373

+
+
+

7.2. RS232/RS485

+

The phyCORE-i.MX 8M Plus supports up to 4 UART units. On the phyBOARD-Pollux, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector X2 at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers JP3 and +JP4 on the baseboard. For more information about the correct setup please +refer to the phyCORE-i.MX 8M Plus/phyBOARD-Pollux Hardware Manual section UARTs.

+

We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers JP3 and JP4 need to be set +correctly.

+
+

7.2.1. RS232

+
    +

  • Display the current settings of a terminal in a human-readable format:

    +
    target:~$ stty -a
+
    +
    +
    • +

  • Configuration of the UART interface can be done with stty. For example:

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • With a simple echo and cat, basic communication can be tested. Example:

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

The host should print out “123”.

+
+
+

7.2.2. RS485

+
+

Hint

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

For easy testing, look at the linux-serial-test. This tool is called the IOCTL +for RS485 and sends a constant stream of data.

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

More information about the linux-serial-test tool and its parameters can be +found here: linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Documentation for calling the IOCTL within c-code is described in the Linux +kernel documentation: +https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection3.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see “test” printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final “count for this session”. There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+
+
+

7.2.2.2. RS485 full-duplex

+

For full-duplex mode your connection setup should look like this:

+../../../_images/RS485_fullduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For full-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 1
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  true
+Bus termination enabled:  false
+
+
+

Also here you can do the echo test to see if sending and receiving works:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see “test” printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

To check if the full-duplex operation works, you need to use the +linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=114660, tx=118755, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=118755, tx=114660, rx err=0
+
+
+

In this example both targets will send and receive simultaneously. They will +receive for 15sec and send for 10sec. The receiver needs to receive a bit +longer, so that all sent messages will get received. Remember to start both +targets almost simultaneously. A small difference in start time is accounted +for with the -W 2 option. At the end the program will print the final +“count for this session”. There you can check that all transmitted frames were +received.

+

All the test examples are target to target, but can also be done with host to +target with a USB to rs485 converter. You may need to adjust the interfaces for +commands to work on the host then.

+

The device tree representation for RS232 and RS485: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L412

+
+
+
+
+

7.3. Network

+

phyBOARD-Pollux-i.MX 8M Plus provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board.

+
+

Warning

+

The naming convention of the Ethernet interfaces in the hardware (ethernet0 +and ethernet1) do not align with the network interfaces (eth0 and eth1) in +Linux. So, be aware of these differences:

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L50.

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Pollux can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L179.

+
+

7.3.1. Network Environment Customization

+
+

7.3.1.1. U-boot network-environment

+
    +

  • To find the Ethernet settings in the target bootloader:

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • With your development host set to IP 192.168.3.10 and netmask 255.255.255.0, +the target should return:

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • If you need to make any changes:

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> should be one of ipaddr, netmask, gatewayip or serverip. +<value> will be the actual value of the chosen parameter.

    +
    • +

  • The changes you made are temporary for now. To save these:

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

Here you can also change the IP address to DHCP instead of using a static one.

+
    +

  • Configure:

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • Set up paths for TFTP and NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+

Tip

+

Variables like nfsroot and netargs can be overwritten by the U-boot External +Environment. For netboot, the external environment will be loaded from tftp. +For example, to locally set the nfsroot variable in a bootenv.txt file, +locate the tftproot directory:

+
nfsroot=/home/user/nfssrc
+
+
+

There is no need to store the info on the target. Please note that this does +not work for variables like ipaddr or serveraddr as they need to be already +set when the external environment is being loaded.

+
+
+
+

7.3.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. WLAN

+

WLAN and Bluetooth on the phyBOARD-Pollux are provided by the PEB-WLBT-05 expansion card. +The PEB-WLBT-05 for phyBOARD-Pollux Quickstart Guide shows you how to install the +PEB-WLBT-05.

+
+

Tip

+

With the BSP Version PD22.1 and newer, the PEB-WLBT-05 overlay needs to be activated first, +otherwise the PEB-WLBT-05 won’t be recognized.

+
target:~$ vi /boot/bootenv.txt
+
+
+

Afterwards the bootenv.txt file should look like this (it can also contain other devicetree +overlays!):

+
overlays=conf-imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+
+
+

The changes will be applied after a reboot:

+
target:~$ reboot
+
+
+

For further information about devicetree overlays, read the device tree chapter.

+
+

For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. Connecting to a WLAN Network

+

First set the correct regulatory domain for your country:

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

You will see:

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

Set up the wireless interface:

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

Now you can scan for available networks:

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection.

+

To do so, add the network-credentials to the file /etc/wpa_supplicant.conf:

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

Now a connection can be established:

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

This should result in the following output:

+
Successfully initialized wpa_supplicant
+
+
+

The ip address is automatically configured over DHCP. For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (scarthgap).

+
+
+
+

7.3.3. Bluetooth

+

Bluetooth is supported on phyBOARD-Pollux with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section.

+

Bluetooth is connected to UART3 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup.

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. Visibility

+

To activate visibility:

+
target:~$ hciconfig hci0 piscan
+
+
+

To disable visibility:

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. Connect

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

Note

+

If the connection fails with the error message: “Failed to connect: +org.bluez.Error.Failed” try restarting PulseAudio with:

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC Card

+

The i.MX 8M Plus supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L422

+

DT configuration for the eMMC interface can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L214

+
+
+

7.5. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 8M Plus is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw Multi-Level Cells (MLC) or Triple-Level +Cells (TLC) combined with a memory controller that handles ECC and wear +leveling. They are connected via an SD/MMC interface to the i.MX 8M Plus and are +represented as block devices in the Linux kernel like SD cards, flash drives, or +hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.5.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +or TLC. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background Operations +(BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • Enabling can be done with this command:

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.5.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 8M Plus SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.5.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
+
+

7.5.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC or TLC +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC used in NAND Flash, MLC or TLC have lower reliability and a higher +error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC or TLC +or mark these blocks as discard. The data on the device is lost and +will be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.5.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 8M Plus uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.5.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

The following table is for the offset of the i.MX 8M Plus SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.6. SPI Master

+

The i.MX 8M Plus controller has a FlexSPI and an ECSPI IP core included. The FlexSPI +host controller supports two SPI channels with up to 4 devices. Each channel +supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data +lines). The ECSPI controller supports 3 SPI interfaces with one dedicated chip +selected for each interface. As chip selects should be realized with GPIOs, more +than one device on each channel is possible.

+
+

7.6.1. SPI NOR Flash

+

phyCORE-i.MX 8M Plus is equipped with a QSPI NOR Flash which connects to the i.MX 8M Plus’s +FlexSPI interface. The QSPI NOR Flash is suitable for booting. Please see +different sections for flashing and bootmode setup. Due to limited space on the +SPI NOR Flash, only the bootloader is stored inside. By default, the kernel, +device tree, and rootfs are taken from eMMC.

+

The Bootloader does detect with the help of the EEPROM Introspection data if an +SPI flash is mounted or not. If no SPI flash is mounted a device tree overlay is +applied with the expansion command to disable the SPI flash device tree node +during boot. If no introspection data is available the SPI NOR flash node is +always enabled. Find more information in the device tree overlay section.

+

The bootloader also passes the SPI MTD partition table to Linux by fixing up the +device tree based on the mtdparts boot parameter. The default partition layout +in the BSP is set to:

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

This is a bootloader environment variable that is defined here and can be +changed during runtime. From Linux userspace, the NOR Flash partitions are +accessible via /dev/mtd<N> devices where <N> is the MTD device number associated +with the NOR flash partition to access. To find the correct MTD device number +for a partition, run on the target:

+
root@phyboard-pollux-imx8mp-3:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

It lists all MTD devices and the corresponding partition names. The flash node +is defined inside of the SPI master node in the module DTS. The SPI node +contains all devices connected to this SPI bus which is in this case only the +SPI NOR Flash.

+

The definition of the SPI master node in the device tree can be found here:

+

https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L76

+
+
+
+

7.7. GPIOs

+

The phyBOARD-Pollux has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to i.MX 8M Plus pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal i.MX 8M Plus GPIO banks GPIO1 – GPIO5.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO5_07). <X> identifies the GPIO +bank and counts from 1 to 5, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo -c gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 20 from chip0):

    +
    target:~$ gpioget -c gpiochip0 20
+
    +
    +
    • +

  • Set the value of GPIO 20 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset -z -c gpiochip0 20=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <line=value>...
+
+Set values of GPIO lines.
+
+Lines are specified by name, or optionally by offset if the chip option
+is provided.
+Values may be '1' or '0', or equivalently 'active'/'inactive' or 'on'/'off'.
+
+The line output state is maintained until the process exits, but after that
+is not guaranteed.
+
+Options:
+      --banner            display a banner on successful startup
+  -b, --bias <bias>       specify the line bias
+                  Possible values: 'pull-down', 'pull-up', 'disabled'.
+                  (default is to leave bias unchanged)
+      --by-name           treat lines as names even if they would parse as an offset
+  -c, --chip <chip>       restrict scope to a particular chip
+  -C, --consumer <name>   consumer name applied to requested lines (default is 'gpioset')
+  -d, --drive <drive>     specify the line drive mode
+                  Possible values: 'push-pull', 'open-drain', 'open-source'.
+                  (default is 'push-pull')
+  -h, --help              display this help and exit
+  -l, --active-low        treat the line as active low
+  -p, --hold-period <period>
+                  the minimum time period to hold lines at the requested values
+  -s, --strict            abort if requested line names are not unique
+  -t, --toggle <period>[,period]...
+                  toggle the line(s) after the specified period(s)
+                  If the last period is non-zero then the sequence repeats.
+      --unquoted  don't quote line names
+  -v, --version           output version information and exit
+  -z, --daemonize set values then detach from the controlling terminal
+
+Chips:
+    A GPIO chip may be identified by number, name, or path.
+    e.g. '0', 'gpiochip0', and '/dev/gpiochip0' all refer to the same chip.
+
+Periods:
+    Periods are taken as milliseconds unless units are specified. e.g. 10us.
+    Supported units are 's', 'ms', and 'us'.
+
+*Note*
+    The state of a GPIO line controlled over the character device reverts to default
+    when the last process referencing the file descriptor representing the device file exits.
+    This means that it's wrong to run gpioset, have it exit and expect the line to continue
+    being driven high or low. It may happen if given pin is floating but it must be interpreted
+    as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.7.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the defconfig you use in +arch/arm64/configs/ in the linux kernel sources. For our NXP based releases, +this could be for example imx8_phytec_distro.config:

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+
+
+
+

7.8. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the phyBOARD-Pollux.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L255

+
+
+

7.9. I²C Bus

+

The i.MX 8M Plus contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 8M Plus. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our phyBOARD-Pollux.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C1 bus configuration (e.g. imx8mp-phycore-som.dtsi): +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L113

+

General I²C2 bus configuration (e.g. imx8mp-phyboard-pollux-rdk.dts) +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L239

+
+
+

7.10. EEPROM

+

On the phyCORE-i.MX8MP there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues.

+
+

Note

+

If you deleted reserved EEPROM spaces, please contact our support!

+
+
+

7.10.1. I2C EEPROM on phyCORE-i.MX8MP

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

The I2C EEPROM on the phyCORE-i.MX8MP SoM is connected to I2C address 0x51 on the I2C-0 +bus. It is possible to read and write directly to the device populated:

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the 4KiB EEPROM (bus: I2C-0 addr: 0x51) with zeros leaving out the EEPROM data use:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM Detection

+

The I2C EEPROM, populated on the phyCORE-i.MX8MP, has a separate ID page that is +addressable over I2C address 0x59 on bus 0 and a normal area that is addressable +over I2C address 0x51 on bus 0. PHYTEC uses this data area of 32 Bytes to store +information about the SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the EEPROM ID page data and the first 256 bytes of the normal area are +deleted, the bootloader will fall back to the phyCORE-i.MX8MP Kit RAM setup, which +is 2GiB RAM.

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

SoMs that are flashed with data format API revision 2 will print out information +about the module in the early stage.

+

DT representation, e.g. in phyCORE-i.MX 8M Plus file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L201

+
+
+
+

7.11. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC Wakealarm

+

It is possible to issue an interrupt from the RTC to wake up the system. The +format uses the Unix epoch time, which is the number of seconds since UTC +midnight on 1 January 1970. To wake up the system after 4 minutes from suspend +to ram state, type:

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

Note

+

Internally the wake alarm time will be rounded up to the next minute since +the alarm function doesn’t support seconds.

+
+
+
+

7.11.2. RTC Parameters

+

RTCs have a few abilities which can be read/set with the help of hwclock +tool.

+
    +

  • We can check RTC supported features with:

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    What this value means is encoded in kernel, each set bit translates to:

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • We can check RTC BSM (Backup Switchover Mode) with:

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • We can set RTC BSM with:

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    What BSM values mean translates to these values:

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    Tip

    +

    You should set BSM mode to DSM or LSM for RTC to switch to backup power +source when the initial power source is not available. Check RV-3028 RTC +datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching +Mode) actually mean.

    +
    +
    • +
+

DT representation for I²C RTCs: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L208

+
+
+
+

7.12. USB Host Controller

+

The USB controller of the i.MX 8M Plus SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +‘SS’). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY.

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+

DT representation for USB Host: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L380

+
+
+

7.13. CAN FD

+

The phyBOARD-Pollux has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The two CAN interfaces should show up as +can0 and can1.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    The information for can0 will look like:

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+
+

Warning

+

The mcp2518fd SPI to CANfd supports only baudrates starting from 125kB/s. +Slower rates can be selected but may not work correctly.

+
+

Device Tree CAN configuration of imx8mp-phyboard-pollux-rdk.dts: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L203

+
+
+

7.14. PCIe

+

The phyCORE-i.MX 8M Plus has one Mini-PCIe slot. In general, PCIe autodetects new +devices on the bus. After connecting the device and booting up the system, you +can use the command lspci to see all PCIe devices recognized.

+
    +

  • Type:

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • You will receive:

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

In this example, the PCIe device is the Intel Corporation WiFi Link 5100.

+

For PCIe devices, you have to enable the correct driver in the kernel +configuration. This WLAN card, for example, is manufactured by Intel. The +option for the driver, which must be enabled, is named CONFIG_IWLWIFI and can be +found under Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimat in +the kernel configuration.

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • The linux-imx is represented by: virtual/kernel

      • +
    +
    • +
+

For some devices like the WLAN card, additional binary firmware blobs are +needed. These firmware blobs have to be placed in /lib/firmware/ before the +device can be used.

+
    +

  • Type:

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • For example, if you try to bring up the network interface:

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • You will get the following output on the serial console:

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

Tip

+

Some PCIe devices, e.g. the Ethernet card, may function properly even if no +firmware blob is loaded from /lib/firmware/ and you received an error message +as shown in the first line of the output above. This is because some +manufacturers provide the firmware as a fallback on the card itself. In this +case, the behavior and output depend strongly on the manufacturer’s firmware.

+
+

Device Tree PCIe configuration of imx8mp-phyboard-pollux-rdk.dts: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L345

+
+
+

7.15. Audio

+

Playback devices supported for phyBOARD-Pollux are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals.

+
+

Note

+

Using the PEB-AV-10 connector for display output along HDMI as audio output +is not supported. The audio output device must match the video output device.

+
+

To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices:

+
target:~$ aplay -L
+
+
+

Or type for recording devices:

+
target:~$ arecord -L
+
+
+
+

7.15.1. Alsamixer

+

To inspect the capabilities of your soundcard, call:

+
target:~$ alsamixer
+
+
+

You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. “MM” means the feature is muted +(both output, left & right), which can be toggled by hitting ‘m’. You can also +toggle by hitting ‘<’ for left and ‘>’ for right output. With the tab +key, you can switch between controls for playback and recording.

+
+
+

7.15.2. Restore default volumes

+

There are some default settings stored in /var/lib/alsa/asound.state. +You can save your current alsa settings with:

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

You can restore saved alsa settings with:

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.15.3. ALSA configuration

+

Our BSP comes with a ALSA configuration file /etc/asound.conf.

+

The ALSA configuration file can be edited as desired or deleted since it is not +required for ALSA to work properly.

+
target:~$ vi /etc/asound.conf
+
+
+

To set PEB-AV-10 as output, set playback.pcm from “dummy” to “pebav10”:

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

If the sound is not audible change playback devices to the software volume control +playback devices, set playback.pcm to the respective softvol playback device e.g. +“softvol_pebav10”. Use alsamixer controls to vary the volume levels.

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.15.4. Pulseaudio Configuration

+

For applications using Pulseaudio, check for available sinks:

+
target:~$ pactl list short sinks
+
+
+

To select the output device, type:

+
target:~$ pactl set-default-sink <sink_number>
+
+
+
+
+

7.15.5. Playback

+

Run speaker-test to check playback availability:

+
target:~$ speaker-test -c 2 -t wav
+
+
+

To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds:

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

To playback other formats like mp3 for example, you can use Gstreamer:

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.15.6. Capture

+

arecord is a command-line tool for capturing audio streams which use Line In as +the default input source. To select a different audio source you can +use alsamixer. For example, switch on Right PGA Mixer Mic3R and Left PGA Mixer +Mic3R in order to capture the audio from the microphone input of the +TLV320-Codec using the 3.5mm jack.

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

Hint

+

Since playback and capture share hardware interfaces, it is not possible to +use different sampling rates and formats for simultaneous playback and +capture operations.

+
+

Device Tree Audio configuration: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L58

+
+
+
+

7.16. Video

+
+

7.16.1. Videos with Gstreamer

+

One example video is installed by default in the BSP at /usr/share/qtphy/videos/. +Start the video playback with one of these commands:

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.17. Display

+

The phyBOARD-Pollux supports up to 3 different display outputs. Two can be used +simultaneously. The following table shows the required extensions and devicetree +overlays for the different interfaces.

+ + + + + + + + + + + + + + + + + + + + + +

Interface

Expansion

devicetree overlay

HDMI

phyBOARD-Pollux

no overlay needed (enabled by default)

LVDS0

PEB-AV-10

imx8mp-phyboard-pollux-peb-av-10.dtbo +(loaded by default)

LVDS1

phyBOARD-Pollux

disabled if PEB-AV-10 overlay is used

+
+

Note

+
    +

  • When changing Weston output, make sure to match the audio output as well.

    • +

  • LVDS0 (PEB-AV-10) and LVDS1 (onboard)can not be used at the same time.

    • +
+
+

HDMI is always enabled in the devicetree. The other interfaces can be enabled +with Device Tree Overlay.

+

The default-enabled Interfaces are HDMI and LVDS0 (PEB-AV-010). We support a +10’’ edt,etml1010g0dka display for the PEB-AV-10.

+
+

Note

+

The current display driver limits the pixel clock for a display connected to +LVDS to 74.25Mhz (or a divider of it). If this does not fit your display +requirements, please contact Support for further help.

+
+
+

7.17.1. Weston Configuration

+

In order to get an output from Weston on the correct display, it still needs to +be configured correctly. This will be done at /etc/xdg/weston/weston.ini.

+
+

7.17.1.1. Single Display

+

In our BSP, the default Weston output is set to HDMI.

+
[output]
+name=HDMI-A-1
+mode=preferred
+
+[output]
+name=LVDS-1
+mode=off
+
+
+

When using the LVDS0 (PEB-AV-10) as output, set the output mode to off for +HDMI-A-1 and for LVDS-1 to current.

+
[output]
+name=HDMI-A-1
+mode=off
+
+[output]
+name=LVDS-1
+mode=current
+
+
+

If you want to use LVDS1 (onboard) then you need to load no overlay. Remove the +imx8mp-phyboard-pollux-peb-av-xxx.dtbo from bootenv.txt.

+
+
+

7.17.1.2. Dual Display

+
+

Note

+

For dual and triple display output you can not use LVDS1 (onboard) and HDMI +together.

+
+

For dual display in dual view mode at HDMI and LVDS0 (PEB-AV-10), both modes +have to be set to the:

+
[output]
+name=HDMI-A-1
+mode=preferred
+
+[output]
+name=LVDS-1
+mode=current
+
+
+
+
+
+

7.17.2. Qt Demo

+

With the phytec-qt6demo-image, Weston starts during boot. Our Qt6 demo application named +“qtphy” can be stopped with:

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • To start the demo again, run:

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • To disable autostart of the demo, run:

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • To enable autostart of the demo, run:

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston can be stopped with:

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

Note

+

The Qt demo must be closed before Weston can be closed.

+
+
+
+

7.17.3. Backlight Control

+

If a display is connected to the PHYTEC board, you can control its backlight +with the Linux kernel sysfs interface. All available backlight devices in the +system can be found in the folder /sys/class/backlight. Reading the appropriate +files and writing to them allows you to control the backlight.

+
+

Note

+

Some boards with multiple display connectors might have multiple backlight +controls in /sys/class/backlight. For example: backlight0 and backlight1

+
+
    +

  • To get, for example, the maximum brightness level (max_brightness) execute:

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    Valid brightness values are 0 to <max_brightness>.

    +
    • +

  • To obtain the current brightness level, type:

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • Write to the file brightness to change the brightness:

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    turns the backlight off for example.

    +

    For documentation of all files, see +https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight.

    +
    • +
+

Device tree description of LVDS-1 and HDMI can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L294 +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L218

+

The device tree of LVDS-0 on PEB-AV-10 can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L133

+
+
+
+

7.18. Power Management

+
+

7.18.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 8M Plus SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as ‘Dynamic Voltage and +Frequency Scaling’ (DVFS). The i.MX 8M Plus BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the i.MX 8 +variant used, several different frequencies are supported.

+
+

Tip

+

Although the DVFS framework provides frequency settings for each CPU core, a +change in the frequency settings of one CPU core always affects all other CPU +cores too. So all CPU cores always share the same DVFS setting. An individual +DVFS setting for each core is not possible.

+
+
    +

  • To get a complete list type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately +1,6 GHz, the result will be:

    +
    1200000 1600000
+
    +
    +
    • +

  • To ask for the current frequency type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

So-called governors are automatically selecting one of these frequencies in +accordance with their goals.

+
    +

  • List all governors available with the following command:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    The result will be:

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative is much like the ondemand governor. It differs in behavior in +that it gracefully increases and decreases the CPU speed rather than jumping +to max speed the moment there is any load on the CPU.

    • +

  • ondemand (default) switches between possible CPU core frequencies in +reference to the current system load. When the system load increases above a +specific limit, it increases the CPU core frequency immediately.

    • +

  • powersave always selects the lowest possible CPU core frequency.

    • +

  • performance always selects the highest possible CPU core frequency.

    • +

  • userspace allows the user or userspace program running as root to set a +specific frequency (e.g. to 1600000). Type:

    • +

  • In order to ask for the current governor, type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    You will normally get:

    +
    ondemand
+
    +
    +
    • +

  • Switching over to another governor (e.g. userspace) is done with:

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • Now you can set the speed:

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +Documentation/admin-guide/pm/cpufreq.rst.

+
+
+

7.18.2. CPU Core Management

+

The i.MX 8M Plus SoC can have multiple processor cores on the die. The i.MX 8M Plus, for +example, has 4 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    Here the system has four processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.18.3. Suspend to RAM

+

The phyCORE-i.MX8MP supports basic suspend and resume. Different wake-up sources can be +used. Suspend/resume is possible with:

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

To wake up with serial console run

+
target:~$ echo enabled > /sys/class/tty/ttymxc0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.19. Thermal Management

+
+

7.19.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.19.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 8M Plus SoC platform. The i.MX 8 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Industrial +and Commercial.

+ + + + + + + + + + + + + + + + + +

Commercial

Industrial

passive (warning)

85°C

95°C

critical (shutdown)

90°C

100°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise, Fair Share, Bang Bang, and +Userspace. The default policy used in the BSP is step_wise. If the value of the +SoC temperature in the sysfs file temp is above trip_point_0, the CPU frequency +is set to the lowest CPU frequency. When the SoC temperature drops below +trip_point_0 again, the throttling is released.

+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+

7.19.3. GPIO Fan

+
+

Note

+

Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan +to GPIO fan due to availability. The PWM fan will not be supported +anymore and will not function with the new release.

+
+

A GPIO fan can be connected to the phyBOARD-Pollux-i.MX 8M Plus. The SoC only contains one +temperature sensor which is already used by the thermal frequency scaling. The +fan can not be controlled by the kernel. We use lmsensors with hwmon for this +instead. lmsensors reads the temperature periodically and enables or disables +the fan at a configurable threshold. For the phyBOARD-Pollux-i.MX 8M Plus, this is 60°C.

+

The settings can be configured in the configuration file:

+
/etc/fancontrol
+
+
+

Fan control is started by a systemd service during boot. This can be disabled +with:

+
target:~$ systemctl disable fancontrol
+
+
+

The device tree description of GPIO Fan can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L35

+
+
+
+

7.20. Watchdog

+

The PHYTEC i.MX 8M Plus modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.20.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.21. snvs Power Key

+

The X_ONOFF pin connected to the ON/OFF button can be pressed long to trigger +Power OFF without SW intervention or used to wake up the system out of suspend. +With the snvs_pwrkey driver, the KEY_POWER event is also reported to userspace +when the button is pressed. On default, systemd is configured to ignore such +events. The function of Power OFF without SW intervention and the wake-up from +suspend are not configured. Triggering a power off with systemd when pushing the +ON/OFF button can be configured under /etc/systemd/logind.conf and set using:

+
HandlePowerKey=poweroff
+
+
+
+
+

7.22. NPU

+

The i.MX 8M Plus SoC contains a Neural Processing Unit up to 2.3 TOPS as an accelerator +for artificial intelligence operations. Refer to our latest phyCORE-i.MX 8M Plus AI Kit +Guide on the phyCORE-i.MX 8M Plus download section to get information about the +NPU: L-1015e.A1 phyCORE-i.MX 8M Plus AI Kit Guide

+
+
+

7.23. ISP

+

The i.MX 8M Plus SoC contains an Image Signal Processor (ISP). For more information see +Using the ISPs on the phyBOARD-Pollux i.MX 8M Plus documentation. This documentation is also +available in German.

+
+
+

7.24. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 8M Plus provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 8M Plus Reference Manual). The following list is +an abstract from the i.MX 8M Plus Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x30350000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x30350000

Description

OCOTP_MAC_ADDR0

9

0

0x640

contains lower 32 bits +of ENET0 MAC address

OCOTP_MAC_ADDR1

9

1

0x650

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

OCOTP_MAC_ADDR2

9

2

0x660

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 8M Plus Security Reference Manual.

+
+

7.24.1. Reading Fuse Values in uBoot

+

You can read the content of a fuse using memory-mapped shadow registers. To +calculate the memory address, use the fuse Bank and Word in the following +formula:

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.24.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+
+

8. i.MX 8M Plus M7 Core

+

In addition to the Cortex-A53 cores, there is a Cortex-M7 Core as MCU +integrated into the i.MX 8M Plus SoC. Our Yocto-Linux-BSP runs on the A53-Cores and +the M7 Core can be used as a secondary core for additional tasks using +bare-metal or RTOS firmware. +Both cores have access to the same peripherals and thus peripheral +usage needs to be limited either in the M7 Core’s firmware or the devicetree +for the Linux operating system. This section describes how to build firmware +examples and how to run them on phyBOARD-Pollux.

+

The phyBOARD-Pollux is currently supported by the NXP MCUXpresso SDK and by +The Zephyr Project. This section only describes the NXP MCUXpresso SDK because +the MCUXpresso SDK has more supported features at the moment.

+

If you want to use the M7 Core with The Zephyr Project, please refer to the +The Zephyr Project documentation:

+ +
+

8.1. Getting the Firmware Examples

+

The firmware can be built using the NXP MCUxpresso SDK with a compatible +compiler toolchain using command-line tools.

+
+

8.1.1. Getting the Sources

+

The MCUX SDK and the examples for the i.MX 8M Plus can be obtained from PHYTEC’s GitHub +page:

+ +
    +

  1. Initialize the MCUX SDK via west:

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    This will create a mcuxsdk directory with the mcux-sdk repository in it. +The mcux-sdk-phytec-examples repository will be automatically cloned into +the mcuxsdk directory. +The given argument <VERSION> is a the branch name of the mcux-sdk repository +that represents the MCUX SDK version. For the newest tested version +you can use 2.13.0.

    +
    +

    Note

    +

    west is a repository management tool and a part of the Zephyr +Project. +To install west, you can use pip. In this example west is installed in +a python virtual environment:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. Update the dependencies:

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    The directory examples-phytec contains all examples ported and tested +for phyBOARD-Pollux with version 2.13.0 of MCUX.

    +

    To build the firmware, a compiler toolchain and make/cmake are required. +The GNU Arm Embedded Toolchain may be available in your distribution’s +repositories, e.g. for Ubuntu.

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    The compiler toolchain can also be obtained directly from +https://developer.arm.com/. After the archive has been extracted, +the ARMGCC_DIR has to be added to the environment, e.g. for the +ARM toolchain 10-2020-q4-major release located in the home directory:

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. Building the Firmware

+

To build the PHYTEC samples an environment has to be sourced

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

The scripts to build the firmware are located in +<sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc. +There are scripts for each memory location the firmware is supposed to run in, +e.g.

+
host:~$ ./build_release.sh
+
+
+

to build the firmware for the M7 Core’s TCM. The output will be placed under +release/ in the armgcc directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+

To build the firmware for the DRAM, run the script build_ddr_release. +The script of the firmware that is supposed to run, e.g.

+
host:~$ ./build_ddr_release.sh
+
+
+

The output will be placed under ddr_release/ in the armgcc +directory. .bin files and can be run in U-Boot and .elf +files within Linux.

+
+
+
+

8.2. Running M7 Core Examples

+

There are two ways to run the M7 Core with the built firmware, U-Boot and +Remoteproc within a running Linux.

+

To receive debug messages start your favorite terminal software (e.g. Minicom, +Tio, or Tera Term) on your host PC and configure it for 115200 baud, 8 data +bits, no parity, and 1 stop bit (8n1) with no handshake.

+

Once a micro-USB cable is connected to the USB-debug port on the phyBOARD-Pollux, two +ttyUSB devices are registered. One prints messages from A53-Core’s debug UART +and the other one from the M7 Core’s debug UART.

+
+

8.2.1. Running Examples from U-Boot

+

To load firmware using the bootloader U-Boot, the bootaux command can be used:

+
    +

  1. Prepare an SD Card with our Yocto-BSP

    2. +

  2. Copy the generated .bin file to the SD Cards first partition

    3. +

  3. Stop the autoboot by pressing any key

    4. +

  4. Type the command depending on the type of firmware:

    5. +
+

For firmware built to run in the M7 Core’s TCM:

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

For firmware built to run in the DRAM:

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

The program’s output should appear on the M7 Core’s debug UART.

+
+
+

8.2.2. Running Examples from Linux using Remoteproc

+

Remoteproc is a module that allows you to control the M7 Core from Linux +during runtime. Firmware built for TCM can be loaded and the execution started +or stopped. To use Remoteproc a devicetree overlay needs to be set:

+

Edit the bootenv.txt file located in the /boot directory on the target by +adding conf-imx8mp-phycore-rpmsg.dtbo:

+
overlays=conf-imx8mp-phycore-rpmsg.dtbo
+
+
+

Restart the target and execute in U-Boot:

+
u-boot=> run prepare_mcore
+
+
+

Firmware .elf files for the M7 Core can be found under /lib/firmware. +To load the firmware, type:

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

To load a different firmware, the M7 Core needs to be stopped:

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

Note

+

The samples found in /lib/firmware on the target come from NXP’s +Yocto layer meta-imx. +To use the samples you built yourself through MCUX SDK, please copy them +to /lib/firmware on the target after building them.

+
+
+ +
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mp/pd24.1.1.html b/previews/271/bsp/imx8/imx8mp/pd24.1.1.html new file mode 100644 index 000000000..3504a3bf9 --- /dev/null +++ b/previews/271/bsp/imx8/imx8mp/pd24.1.1.html @@ -0,0 +1,3388 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + + + + + +

PD24.1.1 i.MX 8M Plus BSP +Manual

Document Title

PD24.1.1 i.MX 8M Plus BSP +Manual

Document Type

BSP Manual

Article Number

PD24.1.1

Yocto Manual

Scarthgap

Release Date

2024/04/08

Is Branch of

PD24.1.1 i.MX 8M Plus BSP +Manual

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

PD24.1.1

Major

2024/04/08

Released

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +phyCORE-i.MX8M Plus Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads of our product.

+
+

1.1. Supported Hardware

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 download.

+

If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware

+
+

1.1.1. phyBOARD-Pollux Components

+
+../../../_images/phyBOARD-Pollux-front-components.jpg + +
+

phyBOARD-Pollux Components (top)

+
+
+
+../../../_images/phyBOARD-Pollux-back-components.jpg + +
+

phyBOARD-Pollux Components (bottom)

+
+
+
+
+
+
+

2. Getting Started

+

The phyCORE-i.MX8M Plus Kit is shipped with a pre-flashed SD card. It contains the +phytec-qt6demo-image and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+

There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool dd. An +alternative way is to use PHYTEC’s system initialization program called +partup, which makes it especially easy to +format more complex systems. You can get prebuilt Linux binaries of partup from its release page. Also read +partup’s README for installation +instructions.

+
+

2.1. Get the Image

+

The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using dd, can be downloaded from the PHYTEC download server.

+

Get either the partup package or the WIC image from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
+
+
+

Note

+

For eMMC, more complex partitioning schemes or even just large images, we +recommend using the partup package, as it is faster in writing than dd +and allows for a more flexible configuration of the target flash device.

+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card, you must have root privileges on your Linux +host PC. Be very careful when specifying the destination device! All files +on the selected device will be erased immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system on your host PC!

+
+
+

2.2.1. Finding the Correct Device

+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+

Unmount all those partitions, e.g.:

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

Now, the SD card is ready to be flashed with an image, using either partup, +dd or bmap-tools.

+
+
+

2.2.2. Using bmap-tools

+

One way to prepare an SD card is using +bmap-tools. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host:~$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic /dev/<your_device>
+
+
+

Replace <your_device> with your actual SD card’s device name found previously, +and make sure to place the file <IMAGENAME>-<MACHINE>.wic.bmap alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip.

+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.2.3. Using partup

+

Writing to an SD card with partup is done in a single command:

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup /dev/<your_device>
+
+
+

Make sure to replace <your_device> with your actual device name found previously.

+

Further usage of partup is explained at its official documentation website.

+
+

Warning

+

Host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to write partup packages created with Yocto Mickledore +or newer to SD-Card. This is due to a new default option in resize2fs which causes an +incompatibility. See release notes.

+
+
+

Note

+

partup has the advantage of allowing to clear specific raw areas in the +MMC user area, which is used in our provided partup packages to erase any +existing U-Boot environments. This is a known issue bmaptool does not +solve, as mentioned in the previous chapter.

+

Another key advantage of partup over other flashing tools is that it allows +configuring MMC specific parts, like writing to eMMC boot partitions, without +the need to call multiple other commands when writing.

+
+
+
+

2.2.4. Using dd

+

After having unmounted all SD card’s partitions, you can create your bootable SD card.

+

Some PHYTEC BSPs produce uncompressed images (with filename-extension *.wic), +and some others produce compressed images (with filename-extension *.wic.xz).

+

To flash an uncompressed images (*.wic) use command below:

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Or to flash a compressed images (*.wic.xz) use that command:

+
host:~$ xzcat phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Again, make sure to replace <your_device> with your actual device name found +previously.

+

The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

+
+
+
+

2.3. First Start-up

+ +../../../_images/SD_Card_Boot2.png +
    +

  • Insert the SD card

    • +

  • Connect the target and the host with mirco USB on (X1) +debug USB

    • +

  • Power up the board

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (scarthgap).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (scarthgap).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-IMX8MP; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-xwayland MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the phyboard-pollux-imx8mp-3 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx8mp.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_pmu_train_1d_dmem_202006.bin, +lpddr4_pmu_train_1d_imem_202006.bin, +lpddr4_pmu_train_2d_dmem_202006.bin, +lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY firmware images

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx8mp-phyboard-pollux-rdk*.dtb: Kernel device tree file

    • +

  • phytec-qt6demo-image*.tar.gz: Root file system

    • +

  • phytec-qt6demo-image*.wic: SD card image

    • +
+
+
+
+
+

4. Installing the OS

+
+

4.1. Bootmode Switch (S3)

+
+

Tip

+

Hardware revision baseboard: 1552.2

+
+

The phyBOARD-Pollux features a boot switch with four individually switchable ports to +select the phyCORE-i.MX 8M Plus default bootsource.

+ + + + + + + + + + + +
+../../../_images/eMMC2.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses2.png +
+

Internal Fuses

+
+
+
+../../../_images/SPI_NOR2.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download3.png +
+

USB Serial Download

+
+
+
+../../../_images/SD_Card_Boot2.png +
+

SD Card

+
+
+
+../../../_images/Test_Mode.png +
+

Test Mode

+
+
+
+
+
+

4.2. Flash eMMC

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S3) is set to eMMC.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk2p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from Network

+

i.MX 8M Plus boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

4.2.1.1. Flash eMMC from Network in U-Boot on Target

+

These steps will show how to update the eMMC via a network.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+
    +

  • Load your image via network to RAM:

    +
    u-boot=> dhcp ${loadaddr} phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.11 (101 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • Write the image to the eMMC:

    +
    u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +
+
+
+

4.2.1.2. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Take a compressed or uncompressed image on the host and send it with ssh through +the network (then uncompress it, if necessary) to the eMMC of the target with a +one-line command:

+
target:~$ ssh <USER>@192.168.3.10 "dd if=<path_to_file>/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic" | dd of=/dev/mmcblk2 conv=fsync
+
+
+
+
+

4.2.1.3. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Show your available image files on the host:

+
host:~$ ls
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
+
+

Send the image with the dd command combined with ssh through the network +to the eMMC of your device:

+
host:~$ dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2 conv=fsync"
+
+
+
+
+
+

4.2.2. Flash eMMC U-Boot image via Network from running U-Boot

+

Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> dhcp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.3. Flash eMMC from USB

+
+

4.2.3.1. Flash eMMC from USB in U-Boot on Target

+
+

Note

+

Only the lower USB-A port is configured for storage devices and only +this port will work when trying to access a storage device in U-Boot.

+
+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE.

+
+

These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch (S3) to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied WIC image to the USB slot.

+

Load your image from the USB device to RAM:

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} *.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic). Set the bootmode switch (S3) to SD Card.

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ cd /mnt
+target:~$ ls
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
    +
    +
    • +

  • Show list of available MMC devices:

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • The eMMC device can be recognized by the fact that it contains two boot +partitions: (mmcblk2boot0; mmcblk2boot1)

    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without partition):

    +
    target:~$ dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic of=/dev/mmcblk2 conv=fsync
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Tip

    +

    Before this will work, you need to configure the bootmode switch (S3) to +eMMC.

    +
    +
    • +
+
+
+
+

4.2.4. Flash eMMC from SD Card

+

Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (*.wic) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see Resizing ext4 Root Filesystem.

+

Alternatively, flash a partup package to the SD card, as described in +Getting Started. This will ensure the full space of the SD card is used.

+
+

4.2.4.1. Flash eMMC from SD card in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1GB due to +limited usage of RAM size in the Bootloader after enabling OPTEE. If the +image file is too large use the Updating eMMC from SD card in +Linux on Target subsection.

+
+
    +

  • Flash an SD card with a working image and create a third FAT partition. Copy +the WIC image (for example phytec-qt6demo-image.rootfs.wic) to this +partition.

    • +

  • Configure the bootmode switch (S3) to SD Card and insert the SD Card.

    • +

  • Power on the board and stop in U-Boot.

    • +

  • Load the image:

    +
    u-boot=> fatload mmc 1:3 ${loadaddr} phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • Switch the mmc dev to eMMC:

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • Flash your WIC image (for example phytec-qt6demo-image.rootfs.wic) +from the SD card to eMMC. This will partition the card and copy imx-boot, +Image, dtb, dtbo, and root file system to eMMC.

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • Power off the board and change the bootmode switch (S3) to eMMC.

    • +
+
+
+

4.2.4.2. Flash eMMC from SD card in Linux on Target

+

You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card.

+
    +

  • Show your saved partup package or WIC image files on the SD card:

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
    +
    +
    • +

  • Show list of available MMC devices:

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • The eMMC device can be recognized by the fact that it contains two boot +partitions: (mmcblk2boot0; mmcblk2boot1)

    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without +partition) using partup:

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup /dev/mmcblk2
+
    +
    +

    Flashing the partup package has the advantage of using the full capacity of +the eMMC device, adjusting partitions accordingly.

    +
    +

    Note

    +

    Alternatively, dd may be used instead:

    +
    target:~$ dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic of=/dev/mmcblk2 conv=fsync
+
    +
    +

    Keep in mind that the root partition does not make use of the full space when +flashing with dd.

    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Warning

    +

    Before this will work, you need to configure the bootmode switch (S3) to eMMC.

    +
    +
    • +
+
+
+
+
+

4.3. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A6 RAUC Update & Device Management Manual.

+
+
+
+

5. Development

+
+

5.1. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.1.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.2. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.2.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel image to your tftp directory:

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • Copy the devicetree to your tftp directory:

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.2.2. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.3.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/phyboard-pollux-imx8mp-3/. For flashing a wic image to eMMC, +you will also need phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic

+
+
+

5.3.3. Prepare Target

+

Set the bootmode switch (S3) to USB Serial Download. Also, connect USB port +X5 (upper connector) to your host.

+
+
+

5.3.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via (X1), as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.3.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
+
+
+
+
+

5.4. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone https://github.com/phytec/u-boot-phytec.git)

+
+
+

5.4.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    https://github.com/phytec/u-boot-phytec.git
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-phytec and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    https://github.com/phytec/linux-phytec.git
+
    +
    +
    • +

  • Our i.MX 8M Plus kernel is based on the linux-phytec kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
recipes-kernel/linux/linux-phytec_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-phytec_*.bb
+
+
+
+
+
+

5.4.2. Build the SDK

+

You can build the SDK yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+
+
+

5.4.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-4.3.sh
+host:~$ ./phytec-ampliphy-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-4.3.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-xwayland/4.3):
+You are about to install the SDK to "/opt/ampliphy-xwayland/4.3". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-xwayland/4.3/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. U-Boot standalone build

+
+

5.5.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone https://github.com/phytec/u-boot-phytec.git
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag used in this release is called v2024.01-phy3

    • +

  • Check out the needed U-Boot tag:

    +
    host:~$ cd ~/u-boot-phytec/
+host:~/u-boot-phytec$ git fetch --all --tags
+host:~/u-boot-phytec$ git checkout tags/v2024.01-phy3
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/u-boot-phytec$ source /opt/ampliphy-xwayland/4.3/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. Get the needed binaries

+

To build the bootloader, you need to copy these files to your u-boot-phytec +build directory and rename them to fit with mkimage script:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx8mp.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +
+

If you already built our BSP with Yocto, you can get the +bl31-imx8mp.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: BSP Images

+

Or you can download the files here: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/

+
+

Warning

+

Make sure you rename the files you need so that they are compatible with the +mkimage tool.

+
+
+
+

5.5.3. Build the bootloader

+
    +

  • build flash.bin (imx-boot):

    +
    host:~/u-boot-phytec$ make phycore-imx8mp_defconfig
+host:~/u-boot-phytec$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. Flash the bootloader to a block device

+

The flash.bin can be found at u-boot-phytec/ directory and now can be +flashed. A chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

E.g. flash SD card:

+
host:~/u-boot-phytec$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables +“BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+
+

5.6. Kernel standalone build

+
+

5.6.1. Setup sources

+
    +

  • The used linux-phytec branch can be found in the release notes

    • +

  • The tag needed for this release is called v6.6.21-phy1

    • +

  • Check out the needed linux-phytec tag:

    +
    host:~$ git clone https://github.com/phytec/linux-phytec.git
+host:~$ cd ~/linux-phytec/
+host:~/linux-phytec$ git fetch --all --tags
+host:~/linux-phytec$ git checkout tags/v6.6.21-phy1
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-phytec$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-phytec$ source /opt/ampliphy-xwayland/4.3/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-phytec$ make defconfig
+host:~/linux-phytec$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-phytec$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-phytec/arch/arm64/boot/Image

    • +

  • The dtb can be found at +~/linux-phytec/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-phytec$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. Copy Kernel to SD Card

+

When one-time boot via netboot is not sufficient, the kernel along with its +modules and the corresponding device tree blob may be copied directly to a +mounted SD card.

+
host:~/linux-phytec$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-phytec$ cp arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb /path/to/sdcard/boot/oftree
+host:~/linux-phytec$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. Accessing the Development states

+
+

5.7.1. Development state of current release

+

These release manifests exist to give you access to the development states +of the Yocto BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line:

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1
+
+
+

This will initialize a BSP that will track the latest development state of the +current release (BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1). From now on repo sync in this folder +will pull all the latest changes from our Git repositories:

+
host:~$ repo sync
+
+
+
+
+

5.7.2. Development state of upcoming release

+

Also development states of upcoming releases can be accessed this way. +For this execute the following command and look for a release with a higher +PDXX.Y number than the latest one (BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1) and .y at the +end:

+
host:~$ ./phyLinux init -p imx8mp
+
+
+
+
+
+

5.8. Accessing the Latest Upstream Support

+

We have a vanilla manifest that makes use of the Yocto master branches (not an +NXP release), Linux, and U-Boot. This can be used to test the latest upstream +kernel/U-Boot.

+
+

Note

+

The master manifest reflects the latest state of development. This tends to +be broken from time to time. We try to fix the master on a regular basis.

+
+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.9.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 8M Plus SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Board.dts - include the module dtsi file. Devices that come from the i.MX 8M Plus +SoC but are just routed down to the carrier board and used there are included +in this dts.

    • +

  • Overlay.dtso - enable/disable features depending on optional hardware that +may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10)

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 8 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the folder arch/arm64/boot/dts/freescale/.

+

Available overlays for phyboard-pollux-imx8mp-3.conf are:

+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 8M Plus BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 8M Plus BSP Device Tree Concept to get an understanding +of our i.MX 8 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 8 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 8M Plus Pin Muxing

+

The i.MX 8M Plus SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 8M Plus terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 8M Plus Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx8mp-phyboard-pollux-rdk.dts:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x140
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x140
+        >;
+};
+
+
+

The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled.

+

The device tree representation for UART1 pinmuxing: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L387

+
+
+

7.2. RS232/RS485

+

The phyCORE-i.MX 8M Plus supports up to 4 UART units. On the phyBOARD-Pollux, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector X2 at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers JP3 and +JP4 on the baseboard. For more information about the correct setup please +refer to the phyCORE-i.MX 8M Plus/phyBOARD-Pollux Hardware Manual section UARTs.

+

We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers JP3 and JP4 need to be set +correctly.

+
+

7.2.1. RS232

+
    +

  • Display the current settings of a terminal in a human-readable format:

    +
    target:~$ stty -a
+
    +
    +
    • +

  • Configuration of the UART interface can be done with stty. For example:

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • With a simple echo and cat, basic communication can be tested. Example:

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

The host should print out “123”.

+
+
+

7.2.2. RS485

+
+

Hint

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

For easy testing, look at the linux-serial-test. This tool is called the IOCTL +for RS485 and sends a constant stream of data.

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

More information about the linux-serial-test tool and its parameters can be +found here: linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Documentation for calling the IOCTL within c-code is described in the Linux +kernel documentation: +https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+

The device tree representation for RS232 and RS485: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L251

+
+
+
+

7.3. Network

+

phyBOARD-Pollux-i.MX 8M Plus provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board.

+
+

Warning

+

The naming convention of the Ethernet interfaces in the hardware (ethernet0 +and ethernet1) do not align with the network interfaces (eth0 and eth1) in +Linux. So, be aware of these differences:

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L41.

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Pollux can be found here: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L106

+
+

7.3.1. Network Environment Customization

+
+

7.3.1.1. U-boot network-environment

+
    +

  • We currently use dynamic IP addresses in U-Boot. This is enabled by this variable:

    +
    +
    u-boot=> printenv ip_dyn
+ip_dyn=yes
+
    +
    +
    +
    • +

  • Set up path for NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+
+

7.3.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+
+

7.4. SD/MMC Card

+

The i.MX 8M Plus supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L261

+

DT configuration for the eMMC interface can be found here: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L181

+
+
+

7.5. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 8M Plus is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw Multi-Level Cells (MLC) or Triple-Level +Cells (TLC) combined with a memory controller that handles ECC and wear +leveling. They are connected via an SD/MMC interface to the i.MX 8M Plus and are +represented as block devices in the Linux kernel like SD cards, flash drives, or +hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.5.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +or TLC. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background Operations +(BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • Enabling can be done with this command:

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.5.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 8M Plus SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.5.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
+
+

7.5.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC or TLC +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC used in NAND Flash, MLC or TLC have lower reliability and a higher +error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC or TLC +or mark these blocks as discard. The data on the device is lost and +will be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.5.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 8M Plus uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.5.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

The following table is for the offset of the i.MX 8M Plus SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.6. SPI Master

+

The i.MX 8M Plus controller has a FlexSPI and an ECSPI IP core included. The FlexSPI +host controller supports two SPI channels with up to 4 devices. Each channel +supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data +lines). The ECSPI controller supports 3 SPI interfaces with one dedicated chip +selected for each interface. As chip selects should be realized with GPIOs, more +than one device on each channel is possible.

+

The definition of the SPI master node in the device tree can be found here: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L67

+
+
+

7.7. GPIOs

+

The phyBOARD-Pollux has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to i.MX 8M Plus pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal i.MX 8M Plus GPIO banks GPIO1 – GPIO5.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO5_07). <X> identifies the GPIO +bank and counts from 1 to 5, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo -c gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 20 from chip0):

    +
    target:~$ gpioget -c gpiochip0 20
+
    +
    +
    • +

  • Set the value of GPIO 20 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset -z -c gpiochip0 20=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <line=value>...
+
+Set values of GPIO lines.
+
+Lines are specified by name, or optionally by offset if the chip option
+is provided.
+Values may be '1' or '0', or equivalently 'active'/'inactive' or 'on'/'off'.
+
+The line output state is maintained until the process exits, but after that
+is not guaranteed.
+
+Options:
+      --banner            display a banner on successful startup
+  -b, --bias <bias>       specify the line bias
+                  Possible values: 'pull-down', 'pull-up', 'disabled'.
+                  (default is to leave bias unchanged)
+      --by-name           treat lines as names even if they would parse as an offset
+  -c, --chip <chip>       restrict scope to a particular chip
+  -C, --consumer <name>   consumer name applied to requested lines (default is 'gpioset')
+  -d, --drive <drive>     specify the line drive mode
+                  Possible values: 'push-pull', 'open-drain', 'open-source'.
+                  (default is 'push-pull')
+  -h, --help              display this help and exit
+  -l, --active-low        treat the line as active low
+  -p, --hold-period <period>
+                  the minimum time period to hold lines at the requested values
+  -s, --strict            abort if requested line names are not unique
+  -t, --toggle <period>[,period]...
+                  toggle the line(s) after the specified period(s)
+                  If the last period is non-zero then the sequence repeats.
+      --unquoted  don't quote line names
+  -v, --version           output version information and exit
+  -z, --daemonize set values then detach from the controlling terminal
+
+Chips:
+    A GPIO chip may be identified by number, name, or path.
+    e.g. '0', 'gpiochip0', and '/dev/gpiochip0' all refer to the same chip.
+
+Periods:
+    Periods are taken as milliseconds unless units are specified. e.g. 10us.
+    Supported units are 's', 'ms', and 'us'.
+
+*Note*
+    The state of a GPIO line controlled over the character device reverts to default
+    when the last process referencing the file descriptor representing the device file exits.
+    This means that it's wrong to run gpioset, have it exit and expect the line to continue
+    being driven high or low. It may happen if given pin is floating but it must be interpreted
+    as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.7.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the defconfig you use in +arch/arm64/configs/ in the linux kernel sources. For our NXP based releases, +this could be for example imx8_phytec_distro.config:

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+
+
+
+

7.8. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the phyBOARD-Pollux.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L160

+
+
+

7.9. I²C Bus

+

The i.MX 8M Plus contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 8M Plus. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our phyBOARD-Pollux.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C1 bus configuration (e.g. imx8mp-phycore-som.dtsi): +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L81

+

General I²C2 bus configuration (e.g. imx8mp-phyboard-pollux-rdk.dts) +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L145

+
+
+

7.10. EEPROM

+

On the phyCORE-i.MX8MP there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues.

+
+

Note

+

If you deleted reserved EEPROM spaces, please contact our support!

+
+
+

7.10.1. I2C EEPROM on phyCORE-i.MX8MP

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

The I2C EEPROM on the phyCORE-i.MX8MP SoM is connected to I2C address 0x51 on the I2C-0 +bus. It is possible to read and write directly to the device populated:

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the 4KiB EEPROM (bus: I2C-0 addr: 0x51) with zeros leaving out the EEPROM data use:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM Detection

+

The I2C EEPROM, populated on the phyCORE-i.MX8MP, has a separate ID page that is +addressable over I2C address 0x59 on bus 0 and a normal area that is addressable +over I2C address 0x51 on bus 0. PHYTEC uses this data area of 32 Bytes to store +information about the SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the EEPROM ID page data and the first 256 bytes of the normal area are +deleted, the bootloader will fall back to the phyCORE-i.MX8MP Kit RAM setup, which +is 2GiB RAM.

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

SoMs that are flashed with data format API revision 2 will print out information +about the module in the early stage.

+

DT representation, e.g. in phyCORE-i.MX 8M Plus file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L169

+
+
+
+

7.11. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC Parameters

+

RTCs have a few abilities which can be read/set with the help of hwclock +tool.

+
    +

  • We can check RTC supported features with:

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    What this value means is encoded in kernel, each set bit translates to:

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • We can check RTC BSM (Backup Switchover Mode) with:

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • We can set RTC BSM with:

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    What BSM values mean translates to these values:

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    Tip

    +

    You should set BSM mode to DSM or LSM for RTC to switch to backup power +source when the initial power source is not available. Check RV-3028 RTC +datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching +Mode) actually mean.

    +
    +
    • +
+

DT representation for I²C RTCs: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L175

+
+
+
+

7.12. USB Host Controller

+

The USB controller of the i.MX 8M Plus SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +‘SS’). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY.

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+

DT representation for USB Host: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L220

+
+
+

7.13. CAN FD

+

The phyBOARD-Pollux has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The two CAN interfaces should show up as +can0 and can1.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    The information for can0 will look like:

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+
+

Warning

+

The mcp2518fd SPI to CANfd supports only baudrates starting from 125kB/s. +Slower rates can be selected but may not work correctly.

+
+

Device Tree CAN configuration of imx8mp-phyboard-pollux-rdk.dts: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L130

+
+
+

7.14. Video

+
+

7.14.1. Videos with Gstreamer

+

One example video is installed by default in the BSP at /usr/share/qtphy/videos/. +Start the video playback with one of these commands:

+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink fullscreen=true
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+

Note

+

The mainline BSP currently only supports software rendering.

+
+
+
+
+

7.15. Display

+

The phyBOARD-Pollux supports LVDS output via the LVDS1 connector on the carrier board. The +LVDS interface is enabled by default.

+
+

7.15.1. Weston Configuration

+

Weston will work without any additional configuration. Configuration options are +done at /etc/xdg/weston/weston.ini.

+

Device tree description of LVDS can be found here: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L182

+
+
+

7.15.2. Qt Demo

+

With the phytec-qt6demo-image, Weston starts during boot. Our Qt6 demo application named +“qtphy” can be stopped with:

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • To start the demo again, run:

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • To disable autostart of the demo, run:

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • To enable autostart of the demo, run:

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston can be stopped with:

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

Note

+

The Qt demo must be closed before Weston can be closed.

+
+
+
+

7.15.3. Backlight Control

+

If a display is connected to the PHYTEC board, you can control its backlight +with the Linux kernel sysfs interface. All available backlight devices in the +system can be found in the folder /sys/class/backlight. Reading the appropriate +files and writing to them allows you to control the backlight.

+
+

Note

+

Some boards with multiple display connectors might have multiple backlight +controls in /sys/class/backlight. For example: backlight0 and backlight1

+
+
    +

  • To get, for example, the maximum brightness level (max_brightness) execute:

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    Valid brightness values are 0 to <max_brightness>.

    +
    • +

  • To obtain the current brightness level, type:

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • Write to the file brightness to change the brightness:

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    turns the backlight off for example.

    +

    For documentation of all files, see +https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight.

    +
    • +
+
+

Note

+

We noticed some visible backlight flickering on brightness level 1 (probably +due to frequency problems with the hardware).

+
+
+
+
+

7.16. Power Management

+
+

7.16.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 8M Plus SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as ‘Dynamic Voltage and +Frequency Scaling’ (DVFS). The i.MX 8M Plus BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the i.MX 8 +variant used, several different frequencies are supported.

+
+

Tip

+

Although the DVFS framework provides frequency settings for each CPU core, a +change in the frequency settings of one CPU core always affects all other CPU +cores too. So all CPU cores always share the same DVFS setting. An individual +DVFS setting for each core is not possible.

+
+
    +

  • To get a complete list type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately +1,6 GHz, the result will be:

    +
    1200000 1600000
+
    +
    +
    • +

  • To ask for the current frequency type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

So-called governors are automatically selecting one of these frequencies in +accordance with their goals.

+
    +

  • List all governors available with the following command:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    The result will be:

    +
    ondemand userspace performance schedutil
+
    +
    +
    • +

  • ondemand (default) switches between possible CPU core frequencies in +reference to the current system load. When the system load increases above a +specific limit, it increases the CPU core frequency immediately.

    • +

  • performance always selects the highest possible CPU core frequency.

    • +

  • userspace allows the user or userspace program running as root to set a +specific frequency (e.g. to 1600000). Type:

    • +

  • In order to ask for the current governor, type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    You will normally get:

    +
    schedutil
+
    +
    +
    • +

  • Switching over to another governor (e.g. userspace) is done with:

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • Now you can set the speed:

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +Documentation/admin-guide/pm/cpufreq.rst.

+
+
+

7.16.2. CPU Core Management

+

The i.MX 8M Plus SoC can have multiple processor cores on the die. The i.MX 8M Plus, for +example, has 4 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    Here the system has four processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+
+

7.17. Thermal Management

+
+

7.17.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.17.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 8M Plus SoC platform. The i.MX 8 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Industrial +and Commercial.

+ + + + + + + + + + + + + + + + + +

Commercial

Industrial

passive (warning)

85°C

95°C

critical (shutdown)

90°C

100°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise, Fair Share, Bang Bang, and +Userspace. The default policy used in the BSP is step_wise. If the value of the +SoC temperature in the sysfs file temp is above trip_point_0, the CPU frequency +is set to the lowest CPU frequency. When the SoC temperature drops below +trip_point_0 again, the throttling is released.

+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+
+

7.18. Watchdog

+

The PHYTEC i.MX 8M Plus modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.18.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.19. snvs Power Key

+

The X_ONOFF pin connected to the ON/OFF button can be pressed long to trigger +Power OFF without SW intervention. With the snvs_pwrkey driver, the KEY_POWER +event is also reported to userspace when the button is pressed. On default, systemd +is configured to ignore such events. The function of Power OFF without SW +intervention are not configured. Triggering a power off with systemd when pushing +the ON/OFF button can be configured under /etc/systemd/logind.conf and set using:

+
HandlePowerKey=poweroff
+
+
+
+
+

7.20. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 8M Plus provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 8M Plus Reference Manual). The following list is +an abstract from the i.MX 8M Plus Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x30350000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x30350000

Description

OCOTP_MAC_ADDR0

9

0

0x640

contains lower 32 bits +of ENET0 MAC address

OCOTP_MAC_ADDR1

9

1

0x650

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

OCOTP_MAC_ADDR2

9

2

0x660

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 8M Plus Security Reference Manual.

+
+

7.20.1. Reading Fuse Values in uBoot

+

You can read the content of a fuse using memory-mapped shadow registers. To +calculate the memory address, use the fuse Bank and Word in the following +formula:

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.20.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx8/imx8mp/pd24.1.2.html b/previews/271/bsp/imx8/imx8mp/pd24.1.2.html new file mode 100644 index 000000000..71e84d2d0 --- /dev/null +++ b/previews/271/bsp/imx8/imx8mp/pd24.1.2.html @@ -0,0 +1,3518 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + + + + + +

PD24.1.2 i.MX 8M Plus BSP +Manual

Document Title

PD24.1.2 i.MX 8M Plus BSP +Mainline Manual

Document Type

BSP Manual

Article Number

PD24.1.2

Yocto Manual

Scarthgap

Release Date

2024/06/26

Is Branch of

PD24.1.2 i.MX 8M Plus BSP +Mainline Manual

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2

Minor

2024/06/26

Released

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +phyCORE-i.MX8M Plus Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads of our product.

+
+

1.1. Supported Hardware

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 download.

+

If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware

+
+

1.1.1. phyBOARD-Pollux Components

+
+../../../_images/phyBOARD-Pollux-front-components.jpg + +
+

phyBOARD-Pollux Components (top)

+
+
+
+../../../_images/phyBOARD-Pollux-back-components.jpg + +
+

phyBOARD-Pollux Components (bottom)

+
+
+
+
+
+
+

2. Getting Started

+

The phyCORE-i.MX8M Plus Kit is shipped with a pre-flashed SD card. It contains the +phytec-qt6demo-image and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+

There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool dd. An +alternative way is to use PHYTEC’s system initialization program called +partup, which makes it especially easy to +format more complex systems. You can get prebuilt Linux binaries of partup from its release page. Also read +partup’s README for installation +instructions.

+
+

2.1. Get the Image

+

The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using dd, can be downloaded from the PHYTEC download server.

+

Get either the partup package or the WIC image from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+
+

Note

+

For eMMC, more complex partitioning schemes or even just large images, we +recommend using the partup package, as it is faster in writing than dd +and allows for a more flexible configuration of the target flash device.

+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card, you must have root privileges on your Linux +host PC. Be very careful when specifying the destination device! All files +on the selected device will be erased immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system on your host PC!

+
+
+

2.2.1. Finding the Correct Device

+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+

Unmount all those partitions, e.g.:

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

Now, the SD card is ready to be flashed with an image, using either partup, +dd or bmap-tools.

+
+
+

2.2.2. Using bmap-tools

+

One way to prepare an SD card is using +bmap-tools. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host:~$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

Replace <your_device> with your actual SD card’s device name found previously, +and make sure to place the file <IMAGENAME>-<MACHINE>.wic.bmap alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip.

+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.2.3. Using partup

+

Writing to an SD card with partup is done in a single command:

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).partup /dev/<your_device>
+
+
+

Make sure to replace <your_device> with your actual device name found previously.

+

Further usage of partup is explained at its official documentation website.

+
+

Warning

+

Host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to write partup packages created with Yocto Mickledore +or newer to SD-Card. This is due to a new default option in resize2fs which causes an +incompatibility. See release notes.

+
+
+

Note

+

partup has the advantage of allowing to clear specific raw areas in the +MMC user area, which is used in our provided partup packages to erase any +existing U-Boot environments. This is a known issue bmaptool does not +solve, as mentioned in the previous chapter.

+

Another key advantage of partup over other flashing tools is that it allows +configuring MMC specific parts, like writing to eMMC boot partitions, without +the need to call multiple other commands when writing.

+
+
+
+

2.2.4. Using dd

+

After having unmounted all SD card’s partitions, you can create your bootable SD card.

+

Some PHYTEC BSPs produce uncompressed images (with filename-extension *.wic), +and some others produce compressed images (with filename-extension *.wic.xz).

+

To flash an uncompressed images (*.wic) use command below:

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Or to flash a compressed images (*.wic.xz) use that command:

+
host:~$ xzcat phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Again, make sure to replace <your_device> with your actual device name found +previously.

+

The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

+
+
+
+

2.3. First Start-up

+ +../../../_images/SD_Card_Boot2.png +
    +

  • Insert the SD card

    • +

  • Connect the target and the host with mirco USB on (X1) +debug USB

    • +

  • Power up the board

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (scarthgap).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (scarthgap).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-IMX8MP; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-xwayland MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the phyboard-pollux-imx8mp-3 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx8mp.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_pmu_train_1d_dmem_202006.bin, +lpddr4_pmu_train_1d_imem_202006.bin, +lpddr4_pmu_train_2d_dmem_202006.bin, +lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY firmware images

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx8mp-phyboard-pollux-rdk*.dtb: Kernel device tree file

    • +

  • phytec-qt6demo-image*.tar.gz: Root file system

    • +

  • phytec-qt6demo-image*.wic.xz: SD card image

    • +
+
+
+
+
+

4. Installing the OS

+

For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see Setup Network Host.

+
+

4.1. Bootmode Switch (S3)

+
+

Tip

+

Hardware revision baseboard: 1552.2

+
+

The phyBOARD-Pollux features a boot switch with four individually switchable ports to +select the phyCORE-i.MX 8M Plus default bootsource.

+ + + + + + + + + + + +
+../../../_images/eMMC2.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses2.png +
+

Internal Fuses

+
+
+
+../../../_images/SPI_NOR2.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download3.png +
+

USB Serial Download

+
+
+
+../../../_images/SD_Card_Boot2.png +
+

SD Card

+
+
+
+../../../_images/Test_Mode.png +
+

Test Mode

+
+
+
+
+
+

4.2. Flash eMMC

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S3) is set to eMMC.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk2p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from Network

+

i.MX 8M Plus boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

4.2.1.1. Flash eMMC from Network in U-Boot on Target

+

These steps will show how to update the eMMC via a network.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+
+

Tip

+

This step only works if the size of the image file is less than 1,28GB due to +limited RAM space available in the Bootloader.

+
+
    +

  • Uncompress your image:

    • +
+
host:~$ unxz /srv/tftp/phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+
    +

  • Load your image via network to RAM:

    +
    u-boot=> dhcp ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.11 (101 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • Write the image to the eMMC:

    +
    u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +
+
+
+

4.2.1.2. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Take a compressed or decompressed image with the accompanying block map file +*.bmap on the host and send it with ssh through the network to the eMMC of +the target with a one-line command:

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.* /tmp && bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
+
+
+
+

4.2.1.3. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Show your available image files on the host:

+
host:~$ ls /srv/tftp
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
+
+

Send the image with the bmaptool command combined with ssh through the network +to the eMMC of your device:

+
host:~$ scp /srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2"
+
+
+
+
+
+

4.2.2. Flash eMMC U-Boot image via Network from running U-Boot

+

Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> dhcp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.3. Flash eMMC from USB stick

+
+

4.2.3.1. Flash eMMC from USB stick in U-Boot on Target

+
+

Note

+

Only the lower USB-A port is configured for storage devices and only +this port will work when trying to access a storage device in U-Boot.

+
+
+

Tip

+

This step only works if the size of the image file is less than 1,28GB due to +limited RAM space available in the Bootloader.

+
+

These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch (S3) to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied uncompressed WIC image to +the USB slot.

+

Load your image from the USB device to RAM:

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

Write the image to the eMMC:

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz). Set the bootmode switch (S3) to SD Card.

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ ls /mnt
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without partition):

    +
    target:~$ bmaptool copy /mnt/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Tip

    +

    Before this will work, you need to configure the bootmode switch (S3) to +eMMC.

    +
    +
    • +
+
+
+
+

4.2.4. Flash eMMC from SD Card

+

Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (*.wic) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see Resizing ext4 Root Filesystem.

+

Alternatively, flash a partup package to the SD card, as described in +Getting Started. This will ensure the full space of the SD card is used.

+
+

4.2.4.1. Flash eMMC from SD card in U-Boot on Target

+
+

Tip

+

This step only works if the size of the image file is less than 1,28GB due to +limited RAM space available in the Bootloader.

+
+
    +

  • Flash an SD card with a working image and create a third ext4 partition. Copy +the WIC image (for example phytec-qt6demo-image.rootfs.wic) to this partition.

    • +

  • Configure the bootmode switch (S3) to SD Card and insert the SD Card.

    • +

  • Power on the board and stop in U-Boot.

    • +

  • Load the image:

    +
    u-boot=> mmc dev 1
+u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • Switch the mmc dev to eMMC:

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • Flash your WIC image (for example phytec-qt6demo-image.roots.wic) +from the SD card to eMMC. This will partition the card and copy imx-boot, +Image, dtb, dtbo, and root file system to eMMC.

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • Power off the board and change the bootmode switch (S3) to eMMC.

    • +
+
+
+

4.2.4.2. Flash eMMC from SD card in Linux on Target

+

You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card.

+
    +

  • Show your saved partup package or WIC image files on the SD card:

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
    +
    +
    • +

  • Write the image to the phyCORE-i.MX 8M Plus eMMC (MMC device 2 without +partition) using partup:

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup /dev/mmcblk2
+
    +
    +

    Flashing the partup package has the advantage of using the full capacity of +the eMMC device, adjusting partitions accordingly.

    +
    +

    Note

    +

    Alternatively, bmaptool may be used instead:

    +
    target:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
    +
    +

    Keep in mind that the root partition does not make use of the full space when +flashing with bmaptool.

    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Warning

    +

    Before this will work, you need to configure the bootmode switch (S3) to eMMC.

    +
    +
    • +
+
+
+
+
+

4.3. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A6 RAUC Update & Device Management Manual.

+
+
+
+

5. Development

+
+

5.1. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.1.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.2. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.2.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel image to your tftp directory:

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • Copy the devicetree to your tftp directory:

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.2.2. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.3.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/phyboard-pollux-imx8mp-3/. For flashing a wic image to eMMC, +you will also need phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic

+
+
+

5.3.3. Prepare Target

+

Set the bootmode switch (S3) to USB Serial Download. Also, connect USB port +X5 (upper connector) to your host.

+
+
+

5.3.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via (X1), as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.3.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
+
+
+
+
+

5.4. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone https://github.com/phytec/u-boot-phytec.git)

+
+
+

5.4.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    https://github.com/phytec/u-boot-phytec.git
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-phytec and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    https://github.com/phytec/linux-phytec.git
+
    +
    +
    • +

  • Our i.MX 8M Plus kernel is based on the linux-phytec kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
recipes-kernel/linux/linux-phytec_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-phytec_*.bb
+
+
+
+
+
+

5.4.2. Get the SDK

+

You can download the SDK here, or build it yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

After a successful build the SDK installer is deployed to build/deploy*/sdk.

+
+
+

5.4.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.1.sh
+host:~$ ./phytec-ampliphy-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.1.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-xwayland/5.0.1):
+You are about to install the SDK to "/opt/ampliphy-xwayland/5.0.1". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-xwayland/5.0.1/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. U-Boot standalone build

+
+

5.5.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone https://github.com/phytec/u-boot-phytec.git
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag used in this release is called v2024.01-phy4

    • +

  • Check out the needed U-Boot tag:

    +
    host:~$ cd ~/u-boot-phytec/
+host:~/u-boot-phytec$ git fetch --all --tags
+host:~/u-boot-phytec$ git checkout tags/v2024.01-phy4
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/u-boot-phytec$ source /opt/ampliphy-xwayland/5.0.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. Get the needed binaries

+

To build the bootloader, you need to copy these files to your u-boot-phytec +build directory and rename them to fit with mkimage script:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx8mp.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +
+

If you already built our BSP with Yocto, you can get the +bl31-imx8mp.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: BSP Images

+

Or you can download the files here: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/

+
+

Warning

+

Make sure you rename the files you need so that they are compatible with the +mkimage tool.

+
+
+
+

5.5.3. Build the bootloader

+
    +

  • build flash.bin (imx-boot):

    +
    host:~/u-boot-phytec$ make phycore-imx8mp_defconfig
+host:~/u-boot-phytec$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. Flash the bootloader to a block device

+

The flash.bin can be found at u-boot-phytec/ directory and now can be +flashed. A chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

E.g. flash SD card:

+
host:~/u-boot-phytec$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables +“BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+

5.5.5. Build U-Boot With a Fixed RAM Size

+

If you cannot boot your system anymore because the hardware introspection in the +EEPROM is damaged or deleted, you can create a flash.bin with a fixed ram size. +You should still contact support and flash the correct EEPROM data, as this +could lead to unexpected behavior.

+

Follow the steps to get the U-boot sources and check the correct branch in the +Build U-Boot section.

+

Edit the file configs/phycore-imx8mp_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+
+
+

Choose the correct RAM size as populated on the board and uncomment the line for +this ram size. +After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+

5.5.6. Build U-Boot With a Fixed RAM Size and Frequency

+

Starting with PD23.1.0 NXP or PD24.1.2 mainline release, the phyCORE-i.MX 8M Plus SoMs +with revision 1549.3 and newer also support 2GHz RAM timings. These will be +enabled for supported boards automatically, but they can also be enabled or +disabled manually.

+

Edit the file configs/phycore-imx8mp_defconfig. +The fixed RAM size with 2GHz timings will be used:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+CONFIG_PHYCORE_IMX8MP_RAM_FREQ_FIX=y
+CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+
+
+

After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+

5.5.7. Build U-Boot With a Fixed RAM Frequency

+

Starting with PD24.1.2 mainline release or PD24.1.0 NXP release, U-Boot can +also be built with just fixed RAM Frequency while the RAM size will still be +used from EEPROM.

+

Edit the file configs/phycore-imx8mp_defconfig. +The RAM size from EEPROM with fixed frequency will be used:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_FREQ_FIX=y
+# CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+# CONFIG_PHYCORE_IMX8MP_USE_1_5GHZ_RAM_TIMINGS=y
+
+
+

After saving the changes, follow the remaining steps from Build U-Boot.

+
+
+
+

5.6. Kernel standalone build

+
+

5.6.1. Setup sources

+
    +

  • The used linux-phytec branch can be found in the release notes

    • +

  • The tag needed for this release is called v6.6.21-phy1

    • +

  • Check out the needed linux-phytec tag:

    +
    host:~$ git clone https://github.com/phytec/linux-phytec.git
+host:~$ cd ~/linux-phytec/
+host:~/linux-phytec$ git fetch --all --tags
+host:~/linux-phytec$ git checkout tags/v6.6.21-phy1
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-phytec$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-phytec$ source /opt/ampliphy-xwayland/5.0.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-phytec$ make defconfig
+host:~/linux-phytec$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-phytec$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-phytec/arch/arm64/boot/Image

    • +

  • The dtb can be found at +~/linux-phytec/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-phytec$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. Copy Kernel to SD Card

+

When one-time boot via netboot is not sufficient, the kernel along with its +modules and the corresponding device tree blob may be copied directly to a +mounted SD card.

+
host:~/linux-phytec$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-phytec$ cp arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb /path/to/sdcard/boot/oftree
+host:~/linux-phytec$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. Accessing the Development states

+
+

5.7.1. Development state of current release

+

These release manifests exist to give you access to the development states +of the Yocto BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line:

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2
+
+
+

This will initialize a BSP that will track the latest development state of the +current release (BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2). From now on repo sync in this folder +will pull all the latest changes from our Git repositories:

+
host:~$ repo sync
+
+
+
+
+

5.7.2. Development state of upcoming release

+

Also development states of upcoming releases can be accessed this way. +For this execute the following command and look for a release with a higher +PDXX.Y number than the latest one (BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2) and .y at the +end:

+
host:~$ ./phyLinux init -p imx8mp
+
+
+
+
+
+

5.8. Accessing the Latest Upstream Support

+

We have a vanilla manifest that makes use of the Yocto master branches (not an +NXP release), Linux, and U-Boot. This can be used to test the latest upstream +kernel/U-Boot.

+
+

Note

+

The master manifest reflects the latest state of development. This tends to +be broken from time to time. We try to fix the master on a regular basis.

+
+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.9.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 8M Plus SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Board.dts - include the module dtsi file. Devices that come from the i.MX 8M Plus +SoC but are just routed down to the carrier board and used there are included +in this dts.

    • +

  • Overlay.dtso - enable/disable features depending on optional hardware that +may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10)

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 8 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the folder arch/arm64/boot/dts/freescale/.

+

Available overlays for phyboard-pollux-imx8mp-3.conf are:

+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 8M Plus BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 8M Plus BSP Device Tree Concept to get an understanding +of our i.MX 8 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 8 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 8M Plus Pin Muxing

+

The i.MX 8M Plus SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 8M Plus terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 8M Plus Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx8mp-phyboard-pollux-rdk.dts:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x140
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x140
+        >;
+};
+
+
+

The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled.

+

The device tree representation for UART1 pinmuxing: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L387

+
+
+

7.2. RS232/RS485

+

The phyCORE-i.MX 8M Plus supports up to 4 UART units. On the phyBOARD-Pollux, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector X2 at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers JP3 and +JP4 on the baseboard. For more information about the correct setup please +refer to the phyCORE-i.MX 8M Plus/phyBOARD-Pollux Hardware Manual section UARTs.

+

We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers JP3 and JP4 need to be set +correctly.

+
+

7.2.1. RS232

+
    +

  • Display the current settings of a terminal in a human-readable format:

    +
    target:~$ stty -a
+
    +
    +
    • +

  • Configuration of the UART interface can be done with stty. For example:

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • With a simple echo and cat, basic communication can be tested. Example:

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

The host should print out “123”.

+
+
+

7.2.2. RS485

+
+

Hint

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

For easy testing, look at the linux-serial-test. This tool is called the IOCTL +for RS485 and sends a constant stream of data.

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

More information about the linux-serial-test tool and its parameters can be +found here: linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Documentation for calling the IOCTL within c-code is described in the Linux +kernel documentation: +https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection3.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see “test” printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final “count for this session”. There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+
+
+

7.2.2.2. RS485 full-duplex

+

For full-duplex mode your connection setup should look like this:

+../../../_images/RS485_fullduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For full-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 1
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  true
+Bus termination enabled:  false
+
+
+

Also here you can do the echo test to see if sending and receiving works:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see “test” printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

To check if the full-duplex operation works, you need to use the +linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=114660, tx=118755, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=118755, tx=114660, rx err=0
+
+
+

In this example both targets will send and receive simultaneously. They will +receive for 15sec and send for 10sec. The receiver needs to receive a bit +longer, so that all sent messages will get received. Remember to start both +targets almost simultaneously. A small difference in start time is accounted +for with the -W 2 option. At the end the program will print the final +“count for this session”. There you can check that all transmitted frames were +received.

+

All the test examples are target to target, but can also be done with host to +target with a USB to rs485 converter. You may need to adjust the interfaces for +commands to work on the host then.

+

The device tree representation for RS232 and RS485: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L251

+
+
+
+
+

7.3. Network

+

phyBOARD-Pollux-i.MX 8M Plus provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board.

+
+

Warning

+

The naming convention of the Ethernet interfaces in the hardware (ethernet0 +and ethernet1) do not align with the network interfaces (eth0 and eth1) in +Linux. So, be aware of these differences:

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L41.

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Pollux can be found here: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L106

+
+

7.3.1. Network Environment Customization

+
+

7.3.1.1. U-boot network-environment

+
    +

  • We currently use dynamic IP addresses in U-Boot. This is enabled by this variable:

    +
    +
    u-boot=> printenv ip_dyn
+ip_dyn=yes
+
    +
    +
    +
    • +

  • Set up path for NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+
+

7.3.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+
+

7.4. SD/MMC Card

+

The i.MX 8M Plus supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://github.com/phytec/linux-phytec//blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L261

+

DT configuration for the eMMC interface can be found here: +https://github.com/phytec/linux-phytec//blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L181

+
+
+

7.5. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 8M Plus is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw Multi-Level Cells (MLC) or Triple-Level +Cells (TLC) combined with a memory controller that handles ECC and wear +leveling. They are connected via an SD/MMC interface to the i.MX 8M Plus and are +represented as block devices in the Linux kernel like SD cards, flash drives, or +hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.5.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +or TLC. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background Operations +(BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • Enabling can be done with this command:

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.5.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 8M Plus SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.5.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
+
+

7.5.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC or TLC +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC used in NAND Flash, MLC or TLC have lower reliability and a higher +error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC or TLC +or mark these blocks as discard. The data on the device is lost and +will be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.5.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 8M Plus uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.5.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

The following table is for the offset of the i.MX 8M Plus SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.6. SPI Master

+

The i.MX 8M Plus controller has a FlexSPI and an ECSPI IP core included. The FlexSPI +host controller supports two SPI channels with up to 4 devices. Each channel +supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data +lines). The ECSPI controller supports 3 SPI interfaces with one dedicated chip +selected for each interface. As chip selects should be realized with GPIOs, more +than one device on each channel is possible.

+

The definition of the SPI master node in the device tree can be found here: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L67

+
+
+

7.7. GPIOs

+

The phyBOARD-Pollux has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to i.MX 8M Plus pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal i.MX 8M Plus GPIO banks GPIO1 – GPIO5.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO5_07). <X> identifies the GPIO +bank and counts from 1 to 5, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo -c gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 20 from chip0):

    +
    target:~$ gpioget -c gpiochip0 20
+
    +
    +
    • +

  • Set the value of GPIO 20 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset -z -c gpiochip0 20=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <line=value>...
+
+Set values of GPIO lines.
+
+Lines are specified by name, or optionally by offset if the chip option
+is provided.
+Values may be '1' or '0', or equivalently 'active'/'inactive' or 'on'/'off'.
+
+The line output state is maintained until the process exits, but after that
+is not guaranteed.
+
+Options:
+      --banner            display a banner on successful startup
+  -b, --bias <bias>       specify the line bias
+                  Possible values: 'pull-down', 'pull-up', 'disabled'.
+                  (default is to leave bias unchanged)
+      --by-name           treat lines as names even if they would parse as an offset
+  -c, --chip <chip>       restrict scope to a particular chip
+  -C, --consumer <name>   consumer name applied to requested lines (default is 'gpioset')
+  -d, --drive <drive>     specify the line drive mode
+                  Possible values: 'push-pull', 'open-drain', 'open-source'.
+                  (default is 'push-pull')
+  -h, --help              display this help and exit
+  -l, --active-low        treat the line as active low
+  -p, --hold-period <period>
+                  the minimum time period to hold lines at the requested values
+  -s, --strict            abort if requested line names are not unique
+  -t, --toggle <period>[,period]...
+                  toggle the line(s) after the specified period(s)
+                  If the last period is non-zero then the sequence repeats.
+      --unquoted  don't quote line names
+  -v, --version           output version information and exit
+  -z, --daemonize set values then detach from the controlling terminal
+
+Chips:
+    A GPIO chip may be identified by number, name, or path.
+    e.g. '0', 'gpiochip0', and '/dev/gpiochip0' all refer to the same chip.
+
+Periods:
+    Periods are taken as milliseconds unless units are specified. e.g. 10us.
+    Supported units are 's', 'ms', and 'us'.
+
+*Note*
+    The state of a GPIO line controlled over the character device reverts to default
+    when the last process referencing the file descriptor representing the device file exits.
+    This means that it's wrong to run gpioset, have it exit and expect the line to continue
+    being driven high or low. It may happen if given pin is floating but it must be interpreted
+    as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.7.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the defconfig you use in +arch/arm64/configs/ in the linux kernel sources. For our NXP based releases, +this could be for example imx8_phytec_distro.config:

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+
+
+
+

7.8. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the phyBOARD-Pollux.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L160

+
+
+

7.9. I²C Bus

+

The i.MX 8M Plus contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 8M Plus. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our phyBOARD-Pollux.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C1 bus configuration (e.g. imx8mp-phycore-som.dtsi): +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L81

+

General I²C2 bus configuration (e.g. imx8mp-phyboard-pollux-rdk.dts) +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L145

+
+
+

7.10. EEPROM

+

On the phyCORE-i.MX8MP there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues.

+
+

Note

+

If you deleted reserved EEPROM spaces, please contact our support!

+
+
+

7.10.1. I2C EEPROM on phyCORE-i.MX8MP

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

The I2C EEPROM on the phyCORE-i.MX8MP SoM is connected to I2C address 0x51 on the I2C-0 +bus. It is possible to read and write directly to the device populated:

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the 4KiB EEPROM (bus: I2C-0 addr: 0x51) with zeros leaving out the EEPROM data use:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM Detection

+

The I2C EEPROM, populated on the phyCORE-i.MX8MP, has a separate ID page that is +addressable over I2C address 0x59 on bus 0 and a normal area that is addressable +over I2C address 0x51 on bus 0. PHYTEC uses this data area of 32 Bytes to store +information about the SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the EEPROM ID page data and the first 256 bytes of the normal area are +deleted, the bootloader will fall back to the phyCORE-i.MX8MP Kit RAM setup, which +is 2GiB RAM.

+
+

Warning

+

The EEPROM ID page (bus: I2C-0 addr: 0x59) and the first 256 bytes of the +normal EEPROM area (bus: I2C-0 addr: 0x51) should not be erased or +overwritten. As this will influence the behavior of the bootloader. The board +might not boot correctly anymore.

+
+

SoMs that are flashed with data format API revision 2 will print out information +about the module in the early stage.

+

DT representation, e.g. in phyCORE-i.MX 8M Plus file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L169

+
+
+
+

7.11. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC Parameters

+

RTCs have a few abilities which can be read/set with the help of hwclock +tool.

+
    +

  • We can check RTC supported features with:

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    What this value means is encoded in kernel, each set bit translates to:

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • We can check RTC BSM (Backup Switchover Mode) with:

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • We can set RTC BSM with:

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    What BSM values mean translates to these values:

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    Tip

    +

    You should set BSM mode to DSM or LSM for RTC to switch to backup power +source when the initial power source is not available. Check RV-3028 RTC +datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching +Mode) actually mean.

    +
    +
    • +
+

DT representation for I²C RTCs: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L175

+
+
+
+

7.12. USB Host Controller

+

The USB controller of the i.MX 8M Plus SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +‘SS’). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY.

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+

DT representation for USB Host: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L220

+
+
+

7.13. CAN FD

+

The phyBOARD-Pollux has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The two CAN interfaces should show up as +can0 and can1.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    The information for can0 will look like:

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+
+

Warning

+

The mcp2518fd SPI to CANfd supports only baudrates starting from 125kB/s. +Slower rates can be selected but may not work correctly.

+
+

Device Tree CAN configuration of imx8mp-phyboard-pollux-rdk.dts: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L130

+
+
+

7.14. Video

+
+

7.14.1. Videos with Gstreamer

+

One example video is installed by default in the BSP at /usr/share/qtphy/videos/. +Start the video playback with one of these commands:

+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink fullscreen=true
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+

Note

+

The mainline BSP currently only supports software rendering.

+
+
+
+
+

7.15. Display

+

The phyBOARD-Pollux supports LVDS output via the LVDS1 connector on the carrier board. The +LVDS interface is enabled by default.

+
+

7.15.1. Weston Configuration

+

Weston will work without any additional configuration. Configuration options are +done at /etc/xdg/weston/weston.ini.

+

Device tree description of LVDS can be found here: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L182

+
+
+

7.15.2. Qt Demo

+

With the phytec-qt6demo-image, Weston starts during boot. Our Qt6 demo application named +“qtphy” can be stopped with:

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • To start the demo again, run:

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • To disable autostart of the demo, run:

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • To enable autostart of the demo, run:

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston can be stopped with:

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

Note

+

The Qt demo must be closed before Weston can be closed.

+
+
+
+

7.15.3. Backlight Control

+

If a display is connected to the PHYTEC board, you can control its backlight +with the Linux kernel sysfs interface. All available backlight devices in the +system can be found in the folder /sys/class/backlight. Reading the appropriate +files and writing to them allows you to control the backlight.

+
+

Note

+

Some boards with multiple display connectors might have multiple backlight +controls in /sys/class/backlight. For example: backlight0 and backlight1

+
+
    +

  • To get, for example, the maximum brightness level (max_brightness) execute:

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    Valid brightness values are 0 to <max_brightness>.

    +
    • +

  • To obtain the current brightness level, type:

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • Write to the file brightness to change the brightness:

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    turns the backlight off for example.

    +

    For documentation of all files, see +https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight.

    +
    • +
+
+

Note

+

We noticed some visible backlight flickering on brightness level 1 (probably +due to frequency problems with the hardware).

+
+
+
+
+

7.16. Power Management

+
+

7.16.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 8M Plus SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as ‘Dynamic Voltage and +Frequency Scaling’ (DVFS). The i.MX 8M Plus BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the i.MX 8 +variant used, several different frequencies are supported.

+
+

Tip

+

Although the DVFS framework provides frequency settings for each CPU core, a +change in the frequency settings of one CPU core always affects all other CPU +cores too. So all CPU cores always share the same DVFS setting. An individual +DVFS setting for each core is not possible.

+
+
    +

  • To get a complete list type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately +1,6 GHz, the result will be:

    +
    1200000 1600000
+
    +
    +
    • +

  • To ask for the current frequency type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

So-called governors are automatically selecting one of these frequencies in +accordance with their goals.

+
    +

  • List all governors available with the following command:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    The result will be:

    +
    ondemand userspace performance schedutil
+
    +
    +
    • +

  • ondemand (default) switches between possible CPU core frequencies in +reference to the current system load. When the system load increases above a +specific limit, it increases the CPU core frequency immediately.

    • +

  • performance always selects the highest possible CPU core frequency.

    • +

  • userspace allows the user or userspace program running as root to set a +specific frequency (e.g. to 1600000). Type:

    • +

  • In order to ask for the current governor, type:

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    You will normally get:

    +
    schedutil
+
    +
    +
    • +

  • Switching over to another governor (e.g. userspace) is done with:

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • Now you can set the speed:

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +Documentation/admin-guide/pm/cpufreq.rst.

+
+
+

7.16.2. CPU Core Management

+

The i.MX 8M Plus SoC can have multiple processor cores on the die. The i.MX 8M Plus, for +example, has 4 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    Here the system has four processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+
+

7.17. Thermal Management

+
+

7.17.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.17.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 8M Plus SoC platform. The i.MX 8 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Industrial +and Commercial.

+ + + + + + + + + + + + + + + + + +

Commercial

Industrial

passive (warning)

85°C

95°C

critical (shutdown)

90°C

100°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise, Fair Share, Bang Bang, and +Userspace. The default policy used in the BSP is step_wise. If the value of the +SoC temperature in the sysfs file temp is above trip_point_0, the CPU frequency +is set to the lowest CPU frequency. When the SoC temperature drops below +trip_point_0 again, the throttling is released.

+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+
+

7.18. Watchdog

+

The PHYTEC i.MX 8M Plus modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.18.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.19. snvs Power Key

+

The X_ONOFF pin connected to the ON/OFF button can be pressed long to trigger +Power OFF without SW intervention. With the snvs_pwrkey driver, the KEY_POWER +event is also reported to userspace when the button is pressed. On default, systemd +is configured to ignore such events. The function of Power OFF without SW +intervention are not configured. Triggering a power off with systemd when pushing +the ON/OFF button can be configured under /etc/systemd/logind.conf and set using:

+
HandlePowerKey=poweroff
+
+
+
+
+

7.20. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 8M Plus provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 8M Plus Reference Manual). The following list is +an abstract from the i.MX 8M Plus Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x30350000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x30350000

Description

OCOTP_MAC_ADDR0

9

0

0x640

contains lower 32 bits +of ENET0 MAC address

OCOTP_MAC_ADDR1

9

1

0x650

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

OCOTP_MAC_ADDR2

9

2

0x660

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 8M Plus Security Reference Manual.

+
+

7.20.1. Reading Fuse Values in uBoot

+

You can read the content of a fuse using memory-mapped shadow registers. To +calculate the memory address, use the fuse Bank and Word in the following +formula:

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.20.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx9/imx9.html b/previews/271/bsp/imx9/imx9.html new file mode 100644 index 000000000..2c31bfe4d --- /dev/null +++ b/previews/271/bsp/imx9/imx9.html @@ -0,0 +1,155 @@ + + + + + + + + + i.MX 9 Manuals — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+ +
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx9/imx93/imx93.html b/previews/271/bsp/imx9/imx93/imx93.html new file mode 100644 index 000000000..fb6563bdb --- /dev/null +++ b/previews/271/bsp/imx9/imx93/imx93.html @@ -0,0 +1,401 @@ + + + + + + + + + i.MX 93 Manuals — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

i.MX 93 Manuals

+
+

BSP-Yocto-NXP-i.MX93-PD24.2.0

+
+

Table of Contents

+ +
+
+
+

BSP-Yocto-NXP-i.MX93-PD24.1.1

+
+

Table of Contents

+ +
+
+
+

BSP-Yocto-NXP-i.MX93-PD24.1.0

+
+

Table of Contents

+ +
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx9/imx93/pd24.1.0.html b/previews/271/bsp/imx9/imx93/pd24.1.0.html new file mode 100644 index 000000000..5dfd8fa47 --- /dev/null +++ b/previews/271/bsp/imx9/imx93/pd24.1.0.html @@ -0,0 +1,3823 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 93 BSP Manual

Document Title

i.MX 93 BSP Manual

Document Type

BSP Manual

Yocto Manual

Mickledore

Release Date

2024/01/31

Is Branch of

i.MX 93 BSP Manual

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-NXP-i.MX93-PD24.1.0

Major

2024/01/31

Released

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +phyBOARD-Segin i.MX 93 Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-91-93/#downloads of our product.

+
+

1.1. Supported Hardware

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-NXP-i.MX93-PD24.1.0, see download.

+

If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware.

+
+

1.1.1. phyBOARD-Segin i.MX 93 Components

+
+../../../_images/phyBOARD-Segin-iMX93-top-components.jpg + +
+

phyBOARD-Segin i.MX 93 Components (top)

+
+
+
+../../../_images/phyBOARD-Segin-iMX93-bottom-components.jpg + +
+

phyBOARD-Segin i.MX 93 Components (bottom)

+
+
+
+
+

1.1.2. phyBOARD-Nash i.MX 93 Components

+
+../../../_images/phyBOARD-Nash-iMX93-top-components.jpg + +
+

phyBOARD-Nash i.MX 93 Components (top)

+
+
+
+../../../_images/phyBOARD-Nash-iMX93-bottom-components.jpg + +
+

phyBOARD-Nash i.MX 93 Components (bottom)

+
+
+
+
+
+
+

2. Getting Started

+

The phyBOARD-Segin i.MX 93 Kit is shipped with a pre-flashed SD card. It contains the +phytec-qt6demo-image and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+

There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool dd. An +alternative way is to use PHYTEC’s system initialization program called +partup, which makes it especially easy to +format more complex systems. You can get prebuilt Linux binaries of partup from its release page. Also read +partup’s README for installation +instructions.

+
+

2.1. Get the Image

+

The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using dd, can be downloaded from the PHYTEC download server.

+

Get either the partup package or the WIC image from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz
+
+
+
+

Note

+

For eMMC, more complex partitioning schemes or even just large images, we +recommend using the partup package, as it is faster in writing than dd +and allows for a more flexible configuration of the target flash device.

+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card, you must have root privileges on your Linux +host PC. Be very careful when specifying the destination device! All files +on the selected device will be erased immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system on your host PC!

+
+
+

2.2.1. Finding the Correct Device

+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+

Unmount all those partitions, e.g.:

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

Now, the SD card is ready to be flashed with an image, using either partup, +dd or bmap-tools.

+
+
+

2.2.2. Using bmap-tools

+

One way to prepare an SD card is using +bmap-tools. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host:~$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

Replace <your_device> with your actual SD card’s device name found previously, +and make sure to place the file <IMAGENAME>-<MACHINE>.wic.bmap alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip.

+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.2.3. Using partup

+

Writing to an SD card with partup is done in a single command:

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).partup /dev/<your_device>
+
+
+

Make sure to replace <your_device> with your actual device name found previously.

+

Further usage of partup is explained at its official documentation website.

+
+

Warning

+

Host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to write partup packages created with Yocto Mickledore +or newer to SD-Card. This is due to a new default option in resize2fs which causes an +incompatibility. See release notes.

+
+
+

Note

+

partup has the advantage of allowing to clear specific raw areas in the +MMC user area, which is used in our provided partup packages to erase any +existing U-Boot environments. This is a known issue bmaptool does not +solve, as mentioned in the previous chapter.

+

Another key advantage of partup over other flashing tools is that it allows +configuring MMC specific parts, like writing to eMMC boot partitions, without +the need to call multiple other commands when writing.

+
+
+
+

2.2.4. Using dd

+

After having unmounted all SD card’s partitions, you can create your bootable SD card.

+

Some PHYTEC BSPs produce uncompressed images (with filename-extension *.wic), +and some others produce compressed images (with filename-extension *.wic.xz).

+

To flash an uncompressed images (*.wic) use command below:

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Or to flash a compressed images (*.wic.xz) use that command:

+
host:~$ xzcat phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Again, make sure to replace <your_device> with your actual device name found +previously.

+

The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

+
+
+
+

2.3. First Start-up

+ +../../../_images/SD_Card_Boot.png +
    +

  • Insert the SD card

    • +

  • Connect the target (serial connector on PEB-EVAL-01) and the host with serial +cable

    • +

  • Power up the board

    • +

  • Open serial port with 115200 baud and 8N1 (you should see u-boot/linux start on the console

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 93 BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (mickledore).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (mickledore).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-i.MX93; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-wayland MACHINE=phyboard-segin-imx93-2 ./phyLinux init -p imx93 -r BSP-Yocto-NXP-i.MX93-PD24.1.0
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the phyboard-segin-imx93-2 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx93.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_dmem_1d_v202201.bin, lpddr4_dmem_2d_v202201.bin, +lpddr4_imem_1d_v202201.bin, +lpddr4_imem_2d_v202201.bin: DDR PHY firmware images

    • +

  • imx-boot: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM +Trusted Firmware and DDR firmware. This is the final bootloader image which is +bootable.

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx93-phyboard-segin.dtb: Kernel device tree file

    • +

  • imx93-phy*.dtbo: Kernel device tree overlay files

    • +

  • phytec-*.tar.gz: Root file system, +of bitbake-image that was built.

    +
      +

    • phytec-qt6demo-image-phyboard-segin-imx93-2.tar.gz: when bitbake-build +was processed for phytec-qt6demo-image

      • +

    • phytec-headless-image-phyboard-segin-imx93-2.tar.gz: when bitbake-build +was processed for phytec-headless-image

      • +
    +
    • +

  • phytec-*.wic.xz: Compressed bootable SD +card image of bitbake-image that was built. Includes bootloader, DTBs, Kernel +and Root file system.

    +
      +

    • phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz: when bitbake-build +was processed for phytec-qt6demo-image

      • +

    • phytec-headless-image-phyboard-segin-imx93-2.wic.xz: when bitbake-build +was processed for phytec-headless-image

      • +
    +
    • +

  • imx93-11x11-evk_m33_*.bin, binaries of demo applications for the +Cortex-M33 MCU; can be manually loaded and started with U-Boot or Linux

    • +
+
+
+
+
+

4. Installing the OS

+
+

4.1. Bootmode Switch (S3)

+
+

Tip

+

Hardware revision baseboard: 1472.5

+
+

The phyBOARD-Segin i.MX 93 features a boot switch with four individually switchable ports to +select the phyCORE-i.MX 93 default bootsource.

+ + + + + + + + + +
+../../../_images/eMMC.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses.png +
+

Internal Fuses

+
+
+
+../../../_images/USB_Serial_Download.png +
+

USB Serial Download

+
+
+
+../../../_images/SD_Card_Boot.png +
+

SD Card

+
+
+
+
+
+

4.2. Flash eMMC

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S3) is set to eMMC.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk0p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from SD Card

+

If there is no network available, you can update the eMMC from SD card. For +that, you only need a ready-to-use image file (*.wic) located on the +SD card. Because the image file is quite large, you have to enlarge your SD card +to use its full space (if it was not enlarged before). To enlarge your SD card, +see Resizing ext4 Root Filesystem.

+

Alternatively, flash a partup package to the SD card, as described in +Getting Started. This will ensure the full space of the SD card is used.

+
+

4.2.1.1. Flash eMMC from SD card in Linux on Target

+

You can flash the eMMC on Linux. You only need a partup package or WIC image +saved on the SD card.

+
    +

  • Show your saved partup package or WIC image or WIC.XZ image files on the SD card:

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.partup
+phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz
+
    +
    +
    • +

  • Show list of available MMC devices:

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk0
+mmcblk0boot0
+mmcblk0boot1
+mmcblk0p1
+mmcblk0p2
+mmcblk0rpmb
+
    +
    +
    • +

  • The eMMC device can be recognized by the fact that it contains two boot +partitions: (mmcblk0boot0; mmcblk0boot1)

    • +

  • Write the image to the phyCORE-i.MX 93 eMMC (/dev/mmcblk0 without +partition) using partup:

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-segin-imx93-2.partup /dev/mmcblk0
+
    +
    +
    +

    Tip

    +

    Using partup is highly recommended since it is easier to use and has the +advantage of using the full capacity of the eMMC device, adjusting +partitions accordingly.

    +
    +
    +

    Note

    +

    Alternatively, dd may be used instead.

    +

    For uncompressed WIC images (*.wic):

    +
    target:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.wic of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +

    For compressed WIC images (*.wic.xz):

    +
    target:~$ zstdcat phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz | sudo dd of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +

    Keep in mind that the root partition does not make use of the full space +when flashing with dd.

    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Warning

    +

    Before this will work, you need to configure the bootmode switch (S3) to eMMC.

    +
    +
    • +
+
+
+
+

4.2.2. Flash eMMC from Network

+

i.MX 93 boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

Note

+

Some PHYTECs BSPs produce compressed .wic.xz images. In this case, the +compressed image must first be uncompressed.

+
host:~$ unxz phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz
+
+
+
+
+

4.2.2.1. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Take an uncompressed image on the host and send it with ssh through +the network to the eMMC of the target with a one-line command:

+
target:~$ ssh <USER>@192.168.3.10 "dd if=<path_to_file>/phytec-qt6demo-image-phyboard-segin-imx93-2.wic" | dd of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
+
+
+
+

4.2.2.2. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Show your available image files on the host:

+
host:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.wic
+
+
+

Send the image with the dd command combined with ssh through the network +to the eMMC of your device:

+
host:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.wic bs=1M status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk0 conv=fsync"
+
+
+
+
+
+

4.2.3. Flash eMMC U-Boot image via Network from running U-Boot

+

Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 0
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.4. Flash eMMC from USB

+
+

4.2.4.1. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-qt6demo-image-phyboard-segin-imx93-2.wic). Set the bootmode switch (S3) to SD Card.

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ cd /mnt
+target:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.wic
+
    +
    +
    • +

  • Show list of available MMC devices:

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk0
+mmcblk0boot0
+mmcblk0boot1
+mmcblk0p1
+mmcblk0p2
+mmcblk0rpmb
+
    +
    +
    • +

  • The eMMC device can be recognized by the fact that it contains two boot +partitions: (mmcblk0boot0; mmcblk0boot1)

    • +

  • Write the image to the phyCORE-i.MX 93 eMMC (/dev/mmcblk0 without partition):

    +
    target:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.wic of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Tip

    +

    Before this will work, you need to configure the bootmode switch (S3) to +eMMC.

    +
    +
    • +
+
+
+
+
+

4.3. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A5 RAUC Update & Device Management Manual.

+
+
+
+

5. Development

+
+

5.1. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.1.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.2. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.2.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel image to your tftp directory:

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • Copy the devicetree to your tftp directory:

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • Copy all the overlays you want to use into your tftp directory:

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-segin-imx93-2.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.2.2. Set the bootenv.txt for Netboot

+

Create a bootenv.txt file in your tftp directory and write the following variables into it.

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> has to be replaced with the devicetree overlay filenames that you want to use. +Separate the filenames by spaces. For example:

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

Tip

+

All supported devicetree overlays are in the device tree chapter.

+
+
+
+

5.2.3. Network Settings on Target

+

To customize the targets ethernet configuration, please follow the description +here: Network Environment Customization

+
+
+

5.2.4. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.3.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/phyboard-segin-imx93-2/. For flashing a wic image to eMMC, +you will also need phytec-qt6demo-image-phyboard-segin-imx93-2.wic.

+
+
+

5.3.3. Prepare Target

+

Set the bootmode switch (S3) to USB Serial Download. Also, connect USB port +X8 (USB micro/OTG connector) to your host.

+
+
+

5.3.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via serial connector on PEB-EVAL-01, as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.3.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 0 0 0 0
+u-boot=> mmc partconf 0
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-segin-imx93-2.wic
+
+
+
+
+
+

5.4. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone git://git.phytec.de/u-boot-imx)

+
+
+

5.4.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-imx and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • Our i.MX 93 kernel is based on the linux-imx kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. Get the SDK

+

You can download the SDK here, or build it yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

After a successful build the SDK installer is deployed to build/deploy*/sdk.

+
+
+

5.4.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-vendor-wayland-glibc-x86_64-phytec-qt6demo-image-cortexa55-toolchain-4.2.2.sh
+host:~$ ./phytec-ampliphy-vendor-wayland-glibc-x86_64-phytec-qt6demo-image-cortexa55-toolchain-4.2.2.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-wayland/4.2.2):
+You are about to install the SDK to "/opt/ampliphy-vendor-wayland/4.2.2". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-vendor-wayland/4.2.2/environment-setup-cortexa55-phytec-linux
+
+
+
+
+

5.4.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. U-Boot standalone build

+
+

5.5.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag needed at this release is called v2023.04_2.1.0-phy1

    • +

  • Check out the needed U-Boot tag:

    • +
+
host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2023.04_2.1.0-phy1
+
+
+
    +

  • Technically, you can now build the U-Boot, but practically there are some +further steps necessary:

    +
      +

    • Create your own development branch:

      +
      host:~/u-boot-imx$ git switch --create <new-branch>
+
      +
      +
      +

      Note

      +

      You can name your development branch as you like, this is just an example.

      +
      +
      • +
    +
    • +

  • Set up a build environment:

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor-wayland/4.2.2/environment-setup-cortexa55-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. Get the needed binaries

+

To build the imx-boot, you need to gather these files for +later use with imx-mkimage tool:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx93.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +

  • Container image: mx93a1-ahab-container.img

    • +
+

If you already built our BSP with Yocto, you can get +these files from the directory mentioned here: BSP Images

+

Or you can download the files from the PHYTEC download server (https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools/). +You can use the commands below to download all the files from that server:

+
host:~$ mkdir ./artefacts && cd ./artefacts
+host:~/artefacts$ wget \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//bl31-imx93.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//tee.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_dmem_1d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_dmem_2d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_imem_1d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_imem_2d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//mx93a1-ahab-container.img
+host:~/artefacts$ cd ..
+
+
+
+
+

5.5.3. Build the bootloader

+
    +

  • Build u-boot:

    +
    host:~/u-boot-imx$ make <defconfig>
+host:~/u-boot-imx$ make
+host:~/u-boot-imx$ cd ..
+
    +
    +
    +

    Note

    +

    In command above replace <defconfig> with phycore-imx93_defconfig.

    +
    +
    • +
+
+

5.5.3.1. Build final flash.bin with imx-mkimage

+
    +

  • Get imx-mkimage:

    +
    host:~$ git clone https://github.com/nxp-imx/imx-mkimage
+host:~$ cd imx-mkimage/
+host:~/imx-mkimage$ git checkout tags/lf-6.1.36_2.1.0
+
    +
    +
    • +

  • Copy firmware binaries into imx-mkimage

    +
    host:~/imx-mkimage$ cp ../artefacts/bl31-imx93.bin ./iMX9/bl31.bin
+host:~/imx-mkimage$ cp \
+                     ../artefacts/lpddr4_* \
+                     ../artefacts/mx93a1-ahab-container.img \
+                     ../artefacts/tee.bin \
+                     ./iMX9/
+
    +
    +
    • +

  • Copy u-boot binaries and DTB into imx-mkimage

    +
    host:~/imx-mkimage$ cp ../u-boot-imx/spl/u-boot-spl.bin ../u-boot-imx/u-boot.bin ./iMX9/
+host:~/imx-mkimage$ cp ../u-boot-imx/arch/arm/dts/<dtb> ./iMX9/
+
    +
    +
    +

    Note

    +

    In command above replace <dtb> with imx93-phyboard-segin.dtb.

    +
    +
    • +

  • Build final flash.bin binary

    +
    +
    host:~/imx-mkimage$ make SOC=iMX9 REV=A1 flash_singleboot
+
    +
    +
    +
    • +
+
+
+
+

5.5.4. Flash the bootloader to a block device

+

The flash.bin can be found at imx-mkimage/iMX9/ directory and now can be flashed. A +chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 93

32 kiB

0 kiB

/dev/mmcblk0

+

E.g. flash SD card:

+
host:~/imx-mkimage$ sudo dd if=./iMX9/flash.bin of=<sd-card> bs=1024 seek=32 conv=sync
+
+
+
+

Note

+

In the command above, replace <sd-card> with your sd-card device name. +For more information on how to find the device name, see the section +Finding the Correct Device in +Getting Started.

+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables “BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+
+

5.6. Kernel standalone build

+
+

5.6.1. Setup sources

+
    +

  • The used linux-imx branch can be found in the release notes

    • +

  • The tag needed for this release is called v6.1.36_2.1.0-phy1

    • +

  • Check out the needed linux-imx tag:

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v6.1.36_2.1.0-phy1
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor-wayland/4.2.2/environment-setup-cortexa55-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-imx$ make imx_v8_defconfig imx9_phytec_distro.config imx9_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-imx/arch/arm64/boot/Image

    • +

  • The dtb can be found at +~/linux-imx/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. Copy Kernel to SD Card

+

When one-time boot via netboot is not sufficient, the kernel along with its +modules and the corresponding device tree blob may be copied directly to a +mounted SD card.

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.7.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.7.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-qt6demo-image-phyboard-segin-imx93-2.wic image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-segin-imx93-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.7.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-qt6demo-image-phyboard-segin-imx93-2.wic image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-segin-imx93-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 93 BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 93 SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Board.dts - include the module dtsi file. Devices that come from the i.MX 93 +SoC but are just routed down to the carrier board and used there are included +in this dts.

    • +

  • Overlay.dtso - enable/disable features depending on optional hardware that +may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10)

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 9 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the folder arch/arm64/boot/dts/freescale/.

+

Available overlays for phyboard-segin-imx93-2.conf are:

+
imx93-phyboard-segin-peb-av-02.dtbo
+imx93-phyboard-segin-peb-eval-01.dtbo
+imx93-phycore-rpmsg.dtbo
+
+
+

The usage of overlays can be configured during runtime in Linux or U-Boot. +Overlays are applied during the boot process in the bootloader after the +boot command is called and before the kernel is loaded. The next sections +explain the configuration in more detail.

+
+

6.2.2.1. Set ${overlays} variable

+

The ${overlays} U-Boot environment variable contains a space-separated list +of overlays that will be applied during boot. Depending on the boot source the +overlays have to either be placed in the boot partition of eMMC/SD-Card or are +loaded over tftp. Overlays set in the $KERNEL_DEVICETREE Yocto machine variable +will be automatically added to the boot partition of the final WIC image.

+

The ${overlays} variable can be either set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=imx93-phyboard-segin-peb-eval-01.dtbo imx93-phyboard-segin-peb-av-02.dtbo
+
+
+
+

Note

+

Make sure the boot partition is mounted! If it is not you can mount it with:

+
target:~$ mount /dev/mmcblkXp0 /boot
+
+
+
+

Changes will take effect after the next reboot. If no bootenv.txt file is +available the overlays variable can be set directly in the U-Boot environment.

+
u-boot=> setenv overlays imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> printenv overlays
+overlays=imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> boot
+
+
+

If a user defined ${overlays} variable should be directly loaded from U-Boot +environment but there is still an external bootenv.txt available, the ${no_bootenv} +variable needs to be set as a flag:

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> boot
+
+
+

More information about the external environment can be found in +U-boot External Environment subsection of the +device tree overlay section.

+

We use the ${overlays} variable for overlays describing expansion boards +that can not be detected during run time. To prevent applying overlays listed in +the ${overlays} variable during boot, the ${no_overlays} variable can be +set to 1 in the bootloader environment.

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot External Environment

+

During the start of the Linux Kernel the external environment bootenv.txt +text file will be loaded from the boot partition of an MMC device or via TFTP. +The main intention of this file is to store the ${overlays} variable. This makes +it easy to pre-define the overlays in Yocto depending on the used machine. The +content from the file is defined in the Yocto recipe bootenv found in +meta-phytec: +https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=mickledore

+

Other variables can be set in this file, too. They will overwrite the existing +settings in the environment. But only variables evaluated after issuing the boot +command can be overwritten, such as ${nfsroot} or ${mmcargs}. Changing other +variables in that file will not have an effect. See the usage during netboot as +an example.

+

If the external environment can not be loaded the boot process will be anyway +continued with the values of the existing environment settings.

+
+
+

6.2.4. Change U-boot Environment from Linux on Target

+

Libubootenv is a tool included in our images to modify the U-Boot environment of +Linux on the target machine.

+

Print the U-Boot environment using the following command:

+
target:~$ fw_printenv
+
+
+

Modify a U-Boot environment variable using the following command:

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

Caution

+

Libubootenv takes the environment selected in a configuration file. The +environment to use is inserted there, and by default it is configured to use +the eMMC environment (known as the default used environment).

+

If the eMMC is not flashed or the eMMC environment is deleted, libubootenv +will not work. You should modify the /etc/fw_env.config file to match the +environment source that you want to use.

+
+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 93 BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 93 BSP Device Tree Concept to get an understanding +of our i.MX 9 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 9 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 93 Pin Muxing

+

The i.MX 93 SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 93 terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 93 Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx93-phyboard-segin.dts:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX93_PAD_UART1_RXD__LPUART1_RX     0x31e
+                MX93_PAD_UART1_TXD__LPUART1_TX     0x30e
+        >;
+};
+
+
+

The first part of the string MX93_PAD_UART1_RXD__LPUART1_RX names the pad +(in this example UART1_RXD). The second part of the string (LPUART1_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal pull up is +activated.

+

The device tree representation for UART1 pinmuxing: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n267

+
+
+

7.2. Network

+

phyBOARD-Segin i.MX 93-i.MX 93 provides two ethernet interfaces. A 100 megabit Ethernet is provided by our +module and board.

+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi?h=v6.1.36_2.1.0-phy1#n61.

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Segin i.MX 93 can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n114.

+
+

7.2.1. Network Environment Customization

+
+

7.2.1.1. U-boot network-environment

+
    +

  • To find the Ethernet settings in the target bootloader:

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • With your development host set to IP 192.168.3.10 and netmask 255.255.255.0, +the target should return:

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • If you need to make any changes:

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> should be one of ipaddr, netmask, gatewayip or serverip. +<value> will be the actual value of the chosen parameter.

    +
    • +

  • The changes you made are temporary for now. To save these:

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

Here you can also change the IP address to DHCP instead of using a static one.

+
    +

  • Configure:

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • Set up paths for TFTP and NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+

Tip

+

Variables like nfsroot and netargs can be overwritten by the U-boot External +Environment. For netboot, the external environment will be loaded from tftp. +For example, to locally set the nfsroot variable in a bootenv.txt file, +locate the tftproot directory:

+
nfsroot=/home/user/nfssrc
+
+
+

There is no need to store the info on the target. Please note that this does +not work for variables like ipaddr or serveraddr as they need to be already +set when the external environment is being loaded.

+
+
+
+

7.2.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+
+

7.3. SD/MMC Card

+

The i.MX 93 supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n216

+

DT configuration for the eMMC interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi?h=v6.1.36_2.1.0-phy1#n195

+
+
+

7.4. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 93 is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw Multi-Level Cells (MLC) or Triple-Level +Cells (TLC) combined with a memory controller that handles ECC and wear +leveling. They are connected via an SD/MMC interface to the i.MX 93 and are +represented as block devices in the Linux kernel like SD cards, flash drives, or +hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.4.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk0
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.4.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +or TLC. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background Operations +(BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • Enabling can be done with this command:

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops_en manual /dev/mmcblk0
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.4.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 93 SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk0 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.4.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk0 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk0: 7617MB
+Sect[ 1799.850385]  mmcblk0: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk0 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk0 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk0: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk0: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk0p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk0p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk0p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk0p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
+
+

7.4.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC or TLC +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC used in NAND Flash, MLC or TLC have lower reliability and a higher +error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk0 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk0:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk0
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk0
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk0 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk0 unit B print
+BYT;
+/dev/mmcblk0:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.4.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC or TLC +or mark these blocks as discard. The data on the device is lost and +will be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk0
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk0 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.4.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 93 uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.4.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk0boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk0boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk0boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk0boot1
+
+
+

The following table is for the offset of the i.MX 93 SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 93

32 kiB

0 kiB

/dev/mmcblk0

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk0
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk0
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk0
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk0
+
+
+
+
+

7.4.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk0
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk0p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk0p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk0
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk0p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk0p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk0p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk0p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk0p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.5. GPIOs

+

The phyBOARD-Segin i.MX 93 doesn’t have a set of pins especially dedicated for user I/Os since +all GPIOs are used by kernel device drivers or used for a specific purpose. The +processor has organized its GPIOs into five banks of 32 GPIOs each (GPIO1 – +GPIO4) GPIOs. gpiochip0, gpiochip32, gpiochip64 and gpiochip96 are the sysfs +representation of these internal i.MX 93 GPIO banks GPIO1 – GPIO4.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO4_07). <X> identifies the GPIO +bank and counts from 1 to 4, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [43810080.gpio] (32 lines)
+gpiochip1 [43820080.gpio] (32 lines)
+gpiochip2 [43830080.gpio] (32 lines)
+gpiochip3 [47400080.gpio] (32 lines)
+
    +
    +
    • +
+
+

Note

+

Order of GPIOchips in i.MX 93 Application Processor Reference Manual and +in Linux kernel differ!

+ + + + + + + + + + + + + + + + + + + + + + + +

GPIOchip address

Linux

Reference Manual

0x43810080

gpiochip0

gpiochip2

0x43820080

gpiochip1

gpiochip3

0x43830080

gpiochip2

gpiochip4

0x47400080

gpiochip3

gpiochip1

+
+
    +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 3 from chip0):

    +
    target:~$ gpioget gpiochip0 3
+
    +
    +
    • +

  • Set the value of GPIO 3 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset --mode=exit gpiochip0 3=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.5.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the +imx9_phytec_distro.config config fragment in the linux kernel sources +under arch/arm64/configs

+
..
+CONFIG_GPIO_SYSFS=y
+..
+
+
+
+
+
+

7.6. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+green:heartbeat@  mmc0::@  mmc1::@  yellow:@
+
+
+

Here the LEDs green:heartbeat is on the phyCORE-i.MX93. If you are using +phyBOARD-Segin there is also yellow LED which is populated on the +PEB-EVAL-01.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 1 > /sys/class/leds/green\:heartbeat/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/green\:heartbeat/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-eval-01.dtso?h=v6.1.36_2.1.0-phy1#n33

+
+
+

7.7. I²C Bus

+

The i.MX 93 contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 93. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our phyBOARD-Segin i.MX 93.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C1 bus configuration (e.g. imx93-phycore-som.dtsi): +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi?h=v6.1.36_2.1.0-phy1#n88

+

General I²C2 bus configuration (e.g. imx93-phyboard-segin.dts) +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n155

+
+
+

7.8. EEPROM

+

There are two different I2C EEPROM flashes populated on phyCORE-i.MX93 SoM and on the +phyBOARD-Segin i.MX 93. For now only the one on the phyCORE-i.MX93 is enabled, and it is used for board +detection.

+
+

7.8.1. I2C EEPROM on phyCORE-i.MX93

+

The I2C EEPROM on the phyCORE-i.MX93 SoM has its memory divided into two parts.

+
    +

  • normal area (size: 4096 bytes, bus: I2C-2, addr: 0x50)

    • +

  • ID page (size: 32 bytes, bus: I2C-2, addr: 0x58)

    • +
+

It is possible to read and write from the device populated:

+
target:~$ hexdump -C /sys/class/i2c-dev/i2c-2/device/2-0058/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-2/device/2-0050/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the whole EEPROM (ID page) with zeros we first need to disable the +EEPROM write protection, use:

+
target:~$ gpioset 2 21=0
+
+
+

Then the EEPROM can be written to:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-2/device/2-0058/eeprom bs=32 count=1
+
+
+
+

Warning

+

The first 256 bytes of the normal EEPROM area (bus: I2C-2 addr: 0x50) are +reserved and should not be overwritten! (See below)

+
+
+
+

7.8.2. EEPROM SoM Detection

+

PHYTEC uses first 256 bytes in EEPROM normal area to store information about the +SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the first 256 bytes of the normal area are deleted, the bootloader will fall +back to the phyCORE-i.MX93 Kit RAM setup, which is 1GiB RAM.

+
+

Warning

+

Data in the first 256 bytes of the normal EEPROM area (bus: I2C-2 addr: 0x50) +shouldn’t be erased or corrupted! This might influence the behavior of the +bootloader. The board might not boot correctly anymore.

+
+
+
+

7.8.3. Rescue EEPROM Data

+

The hardware introspection data is pre-written on the EEPROM data spaces. If +you have accidentally deleted or overwritten the HW data, you could contact our +support!

+

DT representation, e.g. in phyCORE-i.MX 93 file can be found in our PHYTEC git: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi?h=v6.1.36_2.1.0-phy1#n173

+
+
+
+

7.9. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.9.1. RTC Wakealarm

+

It is possible to issue an interrupt from the RTC to wake up the system. The +format uses the Unix epoch time, which is the number of seconds since UTC +midnight on 1 January 1970. To wake up the system after 4 minutes from suspend +to ram state, type:

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

Note

+

Internally the wake alarm time will be rounded up to the next minute since +the alarm function doesn’t support seconds.

+
+
+
+

7.9.2. RTC Parameters

+

RTCs have a few abilities which can be read/set with the help of hwclock +tool.

+
    +

  • We can check RTC supported features with:

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    What this value means is encoded in kernel, each set bit translates to:

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • We can check RTC BSM (Backup Switchover Mode) with:

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • We can set RTC BSM with:

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    What BSM values mean translates to these values:

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    Tip

    +

    You should set BSM mode to DSM or LSM for RTC to switch to backup power +source when the initial power source is not available. Check RV-3028 RTC +datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching +Mode) actually mean.

    +
    +
    • +
+

DT representation for I²C RTCs: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n173

+
+
+
+

7.10. USB Host Controller

+

The USB controller of the i.MX 93 SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 480 Mbps (HighSpeed +‘HS’). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host, but on the phyBOARD-Segin i.MX 93 +one of them is used as a host-only port (USB-A connector).

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+

The OTG port provides an additional pin for over-current protection, which is +not used on the phyBOARD-Segin i.MX 93. Since it’s not used, the driver part is also disabled +from within the device tree. In case this pin is used, activate this +over-current in the device tree and set the correct polarity (active high/low) +according to the device specification. For the correct setup, please refer to +the Kernel documentation under +Linux/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt.

+

DT representation for USB Host: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n190

+
+
+

7.11. CAN FD

+

The phyBOARD-Segin i.MX 93 has one flexCAN interface supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon the Linux network layer. Using +this framework, the CAN interfaces behave like an ordinary Linux network device, +with some additional features special to CAN. More information can be found in +the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The CAN interface should show up as +can0.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
+   link/can  promiscuity 0  allmulti 0 minmtu 0 maxmtu 0
+   can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+         bitrate 500000 sample-point 0.875
+         tq 25 prop-seg 37 phase-seg1 32 phase-seg2 10 sjw 1 brp 1
+         flexcan: tseg1 2..96 tseg2 2..32 sjw 1..16 brp 1..1024 brp_inc 1
+         flexcan: dtseg1 2..39 dtseg2 2..8 dsjw 1..4 dbrp 1..1024 dbrp_inc 1
+         clock 40000000
+         re-started bus-errors arbit-lost error-warn error-pass bus-off
+         0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 parentbus platform parentdev 443a0000.can
+   RX:  bytes packets errors dropped  missed   mcast
+            0       0      0       0       0       0
+   TX:  bytes packets errors dropped carrier collsns
+            0       0      0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+

Device Tree CAN configuration of imx93-phyboard-segin.dts: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n147

+
+
+

7.12. Audio

+

On phyBOARD-Segin i.MX 93 the TI TLV320AIC3007 audio codec is used. It uses I2S for data +transmission and I2C for codec control. The audio signals available are:

+
    +

  • Stereo LINE IN,

    • +

  • Stereo LINE OUT,

    • +

  • Output where D-Class 1W speaker can be connected

    • +
+

To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices:

+
target:~$ aplay -L
+
+
+

Or type for recording devices:

+
target:~$ arecord -L
+
+
+
+

7.12.1. Alsamixer

+

To inspect the capabilities of your soundcard, call:

+
target:~$ alsamixer
+
+
+

You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. “MM” means the feature is muted +(both output, left & right), which can be toggled by hitting ‘m’. You can also +toggle by hitting ‘<’ for left and ‘>’ for right output. With the tab +key, you can switch between controls for playback and recording.

+
+
+

7.12.2. Restore default volumes

+

There are some default settings stored in /var/lib/alsa/asound.state. +You can save your current alsa settings with:

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

You can restore saved alsa settings with:

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.12.3. Playback

+

Run speaker-test to check playback availability:

+
target:~$ speaker-test -c 2 -t wav
+
+
+

To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds:

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

To playback other formats like mp3 for example, you can use Gstreamer:

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+

If Speaker volume it too low you can increase its volume with (values 0-3):

+
target:~$ amixer -c 0 sset Class-D 3
+
+
+
+

Hint

+

Speaker output is only mono so when stereo track is played only left channel +will be played by speaker.

+
+
+
+

7.12.4. Capture

+

arecord is a command-line tool for capturing audio streams which use Line In +as the default input source.

+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

Hint

+

Since playback and capture share hardware interfaces, it is not possible to +use different sampling rates and formats for simultaneous playback and +capture operations.

+
+

Device Tree Audio configuration: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n62

+
+
+
+

7.13. Video

+
+

7.13.1. Videos with Gstreamer

+

One example video is installed by default in the BSP at /usr/share/qtphy/videos/. +Start the video playback with one of these commands:

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.14. Display

+

The phyBOARD-Segin i.MX 93 supports PEB-AV-02 with 7’’ edt,etm0700g0edh6 +parallel display with capacitive touchscreen. Overlay for said display is +enabled in BOOT/bootenv.txt by default!

+

The phyBOARD-Nash i.MX 93 needs additional adapter to support 10’’ +edt,etml1010g3dra LVDS display with capacitive touchscreen. The PEB-AV-10 +(1531.1 revision) can be bought separately to the Kit. Overlay for said display +is enabled in BOOT/bootenv.txt by default!

+
+

7.14.1. Qt Demo

+

With the phytec-qt6demo-image, Weston starts during boot. Our Qt6 demo application named +“qtphy” can be stopped with:

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • To start the demo again, run:

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • To disable autostart of the demo, run:

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • To enable autostart of the demo, run:

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston can be stopped with:

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

Note

+

The Qt demo must be closed before Weston can be closed.

+
+
+
+

7.14.2. Backlight Control

+

If a display is connected to the PHYTEC board, you can control its backlight +with the Linux kernel sysfs interface. All available backlight devices in the +system can be found in the folder /sys/class/backlight. Reading the appropriate +files and writing to them allows you to control the backlight.

+
+

Note

+

Some boards with multiple display connectors might have multiple backlight +controls in /sys/class/backlight. For example: backlight0 and backlight1

+
+
    +

  • To get, for example, the maximum brightness level (max_brightness) execute:

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    Valid brightness values are 0 to <max_brightness>.

    +
    • +

  • To obtain the current brightness level, type:

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • Write to the file brightness to change the brightness:

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    turns the backlight off for example.

    +

    For documentation of all files, see +https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight.

    +
    • +
+

The device tree of PEB-AV-02 can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-02.dtso?h=v6.1.36_2.1.0-phy1

+
+
+
+

7.15. Power Management

+
+

7.15.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 93 SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Unlike i.MX8 M family the i.MX 93 doesn’t support Dynamic Voltage and +Frequency Scaling (DVFS), but has the support of basic Voltage and Frequency +Scaling (VFS). The board can be put into these modes:

+
    +

  • nominal (ND),

    • +

  • overdrive (OD),

    • +

  • Low Drive (LD) and

    • +

  • Low Drive (LD) with Software Fast Frequency Change (SWFFC).

    • +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Mode

CPU freq

DDR data rate

VDD_SOC

OverDrive (OD)

1.7 GHz

3733 MT/s

900mV

NominalDrive (ND)

1.4 GHz

1866 MT/s

850mV

LowDrive (LD)

900 MHz

1866 MT/s

800mV

LowDrive (LD) with SWFFC

900 MHz

625 MT/s

800mV

+

The i.MX 93 BSP supports the VFS feature. The Linux kernel provides a LPM driver +that allows setting VDD_SOC, CPU freq and DDR speed.

+
+

Note

+

Low-cost i.MX 93 SoC variants such as parts numbers NXP IMX9301/IMX9302 do not +support VFS features. Those SoCs always run in LowDrive (LD) mode. Hence, +the Linux LPM driver is disabled automatically for SoMs with such SoCs.

+
+
    +

  • To put the device in OverDrive (OD) mode type:

    +
    +
    target:~$ echo 0 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • To put the device in NominalDrive (ND) mode type:

    +
    +
    target:~$ echo 1 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • To put the device in LowDrive (LD) mode type:

    +
    +
    target:~$ echo 2 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • To put the device in LowDrive (LD) mode with the lowest DDR speed with +SWFFC type:

    +
    +
    target:~$ echo 3 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • To check the current CPU frequency type:

    +
    +
    target:~$ mhz
+
    +
    +
    +
    • +

  • To check the current mode and DDR frequency type:

    +
    +
    target:~$ cat /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • To check the current VDD_SOC type:

    +
    +
    target:~$ cat /sys/kernel/debug/regulator/regulator_summary
+
    +
    +
    +
    • +
+

For more detailed information about the LPM driver and modes, refer to the NXPs +documentation: +https://docs.nxp.com/bundle/AN13917/page/topics/low_power_mode_use_cases.html

+
+
+

7.15.2. CPU Core Management

+

The i.MX 93 SoC can have multiple processor cores on the die. The i.MX 93, for +example, has 2 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0/
+cpu1/
+cpufreq/
+[...]
+
    +
    +

    Here the system has two processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu1/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU1 killed (polled 0 ms)
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu1/online
+
    +
    +
    • +
+
+
+

7.15.3. Suspend to RAM

+

The phyCORE-i.MX93 supports basic suspend and resume. Different wake-up sources can be +used. Suspend/resume is possible with:

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

To wake up with serial console run

+
target:~$ echo enabled > /sys/class/tty/ttyLP0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+

Device can be put into suspend and waken-up with PEB-EVAL-01 S2 button

+

To wake up with RTC alarm check: RTC Wakealarm

+
+
+
+

7.16. Thermal Management

+
+

7.16.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.16.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 93 SoC platform. The i.MX 9 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Commercial, +Industrial and Extended Industrial.

+ + + + + + + + + + + + + + + + + + + + +

Commercial

Industrial

Extended Industrial

passive (warning)

85°C

95°C

115°C

critical (shutdown)

90°C

100°C

120°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise and Power Allocator. The +default policy used in the BSP is step_wise.

+
+

Tip

+

If the value of the SoC temperature in the sysfs file temp reaches +trip_point_1, the board immediately shuts down to avoid any heat damage. If +this doesn’t meet you expectations, an external supervisor circuit that +starts the module again with X_ONOFF signal when the temperature drops below +a selected trip point can be implemented

+
+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+

7.16.3. PWM Fan

+

A PWM fan can be connected to the phyBOARD-Nash i.MX 93 connector X48 (label FAN).

+

Afterwards, a PWM fan overlay needs to be activated, otherwise PWM fan won’t +be recognized.

+
target:~$ vi /boot/bootenv.txt
+
+
+

The bootenv.txt file should look like this (it can also contain other devicetree +overlays!):

+
overlays=imx93-phyboard-nash-pwm-fan.dtbo
+
+
+

The changes will be applied after a reboot:

+
+
target:~$ reboot
+
+
+
+

For further information about devicetree overlays, read the device tree chapter.

+

The SoC only contains one temperature sensor which is already used by the +thermal frequency scaling. The fan thus can not be controlled by the kernel. +We use lmsensors with hwmon for this instead. lmsensors reads the temperature +periodically and adjusts output PWM duty-cycle accordingly. By default, +temperature threshold for PWM fan to activate is set to 60°C.

+

The settings can be configured in the configuration file:

+
/etc/fancontrol
+
+
+

Fan control is started by a systemd service during boot. This can be disabled +with:

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.17. Watchdog

+

The PHYTEC i.MX 93 modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.17.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.18. bbnsm Power Key

+

The X_ONOFF pin connected to the ON/OFF button can be pressed long (for 5 +seconds) to trigger Power OFF without SW intervention or used to wake up the +system out of suspend. With the bbnsm_pwrkey driver, the KEY_POWER event is +also reported to userspace when the button is pressed. On default, systemd is +configured to ignore such events. The function of Power OFF without SW +intervention are not configured. Triggering a power off with systemd when +pushing the ON/OFF button can be configured under /etc/systemd/logind.conf +and set using:

+
HandlePowerKey=poweroff
+
+
+
+
+

7.19. PXP

+

The i.MX 93 SoC contains an PiXel Pipeline (PXP). The PXP combines the following +into a single processing engine:

+
    +

  • Scaling

    • +

  • Color Space Conversion (CSC)

    • +

  • Secondary Color Space Conversion (CSC2)

    • +

  • Rotation

    • +
+

and thus minimizes the memory footprint required for the display pipeline. +How to use the PXP with Gstreamer and Wayland check the How to Use PXP in +GStreamer and Wayland (AN13829) Application note from NXP.

+
+
+

7.20. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 93 provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 93 Reference Manual). The following list is +an abstract from the i.MX 93 Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x47510000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x47510000

Description

BOOT_CFG0

3

0 0x60

boot fuse settings

BOOT_CFG1

3

1 0x64

boot fuse settings

BOOT_CFG2

3

2 0x68

boot fuse settings

BOOT_CFG3

3

3 0x6c

boot fuse settings

MAC1_ADDR

39

3

0x4ec

contains lower 32 bits +of ENET0 MAC address

MAC1/2_ADDR

39

4

0x4f0

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

MAC2_ADDR

39

5

0x4f4

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 93 Security Reference Manual.

+
+

7.20.1. Reading Fuse Values in uBoot

+

MAC1_ADDR:

+
u-boot=> fuse read 39 3
+
+
+
+
+

7.20.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc\@0/47510000.efuse/fsb_s400_fuse0/nvmem
+
+
+
+
+

7.20.3. Burning MAC addresses

+

Let’s say we want to burn the following MAC addresses:

+ + + + + + + + + +

MAC1

12:34:56:78:90:Aa

MAC2

Bb:Cc:Dd:Ee:Ff:D0

+

We would execute this in u-boot:

+
u-boot=> fuse prog 39 3 0x567890Aa
+u-boot=> fuse prog 39 4 0xFfD01234
+u-boot=> fuse prog 39 5 0xBbCcDdEe
+
+
+
+
+

7.20.4. Burning Boot Fuses

+
+

Warning

+

Fuses can only be written once! You can brick your board easily by burning +the wrong boot configuration. It cannot be reversed!

+
+

Which fuse bank/word should be used to program the BOOT_CFGX can be checked in +i.MX 93 Applications Processor Reference Manual attached spreadsheet named +i.MX93_Fusemap.xlsx.

+

These values should be written to the BOOT_CFG0, which can be read/written from +fuses on Bank 3, Word 0.

+ + + + + + + + + + + + + + +

Boot Device

BOOT_CFG0

eMMC

0x20020002

SD Card

0x20000103

+

To set internal fuses to boot from eMMC one can program them with:

+
u-boot=> fuse prog 3 0 0x20020002
+
+
+

In this example we:

+
    +

  • set the Boot_Mode to 0b0010 (eMMC) with BOOT_CFG0[3:0],

    • +

  • set the eMMC Bus width to 0b01 (8 bit) with BOOT_CFG0[18:17]

    • +

  • set the BT_FUSE_SEL (Boot fuses already programmed) bit with BOOT_CFG0[29]

    • +
+

Make sure you set the right bits by reading the Boot Fusemap chapter in +i.MX 93 Applications Processor Reference Manual.

+
+
+
+
+

8. i.MX 93 M33 Core

+

In addition to the Cortex-A55 cores, there is a Cortex-M33 Core as MCU +integrated into the i.MX 93 SoC. Our Yocto-Linux-BSP runs on the A55-Cores and +the M33 Core can be used as a secondary core for additional tasks using +bare-metal firmware. +Both cores have access to the same peripherals and thus peripheral +usage needs to be limited either in the M33 Core’s firmware or the devicetree +for the Linux operating system.

+

Our Yocto-BSP contains pre-built firmware examples for M33 Core from NXP.

+

This section describes how to run pre-built M33 Core firmware examples on phyBOARD-Segin i.MX 93.

+
+

8.1. Running M33 Core Examples

+

There are two ways to run the M33 Core firmware examples, from U-Boot bootloader +and from Remoteproc subsystem within a running Linux.

+

To receive debug messages start your favorite terminal software (e.g. Minicom, +Tio, or Tera Term) on your host PC and configure it for 115200 baud, 8 data +bits, no parity, and 1 stop bit (8n1) with no handshake.

+

On phyBOARD-Segin i.MX 93 an external “USB TTL to serial adapter” is required. Adapter’s I/O +pins should be able to operate at 3.3V voltage levels.

+

Connect external “USB TTL to serial adapter” signals to the +X16 connector on the board according to the following +table:

+ + + + + + + + + + + + + + + + + + + + + +

USB-TTL adapter pins

X16 signal

X16 pin

RXD

X_UART2_TX

5

TXD

X_UART2_RX

8

GND

GND

4

+
+

8.1.1. Running Examples from U-Boot

+

To load firmware examples using the U-Boot bootloader, the bootaux command +can be used:

+
    +

  1. Prepare an SD Card with our Yocto-BSP

    2. +

  2. Stop the autoboot by pressing any key

    3. +

  3. List available M33 Core firmware examples on the first partition of SD Card:

    4. +
+
u-boot=> ls mmc 1
+
+
+
+

Note

+

Available firmware examples start with imx93-11x11-evk_m33_TCM_* and +end with *.bin. Examples come from NXP’s Yocto layer meta-imx and are +selected based on compatibility with phyBOARD-Segin i.MX 93 hardware.

+
+
    +

  1. Load desired firmware example:

    2. +
+
u-boot=> fatload mmc 1 ${loadaddr} <firmware.bin>
+u-boot=> cp.b ${loadaddr} 0x201e0000 ${filesize}
+u-boot=> run prepare_mcore
+u-boot=> bootaux 0x1ffe0000 0
+## Starting auxiliary core addr = 0x1FFE0000...
+
+
+

The program’s output should appear on the M33 Core’s debug UART.

+
+
+

8.1.2. Running Examples from Linux using Remoteproc

+

Remoteproc is a module that allows you to control the M33 Core from Linux +during runtime. Firmware examples for M33 Core can be loaded and the execution +started or stopped within Linux. To use Remoteproc a devicetree overlay needs +to be set:

+

Edit the bootenv.txt file located in the /boot directory on the target +by adding imx93-phycore-rpmsg.dtso:

+
overlays=imx93-phyboard-segin-peb-av-02.dtbo imx93-phycore-rpmsg.dtso
+
+
+

Restart the target and execute in U-Boot:

+
u-boot=> run prepare_mcore
+
+
+

Firmware examples *.elf files for the M33 Core can be found under +/lib/firmware. List available firmware examples:

+
target:~$ ls /lib/firmware/*.elf
+
+
+

To load the firmware, type:

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

To load a different firmware, the M33 Core needs to be stopped:

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

Note

+

The samples found in /lib/firmware on the target come from NXP’s +Yocto layer meta-imx and are selected based on compatibility with phyBOARD-Segin i.MX 93 +hardware.

+
+

Some firmware examples from NXP require additional Linux kernel modules to be +loaded.

+

For example, when loading imx93-11x11-evk_m33_TCM_rpmsg_lite_str_echo_rtos.elf +firmware, one requires corresponding imx_rpmsg_tty module to be loaded:

+
target:~$ modprobe imx_rpmsg_tty
+
+
+

This exposes an RPMsg endpoint as a virtual TTY at /dev/ttyRPMSG30. +Now it is possible to send messages from A55 Core to M33 Core by typing:

+
target:~$ echo "PHYTEC" > /dev/ttyRPMSG30
+
+
+

Observing M33 Core debug UART should result in the following output:

+
RPMSG String Echo FreeRTOS RTOS API Demo...
+
+Nameservice sent, ready for incoming messages...
+Get Message From Master Side : "PHYTEC" [len : 6]
+
+
+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx9/imx93/pd24.1.1.html b/previews/271/bsp/imx9/imx93/pd24.1.1.html new file mode 100644 index 000000000..f8df2cdc5 --- /dev/null +++ b/previews/271/bsp/imx9/imx93/pd24.1.1.html @@ -0,0 +1,4150 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 93 BSP Manual

Document Title

i.MX 93 BSP Manual

Document Type

BSP Manual

Yocto Manual

Mickledore

Release Date

2024/01/31

Is Branch of

i.MX 93 BSP Manual

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-NXP-i.MX93-PD24.1.1

Minor

2024/05/07

Released

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +phyBOARD-Segin i.MX 93 and phyBOARD-Nash i.MX 93 Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-91-93/#downloads of our product.

+
+

1.1. Supported Hardware

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-NXP-i.MX93-PD24.1.1, see download.

+

If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware.

+
+

Tip

+

Console examples in this BSP manual only focus on phyBOARD-Segin i.MX 93. +Similar commands can also be executed for/on phyBOARD-Nash i.MX 93

+
+
+

1.1.1. phyBOARD-Segin i.MX 93 Components

+
+../../../_images/phyBOARD-Segin-iMX93-top-components.jpg + +
+

phyBOARD-Segin i.MX 93 Components (top)

+
+
+
+../../../_images/phyBOARD-Segin-iMX93-bottom-components.jpg + +
+

phyBOARD-Segin i.MX 93 Components (bottom)

+
+
+
+
+

1.1.2. phyBOARD-Nash i.MX 93 Components

+
+../../../_images/phyBOARD-Nash-iMX93-top-components.jpg + +
+

phyBOARD-Nash i.MX 93 Components (top)

+
+
+
+../../../_images/phyBOARD-Nash-iMX93-bottom-components.jpg + +
+

phyBOARD-Nash i.MX 93 Components (bottom)

+
+
+
+
+
+
+

2. Getting Started

+

The phyBOARD-Segin i.MX 93 and phyBOARD-Nash i.MX 93 Kit is shipped with a pre-flashed SD card. It contains the +phytec-qt6demo-image and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+

There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool dd. An +alternative way is to use PHYTEC’s system initialization program called +partup, which makes it especially easy to +format more complex systems. You can get prebuilt Linux binaries of partup from its release page. Also read +partup’s README for installation +instructions.

+
+

2.1. Get the Image

+

The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using dd, can be downloaded from the PHYTEC download server.

+

Get either the partup package or the WIC image from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz
+
+
+
+

Note

+

For eMMC, more complex partitioning schemes or even just large images, we +recommend using the partup package, as it is faster in writing than dd +and allows for a more flexible configuration of the target flash device.

+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card, you must have root privileges on your Linux +host PC. Be very careful when specifying the destination device! All files +on the selected device will be erased immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system on your host PC!

+
+
+

2.2.1. Finding the Correct Device

+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+

Unmount all those partitions, e.g.:

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

Now, the SD card is ready to be flashed with an image, using either partup, +dd or bmap-tools.

+
+
+

2.2.2. Using bmap-tools

+

One way to prepare an SD card is using +bmap-tools. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host:~$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

Replace <your_device> with your actual SD card’s device name found previously, +and make sure to place the file <IMAGENAME>-<MACHINE>.wic.bmap alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip.

+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.2.3. Using partup

+

Writing to an SD card with partup is done in a single command:

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).partup /dev/<your_device>
+
+
+

Make sure to replace <your_device> with your actual device name found previously.

+

Further usage of partup is explained at its official documentation website.

+
+

Warning

+

Host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to write partup packages created with Yocto Mickledore +or newer to SD-Card. This is due to a new default option in resize2fs which causes an +incompatibility. See release notes.

+
+
+

Note

+

partup has the advantage of allowing to clear specific raw areas in the +MMC user area, which is used in our provided partup packages to erase any +existing U-Boot environments. This is a known issue bmaptool does not +solve, as mentioned in the previous chapter.

+

Another key advantage of partup over other flashing tools is that it allows +configuring MMC specific parts, like writing to eMMC boot partitions, without +the need to call multiple other commands when writing.

+
+
+
+

2.2.4. Using dd

+

After having unmounted all SD card’s partitions, you can create your bootable SD card.

+

Some PHYTEC BSPs produce uncompressed images (with filename-extension *.wic), +and some others produce compressed images (with filename-extension *.wic.xz).

+

To flash an uncompressed images (*.wic) use command below:

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Or to flash a compressed images (*.wic.xz) use that command:

+
host:~$ xzcat phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Again, make sure to replace <your_device> with your actual device name found +previously.

+

The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

+
+
+
+

2.3. First Start-up

+ +../../../_images/SD_Card_Boot.png +
    +

  • Insert the SD card

    • +

  • Connect the targets debug console with your host. Use UART1 console on PEB-EVAL-01 for phyBOARD-Segin and X-37 +USB-C debug for phyBOARD-Nash.

    • +

  • Power up the board

    • +

  • Open serial/usb port with 115200 baud and 8N1 (you should see u-boot/linux +start on the console

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 93 BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (mickledore).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (mickledore).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-i.MX93; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-wayland MACHINE=phyboard-segin-imx93-2 ./phyLinux init -p imx93 -r BSP-Yocto-NXP-i.MX93-PD24.1.1
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the phyboard-segin-imx93-2 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx93.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_dmem_1d_v202201.bin, lpddr4_dmem_2d_v202201.bin, +lpddr4_imem_1d_v202201.bin, +lpddr4_imem_2d_v202201.bin: DDR PHY firmware images

    • +

  • imx-boot: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM +Trusted Firmware and DDR firmware. This is the final bootloader image which +is bootable.

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx93-phyboard-*.dtb: Kernel device tree file

    • +

  • imx93-phy*.dtbo: Kernel device tree overlay files

    • +

  • phytec-*.tar.gz: Root file system, +of bitbake-image that was built.

    +
      +

    • phytec-qt6demo-image-phyboard-*-imx93-*.tar.gz: when bitbake-build +was processed for phytec-qt6demo-image

      • +

    • phytec-headless-image-phyboard-*-imx93-*.tar.gz: when bitbake-build +was processed for phytec-headless-image

      • +
    +
    • +

  • phytec-*.wic.xz: Compressed bootable SD +card image of bitbake-image that was built. Includes bootloader, DTBs, Kernel +and Root file system.

    +
      +

    • phytec-qt6demo-image-phyboard-*-imx93-*.wic.xz: when bitbake-build +was processed for phytec-qt6demo-image

      • +

    • phytec-headless-image-phyboard-*-imx93-*.wic.xz: when bitbake-build +was processed for phytec-headless-image

      • +
    +
    • +

  • imx93-11x11-evk_m33_*.bin, binaries of demo applications for the +Cortex-M33 MCU; can be manually loaded and started with U-Boot or Linux

    • +
+
+
+
+
+

4. Installing the OS

+
+

4.1. Bootmode Switch (S3)

+
+

Tip

+

Hardware revision baseboard:

+
    +

  • phyBOARD-Segin-i.MX 93: 1472.5

    • +

  • phyBOARD-Nash-i.MX 93: 1616.0

    • +
+
+

The phyBOARD-Segin/Nash i.MX 93 features a boot switch with four individually switchable ports to +select the phyCORE-i.MX 93 default bootsource.

+ + + + + + + + + +
+../../../_images/eMMC.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses.png +
+

Internal Fuses

+
+
+
+../../../_images/USB_Serial_Download.png +
+

USB Serial Download

+
+
+
+../../../_images/SD_Card_Boot.png +
+

SD Card

+
+
+
+
+
+

4.2. Flash eMMC

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S3) is set to eMMC.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk0p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from SD Card

+

If there is no network available, you can update the eMMC from SD card. For +that, you only need a ready-to-use image file (*.wic) located on the +SD card. Because the image file is quite large, you have to enlarge your SD card +to use its full space (if it was not enlarged before). To enlarge your SD card, +see Resizing ext4 Root Filesystem.

+

Alternatively, flash a partup package to the SD card, as described in +Getting Started. This will ensure the full space of the SD card is used.

+
+

4.2.1.1. Flash eMMC from SD card in Linux on Target

+

You can flash the eMMC on Linux. You only need a partup package or WIC image +saved on the SD card.

+
    +

  • Show your saved partup package or WIC image or WIC.XZ image files on the SD card:

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.partup
+phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz
+
    +
    +
    • +

  • Show list of available MMC devices:

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk0
+mmcblk0boot0
+mmcblk0boot1
+mmcblk0p1
+mmcblk0p2
+mmcblk0rpmb
+
    +
    +
    • +

  • The eMMC device can be recognized by the fact that it contains two boot +partitions: (mmcblk0boot0; mmcblk0boot1)

    • +

  • Write the image to the phyCORE-i.MX 93 eMMC (/dev/mmcblk0 without +partition) using partup:

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-segin-imx93-2.partup /dev/mmcblk0
+
    +
    +
    +

    Tip

    +

    Using partup is highly recommended since it is easier to use and has the +advantage of using the full capacity of the eMMC device, adjusting +partitions accordingly.

    +
    +
    +

    Note

    +

    Alternatively, dd may be used instead.

    +

    For uncompressed WIC images (*.wic):

    +
    target:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.wic of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +

    For compressed WIC images (*.wic.xz):

    +
    target:~$ zstdcat phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz | sudo dd of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +

    Keep in mind that the root partition does not make use of the full space +when flashing with dd.

    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Warning

    +

    Before this will work, you need to configure the bootmode switch (S3) to eMMC.

    +
    +
    • +
+
+
+
+

4.2.2. Flash eMMC from Network

+

i.MX 93 boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

Note

+

Some PHYTECs BSPs produce compressed .wic.xz images. In this case, the +compressed image must first be uncompressed.

+
host:~$ unxz phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz
+
+
+
+
+

4.2.2.1. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Take an uncompressed image on the host and send it with ssh through +the network to the eMMC of the target with a one-line command:

+
target:~$ ssh <USER>@192.168.3.10 "dd if=<path_to_file>/phytec-qt6demo-image-phyboard-segin-imx93-2.wic" | dd of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
+
+
+
+

4.2.2.2. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Show your available image files on the host:

+
host:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.wic
+
+
+

Send the image with the dd command combined with ssh through the network +to the eMMC of your device:

+
host:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.wic bs=1M status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk0 conv=fsync"
+
+
+
+
+
+

4.2.3. Flash eMMC U-Boot image via Network from running U-Boot

+

Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 0
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.4. Flash eMMC from USB

+
+

4.2.4.1. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-qt6demo-image-phyboard-segin-imx93-2.wic). Set the bootmode switch (S3) to SD Card.

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ cd /mnt
+target:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.wic
+
    +
    +
    • +

  • Show list of available MMC devices:

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk0
+mmcblk0boot0
+mmcblk0boot1
+mmcblk0p1
+mmcblk0p2
+mmcblk0rpmb
+
    +
    +
    • +

  • The eMMC device can be recognized by the fact that it contains two boot +partitions: (mmcblk0boot0; mmcblk0boot1)

    • +

  • Write the image to the phyCORE-i.MX 93 eMMC (/dev/mmcblk0 without partition):

    +
    target:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.wic of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Tip

    +

    Before this will work, you need to configure the bootmode switch (S3) to +eMMC.

    +
    +
    • +
+
+
+
+
+

4.3. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A5 RAUC Update & Device Management Manual.

+
+
+
+

5. Development

+
+

5.1. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.1.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.2. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.2.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel image to your tftp directory:

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • Copy the devicetree to your tftp directory:

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • Copy all the overlays you want to use into your tftp directory:

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-segin-imx93-2.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.2.2. Set the bootenv.txt for Netboot

+

Create a bootenv.txt file in your tftp directory and write the following variables into it.

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> has to be replaced with the devicetree overlay filenames that you want to use. +Separate the filenames by spaces. For example:

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

Tip

+

All supported devicetree overlays are in the device tree chapter.

+
+
+
+

5.2.3. Network Settings on Target

+

To customize the targets ethernet configuration, please follow the description +here: Network Environment Customization

+
+
+

5.2.4. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.3.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/phyboard-segin-imx93-2/. For flashing a wic image to eMMC, +you will also need phytec-qt6demo-image-phyboard-segin-imx93-2.wic.

+
+
+

5.3.3. Prepare Target

+

Set the bootmode switch (S3) to USB Serial Download. Also, connect USB port +X8 (USB micro/OTG connector) to your host.

+
+
+

5.3.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via UART1 console on PEB-EVAL-01 for phyBOARD-Segin and X-37 +USB-C debug for phyBOARD-Nash, as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.3.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 0 0 0 0
+u-boot=> mmc partconf 0
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-segin-imx93-2.wic
+
+
+
+
+
+

5.4. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone git://git.phytec.de/u-boot-imx)

+
+
+

5.4.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-imx and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • Our i.MX 93 kernel is based on the linux-imx kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. Get the SDK

+

You can download the SDK here, or build it yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

After a successful build the SDK installer is deployed to build/deploy*/sdk.

+
+
+

5.4.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-vendor-wayland-glibc-x86_64-phytec-qt6demo-image-cortexa55-toolchain-4.2.3.sh
+host:~$ ./phytec-ampliphy-vendor-wayland-glibc-x86_64-phytec-qt6demo-image-cortexa55-toolchain-4.2.3.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-wayland/4.2.3):
+You are about to install the SDK to "/opt/ampliphy-vendor-wayland/4.2.3". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-vendor-wayland/4.2.3/environment-setup-cortexa55-phytec-linux
+
+
+
+
+

5.4.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. U-Boot standalone build

+
+

5.5.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag needed at this release is called v2023.04_2.2.0-phy3

    • +

  • Check out the needed U-Boot tag:

    • +
+
host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2023.04_2.2.0-phy3
+
+
+
    +

  • Technically, you can now build the U-Boot, but practically there are some +further steps necessary:

    +
      +

    • Create your own development branch:

      +
      host:~/u-boot-imx$ git switch --create <new-branch>
+
      +
      +
      +

      Note

      +

      You can name your development branch as you like, this is just an example.

      +
      +
      • +
    +
    • +

  • Set up a build environment:

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor-wayland/4.2.3/environment-setup-cortexa55-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. Get the needed binaries

+

To build the imx-boot, you need to gather these files for +later use with imx-mkimage tool:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx93.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +

  • Container image: mx93a1-ahab-container.img

    • +
+

If you already built our BSP with Yocto, you can get +these files from the directory mentioned here: BSP Images

+

Or you can download the files from the PHYTEC download server (https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools/). +You can use the commands below to download all the files from that server:

+
host:~$ mkdir ./artefacts && cd ./artefacts
+host:~/artefacts$ wget \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//bl31-imx93.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//tee.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_dmem_1d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_dmem_2d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_imem_1d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_imem_2d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//mx93a1-ahab-container.img
+host:~/artefacts$ cd ..
+
+
+
+
+

5.5.3. Build the bootloader

+
    +

  • Build u-boot:

    +
    host:~/u-boot-imx$ make <defconfig>
+host:~/u-boot-imx$ make
+host:~/u-boot-imx$ cd ..
+
    +
    +
    +

    Note

    +

    In command above replace <defconfig> with imx93-phyboard-segin_defconfig or imx93-phyboard-nash_defconfig, depending on the board you are about to build for.

    +
    +
    • +
+
+

5.5.3.1. Build final flash.bin with imx-mkimage

+
    +

  • Get imx-mkimage:

    +
    host:~$ git clone https://github.com/nxp-imx/imx-mkimage
+host:~$ cd imx-mkimage/
+host:~/imx-mkimage$ git checkout tags/lf-6.1.55-2.2.0
+
    +
    +
    • +

  • Copy firmware binaries into imx-mkimage

    +
    host:~/imx-mkimage$ cp ../artefacts/bl31-imx93.bin ./iMX9/bl31.bin
+host:~/imx-mkimage$ cp \
+                     ../artefacts/lpddr4_* \
+                     ../artefacts/mx93a1-ahab-container.img \
+                     ../artefacts/tee.bin \
+                     ./iMX9/
+
    +
    +
    • +

  • Copy u-boot binaries and DTB into imx-mkimage

    +
    host:~/imx-mkimage$ cp ../u-boot-imx/spl/u-boot-spl.bin ../u-boot-imx/u-boot.bin ./iMX9/
+host:~/imx-mkimage$ cp ../u-boot-imx/arch/arm/dts/<dtb> ./iMX9/
+
    +
    +
    +

    Note

    +

    In command above replace <dtb> with imx93-phyboard-segin.dtb or imx93-phyboard-nash.dtb, depending on the board you are about to build for.

    +
    +
    • +

  • Build final flash.bin binary

    +
    +
    host:~/imx-mkimage$ make SOC=iMX9 REV=A1 flash_singleboot
+
    +
    +
    +
    • +
+
+
+
+

5.5.4. Flash the bootloader to a block device

+

The flash.bin can be found at imx-mkimage/iMX9/ directory and now can be flashed. A +chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 93

32 kiB

0 kiB

/dev/mmcblk0

+

E.g. flash SD card:

+
host:~/imx-mkimage$ sudo dd if=./iMX9/flash.bin of=<sd-card> bs=1024 seek=32 conv=sync
+
+
+
+

Note

+

In the command above, replace <sd-card> with your sd-card device name. +For more information on how to find the device name, see the section +Finding the Correct Device in +Getting Started.

+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables “BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+
+

5.6. Kernel standalone build

+
+

5.6.1. Setup sources

+
    +

  • The used linux-imx branch can be found in the release notes

    • +

  • The tag needed for this release is called v6.1.55_2.2.0-phy3

    • +

  • Check out the needed linux-imx tag:

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v6.1.55_2.2.0-phy3
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor-wayland/4.2.3/environment-setup-cortexa55-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-imx$ make imx_v8_defconfig imx9_phytec_distro.config imx9_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-imx/arch/arm64/boot/Image

    • +

  • The dtb can be found at +~/linux-imx/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. Copy Kernel to SD Card

+

When one-time boot via netboot is not sufficient, the kernel along with its +modules and the corresponding device tree blob may be copied directly to a +mounted SD card.

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.7.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.7.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-qt6demo-image-phyboard-segin-imx93-2.wic image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-segin-imx93-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.7.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-qt6demo-image-phyboard-segin-imx93-2.wic image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-segin-imx93-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 93 BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 93 SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Board.dts - include the module dtsi file. Devices that come from the i.MX 93 +SoC but are just routed down to the carrier board and used there are included +in this dts.

    • +

  • Overlay.dtso - enable/disable features depending on optional hardware that +may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10)

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 9 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the folder arch/arm64/boot/dts/freescale/.

+

Available overlays for phyboard-segin-imx93-2.conf are:

+
imx93-phyboard-segin-peb-av-02.dtbo
+imx93-phyboard-segin-peb-eval-01.dtbo
+imx93-phycore-rpmsg.dtbo
+imx93-phycore-no-emmc.dtbo
+imx93-phycore-no-eth.dtbo
+
+
+

Available overlays for phyboard-nash-imx93-1.conf are:

+
imx93-phyboard-nash-peb-av-010.dtbo
+imx93-phycore-rpmsg.dtbo
+imx93-phycore-no-emmc.dtbo
+imx93-phycore-no-eth.dtbo
+
+
+

The usage of overlays can be configured during runtime in Linux or U-Boot. +Overlays are applied during the boot process in the bootloader after the +boot command is called and before the kernel is loaded. The next sections +explain the configuration in more detail.

+
+

6.2.2.1. Set ${overlays} variable

+

The ${overlays} U-Boot environment variable contains a space-separated list +of overlays that will be applied during boot. Depending on the boot source the +overlays have to either be placed in the boot partition of eMMC/SD-Card or are +loaded over tftp. Overlays set in the $KERNEL_DEVICETREE Yocto machine variable +will be automatically added to the boot partition of the final WIC image.

+

The ${overlays} variable can be either set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=imx93-phyboard-segin-peb-eval-01.dtbo imx93-phyboard-segin-peb-av-02.dtbo
+
+
+
+

Note

+

Make sure the boot partition is mounted! If it is not you can mount it with:

+
target:~$ mount /dev/mmcblkXp0 /boot
+
+
+
+

Changes will take effect after the next reboot. If no bootenv.txt file is +available the overlays variable can be set directly in the U-Boot environment.

+
u-boot=> setenv overlays imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> printenv overlays
+overlays=imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> boot
+
+
+

If a user defined ${overlays} variable should be directly loaded from U-Boot +environment but there is still an external bootenv.txt available, the ${no_bootenv} +variable needs to be set as a flag:

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> boot
+
+
+

More information about the external environment can be found in +U-boot External Environment subsection of the +device tree overlay section.

+

We use the ${overlays} variable for overlays describing expansion boards +that can not be detected during run time. To prevent applying overlays listed in +the ${overlays} variable during boot, the ${no_overlays} variable can be +set to 1 in the bootloader environment.

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot External Environment

+

During the start of the Linux Kernel the external environment bootenv.txt +text file will be loaded from the boot partition of an MMC device or via TFTP. +The main intention of this file is to store the ${overlays} variable. This makes +it easy to pre-define the overlays in Yocto depending on the used machine. The +content from the file is defined in the Yocto recipe bootenv found in +meta-phytec: +https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=mickledore

+

Other variables can be set in this file, too. They will overwrite the existing +settings in the environment. But only variables evaluated after issuing the boot +command can be overwritten, such as ${nfsroot} or ${mmcargs}. Changing other +variables in that file will not have an effect. See the usage during netboot as +an example.

+

If the external environment can not be loaded the boot process will be anyway +continued with the values of the existing environment settings.

+
+
+

6.2.4. Change U-boot Environment from Linux on Target

+

Libubootenv is a tool included in our images to modify the U-Boot environment of +Linux on the target machine.

+

Print the U-Boot environment using the following command:

+
target:~$ fw_printenv
+
+
+

Modify a U-Boot environment variable using the following command:

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

Caution

+

Libubootenv takes the environment selected in a configuration file. The +environment to use is inserted there, and by default it is configured to use +the eMMC environment (known as the default used environment).

+

If the eMMC is not flashed or the eMMC environment is deleted, libubootenv +will not work. You should modify the /etc/fw_env.config file to match the +environment source that you want to use.

+
+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 93 BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 93 BSP Device Tree Concept to get an understanding +of our i.MX 9 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 9 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 93 Pin Muxing

+

The i.MX 93 SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 93 terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 93 Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx93-phyboard-segin.dts:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX93_PAD_UART1_RXD__LPUART1_RX     0x31e
+                MX93_PAD_UART1_TXD__LPUART1_TX     0x30e
+        >;
+};
+
+
+

The first part of the string MX93_PAD_UART1_RXD__LPUART1_RX names the pad +(in this example UART1_RXD). The second part of the string (LPUART1_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal pull up is +activated.

+

The device tree representation for UART1 pinmuxing: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n262

+
+
+

7.2. Network

+

phyBOARD-Segin/Nash i.MX 93 provides two ethernet interfaces.

+
    +

  • On phyBOARD-Segin we have:

    +
      +

    • a 100 megabit Ethernet provided by phyCORE-i.MX93

      • +

    • and 100 megabit Ethernet provided by phyBOARD.

      • +
    +
    • +

  • On phyBOARD-Nash we have:

    +
      +

    • a 100 megabit Ethernet provided by phyCORE-i.MX93

      • +

    • and 1 gigabit Ethernet provided by phyBOARD.

      • +
    +
    • +
+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi?h=v6.1.55_2.2.0-phy3#n61.

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Segin/Nash i.MX 93 can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n114 or here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n83.

+
+

7.2.1. Network Environment Customization

+
+

7.2.1.1. U-boot network-environment

+
    +

  • To find the Ethernet settings in the target bootloader:

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • With your development host set to IP 192.168.3.10 and netmask 255.255.255.0, +the target should return:

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • If you need to make any changes:

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> should be one of ipaddr, netmask, gatewayip or serverip. +<value> will be the actual value of the chosen parameter.

    +
    • +

  • The changes you made are temporary for now. To save these:

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

Here you can also change the IP address to DHCP instead of using a static one.

+
    +

  • Configure:

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • Set up paths for TFTP and NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+

Tip

+

Variables like nfsroot and netargs can be overwritten by the U-boot External +Environment. For netboot, the external environment will be loaded from tftp. +For example, to locally set the nfsroot variable in a bootenv.txt file, +locate the tftproot directory:

+
nfsroot=/home/user/nfssrc
+
+
+

There is no need to store the info on the target. Please note that this does +not work for variables like ipaddr or serveraddr as they need to be already +set when the external environment is being loaded.

+
+
+
+

7.2.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+
+

7.3. SD/MMC Card

+

The i.MX 93 supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n216 or here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n201

+

DT configuration for the eMMC interface can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi?h=v6.1.55_2.2.0-phy3#n194 or here:

+
+
+

7.4. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 93 is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw Multi-Level Cells (MLC) or Triple-Level +Cells (TLC) combined with a memory controller that handles ECC and wear +leveling. They are connected via an SD/MMC interface to the i.MX 93 and are +represented as block devices in the Linux kernel like SD cards, flash drives, or +hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.4.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk0
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.4.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +or TLC. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background Operations +(BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • Enabling can be done with this command:

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops_en manual /dev/mmcblk0
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.4.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 93 SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk0 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.4.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk0 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk0: 7617MB
+Sect[ 1799.850385]  mmcblk0: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk0 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk0 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk0: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk0: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk0p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk0p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk0p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk0p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
+
+

7.4.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC or TLC +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC used in NAND Flash, MLC or TLC have lower reliability and a higher +error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk0 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk0:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk0
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk0
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk0 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk0 unit B print
+BYT;
+/dev/mmcblk0:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.4.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC or TLC +or mark these blocks as discard. The data on the device is lost and +will be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk0
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk0 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.4.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 93 uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.4.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk0boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk0boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk0boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk0boot1
+
+
+

The following table is for the offset of the i.MX 93 SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 93

32 kiB

0 kiB

/dev/mmcblk0

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk0
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk0
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk0
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk0
+
+
+
+
+

7.4.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk0
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk0p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk0p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk0
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk0p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk0p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk0p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk0p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk0p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.5. GPIOs

+

The phyBOARD-Segin/Nash i.MX 93 doesn’t have a set of pins especially dedicated for user I/Os since +all GPIOs are used by kernel device drivers or used for a specific purpose. The +processor has organized its GPIOs into five banks of 32 GPIOs each (GPIO1 – +GPIO4) GPIOs. gpiochip0, gpiochip32, gpiochip64 and gpiochip96 are the sysfs +representation of these internal i.MX 93 GPIO banks GPIO1 – GPIO4.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO4_07). <X> identifies the GPIO +bank and counts from 1 to 4, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [43810080.gpio] (32 lines)
+gpiochip1 [43820080.gpio] (32 lines)
+gpiochip2 [43830080.gpio] (32 lines)
+gpiochip3 [47400080.gpio] (32 lines)
+
    +
    +
    • +
+
+

Note

+

Order of GPIOchips in i.MX 93 Application Processor Reference Manual and +in Linux kernel differ!

+ + + + + + + + + + + + + + + + + + + + + + + +

GPIOchip address

Linux

Reference Manual

0x43810080

gpiochip0

gpiochip2

0x43820080

gpiochip1

gpiochip3

0x43830080

gpiochip2

gpiochip4

0x47400080

gpiochip3

gpiochip1

+
+
    +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 3 from chip0):

    +
    target:~$ gpioget gpiochip0 3
+
    +
    +
    • +

  • Set the value of GPIO 3 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset --mode=exit gpiochip0 3=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.5.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the +imx9_phytec_distro.config config fragment in the linux kernel sources +under arch/arm64/configs

+
..
+CONFIG_GPIO_SYSFS=y
+..
+
+
+
+
+
+

7.6. ADC

+

The PHYTEC i.MX 93 include general purpose Analog-to-Digital Converters (ADC) which +can be used for interfacing analog sensors.

+

Reading the ADC values can be done through sysfs:

+
target:~$ cat /sys/bus/iio/devices/iio:deviceX/in_voltageY_raw
+
+
+

On phyBOARD-Nash the ADC lines are accessible on X16 expansion connector:

+ + + + + + + + + + + + + + +

ADC input

X16 pin

ADC_IN0

47

ADC_IN2

49

+
+
+

7.7. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+green:heartbeat@  mmc0::@  mmc1::@  yellow:@
+
+
+

Here the LEDs green:heartbeat is on the phyCORE-i.MX93. If you are using +phyBOARD-Segin there is also yellow LED which is populated on the +PEB-EVAL-01.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 1 > /sys/class/leds/green\:heartbeat/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/green\:heartbeat/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-eval-01.dtso?h=v6.1.55_2.2.0-phy3#n33

+
+
+

7.8. I²C Bus

+

The i.MX 93 contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 93. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our phyBOARD-Segin/Nash i.MX 93.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C1 bus configuration (e.g. imx93-phycore-som.dtsi): +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi?h=v6.1.55_2.2.0-phy3#n88

+

General I²C2 bus configuration for imx93-phyboard-segin.dts: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n155 or for +imx93-phyboard-nash.dts: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n113

+
+
+

7.9. EEPROM

+

There are two different I2C EEPROM flashes populated on phyCORE-i.MX93 SoM and on the +phyBOARD-Segin/Nash i.MX 93. For now only the one on the phyCORE-i.MX93 is enabled, and it is used for board +detection.

+
+

7.9.1. I2C EEPROM on phyCORE-i.MX93

+

The I2C EEPROM on the phyCORE-i.MX93 SoM has its memory divided into two parts.

+
    +

  • normal area (size: 4096 bytes, bus: I2C-2, addr: 0x50)

    • +

  • ID page (size: 32 bytes, bus: I2C-2, addr: 0x58)

    • +
+

It is possible to read and write from the device populated:

+
target:~$ hexdump -C /sys/class/i2c-dev/i2c-2/device/2-0058/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-2/device/2-0050/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the whole EEPROM (ID page) with zeros we first need to disable the +EEPROM write protection, use:

+
target:~$ gpioset 2 21=0
+
+
+

Then the EEPROM can be written to:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-2/device/2-0058/eeprom bs=32 count=1
+
+
+
+

Warning

+

The first 256 bytes of the normal EEPROM area (bus: I2C-2 addr: 0x50) are +reserved and should not be overwritten! (See below)

+
+
+
+

7.9.2. EEPROM SoM Detection

+

PHYTEC uses first 256 bytes in EEPROM normal area to store information about the +SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the first 256 bytes of the normal area are deleted, the bootloader will fall +back to the phyCORE-i.MX93 Kit RAM setup, which is 1GiB RAM.

+
+

Warning

+

Data in the first 256 bytes of the normal EEPROM area (bus: I2C-2 addr: 0x50) +shouldn’t be erased or corrupted! This might influence the behavior of the +bootloader. The board might not boot correctly anymore.

+
+
+
+

7.9.3. Rescue EEPROM Data

+

The hardware introspection data is pre-written on the EEPROM data spaces. If +you have accidentally deleted or overwritten the HW data, you could contact our +support!

+

DT representation, e.g. in phyCORE-i.MX 93 file can be found in our PHYTEC git: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi?h=v6.1.55_2.2.0-phy3#n172

+
+
+
+

7.10. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.10.1. RTC Wakealarm

+

It is possible to issue an interrupt from the RTC to wake up the system. The +format uses the Unix epoch time, which is the number of seconds since UTC +midnight on 1 January 1970. To wake up the system after 4 minutes from suspend +to ram state, type:

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

Note

+

Internally the wake alarm time will be rounded up to the next minute since +the alarm function doesn’t support seconds.

+
+
+
+

7.10.2. RTC Parameters

+

RTCs have a few abilities which can be read/set with the help of hwclock +tool.

+
    +

  • We can check RTC supported features with:

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    What this value means is encoded in kernel, each set bit translates to:

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • We can check RTC BSM (Backup Switchover Mode) with:

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • We can set RTC BSM with:

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    What BSM values mean translates to these values:

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    Tip

    +

    You should set BSM mode to DSM or LSM for RTC to switch to backup power +source when the initial power source is not available. Check RV-3028 RTC +datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching +Mode) actually mean.

    +
    +
    • +
+

DT representation for I²C RTCs: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n173 or +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n122

+
+
+
+

7.11. USB Host Controller

+

The USB controller of the i.MX 93 SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 480 Mbps (HighSpeed +‘HS’). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host, but on the phyBOARD-Segin/Nash i.MX 93 +one of them is used as a host-only port (USB-A connector).

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+

The OTG port provides an additional pin for over-current protection, which is +not used on the phyBOARD-Segin/Nash i.MX 93. Since it’s not used, the driver part is also disabled +from within the device tree. In case this pin is used, activate this +over-current in the device tree and set the correct polarity (active high/low) +according to the device specification. For the correct setup, please refer to +the Kernel documentation under +Linux/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt.

+

DT representation for USB Host: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n190 or +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n180

+
+
+

7.12. RS232/RS485

+

The phyBOARD-Nash i.MX 93 SoC provides one RS232/RS485 serial port.

+
+

Warning

+

RS232 with HW flow control and RS485 are not working due to HW bug on the +phyBOARD-Nash PCB revision 1616.0

+
+
+

7.12.1. RS232

+
    +

  • Display the current settings of a terminal in a human-readable format:

    +
    target:~$ stty -a
+
    +
    +
    • +

  • Configuration of the UART interface can be done with stty. For example:

    +
    target:~$ stty -F /dev/ttyLP6 115200 crtscts raw -echo
+
    +
    +
    • +

  • With a simple echo and cat, basic communication can be tested. Example:

    +
    target:~$ echo 123 > /dev/ttyLP6
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

The host should print out “123”.

+
+
+

7.12.2. RS485

+
+

Hint

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

For easy testing, look at the linux-serial-test. This tool is called the IOCTL +for RS485 and sends a constant stream of data.

+
target:~$ linux-serial-test -p /dev/ttyLP6 -b 115200 --rs485 0
+
+
+

More information about the linux-serial-test tool and its parameters can be +found here: linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Documentation for calling the IOCTL within c-code is described in the Linux +kernel documentation: +https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+

The device tree representation for RS232 and RS485: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n173

+
+
+
+

7.13. CAN FD

+

The phyBOARD-Segin/Nash i.MX 93 has one flexCAN interface supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon the Linux network layer. Using +this framework, the CAN interfaces behave like an ordinary Linux network device, +with some additional features special to CAN. More information can be found in +the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The CAN interface should show up as +can0.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
+   link/can  promiscuity 0  allmulti 0 minmtu 0 maxmtu 0
+   can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+         bitrate 500000 sample-point 0.875
+         tq 25 prop-seg 37 phase-seg1 32 phase-seg2 10 sjw 1 brp 1
+         flexcan: tseg1 2..96 tseg2 2..32 sjw 1..16 brp 1..1024 brp_inc 1
+         flexcan: dtseg1 2..39 dtseg2 2..8 dsjw 1..4 dbrp 1..1024 dbrp_inc 1
+         clock 40000000
+         re-started bus-errors arbit-lost error-warn error-pass bus-off
+         0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 parentbus platform parentdev 443a0000.can
+   RX:  bytes packets errors dropped  missed   mcast
+            0       0      0       0       0       0
+   TX:  bytes packets errors dropped carrier collsns
+            0       0      0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+

Device Tree CAN configuration of imx93-phyboard-segin.dts: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n147 or +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n105

+
+
+

7.14. Audio on phyBOARD-Segin

+

On phyBOARD-Segin i.MX 93 the TI TLV320AIC3007 audio codec is used. It uses I2S +for data transmission and I2C for codec control. The audio signals available +are:

+
    +

  • Stereo LINE IN,

    • +

  • Stereo LINE OUT,

    • +

  • Output where D-Class 1W speaker can be connected

    • +
+

To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices:

+
target:~$ aplay -L
+
+
+

Or type for recording devices:

+
target:~$ arecord -L
+
+
+
+

7.14.1. Alsamixer

+

To inspect the capabilities of your soundcard, call:

+
target:~$ alsamixer
+
+
+

You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. “MM” means the feature is muted +(both output, left & right), which can be toggled by hitting ‘m’. You can also +toggle by hitting ‘<’ for left and ‘>’ for right output. With the tab +key, you can switch between controls for playback and recording.

+
+
+

7.14.2. Restore default volumes

+

There are some default settings stored in /var/lib/alsa/asound.state. +You can save your current alsa settings with:

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

You can restore saved alsa settings with:

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.14.3. Playback

+

Run speaker-test to check playback availability:

+
target:~$ speaker-test -c 2 -t wav
+
+
+

To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds:

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

To playback other formats like mp3 for example, you can use Gstreamer:

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+

If Speaker volume it too low you can increase its volume with (values 0-3):

+
target:~$ amixer -c 0 sset Class-D 3
+
+
+
+

Hint

+

Speaker output is only mono so when stereo track is played only left channel +will be played by speaker.

+
+
+
+

7.14.4. Capture

+

arecord is a command-line tool for capturing audio streams which use Line In +as the default input source.

+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

Hint

+

Since playback and capture share hardware interfaces, it is not possible to +use different sampling rates and formats for simultaneous playback and +capture operations.

+
+

Device Tree Audio configuration: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n62

+
+
+
+

7.15. Audio on phyBOARD-Nash

+
+

Warning

+

Due to HW bug Audio is broken on phyBOARD-Nash i.MX 93 PCB revision: 1616.0

+
+

To use audio with phyBOARD-Nash an additional adapter for the Audio/Video +connector is needed. The PEB-AV-10 (1531.1 revision) can be bought separately to +the Kit. PEB-AV-10 is populated with a TI TLV320AIC3007 audio codec. Audio +support is done via the I2S interface and controlled via I2C.

+

There is a 3.5mm headset jack with OMTP standard and an 8-pin header to connect +audio devices with the AV-Connector. The 8-pin header contains a mono speaker, +headphones, and line-in signals.

+

To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices:

+
target:~$ aplay -L
+
+
+

Or type for recording devices:

+
target:~$ arecord -L
+
+
+
+

7.15.1. Alsamixer

+

To inspect the capabilities of your soundcard, call:

+
target:~$ alsamixer
+
+
+

You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. “MM” means the feature is muted +(both output, left & right), which can be toggled by hitting ‘m’. You can also +toggle by hitting ‘<’ for left and ‘>’ for right output. With the tab +key, you can switch between controls for playback and recording.

+
+
+

7.15.2. Restore default volumes

+

There are some default settings stored in /var/lib/alsa/asound.state. +You can save your current alsa settings with:

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

You can restore saved alsa settings with:

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.15.3. ALSA configuration

+

Our BSP comes with a ALSA configuration file /etc/asound.conf.

+

The ALSA configuration file can be edited as desired or deleted since it is not +required for ALSA to work properly.

+
target:~$ vi /etc/asound.conf
+
+
+

To set PEB-AV-10 as output, set playback.pcm from “dummy” to “pebav10”:

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

If the sound is not audible change playback devices to the software volume control +playback devices, set playback.pcm to the respective softvol playback device e.g. +“softvol_pebav10”. Use alsamixer controls to vary the volume levels.

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.15.4. Pulseaudio Configuration

+

For applications using Pulseaudio, check for available sinks:

+
target:~$ pactl list short sinks
+
+
+

To select the output device, type:

+
target:~$ pactl set-default-sink <sink_number>
+
+
+
+
+

7.15.5. Playback

+

Run speaker-test to check playback availability:

+
target:~$ speaker-test -c 2 -t wav
+
+
+

To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds:

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

To playback other formats like mp3 for example, you can use Gstreamer:

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.15.6. Capture

+

arecord is a command-line tool for capturing audio streams which use Line In as +the default input source. To select a different audio source you can +use alsamixer. For example, switch on Right PGA Mixer Mic3R and Left PGA Mixer +Mic3R in order to capture the audio from the microphone input of the +TLV320-Codec using the 3.5mm jack.

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

Hint

+

Since playback and capture share hardware interfaces, it is not possible to +use different sampling rates and formats for simultaneous playback and +capture operations.

+
+

Device Tree Audio configuration: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash-peb-av-010.dtso?h=v6.1.55_2.2.0-phy3#n57

+
+
+
+

7.16. Video

+
+

7.16.1. Videos with Gstreamer

+

One example video is installed by default in the BSP at /usr/share/qtphy/videos/. +Start the video playback with one of these commands:

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.17. Display

+

The phyBOARD-Segin i.MX 93 supports PEB-AV-02 with 7’’ edt,etm0700g0edh6 +parallel display with capacitive touchscreen. Overlay for said display is +enabled in BOOT/bootenv.txt by default!

+

The phyBOARD-Nash i.MX 93 needs additional adapter to support 10’’ +edt,etml1010g3dra LVDS display with capacitive touchscreen. The PEB-AV-10 +(1531.1 revision) can be bought separately to the Kit. Overlay for said display +is enabled in BOOT/bootenv.txt by default!

+
+

7.17.1. Qt Demo

+

With the phytec-qt6demo-image, Weston starts during boot. Our Qt6 demo application named +“qtphy” can be stopped with:

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • To start the demo again, run:

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • To disable autostart of the demo, run:

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • To enable autostart of the demo, run:

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston can be stopped with:

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

Note

+

The Qt demo must be closed before Weston can be closed.

+
+
+
+

7.17.2. Backlight Control

+

If a display is connected to the PHYTEC board, you can control its backlight +with the Linux kernel sysfs interface. All available backlight devices in the +system can be found in the folder /sys/class/backlight. Reading the appropriate +files and writing to them allows you to control the backlight.

+
+

Note

+

Some boards with multiple display connectors might have multiple backlight +controls in /sys/class/backlight. For example: backlight0 and backlight1

+
+
    +

  • To get, for example, the maximum brightness level (max_brightness) execute:

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    Valid brightness values are 0 to <max_brightness>.

    +
    • +

  • To obtain the current brightness level, type:

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • Write to the file brightness to change the brightness:

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    turns the backlight off for example.

    +

    For documentation of all files, see +https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight.

    +
    • +
+

The device tree of PEB-AV-02 can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-02.dtso?h=v6.1.55_2.2.0-phy3

+

The device tree of PEB-AV-10 can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash-peb-av-010.dtso?h=v6.1.55_2.2.0-phy3

+
+
+
+

7.18. Power Management

+
+

7.18.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 93 SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Unlike i.MX8 M family the i.MX 93 doesn’t support Dynamic Voltage and +Frequency Scaling (DVFS), but has the support of basic Voltage and Frequency +Scaling (VFS). The board can be put into these modes:

+
    +

  • nominal (ND),

    • +

  • overdrive (OD),

    • +

  • Low Drive (LD) and

    • +

  • Low Drive (LD) with Software Fast Frequency Change (SWFFC).

    • +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Mode

CPU freq

DDR data rate

VDD_SOC

OverDrive (OD)

1.7 GHz

3733 MT/s

900mV

NominalDrive (ND)

1.4 GHz

1866 MT/s

850mV

LowDrive (LD)

900 MHz

1866 MT/s

800mV

LowDrive (LD) with SWFFC

900 MHz

625 MT/s

800mV

+

The i.MX 93 BSP supports the VFS feature. The Linux kernel provides a LPM driver +that allows setting VDD_SOC, CPU freq and DDR speed.

+
+

Note

+

Low-cost i.MX 93 SoC variants such as parts numbers NXP IMX9301/IMX9302 do not +support VFS features. Those SoCs always run in LowDrive (LD) mode. Hence, +the Linux LPM driver is disabled automatically for SoMs with such SoCs.

+
+
    +

  • To put the device in OverDrive (OD) mode type:

    +
    +
    target:~$ echo 0 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • To put the device in NominalDrive (ND) mode type:

    +
    +
    target:~$ echo 1 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • To put the device in LowDrive (LD) mode type:

    +
    +
    target:~$ echo 2 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • To put the device in LowDrive (LD) mode with the lowest DDR speed with +SWFFC type:

    +
    +
    target:~$ echo 3 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • To check the current CPU frequency type:

    +
    +
    target:~$ mhz
+
    +
    +
    +
    • +

  • To check the current mode and DDR frequency type:

    +
    +
    target:~$ cat /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • To check the current VDD_SOC type:

    +
    +
    target:~$ cat /sys/kernel/debug/regulator/regulator_summary
+
    +
    +
    +
    • +
+

For more detailed information about the LPM driver and modes, refer to the NXPs +documentation: +https://docs.nxp.com/bundle/AN13917/page/topics/low_power_mode_use_cases.html

+
+
+

7.18.2. CPU Core Management

+

The i.MX 93 SoC can have multiple processor cores on the die. The i.MX 93, for +example, has 2 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0/
+cpu1/
+cpufreq/
+[...]
+
    +
    +

    Here the system has two processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu1/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU1 killed (polled 0 ms)
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu1/online
+
    +
    +
    • +
+
+
+

7.18.3. Suspend to RAM

+

The phyCORE-i.MX93 supports basic suspend and resume. Different wake-up sources can be +used. Suspend/resume is possible with:

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

To wake up with serial console run

+
target:~$ echo enabled > /sys/class/tty/ttyLP0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+

Device can be put into suspend and waken-up with PEB-EVAL-01 S2 button

+

To wake up with RTC alarm check: RTC Wakealarm

+
+
+
+

7.19. Thermal Management

+
+

7.19.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.19.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 93 SoC platform. The i.MX 9 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Commercial, +Industrial and Extended Industrial.

+ + + + + + + + + + + + + + + + + + + + +

Commercial

Industrial

Extended Industrial

passive (warning)

85°C

95°C

115°C

critical (shutdown)

90°C

100°C

120°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise and Power Allocator. The +default policy used in the BSP is step_wise.

+
+

Tip

+

If the value of the SoC temperature in the sysfs file temp reaches +trip_point_1, the board immediately shuts down to avoid any heat damage. If +this doesn’t meet you expectations, an external supervisor circuit that +starts the module again with X_ONOFF signal when the temperature drops below +a selected trip point can be implemented

+
+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+

7.19.3. PWM Fan

+

A PWM fan can be connected to the phyBOARD-Nash i.MX 93 connector X48 (label FAN).

+

Afterwards, a PWM fan overlay needs to be activated, otherwise PWM fan won’t +be recognized.

+
target:~$ vi /boot/bootenv.txt
+
+
+

The bootenv.txt file should look like this (it can also contain other devicetree +overlays!):

+
overlays=imx93-phyboard-nash-pwm-fan.dtbo
+
+
+

The changes will be applied after a reboot:

+
+
target:~$ reboot
+
+
+
+

For further information about devicetree overlays, read the device tree chapter.

+

The SoC only contains one temperature sensor which is already used by the +thermal frequency scaling. The fan thus can not be controlled by the kernel. +We use lmsensors with hwmon for this instead. lmsensors reads the temperature +periodically and adjusts output PWM duty-cycle accordingly. By default, +temperature threshold for PWM fan to activate is set to 60°C.

+

The settings can be configured in the configuration file:

+
/etc/fancontrol
+
+
+

Fan control is started by a systemd service during boot. This can be disabled +with:

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.20. Watchdog

+

The PHYTEC i.MX 93 modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.20.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.21. bbnsm Power Key

+

The X_ONOFF pin connected to the ON/OFF button can be pressed long (for 5 +seconds) to trigger Power OFF without SW intervention or used to wake up the +system out of suspend. With the bbnsm_pwrkey driver, the KEY_POWER event is +also reported to userspace when the button is pressed. On default, systemd is +configured to ignore such events. The function of Power OFF without SW +intervention are not configured. Triggering a power off with systemd when +pushing the ON/OFF button can be configured under /etc/systemd/logind.conf +and set using:

+
HandlePowerKey=poweroff
+
+
+
+
+

7.22. PXP

+

The i.MX 93 SoC contains an PiXel Pipeline (PXP). The PXP combines the following +into a single processing engine:

+
    +

  • Scaling

    • +

  • Color Space Conversion (CSC)

    • +

  • Secondary Color Space Conversion (CSC2)

    • +

  • Rotation

    • +
+

and thus minimizes the memory footprint required for the display pipeline. +How to use the PXP with Gstreamer and Wayland check the How to Use PXP in +GStreamer and Wayland (AN13829) Application note from NXP.

+
+
+

7.23. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 93 provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 93 Reference Manual). The following list is +an abstract from the i.MX 93 Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x47510000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x47510000

Description

BOOT_CFG0

3

0 0x60

boot fuse settings

BOOT_CFG1

3

1 0x64

boot fuse settings

BOOT_CFG2

3

2 0x68

boot fuse settings

BOOT_CFG3

3

3 0x6c

boot fuse settings

MAC1_ADDR

39

3

0x4ec

contains lower 32 bits +of ENET0 MAC address

MAC1/2_ADDR

39

4

0x4f0

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

MAC2_ADDR

39

5

0x4f4

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 93 Security Reference Manual.

+
+

7.23.1. Reading Fuse Values in uBoot

+

MAC1_ADDR:

+
u-boot=> fuse read 39 3
+
+
+
+
+

7.23.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc\@0/47510000.efuse/fsb_s400_fuse0/nvmem
+
+
+
+
+

7.23.3. Burning MAC addresses

+

Let’s say we want to burn the following MAC addresses:

+ + + + + + + + + +

MAC1

12:34:56:78:90:Aa

MAC2

Bb:Cc:Dd:Ee:Ff:D0

+

We would execute this in u-boot:

+
u-boot=> fuse prog 39 3 0x567890Aa
+u-boot=> fuse prog 39 4 0xFfD01234
+u-boot=> fuse prog 39 5 0xBbCcDdEe
+
+
+
+
+

7.23.4. Burning Boot Fuses

+
+

Warning

+

Fuses can only be written once! You can brick your board easily by burning +the wrong boot configuration. It cannot be reversed!

+
+

Which fuse bank/word should be used to program the BOOT_CFGX can be checked in +i.MX 93 Applications Processor Reference Manual attached spreadsheet named +i.MX93_Fusemap.xlsx.

+

These values should be written to the BOOT_CFG0, which can be read/written from +fuses on Bank 3, Word 0.

+ + + + + + + + + + + + + + +

Boot Device

BOOT_CFG0

eMMC

0x20020002

SD Card

0x20000103

+

To set internal fuses to boot from eMMC one can program them with:

+
u-boot=> fuse prog 3 0 0x20020002
+
+
+

In this example we:

+
    +

  • set the Boot_Mode to 0b0010 (eMMC) with BOOT_CFG0[3:0],

    • +

  • set the eMMC Bus width to 0b01 (8 bit) with BOOT_CFG0[18:17]

    • +

  • set the BT_FUSE_SEL (Boot fuses already programmed) bit with BOOT_CFG0[29]

    • +
+

Make sure you set the right bits by reading the Boot Fusemap chapter in +i.MX 93 Applications Processor Reference Manual.

+
+
+
+

7.24. TPM

+

The phyBOARD-Nash i.MX 93 is equipped with a Trusted Platform Module (TPM) +that provides hardware-based security functions.

+

Here are some useful examples to work with the TPM

+

Generate 4-byte random value with TPM2 tools:

+
+
target:~$ tpm2_getrandom --hex 4
+
+
+
+

Generate 4-byte random value with OpenSSL tools:

+
+
target:~$ openssl rand -engine libtpm2tss --hex 4
+
+
+
+

Generate RSA private key and validate its contents:

+
+
target:~$ openssl genrsa -engine libtpm2tss -out /tmp/priv_key 512
+Engine "tpm2tss" set.
+target:~$ openssl rsa -check -in /tmp/priv_key -noout
+RSA key ok
+target:~$ cat /tmp/priv_key
+-----BEGIN PRIVATE KEY-----
+MIIBVQIBADANBgkqhkiG9w0BAQEFAASCAT8wggE7AgEAAkEAxsvmcbxjwuKnYeuZ
+2AVBmuLvYyqF/LpYOD3IB/v+YvEolxdGGmjiFLECU6xZ1j3+dIt4Y1zbcKS1OcWT
+I8mbSwIDAQABAkBoy8wrYNhmP/1kzUJIclznPYJckGoZlFI1M7xjGSA9H1xDK6if
+5g5CYCHPrbBp8e0mEokPRZoihxxzGTxGPiahAiEA/7OYMOpVZ5SD3YcRsWcQlkWI
+MOSPUYg6vxvGG9xp4FcCIQDHB01RoHr+qXJwxIu3/3oQAUBI4ACJ4JRp0KelwhC0
+LQIhANJzSvg/dak5l8pU55/99q3nbm7nPnnZSJiP0F6P62gjAiEAjf7qrfMF7Uyt
+RkEjwbl2t5Z868FNARGGMVxZT4x+aF0CIGxlmP2pL8xFu1bWB282LSedqZUdQwel
+Lxi7+svb2+uJ
+-----END PRIVATE KEY-----
+
+
+
+
+

Note

+

Do NOT share your private RSA keys if you are going to use these keys for any +security purposes.

+
+

Generate RSA public key and validate its contents:

+
+
target:~$ openssl rsa -in /tmp/test_key -pubout -out /tmp/pub_key
+writing RSA key
+target:~$ openssl pkey -inform PEM -pubin -in /tmp/pub_key -noout
+target:~$ cat /tmp/pub_key
+-----BEGIN PUBLIC KEY-----
+MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMbL5nG8Y8Lip2HrmdgFQZri72Mqhfy6
+WDg9yAf7/mLxKJcXRhpo4hSxAlOsWdY9/nSLeGNc23CktTnFkyPJm0sCAwEAAQ==
+-----END PUBLIC KEY-----
+
+
+
+

Device tree TPM configuration can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n151

+
+
+
+

8. i.MX 93 M33 Core

+

In addition to the Cortex-A55 cores, there is a Cortex-M33 Core as MCU +integrated into the i.MX 93 SoC. Our Yocto-Linux-BSP runs on the A55-Cores and +the M33 Core can be used as a secondary core for additional tasks using +bare-metal firmware. +Both cores have access to the same peripherals and thus peripheral +usage needs to be limited either in the M33 Core’s firmware or the devicetree +for the Linux operating system.

+

Our Yocto-BSP contains pre-built firmware examples for M33 Core from NXP.

+

This section describes how to run pre-built M33 Core firmware examples on phyBOARD-Segin/Nash i.MX 93.

+
+

8.1. Running M33 Core Examples

+

There are two ways to run the M33 Core firmware examples, from U-Boot bootloader +and from Remoteproc subsystem within a running Linux.

+

To receive debug messages start your favorite terminal software (e.g. Minicom, +Tio, or Tera Term) on your host PC and configure it for 115200 baud, 8 data +bits, no parity, and 1 stop bit (8n1) with no handshake.

+

On phyBOARD-Segin/Nash i.MX 93 an external “USB TTL to serial adapter” is required. Adapter’s I/O +pins should be able to operate at 3.3V voltage levels.

+

Connect external “USB TTL to serial adapter” signals to the +X16 connector on the board according to the following +table:

+ + + + + + + + + + + + + + + + + + + + + +

USB-TTL adapter pins

X16 signal

X16 pin

RXD

X_UART2_TX

5

TXD

X_UART2_RX

8

GND

GND

4

+
+

8.1.1. Running Examples from U-Boot

+

To load firmware examples using the U-Boot bootloader, the bootaux command +can be used:

+
    +

  1. Prepare an SD Card with our Yocto-BSP

    2. +

  2. Stop the autoboot by pressing any key

    3. +

  3. List available M33 Core firmware examples on the first partition of SD Card:

    4. +
+
u-boot=> ls mmc 1
+
+
+
+

Note

+

Available firmware examples start with imx93-11x11-evk_m33_TCM_* and +end with *.bin. Examples come from NXP’s Yocto layer meta-imx and are +selected based on compatibility with phyBOARD-Segin/Nash i.MX 93 hardware.

+
+
    +

  1. Load desired firmware example:

    2. +
+
u-boot=> fatload mmc 1 ${loadaddr} <firmware.bin>
+u-boot=> cp.b ${loadaddr} 0x201e0000 ${filesize}
+u-boot=> run prepare_mcore
+u-boot=> bootaux 0x1ffe0000 0
+## Starting auxiliary core addr = 0x1FFE0000...
+
+
+

The program’s output should appear on the M33 Core’s debug UART.

+
+
+

8.1.2. Running Examples from Linux using Remoteproc

+

Remoteproc is a module that allows you to control the M33 Core from Linux +during runtime. Firmware examples for M33 Core can be loaded and the execution +started or stopped within Linux. To use Remoteproc a devicetree overlay needs +to be set:

+

Edit the bootenv.txt file located in the /boot directory on the target +by adding imx93-phycore-rpmsg.dtso:

+
overlays=imx93-phyboard-segin-peb-av-02.dtbo imx93-phycore-rpmsg.dtso
+
+
+

Restart the target and execute in U-Boot:

+
u-boot=> run prepare_mcore
+
+
+

Firmware examples *.elf files for the M33 Core can be found under +/lib/firmware. List available firmware examples:

+
target:~$ ls /lib/firmware/*.elf
+
+
+

To load the firmware, type:

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

To load a different firmware, the M33 Core needs to be stopped:

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

Note

+

The samples found in /lib/firmware on the target come from NXP’s +Yocto layer meta-imx and are selected based on compatibility with phyBOARD-Segin/Nash i.MX 93 +hardware.

+
+

Some firmware examples from NXP require additional Linux kernel modules to be +loaded.

+

For example, when loading imx93-11x11-evk_m33_TCM_rpmsg_lite_str_echo_rtos.elf +firmware, one requires corresponding imx_rpmsg_tty module to be loaded:

+
target:~$ modprobe imx_rpmsg_tty
+
+
+

This exposes an RPMsg endpoint as a virtual TTY at /dev/ttyRPMSG30. +Now it is possible to send messages from A55 Core to M33 Core by typing:

+
target:~$ echo "PHYTEC" > /dev/ttyRPMSG30
+
+
+

Observing M33 Core debug UART should result in the following output:

+
RPMSG String Echo FreeRTOS RTOS API Demo...
+
+Nameservice sent, ready for incoming messages...
+Get Message From Master Side : "PHYTEC" [len : 6]
+
+
+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/bsp/imx9/imx93/pd24.2.0.html b/previews/271/bsp/imx9/imx93/pd24.2.0.html new file mode 100644 index 000000000..33dc703e8 --- /dev/null +++ b/previews/271/bsp/imx9/imx93/pd24.2.0.html @@ -0,0 +1,4241 @@ + + + + + + + + + 1. PHYTEC Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 93 BSP Manual

Document Title

i.MX 93 BSP Manual

Document Type

BSP Manual

Yocto Manual

Scarthgap

Release Date

2024/10/08

Is Branch of

i.MX 93 BSP Manual

+

The table below shows the Compatible BSPs for this manual:

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-NXP-i.MX93-PD24.2.0

Major

2024/10/08

Released

+

This BSP manual guides you through the installation and creation steps for the +Board Support Package (BSP) and describes how to handle the interfaces for the +phyBOARD-Segin i.MX 93 and phyBOARD-Nash i.MX 93 Kit. Furthermore, this document describes how to create BSP images from the +source code. This is useful for those who need to change the default image and +need a way to implement these changes in a simple and reproducible way. Further, +some sections of this manual require executing commands on a personal +computer (host). Any and all of these commands are assumed to be executed on a +Linux Operating System.

+
+

Note

+

This document contains code examples that describe the communication with the +board over the serial shell. The code examples lines begin with “host:~$”, +“target:~$” or “u-boot=>”. This describes where the commands are to be +executed. Only after these keywords must the actual command be copied.

+
+
+

1. PHYTEC Documentation

+

PHYTEC provides a variety of hardware and software documentation for +all of our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE +board along with brief informationon building a BSP, the device +tree, and accessing peripherals.

    • +

  • Hardware Manual: A detailed description of the System on +Module and accompanying carrierboard.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version +the phyCORE uses. This guide contains an overview of Yocto; +introducing, installing, and customizing the PHYTEC BSP; how to +work with programs like Poky and Bitbake; and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating +software, device tree, and accessing peripherals can be found +here.

    • +

  • Development Environment Guide: This guide shows how to work +with the Virtual Machine (VM) Host PHYTEC has developed and +prepared to run various Development Environments. There are +detailed step-by-step instructions for Eclipse and Qt Creator, +which are included in the VM. There are instructions for running +demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a +part of this guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin +table (in Excel format). This table will show the complete +default signal path, from the processor to the carrier board. +The default device tree muxing option will also be included. +This gives a developer all the information needed in one location +to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an +application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also +provide Product Change Notifications, Application Notes, and +Technical Notes. These will be done on a case-by-case basis. Most +of the documentation can be found on the https://www.phytec.de/produkte/system-on-modules/phycore-imx-91-93/#downloads of our product.

+
+

1.1. Supported Hardware

+

On our web page, you can see all supported Machines with the available Article +Numbers for this release: BSP-Yocto-NXP-i.MX93-PD24.2.0, see download.

+

If you choose a specific Machine Name in the section Supported Machines, +you can see which Article Numbers are available under this machine and also +a short description of the hardware information. In case you only have +the Article Number of your hardware, you can leave the Machine +Name drop-down menu empty and only choose your Article Number. Now it +should show you the necessary Machine Name for your specific hardware.

+
+

Tip

+

Console examples in this BSP manual only focus on phyBOARD-Segin i.MX 93. +Similar commands can also be executed for/on phyBOARD-Nash i.MX 93

+
+
+

1.1.1. phyBOARD-Segin i.MX 93 Components

+
+../../../_images/phyBOARD-Segin-iMX93-top-components.jpg + +
+

phyBOARD-Segin i.MX 93 Components (top)

+
+
+
+../../../_images/phyBOARD-Segin-iMX93-bottom-components.jpg + +
+

phyBOARD-Segin i.MX 93 Components (bottom)

+
+
+
+
+

1.1.2. phyBOARD-Nash i.MX 93 Components

+
+../../../_images/phyBOARD-Nash-iMX93-top-components.jpg + +
+

phyBOARD-Nash i.MX 93 Components (top)

+
+
+
+../../../_images/phyBOARD-Nash-iMX93-bottom-components.jpg + +
+

phyBOARD-Nash i.MX 93 Components (bottom)

+
+
+
+
+
+
+

2. Getting Started

+

The phyBOARD-Segin i.MX 93 and phyBOARD-Nash i.MX 93 Kit is shipped with a pre-flashed SD card. It contains the +phytec-qt6demo-image and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +PHYTEC download server. This chapter explains how to flash a BSP +image to SD card and how to start the board.

+

There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool dd. An +alternative way is to use PHYTEC’s system initialization program called +partup, which makes it especially easy to +format more complex systems. You can get prebuilt Linux binaries of partup from its release page. Also read +partup’s README for installation +instructions.

+
+

2.1. Get the Image

+

The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using dd, can be downloaded from the PHYTEC download server.

+

Get either the partup package or the WIC image from the download server:

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic.xz
+
+
+
+

Note

+

For eMMC, more complex partitioning schemes or even just large images, we +recommend using the partup package, as it is faster in writing than dd +and allows for a more flexible configuration of the target flash device.

+
+
+
+

2.2. Write the Image to SD Card

+
+

Warning

+

To create your bootable SD card, you must have root privileges on your Linux +host PC. Be very careful when specifying the destination device! All files +on the selected device will be erased immediately without any further query!

+

Selecting the wrong device may result in data loss and e.g. could erase +your currently running system on your host PC!

+
+
+

2.2.1. Finding the Correct Device

+

To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card.

+
    +

  1. In order to get the correct device name, remove your SD card and +execute:

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. Now insert your SD card and execute the command again:

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. Compare the two outputs to find the new device names listed in the second +output. These are the device names of the SD card (device and partitions if +the SD card was formatted).

    4. +

  4. In order to verify the device names being found, execute the command +sudo dmesg. Within the last lines of its output, you should also find the +device names, e.g. /dev/sde or /dev/mmcblk0 (depending on your +system).

    5. +
+

Alternatively, you may use a graphical program of your choice, like GNOME Disks or KDE Partition Manager, to find the correct device.

+

Now that you have the correct device name, e.g. /dev/sde, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. /dev/sde1) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption.

+

Unmount all those partitions, e.g.:

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

Now, the SD card is ready to be flashed with an image, using either partup, +dd or bmap-tools.

+
+
+

2.2.2. Using bmap-tools

+

One way to prepare an SD card is using +bmap-tools. Yocto +automatically creates a block map file (<IMAGENAME>-<MACHINE>.wic.bmap) for +the WIC image that describes the image content and includes checksums for data +integrity. bmaptool is packaged by various Linux distributions. For +Debian-based systems install it by issuing:

+
host:~$ sudo apt install bmap-tools
+
+
+

Flash a WIC image to SD card by calling:

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

Replace <your_device> with your actual SD card’s device name found previously, +and make sure to place the file <IMAGENAME>-<MACHINE>.wic.bmap alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip.

+
+

Warning

+

bmaptool only overwrites the areas of an SD card where image data is +located. This means that a previously written U-Boot environment may still be +available after writing the image.

+
+
+
+

2.2.3. Using partup

+

Writing to an SD card with partup is done in a single command:

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).partup /dev/<your_device>
+
+
+

Make sure to replace <your_device> with your actual device name found previously.

+

Further usage of partup is explained at its official documentation website.

+
+

Warning

+

Host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to write partup packages created with Yocto Mickledore +or newer to SD-Card. This is due to a new default option in resize2fs which causes an +incompatibility. See release notes.

+
+
+

Note

+

partup has the advantage of allowing to clear specific raw areas in the +MMC user area, which is used in our provided partup packages to erase any +existing U-Boot environments. This is a known issue bmaptool does not +solve, as mentioned in the previous chapter.

+

Another key advantage of partup over other flashing tools is that it allows +configuring MMC specific parts, like writing to eMMC boot partitions, without +the need to call multiple other commands when writing.

+
+
+
+

2.2.4. Using dd

+

After having unmounted all SD card’s partitions, you can create your bootable SD card.

+

Some PHYTEC BSPs produce uncompressed images (with filename-extension *.wic), +and some others produce compressed images (with filename-extension *.wic.xz).

+

To flash an uncompressed images (*.wic) use command below:

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Or to flash a compressed images (*.wic.xz) use that command:

+
host:~$ xzcat phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

Again, make sure to replace <your_device> with your actual device name found +previously.

+

The parameter conv=fsync forces a sync operation on the device before +dd returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter status=progress will print out +information on how much data is and still has to be copied until it is +finished.

+
+
+
+

2.3. First Start-up

+ +../../../_images/SD_Card_Boot.png +
    +

  • Insert the SD card

    • +

  • Connect the targets debug console with your host. Use UART1 console on PEB-EVAL-01 for phyBOARD-Segin and X-37 +USB-C debug for phyBOARD-Nash.

    • +

  • Power up the board

    • +

  • Open serial/usb port with 115200 baud and 8N1 (you should see u-boot/linux +start on the console

    • +
+
+
+
+

3. Building the BSP

+

This section will guide you through the general build process of the i.MX 93 BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (scarthgap).

+
+

3.1. Basic Set-Up

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (scarthgap).

+
+
+

3.2. Get the BSP

+

There are two ways to get the BSP sources. You can download the complete BSP +sources from our download page: BSP-Yocto-i.MX93; or you can fetch and build it +yourself with Yocto. This is particularly useful if you want to make +customizations.

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP structure.

+
    +

  • Create a fresh project folder, get phyLinux, and make the script executable:

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    Warning

    +

    A clean folder is important because phyLinux will clean its working +directory. Calling phyLinux from a directory that isn’t empty will result in +a warning.

    +
    +
    • +

  • Run phyLinux:

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    Note

    +

    On the first initialization, the phyLinux script will ask you to install +the Repo tool in your /usr/local/bin directory.

    +
    +
    • +

  • During the execution of the init command, you need to choose your processor +platform (SoC), PHYTEC’s BSP release number, and the hardware you are working +on.

    +
    +

    Note

    +

    If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. And have a look at +our BSP.

    +
    +
    • +

  • It is also possible to pass this information directly using command line +parameters:

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-wayland MACHINE=phyboard-segin-imx93-2 ./phyLinux init -p imx93 -r BSP-Yocto-NXP-i.MX93-PD24.2.0
+
    +
    +
    • +
+

After the execution of the init command, phyLinux will print a few important +notes. For example, it will print your git identify, SOC and BSP release which +was selected as well as information for the next steps in the build process.

+
+

3.2.1. Starting the Build Process

+
    +

  • Set up the shell environment variables:

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    Note

    +

    This needs to be done every time you open a new shell for starting builds.

    +
    +
    • +

  • The current working directory of the shell should change to build/.

    • +

  • Open the main configuration file and accept the GPU and VPU binary license +agreements. Do this by uncommenting the corresponding line, as below.

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • Build your image:

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    Note

    +

    For the first build we suggest starting with our smaller non-graphical +image phytec-headless-image to see if everything is working correctly.

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    The first compile process takes about 40 minutes on a modern Intel +Core i7. All subsequent builds will use the filled caches and should take +about 3 minutes.

    +
    +
    • +
+
+
+

3.2.2. BSP Images

+

All images generated by Bitbake are deployed to +~/yocto/build/deploy*/images/<machine>. The following list shows for +example all files generated for the phyboard-segin-imx93-2 machine:

+
    +

  • u-boot.bin: Binary compiled U-boot bootloader (U-Boot). Not the final +Bootloader image!

    • +

  • oftree: Default kernel device tree

    • +

  • u-boot-spl.bin: Secondary program loader (SPL)

    • +

  • bl31-imx93.bin: ARM Trusted Firmware binary

    • +

  • lpddr4_dmem_1d_v202201.bin, lpddr4_dmem_2d_v202201.bin, +lpddr4_imem_1d_v202201.bin, +lpddr4_imem_2d_v202201.bin: DDR PHY firmware images

    • +

  • imx-boot: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM +Trusted Firmware and DDR firmware. This is the final bootloader image which +is bootable.

    • +

  • Image: Linux kernel image

    • +

  • Image.config: Kernel configuration

    • +

  • imx93-phyboard-*.dtb: Kernel device tree file

    • +

  • imx93-phy*.dtbo: Kernel device tree overlay files

    • +

  • phytec-*.tar.gz: Root file system, +of bitbake-image that was built.

    +
      +

    • phytec-qt6demo-image-phyboard-*-imx93-*.tar.gz: when bitbake-build +was processed for phytec-qt6demo-image

      • +

    • phytec-headless-image-phyboard-*-imx93-*.tar.gz: when bitbake-build +was processed for phytec-headless-image

      • +
    +
    • +

  • phytec-*.rootfs.wic.xz: Compressed bootable SD +card image of bitbake-image that was built. Includes bootloader, DTBs, Kernel +and Root file system.

    +
      +

    • phytec-qt6demo-image-phyboard-*-imx93-*.rootfs.wic.xz: when bitbake-build +was processed for phytec-qt6demo-image

      • +

    • phytec-headless-image-phyboard-*-imx93-*.rootfs.wic.xz: when bitbake-build +was processed for phytec-headless-image

      • +
    +
    • +

  • imx93-11x11-evk_m33_*.bin, binaries of demo applications for the +Cortex-M33 MCU; can be manually loaded and started with U-Boot or Linux

    • +
+
+
+
+
+

4. Installing the OS

+
+

4.1. Bootmode Switch (S3)

+
+

Tip

+

Hardware revision baseboard:

+
    +

  • phyBOARD-Segin i.MX 93: 1472.5

    • +

  • phyBOARD-Nash i.MX 93: 1616.0, 1616.1

    • +
+
+

The phyBOARD-Segin/Nash i.MX 93 features a boot switch with four individually switchable ports to +select the phyCORE-i.MX 93 default bootsource.

+ + + + + + + + + +
+../../../_images/eMMC.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses.png +
+

Internal Fuses

+
+
+
+../../../_images/USB_Serial_Download.png +
+

USB Serial Download

+
+
+
+../../../_images/SD_Card_Boot.png +
+

SD Card

+
+
+
+
+
+

4.2. Flash eMMC

+

To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the bootmode switch (S3) is set to eMMC.

+
+

Warning

+

When eMMC and SD card are flashed with the same (identical) image, the UUIDs +of the boot partitions are also identical. If the SD card is connected when +booting, this leads to non-deterministic behavior as Linux mounts the boot +partition based on UUID.

+
target:~$ blkid
+
+
+

can be run to inspect whether the current setup is affected. If mmcblk0p1 +and mmcblk1p1 have an identical UUID, the setup is affected.

+
+
+

4.2.1. Flash eMMC from SD Card

+

If there is no network available, you can update the eMMC from SD card. For +that, you only need a ready-to-use image file (*.wic) located on the +SD card. Because the image file is quite large, you have to enlarge your SD card +to use its full space (if it was not enlarged before). To enlarge your SD card, +see Resizing ext4 Root Filesystem.

+

Alternatively, flash a partup package to the SD card, as described in +Getting Started. This will ensure the full space of the SD card is used.

+
+

4.2.1.1. Flash eMMC from SD card in Linux on Target

+

You can flash the eMMC on Linux. You only need a partup package or WIC image +saved on the SD card.

+
    +

  • Show your saved partup package or WIC image or WIC.XZ image files on the SD card:

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.partup
+phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic.xz
+
    +
    +
    • +

  • Show list of available MMC devices:

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk0
+mmcblk0boot0
+mmcblk0boot1
+mmcblk0p1
+mmcblk0p2
+mmcblk0rpmb
+
    +
    +
    • +

  • The eMMC device can be recognized by the fact that it contains two boot +partitions: (mmcblk0boot0; mmcblk0boot1)

    • +

  • Write the image to the phyCORE-i.MX 93 eMMC (/dev/mmcblk0 without +partition) using partup:

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.partup /dev/mmcblk0
+
    +
    +
    +

    Tip

    +

    Using partup is highly recommended since it is easier to use and has the +advantage of using the full capacity of the eMMC device, adjusting +partitions accordingly.

    +
    +
    +

    Note

    +

    Alternatively, dd may be used instead.

    +

    For uncompressed WIC images (*.wic):

    +
    target:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +

    For compressed WIC images (*.wic.xz):

    +
    target:~$ zstdcat phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic.xz | sudo dd of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +

    Keep in mind that the root partition does not make use of the full space +when flashing with dd.

    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Warning

    +

    Before this will work, you need to configure the bootmode switch (S3) to eMMC.

    +
    +
    • +
+
+
+
+

4.2.2. Flash eMMC from Network

+

i.MX 93 boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the WIC image (<name>.wic) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system.

+
+

Note

+

Some PHYTECs BSPs produce compressed .wic.xz images. In this case, the +compressed image must first be uncompressed.

+
host:~$ unxz phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic.xz
+
+
+
+
+

4.2.2.1. Flash eMMC via Network in Linux on Target

+

You can update the eMMC from your target.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Take an uncompressed image on the host and send it with ssh through +the network to the eMMC of the target with a one-line command:

+
target:~$ ssh <USER>@192.168.3.10 "dd if=<path_to_file>/phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic" | dd of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
+
+
+
+

4.2.2.2. Flash eMMC via Network in Linux on Host

+

It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Show your available image files on the host:

+
host:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic
+
+
+

Send the image with the dd command combined with ssh through the network +to the eMMC of your device:

+
host:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic bs=1M status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk0 conv=fsync"
+
+
+
+
+
+

4.2.3. Flash eMMC U-Boot image via Network from running U-Boot

+

Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area.

+
+

Tip

+

A working network is necessary! Setup Network Host

+
+

Load image over tftp into RAM and then write it to eMMC:

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 0
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

Hint

+

The hexadecimal value represents the offset as a multiple of 512 byte +blocks. See the offset table for the correct value +of the corresponding SoC.

+
+
+
+

4.2.4. Flash eMMC from USB

+
+

4.2.4.1. Flash eMMC from USB in Linux

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic). Set the bootmode switch (S3) to SD Card.

+
    +

  • Insert and mount the USB stick:

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • Now show your saved image files on the USB Stick:

    +
    target:~$ cd /mnt
+target:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic
+
    +
    +
    • +

  • Show list of available MMC devices:

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk0
+mmcblk0boot0
+mmcblk0boot1
+mmcblk0p1
+mmcblk0p2
+mmcblk0rpmb
+
    +
    +
    • +

  • The eMMC device can be recognized by the fact that it contains two boot +partitions: (mmcblk0boot0; mmcblk0boot1)

    • +

  • Write the image to the phyCORE-i.MX 93 eMMC (/dev/mmcblk0 without partition):

    +
    target:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +
    • +

  • After a complete write, your board can boot from eMMC.

    +
    +

    Tip

    +

    Before this will work, you need to configure the bootmode switch (S3) to +eMMC.

    +
    +
    • +
+
+
+
+
+

4.3. RAUC

+

The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: L-1006e.A5 RAUC Update & Device Management Manual.

+
+
+
+

5. Development

+
+

5.1. Host Network Preparation

+

For various tasks involving a network in the Bootloader, some host services are +required to be set up. On the development host, a TFTP, NFS and DHCP server must +be installed and configured. The following tools will be needed to boot via +Ethernet:

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP Server Setup

+
    +

  • First, create a directory to store the TFTP files:

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • Then copy your BSP image files to this directory and make sure other users have read +access to all the files in the tftp directory, otherwise they are not accessible +from the target.

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • You also need to configure a static IP address for the appropriate interface. +The default IP address of the PHYTEC evaluation boards is 192.168.3.11. Setting +a host address 192.168.3.10 with netmask 255.255.255.0 is a good choice.

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    Replace <network-interface> with the network interface you configured and want to +connect the board to. You can show all network interfaces by not specifying a network +interface.

    +
    • +

  • The message you receive should contain this:

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • Create or edit the /etc/default/tftpd-hpa file:

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • Set TFTP_DIRECTORY to your TFTP server root directory

    • +

  • Set TFTP_ADDRESS to the host address the server is listening to (set to +0.0.0.0:69 to listen to all local IPs)

    • +

  • Set TFTP_OPTIONS, the following command shows the available options:

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • Restart the services to pick up the configuration changes:

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

Now connect the ethernet port of the board to your host system. +We also need a network connection between the embedded board and the TFTP +server. The server should be set to IP 192.168.3.10 and +netmask 255.255.255.0.

+
+

5.1.1.1. NFS Server Setup

+
    +

  • Create an nfs directory:

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • The NFS server is not restricted to a certain file system location, so all we +have to do on most distributions is modify the file /etc/exports and export +our root file system to the embedded network. In this example file, the whole +directory is exported and the “lab network” address of the development host is +192.168.3.10. The IP address has to be adapted to the local needs:

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • Now the NFS-Server has to read the /etc/exportfs file again:

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP Server setup

+
    +

  • Create or edit the /etc/kea/kea-dhcp4.conf file; Using the internal subnet +sample. Replace <network-interface> with the name for the physical network +interface:

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

Warning

+

Be careful when creating subnets as this may interfere with the company +network policy. To be on the safe side, use a different network and specify +that via the interfaces configuration option.

+
+
    +

  • Now the DHCP-Server has to read the /etc/kea/kea-dhcp4.conf file again:

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

When you boot/restart your host PC and don’t have the network interface, as +specified in the kea-dhcp4 config, already active the kea-dhcp4-server will +fail to start. Make sure to start/restart the systemd service when you connect +the interface.

+
+
+
+
+

5.2. Booting the Kernel from a Network

+

Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device.

+
+

5.2.1. Place Images on Host for Netboot

+
    +

  • Copy the kernel image to your tftp directory:

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • Copy the devicetree to your tftp directory:

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • Copy all the overlays you want to use into your tftp directory:

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • Make sure other users have read access to all the files in the tftp directory, +otherwise they are not accessible from the target:

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • Extract the rootfs to your nfs directory:

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-segin-imx93-2.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

Note

+

Make sure you extract with sudo to preserve the correct ownership.

+
+
+
+

5.2.2. Set the bootenv.txt for Netboot

+

Create a bootenv.txt file in your tftp directory and write the following variables into it.

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> has to be replaced with the devicetree overlay filenames that you want to use. +Separate the filenames by spaces. For example:

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

Tip

+

All supported devicetree overlays are in the device tree chapter.

+
+
+
+

5.2.3. Network Settings on Target

+

To customize the targets ethernet configuration, please follow the description +here: Network Environment Customization

+
+
+

5.2.4. Booting from an Embedded Board

+

Boot the board into the U-boot prompt and press any key to hold.

+
    +

  • To boot from a network, call:

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. Working with UUU-Tool

+

The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the Official UUU-tool +documentation.

+
+

5.3.1. Host preparations for UUU-Tool Usage

+
    +

  • Follow the instructions from https://github.com/nxp-imx/mfgtools#linux.

    • +

  • If you built UUU from source, add it to PATH:

    +

    This BASH command adds UUU only temporarily to PATH. To add it permanently, add this line to +~/.bashrc.

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • Set udev rules (documented in uuu -udev):

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. Get Images

+

Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/phyboard-segin-imx93-2/. For flashing a wic image to eMMC, +you will also need phytec-qt6demo-image-phyboard-segin-imx93-2.wic.

+
+
+

5.3.3. Prepare Target

+

Set the bootmode switch (S3) to USB Serial Download. Also, connect USB port +X8 (USB micro/OTG connector) to your host.

+
+
+

5.3.4. Starting bootloader via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

You can see the bootlog on the console via UART1 console on PEB-EVAL-01 for phyBOARD-Segin and X-37 +USB-C debug for phyBOARD-Nash, as usual.

+
+

Note

+

The default boot command when booting with UUU-Tool is set to fastboot. If +you want to change this, please adjust the environment variable bootcmd_mfg +in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with +UUU-tool the default environment is loaded. Saveenv has no effect. If you +want to change the boot command permanently for UUU-boot, you need to change +this in U-Boot code.

+
+
+
+

5.3.5. Flashing U-boot Image to eMMC via UUU-Tool

+
+

Warning

+

UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets +the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the +bootloader to reside in the eMMC USER partition. Flashing next U-Boot version +.wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device +always using U-boot saved in BOOT partitions. To fix this in U-Boot:

+
u-boot=> mmc partconf 0 0 0 0
+u-boot=> mmc partconf 0
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

This way the bootloader is still flashed to eMMC BOOT partitions but it is +not used!

+

When using partup tool and .partup package for eMMC flashing this is +done by default, which makes partup again superior flash option.

+
+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. Flashing wic Image to eMMC via UUU-Tool

+

Execute and power up the board:

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-segin-imx93-2.wic
+
+
+
+
+
+

5.4. Standalone Build preparation

+

In this section, we describe how to build the U-Boot and the Linux kernel +without using the Yocto Project. This +procedure makes the most sense for development. The U-Boot source code, +the Linux kernel, and all other git repositories are available on our +Git server at git://git.phytec.de.

+
+

Note

+

Should your company firewall/gateway inhibit the git protocol, you may use +HTTP or HTTPS instead (e.g. git clone git://git.phytec.de/u-boot-imx)

+
+
+

5.4.1. Git Repositories

+
    +

  • Used U-Boot repository:

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • Our U-Boot is based on the u-boot-imx and adds board-specific patches.

    • +

  • Used Linux kernel repository:

    +
    git://github.com/phytec/linux-phytec-imx.git
+
    +
    +
    • +

  • Our i.MX 93 kernel is based on the linux-phytec-imx kernel.

    • +
+

To find out which u-boot and kernel tags to use for a specific board, have a +look at your BSP source folder:

+
+
meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. Get the SDK

+

You can download the SDK here, or build it yourself with Yocto:

+
    +

  • Move to the Yocto build directory:

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

After a successful build the SDK installer is deployed to build/deploy*/sdk.

+
+
+

5.4.3. Install the SDK

+
    +

  • Set correct permissions and install the SDK:

    +
    host:~$ chmod +x phytec-ampliphy-vendor-wayland-glibc-x86_64-phytec-qt6demo-image-cortexa55-toolchain-5.0.sh
+host:~$ ./phytec-ampliphy-vendor-wayland-glibc-x86_64-phytec-qt6demo-image-cortexa55-toolchain-5.0.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-wayland/5.0):
+You are about to install the SDK to "/opt/ampliphy-vendor-wayland/5.0". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. Using the SDK

+

Activate the toolchain for your shell by sourcing the environment-setup file +in the toolchain directory:

+
host:~$ source /opt/ampliphy-vendor-wayland/5.0/environment-setup-cortexa55-phytec-linux
+
+
+
+
+

5.4.5. Installing Required Tools

+

Building Linux and U-Boot out-of-tree requires some additional host tool +dependencies to be installed. For Ubuntu you can install them with:

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. U-Boot standalone build

+
+

5.5.1. Get the source code

+
    +

  • Get the U-Boot sources:

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • To get the correct U-Boot tag you need to take a look at our release +notes, which can be found here: release notes

    • +

  • The tag needed at this release is called v2024.04-2.0.0-phy6

    • +

  • Check out the needed U-Boot tag:

    • +
+
host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2024.04-2.0.0-phy6
+
+
+
    +

  • Technically, you can now build the U-Boot, but practically there are some +further steps necessary:

    +
      +

    • Create your own development branch:

      +
      host:~/u-boot-imx$ git switch --create <new-branch>
+
      +
      +
      +

      Note

      +

      You can name your development branch as you like, this is just an example.

      +
      +
      • +
    +
    • +

  • Set up a build environment:

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor-wayland/5.0/environment-setup-cortexa55-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. Get the needed binaries

+

To build the imx-boot, you need to gather these files for +later use with imx-mkimage tool:

+
    +

  • ARM Trusted firmware binary (mkimage tool compatible format +bl31.bin): bl31-imx93.bin

    • +

  • OPTEE image (optional): tee.bin

    • +

  • DDR firmware files (mkimage tool compatible format +lpddr4_[i,d]mem_*d_*.bin): +lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, +lpddr4_imem_2d_*.bin

    • +

  • Container image: mx93a1-ahab-container.img

    • +
+

If you already built our BSP with Yocto, you can get +these files from the directory mentioned here: BSP Images

+

Or you can download the files from the PHYTEC download server (https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools/). +You can use the commands below to download all the files from that server:

+
host:~$ mkdir ./artefacts && cd ./artefacts
+host:~/artefacts$ wget \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//bl31-imx93.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//tee.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_dmem_1d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_dmem_2d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_imem_1d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_imem_2d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//mx93a1-ahab-container.img
+host:~/artefacts$ cd ..
+
+
+
+
+

5.5.3. Build the bootloader

+
    +

  • Build u-boot:

    +
    host:~/u-boot-imx$ make <defconfig>
+host:~/u-boot-imx$ make
+host:~/u-boot-imx$ cd ..
+
    +
    +
    +

    Note

    +

    In command above replace <defconfig> with imx93-phycore_defconfig

    +
    +
    • +
+
+

5.5.3.1. Build final flash.bin with imx-mkimage

+
    +

  • Get imx-mkimage:

    +
    host:~$ git clone https://github.com/nxp-imx/imx-mkimage
+host:~$ cd imx-mkimage/
+host:~/imx-mkimage$ git checkout tags/lf-6.6.23-2.0.0
+
    +
    +
    • +

  • Copy firmware binaries into imx-mkimage

    +
    host:~/imx-mkimage$ cp ../artefacts/bl31-imx93.bin ./iMX9/bl31.bin
+host:~/imx-mkimage$ cp \
+                     ../artefacts/lpddr4_* \
+                     ../artefacts/mx93a1-ahab-container.img \
+                     ../artefacts/tee.bin \
+                     ./iMX9/
+
    +
    +
    • +

  • Copy u-boot binaries and DTB into imx-mkimage

    +
    host:~/imx-mkimage$ cp ../u-boot-imx/spl/u-boot-spl.bin ../u-boot-imx/u-boot.bin ./iMX9/
+host:~/imx-mkimage$ cp ../u-boot-imx/arch/arm/dts/<dtb> ./iMX9/
+
    +
    +
    +

    Note

    +

    In command above replace <dtb> with imx93-phyboard-segin.dtb

    +
    +
    • +

  • Build final flash.bin binary

    +
    +
    host:~/imx-mkimage$ make SOC=iMX9 REV=A1 flash_singleboot
+
    +
    +
    +
    • +
+
+
+
+

5.5.4. Flash the bootloader to a block device

+

The flash.bin can be found at imx-mkimage/iMX9/ directory and now can be flashed. A +chip-specific offset is needed:

+ + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

i.MX 93

32 kiB

0 kiB

/dev/mmcblk0

+

E.g. flash SD card:

+
host:~/imx-mkimage$ sudo dd if=./iMX9/flash.bin of=<sd-card> bs=1024 seek=32 conv=sync
+
+
+
+

Note

+

In the command above, replace <sd-card> with your sd-card device name. +For more information on how to find the device name, see the section +Finding the Correct Device in +Getting Started.

+
+
+

Hint

+

The specific offset values are also declared in the Yocto variables “BOOTLOADER_SEEK” and “BOOTLOADER_SEEK_EMMC”

+
+
+
+
+

5.6. Kernel standalone build

+
+

5.6.1. Setup sources

+
    +

  • The used linux-phytec-imx branch can be found in the release notes

    • +

  • The tag needed for this release is called v6.6.23-2.0.0-phy8

    • +

  • Check out the needed linux-phytec-imx tag:

    +
    host:~$ git clone git://github.com/phytec/linux-phytec-imx.git
+host:~$ cd ~/linux-phytec-imx/
+host:~/linux-phytec-imx$ git fetch --all --tags
+host:~/linux-phytec-imx$ git checkout tags/v6.6.23-2.0.0-phy8
+
    +
    +
    • +

  • For committing changes, it is highly recommended to switch to a new branch:

    +
    host:~/linux-phytec-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • Set up a build environment:

    +
    host:~/linux-phytec-imx$ source /opt/ampliphy-vendor-wayland/5.0/environment-setup-cortexa55-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. Build the kernel

+
    +

  • Build the linux kernel:

    +
    host:~/linux-phytec-imx$ make imx9_phytec_defconfig
+host:~/linux-phytec-imx$ make -j$(nproc)
+
    +
    +
    • +

  • Install kernel modules to e.g. NFS directory:

    +
    host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • The Image can be found at ~/linux-phytec-imx/arch/arm64/boot/Image

    • +

  • The dtb can be found at +~/linux-phytec-imx/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dtb

    • +

  • For (re-)building only Devicetrees and -overlays, it is sufficient to run

    +
    host:~/linux-phytec-imx$ make dtbs
+
    +
    +
    • +
+
+

Note

+

If you are facing the following build issue:

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

Make sure you installed the package “libyaml-dev” on your host system:

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. Copy Kernel to SD Card

+

When one-time boot via netboot is not sufficient, the kernel along with its +modules and the corresponding device tree blob may be copied directly to a +mounted SD card.

+
host:~/linux-phytec-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-phytec-imx$ cp arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dtb /path/to/sdcard/boot/oftree
+host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. Format SD-Card

+

Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted.

+
+

5.7.1. Gparted

+
    +

  • Get GParted:

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • Insert the SD Card into your host and get the device name:

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • Unmount all SD Card partitions.

    • +

  • Launch GParted:

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.7.1.1. Expand rootfs

+
+

Warning

+

Running gparted on host systems which are using resize2fs version 1.46.6 and older +(e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto +Mickledore and newer. +This is due to a new default option in resize2fs which causes a incompatibility. +See release notes.

+
+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +

  • Choose the ext4 root partition and click on resize:

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • Drag the slider as far as you like or enter the size manually.

    • +
+../../../_images/gparted3.png +
    +

  • Confirm your entry by clicking on the “Change size” button.

    • +
+../../../_images/gparted4.png +
    +

  • To apply your changes, press the green tick.

    • +

  • Now you can mount the root partition and copy e.g. the +phytec-qt6demo-image-phyboard-segin-imx93-2.wic image to it. Then unmount it again:

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-segin-imx93-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.7.1.2. Create the Third Partition

+
    +

  • Choose your SD Card device at the drop-down menu on the top right

    • +
+../../../_images/gparted1.png +
    +

  • Choose the bigger unallocated area and press “New”:

    • +
+../../../_images/gparted6.png +
    +

  • Click “Add”

    • +
+../../../_images/gparted7.png +
    +

  • Confirm your changes by pressing the green tick.

    • +
+../../../_images/gparted8.png +
    +

  • Now you can mount the new partition and copy e.g. +phytec-qt6demo-image-phyboard-segin-imx93-2.wic image to it. Then unmount it again:

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-segin-imx93-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. Device Tree (DT)

+
+

6.1. Introduction

+

The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html)

+

“The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn’t need to hard code details of the machine.”

+

The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at devicetree.org.

+
+
+

6.2. PHYTEC i.MX 93 BSP Device Tree Concept

+

The following sections explain some rules PHYTEC has defined on how to set up +device trees for our i.MX 93 SoC-based boards.

+
+

6.2.1. Device Tree Structure

+
    +

  • Module.dtsi - Module includes all devices mounted on the SoM, such as PMIC +and RAM.

    • +

  • Board.dts - include the module dtsi file. Devices that come from the i.MX 93 +SoC but are just routed down to the carrier board and used there are included +in this dts.

    • +

  • Overlay.dtso - enable/disable features depending on optional hardware that +may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10)

    • +
+

From the root directory of the Linux Kernel our devicetree files for i.MX 9 +platforms can be found in arch/arm64/boot/dts/freescale/.

+
+
+

6.2.2. Device Tree Overlay

+

Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the folder arch/arm64/boot/dts/freescale/.

+

Available overlays for phyboard-segin-imx93-2.conf are:

+
imx93-phyboard-segin-peb-av-02.dtbo
+imx93-phyboard-segin-peb-eval-01.dtbo
+imx93-phyboard-segin-peb-wlbt-05.dtbo
+imx93-phycore-rpmsg.dtbo
+imx93-phycore-no-emmc.dtbo
+imx93-phycore-no-eth.dtbo
+
+
+

Available overlays for phyboard-nash-imx93-1.conf are:

+
imx93-phyboard-nash-jtag.dtbo
+imx93-phyboard-nash-peb-av-10.dtbo
+imx93-phyboard-nash-pwm-fan.dtbo
+imx93-phyboard-nash-vm016.dtbo
+imx93-phycore-rpmsg.dtbo
+imx93-phycore-no-emmc.dtbo
+imx93-phycore-no-eth.dtbo
+
+
+

The usage of overlays can be configured during runtime in Linux or U-Boot. +Overlays are applied during the boot process in the bootloader after the +boot command is called and before the kernel is loaded. The next sections +explain the configuration in more detail.

+
+

6.2.2.1. Set ${overlays} variable

+

The ${overlays} U-Boot environment variable contains a space-separated list +of overlays that will be applied during boot. Depending on the boot source the +overlays have to either be placed in the boot partition of eMMC/SD-Card or are +loaded over tftp. Overlays set in the $KERNEL_DEVICETREE Yocto machine variable +will be automatically added to the boot partition of the final WIC image.

+

The ${overlays} variable can be either set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=imx93-phyboard-segin-peb-eval-01.dtbo imx93-phyboard-segin-peb-av-02.dtbo
+
+
+
+

Note

+

Make sure the boot partition is mounted! If it is not you can mount it with:

+
target:~$ mount /dev/mmcblkXp0 /boot
+
+
+
+

Changes will take effect after the next reboot. If no bootenv.txt file is +available the overlays variable can be set directly in the U-Boot environment.

+
u-boot=> setenv overlays imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> printenv overlays
+overlays=imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> boot
+
+
+

If a user defined ${overlays} variable should be directly loaded from U-Boot +environment but there is still an external bootenv.txt available, the ${no_bootenv} +variable needs to be set as a flag:

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> boot
+
+
+

More information about the external environment can be found in +U-boot External Environment subsection of the +device tree overlay section.

+

We use the ${overlays} variable for overlays describing expansion boards +that can not be detected during run time. To prevent applying overlays listed in +the ${overlays} variable during boot, the ${no_overlays} variable can be +set to 1 in the bootloader environment.

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot External Environment

+

During the start of the Linux Kernel the external environment bootenv.txt +text file will be loaded from the boot partition of an MMC device or via TFTP. +The main intention of this file is to store the ${overlays} variable. This makes +it easy to pre-define the overlays in Yocto depending on the used machine. The +content from the file is defined in the Yocto recipe bootenv found in +meta-phytec: +https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=scarthgap

+

Other variables can be set in this file, too. They will overwrite the existing +settings in the environment. But only variables evaluated after issuing the boot +command can be overwritten, such as ${nfsroot} or ${mmcargs}. Changing other +variables in that file will not have an effect. See the usage during netboot as +an example.

+

If the external environment can not be loaded the boot process will be anyway +continued with the values of the existing environment settings.

+
+
+

6.2.4. Change U-boot Environment from Linux on Target

+

Libubootenv is a tool included in our images to modify the U-Boot environment of +Linux on the target machine.

+

Print the U-Boot environment using the following command:

+
target:~$ fw_printenv
+
+
+

Modify a U-Boot environment variable using the following command:

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

Caution

+

Libubootenv takes the environment selected in a configuration file. The +environment to use is inserted there, and by default it is configured to use +the eMMC environment (known as the default used environment).

+

If the eMMC is not flashed or the eMMC environment is deleted, libubootenv +will not work. You should modify the /etc/fw_env.config file to match the +environment source that you want to use.

+
+
+
+
+
+

7. Accessing Peripherals

+

To find out which boards and modules are supported by the release of PHYTEC’s +phyCORE-i.MX 93 BSP described herein, visit our BSP web page and click +the corresponding BSP release in the download section. Here you can find all +hardware supported in the columns “Hardware Article Number” and the correct +machine name in the corresponding cell under “Machine Name”.

+

To achieve maximum software reuse, the Linux kernel offers a sophisticated +infrastructure that layers software components into board-specific parts. The +BSP tries to modularize the kit features as much as possible. When a customized +baseboard or even a customer-specific module is developed, most of the software +support can be re-used without error-prone copy-and-paste. The kernel code +corresponding to the boards can be found in device trees (DT) in the kernel +repository under arch/arm64/boot/dts/freescale/*.dts.

+

In fact, software reuse is one of the most important features of the +Linux kernel, especially of the ARM implementation which always has to fight +with an insane number of possibilities of the System-on-Chip CPUs. The whole +board-specific hardware is described in DTs and is not part of the kernel image +itself. The hardware description is in its own separate binary, called the +Device Tree Blob (DTB) (section device tree).

+

Please read section PHYTEC i.MX 93 BSP Device Tree Concept to get an understanding +of our i.MX 9 BSP device tree model.

+

The following sections provide an overview of the supported hardware components +and their operating system drivers on the i.MX 9 platform. Further changes +can be ported upon customer request.

+
+

7.1. i.MX 93 Pin Muxing

+

The i.MX 93 SoC contains many peripheral interfaces. In order to reduce package +size and lower overall system cost while maintaining maximum functionality, many +of the i.MX 93 terminals can multiplex up to eight signal functions. Although +there are many combinations of pin multiplexing that are possible, only a +certain number of sets, called IO sets, are valid due to timing limitations. +These valid IO sets were carefully chosen to provide many possible application +scenarios for the user.

+

Please refer to our Hardware Manual or the NXP i.MX 93 Reference Manual for more +information about the specific pins and the muxing capabilities.

+

The IO set configuration, also called muxing, is done in the Device Tree. The +driver pinctrl-single reads the DT’s node fsl,pins, and does the appropriate pin +muxing.

+

The following is an example of the pin muxing of the UART1 device in +imx93-phyboard-segin.dts:

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX93_PAD_UART1_RXD__LPUART1_RX     0x31e
+                MX93_PAD_UART1_TXD__LPUART1_TX     0x30e
+        >;
+};
+
+
+

The first part of the string MX93_PAD_UART1_RXD__LPUART1_RX names the pad +(in this example UART1_RXD). The second part of the string (LPUART1_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal pull up is +activated.

+

The device tree representation for UART1 pinmuxing: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L259

+
+
+

7.2. Network

+

phyBOARD-Segin/Nash i.MX 93 provides two ethernet interfaces.

+
    +

  • On phyBOARD-Segin i.MX 93 we have:

    +
      +

    • a 100 megabit Ethernet provided by phyCORE-i.MX93

      • +

    • and 100 megabit Ethernet provided by phyBOARD.

      • +
    +
    • +

  • On phyBOARD-Nash i.MX 93 we have:

    +
      +

    • a 100 megabit Ethernet provided by phyCORE-i.MX93

      • +

    • and 1 gigabit Ethernet provided by phyBOARD.

      • +
    +
    • +
+

All interfaces offer a standard Linux network port that can be programmed using +the BSD socket interface. The whole network configuration is handled by +the systemd-networkd daemon. The relevant configuration files can be found on +the target in /lib/systemd/network/ as well as the BSP in +meta-ampliphy/recipes-core/systemd/systemd-conf.

+

IP addresses can be configured within *.network files. The default IP address +and netmask for eth0 is:

+
eth0: 192.168.3.11/24
+
+
+

The DT Ethernet setup might be split into two files depending on your hardware +configuration: the module DT and the board-specific DT. The device tree set up +for the FEC ethernet IP core where the ethernet PHY is populated on the SoM can +be found here: https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi#L61.

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Segin/Nash i.MX 93 can be found here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L114 or here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L83.

+
+

7.2.1. Network Environment Customization

+
+

7.2.1.1. U-boot network-environment

+
    +

  • To find the Ethernet settings in the target bootloader:

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • With your development host set to IP 192.168.3.10 and netmask 255.255.255.0, +the target should return:

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • If you need to make any changes:

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> should be one of ipaddr, netmask, gatewayip or serverip. +<value> will be the actual value of the chosen parameter.

    +
    • +

  • The changes you made are temporary for now. To save these:

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

Here you can also change the IP address to DHCP instead of using a static one.

+
    +

  • Configure:

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • Set up paths for TFTP and NFS. A modification could look like this:

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

Please note that these modifications will only affect the bootloader settings.

+
+

Tip

+

Variables like nfsroot and netargs can be overwritten by the U-boot External +Environment. For netboot, the external environment will be loaded from tftp. +For example, to locally set the nfsroot variable in a bootenv.txt file, +locate the tftproot directory:

+
nfsroot=/home/user/nfssrc
+
+
+

There is no need to store the info on the target. Please note that this does +not work for variables like ipaddr or serveraddr as they need to be already +set when the external environment is being loaded.

+
+
+
+

7.2.1.2. Kernel network-environment

+
    +

  • Find the ethernet settings for eth0 in the target kernel:

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • Temporary adaption of the eth0 configuration:

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.2.2. WLAN

+
+

Note

+

For now, only phyBOARD-Segin i.MX 93 supports WLAN/Bluetooth features. WLAN/Bluetooth is +thus not supported on phyBOARD-Nash i.MX 93 yet.

+
+

WLAN and Bluetooth on the phyBOARD-Segin i.MX 93 are provided by the PEB-WLBT-05 expansion card. +The PEB-WLBT-05 for phyBOARD-Segin i.MX 93 Quickstart Guide shows you how to install the +PEB-WLBT-05.

+
+

Tip

+

With the BSP Version PD24.2 and newer, the PEB-WLBT-05 overlay needs to be activated first, +otherwise the PEB-WLBT-05 won’t be recognized.

+
target:~$ vi /boot/bootenv.txt
+
+
+

Afterwards the bootenv.txt file should look like this (it can also contain other devicetree +overlays!):

+
overlays=imx93-phyboard-segin-peb-wlbt-05.dtbo
+
+
+

The changes will be applied after a reboot:

+
target:~$ reboot
+
+
+

For further information about devicetree overlays, read the device tree chapter.

+
+

For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

Note

+

By default, bluetooth is not supported on phyBOARD-Segin i.MX 93 with PEB-WLBT-05 +expansion card due to hard-wired connections. However, it is possible to +re-work PEB-WLBT-05 card by adjusting solder pads and enabling bluetooth in +the software. Please contact your PHYTEC representative for more information.

+
+
+

7.2.2.1. Connecting to a WLAN Network

+

First set the correct regulatory domain for your country:

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

You will see:

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

Set up the wireless interface:

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

Now you can scan for available networks:

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection.

+

To do so, add the network-credentials to the file /etc/wpa_supplicant.conf:

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

Now a connection can be established:

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

This should result in the following output:

+
Successfully initialized wpa_supplicant
+
+
+

The ip address is automatically configured over DHCP. For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (scarthgap).

+
+
+
+
+

7.3. SD/MMC Card

+

The i.MX 93 supports a slot for Secure Digital Cards and MultiMedia Cards to be +used as general-purpose block devices. These devices can be used in the same way +as any other block device.

+
+

Warning

+

These kinds of devices are hot-pluggable. Nevertheless, you must ensure not +to unplug the device while it is still mounted. This may result in data loss!

+
+

After inserting an SD/MMC card, the kernel will generate new device nodes +in /dev. The full device can be reached via its /dev/mmcblk1 device node. SD/MMC +card partitions will show up as:

+
/dev/mmcblk1p<Y>
+
+
+

<Y> counts as the partition number starting from 1 to the max count of +partitions on this device. The partitions can be formatted with any kind of file +system and also handled in a standard manner, e.g. the mount and umount command +work as expected.

+
+

Tip

+

These partition device nodes will only be available if the card contains a +valid partition table (”hard disk” like handling). If no partition table is +present, the whole device can be used as a file system (”floppy” like +handling). In this case, /dev/mmcblk1 must be used for formatting and +mounting. The cards are always mounted as being writable.

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L213 or here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L202

+

DT configuration for the eMMC interface can be found here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi#L194 or here:

+
+
+

7.4. eMMC Devices

+

PHYTEC modules like phyCORE-i.MX 93 is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw Multi-Level Cells (MLC) or Triple-Level +Cells (TLC) combined with a memory controller that handles ECC and wear +leveling. They are connected via an SD/MMC interface to the i.MX 93 and are +represented as block devices in the Linux kernel like SD cards, flash drives, or +hard disks.

+

The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer’s datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard.

+

PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1

+
+

7.4.1. Extended CSD Register

+

eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard.

+

In the Linux user space, you can query the registers:

+
target:~$ mmc extcsd read /dev/mmcblk0
+
+
+

You will see:

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.4.2. Enabling Background Operations (BKOPS)

+

In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +or TLC. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called Background Operations +(BKOPS).

+

By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency.

+

The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details.

+

Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):

+
    +

  • Value 0: The host does not support the manual trigger of BKOPS. Device write +performance suffers.

    • +

  • Value 1: The host does support the manual trigger of BKOPS. It will issue +BKOPS from time to time when it does not need the device.

    • +
+

The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details).

+

The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)).

+
    +

  • To check whether BKOPS_EN is set, execute:

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep BKOPS_EN
+
    +
    +

    The output will be, for example:

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    Where value 0x00 means BKOPS_EN is disabled and device write performance +suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue +background operations from time to time.

    +
    • +

  • Enabling can be done with this command:

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • To set the BKOPS_EN bit, execute:

    +
    target:~$ mmc bkops_en manual /dev/mmcblk0
+
    +
    +
    • +

  • To ensure that the new setting is taken over and the kernel triggers BKOPS by +itself, shut down the system:

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

Tip

+

The BKOPS_EN bit is one-time programmable only. It cannot be reversed.

+
+
+
+

7.4.3. Reliable Write

+

There are two different Reliable Write options:

+
    +

  1. Reliable Write option for a whole eMMC device/partition.

    2. +

  2. Reliable Write for single write transactions.

    3. +
+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table (see the previous section).

+
+

The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-i.MX 93 SoMs. To check this on the running target:

+
target:~$ mmc extcsd read /dev/mmcblk0 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

Otherwise, it can be enabled with the mmc tool:

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META.

+

Conclusion: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application.

+
+
+

7.4.4. Resizing ext4 Root Filesystem

+

When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ parted /dev/mmcblk0 print
+
    +
    +
    • +

  • The output looks like this:

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk0: 7617MB
+Sect[ 1799.850385]  mmcblk0: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • Use parted to resize the root partition to the max size of the device:

    +
    target:~$ parted /dev/mmcblk0 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk0 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk0: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk0: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • Resize the filesystem to a new partition size:

    +
    target:~$ resize2fs /dev/mmcblk0p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk0p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk0p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk0p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted.

+
+
+

7.4.5. Enable pseudo-SLC Mode

+

eMMC devices use MLC or TLC +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC used in NAND Flash, MLC or TLC have lower reliability and a higher +error rate at lower costs.

+

If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity.

+
+

Warning

+

When enabling the enhanced attribute on the device, all data will be lost.

+
+

The following sequence shows how to enable the enhanced attribute.

+
    +

  • First obtain the current size of the eMMC device with:

    +
    target:~$ parted -m /dev/mmcblk0 unit B print
+
    +
    +

    You will receive:

    +
    BYT;
+/dev/mmcblk0:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    As you can see this device has 63652757504 Byte = 60704 MiB.

    +
    • +

  • To get the maximum size of the device after pseudo-SLC is enabled use:

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    which shows, for example:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    Here the maximum size is 3719168 KiB = 3632 MiB.

    +
    • +

  • Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by +typing:

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk0
+
    +
    +

    You will get:

    +
    Done setting ENH_USR area on /dev/mmcblk0
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk0 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • To ensure that the new setting has taken over, shut down the system:

    +
    target:~$ poweroff
+
    +
    +

    and perform a power cycle. It is recommended that you verify the settings now.

    +
    • +

  • First, check the value of ENH_SIZE_MULT which must be 3719168 KiB:

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    You should receive:

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • Finally, check the size of the device:

    +
    target:~$ parted -m /dev/mmcblk0 unit B print
+BYT;
+/dev/mmcblk0:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.4.6. Erasing the Device

+

It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC or TLC +or mark these blocks as discard. The data on the device is lost and +will be read back as zeros.

+
    +

  • After booting from SD Card execute:

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk0
+
    +
    +

    The option –secure ensures that the command waits until the eMMC device has +erased all blocks. The -f (force) option disables all checking before erasing +and it is needed when the eMMC device contains existing partitions with data.

    +
    • +
+
+

Tip

+
target:~$ dd if=/dev/zero of=/dev/mmcblk0 conv=fsync
+
+
+

also destroys all information on the device, but this command is bad for wear +leveling and takes much longer!

+
+
+
+

7.4.7. eMMC Boot Partitions

+

An eMMC device contains four different hardware partitions: user, boot1, boot2, +and rpmb.

+

The user partition is called the User Data Area in the JEDEC standard and is the +main storage partition. The partitions boot1 and boot2 can be used to host the +bootloader and are more reliable. Which partition the i.MX 93 uses to load +the bootloader is controlled by the boot configuration of the eMMC device. The +partition rpmb is a small partition and can only be accessed via a trusted +mechanism.

+

Furthermore, the user partition can be divided into four user-defined General +Purpose Area Partitions. An explanation of this feature exceeds the scope of +this document. For further information, see the JEDEC Standard Chapter 7.2 +Partition Management.

+
+

Tip

+

Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT +partition table.

+
+

The current PHYTEC BSP does not use the extra partitioning feature of eMMC +devices. The U-Boot is flashed at the beginning of the user partition. +The U-Boot environment is placed at a fixed location after the U-Boot. An MBR +partition table is used to create two partitions, a FAT32 boot, and ext4 rootfs +partition. They are located right after the U-Boot and the U-Boot environment. +The FAT32 boot partition contains the kernel and device tree.

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. The U-Boot environment still resides in the +user area before the first partition. The user area also still contains the +bootloader which the image first shipped during its initialization process. +Below is an example, to flash the bootloader to one of the two boot partitions +and switch the boot device via userspace commands.

+
+
+

7.4.8. Via userspace Commands

+

On the host, run:

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

The partitions boot1 and boot2 are read-only by default. To write to them from +user space, you have to disable force_ro in the sysfs.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk0boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk0boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk0boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk0boot1
+
+
+

The following table is for the offset of the i.MX 93 SoC:

+ + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot +Partition

eMMC Device

Bootloader Filename

i.MX 93

32 kiB

0 kiB

/dev/mmcblk0

imx-boot

+

After that set the boot partition from user space using the mmc tool:

+

(for ‘boot0’) :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk0
+
+
+

(for ‘boot1’) :

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk0
+
+
+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk0
+
+
+

To choose back to the user area u-boot environment:

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk0
+
+
+
+
+

7.4.9. Resizing ext4 Root Filesystem

+

fdisk can be used to expand the root filesystem. The example works for any block +device such as eMMC, SD Card, or hard disk.

+
    +

  • Get the current device size:

    +
    target:~$ fdisk -l /dev/mmcblk0
+
    +
    +
    • +

  • The output looks like:

    +
    Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk0p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk0p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • Use fdisk to delete and create a partition with a max size of the device:

    +
    target:~$ fdisk /dev/mmcblk0
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk0p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk0p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk0p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk0p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk0p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

Increasing the file system size can be done while it is mounted. An online +resizing operation is performed. But you can also boot the board from an SD card +and then resize the file system on the eMMC partition while it is not +mounted. Furthermore, the board has to be rebooted so that the new partition +table will be read.

+
+
+
+

7.5. GPIOs

+

The phyBOARD-Segin/Nash i.MX 93 doesn’t have a set of pins especially dedicated for user I/Os since +all GPIOs are used by kernel device drivers or used for a specific purpose. The +processor has organized its GPIOs into five banks of 32 GPIOs each (GPIO1 – +GPIO4) GPIOs. gpiochip0, gpiochip32, gpiochip64 and gpiochip96 are the sysfs +representation of these internal i.MX 93 GPIO banks GPIO1 – GPIO4.

+

The GPIOs are identified as GPIO<X>_<Y> (e.g. GPIO4_07). <X> identifies the GPIO +bank and counts from 1 to 4, while <Y> stands for the GPIO within the bank. <Y> +is being counted from 0 to 31 (32 GPIOs on each bank).

+

By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is:

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools:

+
    +

  • Detecting the gpiochips on the chip:

    +
    target:~$ gpiodetect
+gpiochip0 [43810080.gpio] (32 lines)
+gpiochip1 [43820080.gpio] (32 lines)
+gpiochip2 [43830080.gpio] (32 lines)
+gpiochip3 [47400080.gpio] (32 lines)
+
    +
    +
    • +
+
+

Note

+

Order of GPIOchips in i.MX 93 Application Processor Reference Manual and +in Linux kernel differ!

+ + + + + + + + + + + + + + + + + + + + + + + +

GPIOchip address

Linux

Reference Manual

0x43810080

gpiochip0

gpiochip2

0x43820080

gpiochip1

gpiochip3

0x43830080

gpiochip2

gpiochip4

0x47400080

gpiochip3

gpiochip1

+
+
    +

  • Show detailed information about the gpiochips. Like their names, consumers, +direction, active state, and additional flags:

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • Read the value of a GPIO (e.g GPIO 3 from chip0):

    +
    target:~$ gpioget gpiochip0 3
+
    +
    +
    • +

  • Set the value of GPIO 3 on chip0 to 0 and exit tool:

    +
    target:~$ gpioset --mode=exit gpiochip0 3=0
+
    +
    +
    • +

  • Help text of gpioset shows possible options:

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

Warning

+

Some of the user IOs are used for special functions. Before using a user IO, +refer to the schematic or the hardware manual of your board to ensure that it +is not already in use.

+
+
+

7.5.1. GPIOs via sysfs

+
+

Warning

+

Accessing gpios via sysfs is deprecated and we encourage to use libgpiod +instead.

+
+

Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling CONFIG_GPIO_SYSFS in the kernel +configuration. To make CONFIG_GPIO_SYSFS visible in menuconfig the option +CONFIG_EXPERT has to be enabled first.

+

You can also add this option for example to the +imx9_phytec_distro.config config fragment in the linux kernel sources +under arch/arm64/configs

+
..
+CONFIG_GPIO_SYSFS=y
+..
+
+
+
+
+
+

7.6. ADC

+

The PHYTEC i.MX 93 include general purpose Analog-to-Digital Converters (ADC) which +can be used for interfacing analog sensors.

+

Reading the ADC values can be done through sysfs:

+
target:~$ cat /sys/bus/iio/devices/iio:deviceX/in_voltageY_raw
+
+
+

On phyBOARD-Nash i.MX 93 the ADC lines are accessible on X16 expansion connector:

+ + + + + + + + + + + + + + +

ADC input

X16 pin

ADC_IN0

47

ADC_IN2

49

+
+
+

7.7. LEDs

+

If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using /sys/class/leds/ instead +of /sys/class/gpio/. The maximum brightness of the LEDs can be read from +the max_brightness file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings.

+

Below is a simple example.

+

To get all available LEDs, type:

+
target:~$ ls /sys/class/leds
+green:heartbeat@  mmc0::@  mmc1::@  yellow:@
+
+
+

Here the LEDs green:heartbeat is on the phyCORE-i.MX93. If you are using +phyBOARD-Segin there is also yellow LED which is populated on the +PEB-EVAL-01.

+
    +

  • To toggle the LEDs ON:

    +
    target:~$ echo 1 > /sys/class/leds/green\:heartbeat/brightness
+
    +
    +
    • +

  • To toggle OFF:

    +
    target:~$ echo 0 > /sys/class/leds/green\:heartbeat/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-eval-01.dtso#L33

+
+
+

7.8. I²C Bus

+

The i.MX 93 contains several Multimaster fast-mode I²C modules. PHYTEC boards +provide plenty of different I²C devices connected to the I²C modules of the +i.MX 93. This section describes the basic device usage and its DT representation +of some I²C devices integrated into our phyBOARD-Segin/Nash i.MX 93.

+

The device tree node for i2c contains settings such as clock-frequency to set +the bus frequency and the pin control settings including scl-gpios and sda-gpios +which are alternate pin configurations used for bus recovery.

+

General I²C3 bus configuration (e.g. imx93-phycore-som.dtsi): +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi#L88

+

General I²C2 bus configuration for imx93-phyboard-segin.dts: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L155 or for +imx93-phyboard-nash.dts: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L113

+
+
+

7.9. EEPROM

+

There are two different I2C EEPROM flashes populated on phyCORE-i.MX93 SoM and on the +phyBOARD-Segin/Nash i.MX 93. For now only the one on the phyCORE-i.MX93 is enabled, and it is used for board +detection.

+
+

7.9.1. I2C EEPROM on phyCORE-i.MX93

+

The I2C EEPROM on the phyCORE-i.MX93 SoM has its memory divided into two parts.

+
    +

  • normal area (size: 4096 bytes, bus: I2C-2, addr: 0x50)

    • +

  • ID page (size: 32 bytes, bus: I2C-2, addr: 0x58)

    • +
+

It is possible to read and write from the device populated:

+
target:~$ hexdump -C /sys/class/i2c-dev/i2c-2/device/2-0058/eeprom
+
+
+

To read and print the first 1024 bytes of the EEPROM as a hex number, +execute:

+
target:~$ dd if=/sys/class/i2c-dev/i2c-2/device/2-0050/eeprom bs=1 count=1024  | od -x
+
+
+

To fill the whole EEPROM (ID page) with zeros we first need to disable the +EEPROM write protection, use:

+
target:~$ gpioset 2 21=0
+
+
+

Then the EEPROM can be written to:

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-2/device/2-0058/eeprom bs=32 count=1
+
+
+
+

Warning

+

The first 256 bytes of the normal EEPROM area (bus: I2C-2 addr: 0x50) are +reserved and should not be overwritten! (See below)

+
+
+
+

7.9.2. EEPROM SoM Detection

+

PHYTEC uses first 256 bytes in EEPROM normal area to store information about the +SoM. This includes PCB revision and mounting options.

+

The EEPROM data is read at a really early stage during startup. It is used to +select the correct RAM configuration. This makes it possible to use the same +bootloader image for different RAM sizes and choose the correct DTS overlays +automatically.

+

If the first 256 bytes of the normal area are deleted, the bootloader will fall +back to the phyCORE-i.MX93 Kit RAM setup, which is 1GiB RAM.

+
+

Warning

+

Data in the first 256 bytes of the normal EEPROM area (bus: I2C-2 addr: 0x50) +shouldn’t be erased or corrupted! This might influence the behavior of the +bootloader. The board might not boot correctly anymore.

+
+
+
+

7.9.3. Rescue EEPROM Data

+

The hardware introspection data is pre-written on the EEPROM data spaces. If +you have accidentally deleted or overwritten the HW data, you could contact our +support!

+

DT representation, e.g. in phyCORE-i.MX 93 file can be found in our PHYTEC git: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi#L172

+
+
+
+

7.10. RTC

+

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file.

+
    +

  • To find the name of the RTC device, you can read its sysfs entry with:

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • You will get, for example:

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

Tip

+

This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device +IDs based on the device tree/aliases entries if present.

+
+

Date and time can be manipulated with the hwclock tool and the date command. +To show the current date and time set on the target:

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

Change the date and time with the date command. The date command sets the time +with the following syntax “YYYY-MM-DD hh:mm:ss (+|-)hh:mm”:

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

Note

+

Your timezone (in this example +0100) may vary.

+
+

Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the hwclock command. Write the current date and time (set +with the date command) to the RTC using the hwclock tool and reboot the +target to check if the changes were applied to the RTC:

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

To set the time and date from the RTC use:

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.10.1. RTC Wakealarm

+

It is possible to issue an interrupt from the RTC to wake up the system. The +format uses the Unix epoch time, which is the number of seconds since UTC +midnight on 1 January 1970. To wake up the system after 4 minutes from suspend +to ram state, type:

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

Note

+

Internally the wake alarm time will be rounded up to the next minute since +the alarm function doesn’t support seconds.

+
+
+
+

7.10.2. RTC Parameters

+

RTCs have a few abilities which can be read/set with the help of hwclock +tool.

+
    +

  • We can check RTC supported features with:

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    What this value means is encoded in kernel, each set bit translates to:

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • We can check RTC BSM (Backup Switchover Mode) with:

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • We can set RTC BSM with:

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    What BSM values mean translates to these values:

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    Tip

    +

    You should set BSM mode to DSM or LSM for RTC to switch to backup power +source when the initial power source is not available. Check RV-3028 RTC +datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching +Mode) actually mean.

    +
    +
    • +
+

DT representation for I²C RTCs: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L173 or +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L122

+
+
+
+

7.11. USB Host Controller

+

The USB controller of the i.MX 93 SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 480 Mbps (HighSpeed +‘HS’). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host, but on the phyBOARD-Segin/Nash i.MX 93 +one of them is used as a host-only port (USB-A connector).

+

The unified BSP includes support for mass storage devices and keyboards. Other +USB-related device drivers must be enabled in the kernel configuration on +demand. Due to udev, all mass storage devices connected get unique IDs and can +be found in /dev/disk/by-id. These IDs can be used in /etc/fstab to mount the +different USB memory devices in different ways.

+

The OTG port provides an additional pin for over-current protection, which is +not used on the phyBOARD-Segin/Nash i.MX 93. Since it’s not used, the driver part is also disabled +from within the device tree. In case this pin is used, activate this +over-current in the device tree and set the correct polarity (active high/low) +according to the device specification. For the correct setup, please refer to +the Kernel documentation under +Linux/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt.

+

DT representation for USB Host: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L193 or +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L181

+
+
+

7.12. RS232/RS485

+

The phyBOARD-Nash i.MX 93 i.MX 93 SoC provides one RS232/RS485 serial port.

+
+

Warning

+

RS232 with HW flow control and RS485 are not working due to HW bug on the +phyBOARD-Nash i.MX 93 PCB revision 1616.0

+
+
+

7.12.1. RS232

+
    +

  • Display the current settings of a terminal in a human-readable format:

    +
    target:~$ stty -a
+
    +
    +
    • +

  • Configuration of the UART interface can be done with stty. For example:

    +
    target:~$ stty -F /dev/ttyLP6 115200 crtscts raw -echo
+
    +
    +
    • +

  • With a simple echo and cat, basic communication can be tested. Example:

    +
    target:~$ echo 123 > /dev/ttyLP6
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

The host should print out “123”.

+
+
+

7.12.2. RS485

+
+

Hint

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

For easy testing, look at the linux-serial-test. This tool is called the IOCTL +for RS485 and sends a constant stream of data.

+
target:~$ linux-serial-test -p /dev/ttyLP6 -b 115200 --rs485 0
+
+
+

More information about the linux-serial-test tool and its parameters can be +found here: linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Documentation for calling the IOCTL within c-code is described in the Linux +kernel documentation: +https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+

The device tree representation for RS232 and RS485: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L174

+
+
+
+

7.13. CAN FD

+

The phyBOARD-Segin/Nash i.MX 93 has one flexCAN interface supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon the Linux network layer. Using +this framework, the CAN interfaces behave like an ordinary Linux network device, +with some additional features special to CAN. More information can be found in +the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • Use:

    +
    target:~$ ip link
+
    +
    +

    to see the state of the interfaces. The CAN interface should show up as +can0.

    +
    • +

  • To get information on can0, such as bit rate and error counters, type:

    +
    target:~$ ip -d -s link show can0
+4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
+   link/can  promiscuity 0  allmulti 0 minmtu 0 maxmtu 0
+   can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+         bitrate 500000 sample-point 0.875
+         tq 25 prop-seg 37 phase-seg1 32 phase-seg2 10 sjw 1 brp 1
+         flexcan: tseg1 2..96 tseg2 2..32 sjw 1..16 brp 1..1024 brp_inc 1
+         flexcan: dtseg1 2..39 dtseg2 2..8 dsjw 1..4 dbrp 1..1024 dbrp_inc 1
+         clock 40000000
+         re-started bus-errors arbit-lost error-warn error-pass bus-off
+         0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 parentbus platform parentdev 443a0000.can
+   RX:  bytes packets errors dropped  missed   mcast
+            0       0      0       0       0       0
+   TX:  bytes packets errors dropped carrier collsns
+            0       0      0       0       0       0
+
    +
    +
    • +
+

The output contains a standard set of parameters also shown for Ethernet +interfaces, so not all of these are necessarily relevant for CAN (for example +the MAC address). The following output parameters contain useful information:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

Interface Name

NOARP

CAN cannot use ARP protocol

MTU

Maximum Transfer Unit

RX packets

Number of Received Packets

TX packets

Number of Transmitted Packets

RX bytes

Number of Received Bytes

TX bytes

Number of Transmitted Bytes

errors…

Bus Error Statistics

+

The CAN configuration is done in the systemd configuration +file /lib/systemd/network/can0.network. For a persistent change of (as an +example, the default bitrates), change the configuration in the BSP +under ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network in +the root filesystem and rebuild the root filesystem.

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

The bitrate can also be changed manually, for example, to make use of the +flexible bitrate:

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

You can send messages with cansend or receive messages with candump:

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

To generate random CAN traffic for testing purposes, use cangen:

+
target:~$ cangen
+
+
+

cansend --help and candump --help provide help messages for further information +on options and usage.

+

Device Tree CAN configuration of imx93-phyboard-segin.dts: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L147 or +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L105

+
+
+

7.14. Audio on phyBOARD-Segin i.MX 93

+

On phyBOARD-Segin i.MX 93 the TI TLV320AIC3007 audio codec is used. It uses I2S +for data transmission and I2C for codec control. The audio signals available +are:

+
    +

  • Stereo LINE IN,

    • +

  • Stereo LINE OUT,

    • +

  • Output where D-Class 1W speaker can be connected

    • +
+

To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices:

+
target:~$ aplay -L
+
+
+

Or type for recording devices:

+
target:~$ arecord -L
+
+
+
+

7.14.1. Alsamixer

+

To inspect the capabilities of your soundcard, call:

+
target:~$ alsamixer
+
+
+

You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. “MM” means the feature is muted +(both output, left & right), which can be toggled by hitting ‘m’. You can also +toggle by hitting ‘<’ for left and ‘>’ for right output. With the tab +key, you can switch between controls for playback and recording.

+
+
+

7.14.2. Restore default volumes

+

There are some default settings stored in /var/lib/alsa/asound.state. +You can save your current alsa settings with:

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

You can restore saved alsa settings with:

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.14.3. Playback

+

Run speaker-test to check playback availability:

+
target:~$ speaker-test -c 2 -t wav
+
+
+

To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds:

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

To playback other formats like mp3 for example, you can use Gstreamer:

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+

If Speaker volume it too low you can increase its volume with (values 0-3):

+
target:~$ amixer -c 0 sset Class-D 3
+
+
+
+

Hint

+

Speaker output is only mono so when stereo track is played only left channel +will be played by speaker.

+
+
+
+

7.14.4. Capture

+

arecord is a command-line tool for capturing audio streams which use Line In +as the default input source.

+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

Hint

+

Since playback and capture share hardware interfaces, it is not possible to +use different sampling rates and formats for simultaneous playback and +capture operations.

+
+

Device Tree Audio configuration: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L62

+
+
+
+

7.15. Audio on phyBOARD-Nash i.MX 93

+
+

Warning

+

Due to HW bug Audio is broken on phyBOARD-Nash i.MX 93 PCB revision: 1616.0

+
+

To use audio with phyBOARD-Nash i.MX 93 an additional adapter for the Audio/Video +connector is needed. The PEB-AV-10 (1531.1 revision) can be bought separately to +the Kit. PEB-AV-10 is populated with a TI TLV320AIC3007 audio codec. Audio +support is done via the I2S interface and controlled via I2C.

+

There is a 3.5mm headset jack with OMTP standard and an 8-pin header to connect +audio devices with the AV-Connector. The 8-pin header contains a mono speaker, +headphones, and line-in signals.

+

To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices:

+
target:~$ aplay -L
+
+
+

Or type for recording devices:

+
target:~$ arecord -L
+
+
+
+

7.15.1. Alsamixer

+

To inspect the capabilities of your soundcard, call:

+
target:~$ alsamixer
+
+
+

You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. “MM” means the feature is muted +(both output, left & right), which can be toggled by hitting ‘m’. You can also +toggle by hitting ‘<’ for left and ‘>’ for right output. With the tab +key, you can switch between controls for playback and recording.

+
+
+

7.15.2. Restore default volumes

+

There are some default settings stored in /var/lib/alsa/asound.state. +You can save your current alsa settings with:

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

You can restore saved alsa settings with:

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.15.3. ALSA configuration

+

Our BSP comes with a ALSA configuration file /etc/asound.conf.

+

The ALSA configuration file can be edited as desired or deleted since it is not +required for ALSA to work properly.

+
target:~$ vi /etc/asound.conf
+
+
+

To set PEB-AV-10 as output, set playback.pcm from “dummy” to “pebav10”:

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

If the sound is not audible change playback devices to the software volume control +playback devices, set playback.pcm to the respective softvol playback device e.g. +“softvol_pebav10”. Use alsamixer controls to vary the volume levels.

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.15.4. Pulseaudio Configuration

+

For applications using Pulseaudio, check for available sinks:

+
target:~$ pactl list short sinks
+
+
+

To select the output device, type:

+
target:~$ pactl set-default-sink <sink_number>
+
+
+
+
+

7.15.5. Playback

+

Run speaker-test to check playback availability:

+
target:~$ speaker-test -c 2 -t wav
+
+
+

To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds:

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

To playback other formats like mp3 for example, you can use Gstreamer:

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.15.6. Capture

+

arecord is a command-line tool for capturing audio streams which use Line In as +the default input source. To select a different audio source you can +use alsamixer. For example, switch on Right PGA Mixer Mic3R and Left PGA Mixer +Mic3R in order to capture the audio from the microphone input of the +TLV320-Codec using the 3.5mm jack.

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

Hint

+

Since playback and capture share hardware interfaces, it is not possible to +use different sampling rates and formats for simultaneous playback and +capture operations.

+
+

Device Tree Audio configuration: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash-peb-av-10.dtso#L56

+
+
+
+

7.16. Video

+
+

7.16.1. Videos with Gstreamer

+

One example video is installed by default in the BSP at /usr/share/qtphy/videos/. +Start the video playback with one of these commands:

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • Or:

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.17. Display

+

The phyBOARD-Segin i.MX 93 supports PEB-AV-02 with 7’’ edt,etm0700g0edh6 +parallel display with capacitive touchscreen. Overlay for said display is +enabled in BOOT/bootenv.txt by default!

+

The phyBOARD-Nash i.MX 93 needs additional adapter to support 10’’ +edt,etml1010g3dra LVDS display with capacitive touchscreen. The PEB-AV-10 +(1531.1 revision) can be bought separately to the Kit. Overlay for said display +is enabled in BOOT/bootenv.txt by default!

+
+

7.17.1. Qt Demo

+

With the phytec-qt6demo-image, Weston starts during boot. Our Qt6 demo application named +“qtphy” can be stopped with:

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • To start the demo again, run:

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • To disable autostart of the demo, run:

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • To enable autostart of the demo, run:

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston can be stopped with:

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

Note

+

The Qt demo must be closed before Weston can be closed.

+
+
+
+

7.17.2. Backlight Control

+

If a display is connected to the PHYTEC board, you can control its backlight +with the Linux kernel sysfs interface. All available backlight devices in the +system can be found in the folder /sys/class/backlight. Reading the appropriate +files and writing to them allows you to control the backlight.

+
+

Note

+

Some boards with multiple display connectors might have multiple backlight +controls in /sys/class/backlight. For example: backlight0 and backlight1

+
+
    +

  • To get, for example, the maximum brightness level (max_brightness) execute:

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    Valid brightness values are 0 to <max_brightness>.

    +
    • +

  • To obtain the current brightness level, type:

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • Write to the file brightness to change the brightness:

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    turns the backlight off for example.

    +

    For documentation of all files, see +https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight.

    +
    • +
+

The device tree of PEB-AV-02 can be found here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-02.dtso

+

The device tree of PEB-AV-10 can be found here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash-peb-av-10.dtso

+
+
+
+

7.18. Power Management

+
+

7.18.1. CPU Core Frequency Scaling

+

The CPU in the i.MX 93 SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Unlike i.MX8 M family the i.MX 93 doesn’t support Dynamic Voltage and +Frequency Scaling (DVFS), but has the support of basic Voltage and Frequency +Scaling (VFS). The board can be put into these modes:

+
    +

  • nominal (ND),

    • +

  • overdrive (OD),

    • +

  • Low Drive (LD) and

    • +

  • Low Drive (LD) with Software Fast Frequency Change (SWFFC).

    • +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Mode

CPU freq

DDR data rate

VDD_SOC

OverDrive (OD)

1.7 GHz

3733 MT/s

900mV

NominalDrive (ND)

1.4 GHz

1866 MT/s

850mV

LowDrive (LD)

900 MHz

1866 MT/s

800mV

LowDrive (LD) with SWFFC

900 MHz

625 MT/s

800mV

+

The i.MX 93 BSP supports the VFS feature. The Linux kernel provides a LPM driver +that allows setting VDD_SOC, CPU freq and DDR speed.

+
+

Note

+

Low-cost i.MX 93 SoC variants such as parts numbers NXP IMX9301/IMX9302 do not +support VFS features. Those SoCs always run in LowDrive (LD) mode. Hence, +the Linux LPM driver is disabled automatically for SoMs with such SoCs.

+
+
    +

  • To put the device in OverDrive (OD) mode type:

    +
    +
    target:~$ echo 0 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • To put the device in NominalDrive (ND) mode type:

    +
    +
    target:~$ echo 1 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • To put the device in LowDrive (LD) mode type:

    +
    +
    target:~$ echo 2 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • To put the device in LowDrive (LD) mode with the lowest DDR speed with +SWFFC type:

    +
    +
    target:~$ echo 3 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • To check the current CPU frequency type:

    +
    +
    target:~$ mhz
+
    +
    +
    +
    • +

  • To check the current mode and DDR frequency type:

    +
    +
    target:~$ cat /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • To check the current VDD_SOC type:

    +
    +
    target:~$ cat /sys/kernel/debug/regulator/regulator_summary
+
    +
    +
    +
    • +
+

For more detailed information about the LPM driver and modes, refer to the NXPs +documentation: +https://docs.nxp.com/bundle/AN13917/page/topics/low_power_mode_use_cases.html

+
+
+

7.18.2. CPU Core Management

+

The i.MX 93 SoC can have multiple processor cores on the die. The i.MX 93, for +example, has 2 ARM Cores which can be turned on and off individually at runtime.

+
    +

  • To see all available cores in the system, execute:

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • This will show, for example:

    +
    cpu0/
+cpu1/
+cpufreq/
+[...]
+
    +
    +

    Here the system has two processor cores. By default, all available cores in the +system are enabled to get maximum performance.

    +
    • +

  • To switch off a single-core, execute:

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu1/online
+
    +
    +

    As confirmation, you will see:

    +
    [  110.505012] psci: CPU1 killed (polled 0 ms)
+
    +
    +

    Now the core is powered down and no more processes are scheduled on this core.

    +
    • +

  • You can use top to see a graphical overview of the cores and processes:

    +
    target:~$ htop
+
    +
    +
    • +

  • To power up the core again, execute:

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu1/online
+
    +
    +
    • +
+
+
+

7.18.3. Suspend to RAM

+

The phyCORE-i.MX93 supports basic suspend and resume. Different wake-up sources can be +used. Suspend/resume is possible with:

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

To wake up with serial console run

+
target:~$ echo enabled > /sys/class/tty/ttyLP0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+

Device can be put into suspend and waken-up with PEB-EVAL-01 S2 button

+

To wake up with RTC alarm check: RTC Wakealarm

+
+
+
+

7.19. Thermal Management

+
+

7.19.1. U-Boot

+

The previous temperature control in the U-Boot was not satisfactory. Now the +u-boot has a temperature shutdown to prevent the board from getting too hot +during booting. The temperatures at which the shutdown occurs are identical to +those in the kernel.

+

The individual temperature ranges with the current temperature are displayed in +the boot log:

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.19.2. Kernel

+

The Linux kernel has integrated thermal management that is capable of monitoring +SoC temperatures, reducing the CPU frequency, driving fans, advising other +drivers to reduce the power consumption of devices, and – worst-case – shutting +down the system gracefully +(https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

+

This section describes how the thermal management kernel API is used for the +i.MX 93 SoC platform. The i.MX 9 has internal temperature sensors for the +SoC.

+
    +

  • The current temperature can be read in millicelsius with:

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • You will get, for example:

    +
    49000
+
    +
    +
    • +
+

There are two trip points registered by the imx_thermal kernel driver. These +differ depending on the CPU variant. A distinction is made between Commercial, +Industrial and Extended Industrial.

+ + + + + + + + + + + + + + + + + + + + +

Commercial

Industrial

Extended Industrial

passive (warning)

85°C

95°C

115°C

critical (shutdown)

90°C

100°C

120°C

+

(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)

+

The kernel thermal management uses these trip points to trigger events and +change the cooling behavior. The following thermal policies (also named thermal +governors) are available in the kernel: Step Wise and Power Allocator. The +default policy used in the BSP is step_wise.

+
+

Tip

+

If the value of the SoC temperature in the sysfs file temp reaches +trip_point_1, the board immediately shuts down to avoid any heat damage. If +this doesn’t meet you expectations, an external supervisor circuit that +starts the module again with X_ONOFF signal when the temperature drops below +a selected trip point can be implemented

+
+
+

Note

+

The actual values of the thermal trip points may differ since we mount CPUs +with different temperature grades.

+
+
+
+

7.19.3. PWM Fan

+

A PWM fan can be connected to the phyBOARD-Nash i.MX 93 connector X48 (label FAN).

+

Afterwards, a PWM fan overlay needs to be activated, otherwise PWM fan won’t +be recognized.

+
target:~$ vi /boot/bootenv.txt
+
+
+

The bootenv.txt file should look like this (it can also contain other devicetree +overlays!):

+
overlays=imx93-phyboard-nash-pwm-fan.dtbo
+
+
+

The changes will be applied after a reboot:

+
+
target:~$ reboot
+
+
+
+

For further information about devicetree overlays, read the device tree chapter.

+

The SoC only contains one temperature sensor which is already used by the +thermal frequency scaling. The fan thus can not be controlled by the kernel. +We use lmsensors with hwmon for this instead. lmsensors reads the temperature +periodically and adjusts output PWM duty-cycle accordingly. By default, +temperature threshold for PWM fan to activate is set to 60°C.

+

The settings can be configured in the configuration file:

+
/etc/fancontrol
+
+
+

Fan control is started by a systemd service during boot. This can be disabled +with:

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.20. Watchdog

+

The PHYTEC i.MX 93 modules include a hardware watchdog that is able to reset the +board when the system hangs. The watchdog is started on default in U-Boot with a +timeout of 60s. So even during early kernel start, the watchdog is already up +and running. The Linux kernel driver takes control over the watchdog and makes +sure that it is fed. This section explains how to configure the watchdog in +Linux using systemd to check for system hangs and during reboot.

+
+

7.20.1. Watchdog Support in systemd

+

Systemd has included hardware watchdog support since version 183.

+
    +

  • To activate watchdog support, the file system.conf in /etc/systemd/ has to be +adapted by enabling the options:

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec defines the timeout value of the watchdog, +while ShutdownWatchdogSec defines the timeout when the system is rebooted. For +more detailed information about hardware watchdogs under systemd can be found at +http://0pointer.de/blog/projects/watchdog.html. The changes will take effect +after a reboot or run:

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.21. bbnsm Power Key

+

The X_ONOFF pin connected to the ON/OFF button can be pressed long (for 5 +seconds) to trigger Power OFF without SW intervention or used to wake up the +system out of suspend. With the bbnsm_pwrkey driver, the KEY_POWER event is +also reported to userspace when the button is pressed. On default, systemd is +configured to ignore such events. The function of Power OFF without SW +intervention are not configured. Triggering a power off with systemd when +pushing the ON/OFF button can be configured under /etc/systemd/logind.conf +and set using:

+
HandlePowerKey=poweroff
+
+
+
+
+

7.22. PXP

+

The i.MX 93 SoC contains an PiXel Pipeline (PXP). The PXP combines the following +into a single processing engine:

+
    +

  • Scaling

    • +

  • Color Space Conversion (CSC)

    • +

  • Secondary Color Space Conversion (CSC2)

    • +

  • Rotation

    • +
+

and thus minimizes the memory footprint required for the display pipeline. +How to use the PXP with Gstreamer and Wayland check the How to Use PXP in +GStreamer and Wayland (AN13829) Application note from NXP.

+
+
+

7.23. On-Chip OTP Controller (OCOTP_CTRL) - eFuses

+

The i.MX 93 provides one-time programmable fuses to store information such as the +MAC address, boot configuration, and other permanent settings (“On-Chip OTP +Controller (OCOTP_CTRL)” in the i.MX 93 Reference Manual). The following list is +an abstract from the i.MX 93 Reference Manual and includes some useful registers +in the OCOTP_CTRL (at base address 0x47510000):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Bank

Word

Memory offset +at 0x47510000

Description

BOOT_CFG0

3

0 0x60

boot fuse settings

BOOT_CFG1

3

1 0x64

boot fuse settings

BOOT_CFG2

3

2 0x68

boot fuse settings

BOOT_CFG3

3

3 0x6c

boot fuse settings

MAC1_ADDR

39

3

0x4ec

contains lower 32 bits +of ENET0 MAC address

MAC1/2_ADDR

39

4

0x4f0

contains upper 16 bits +of ENET0 MAC address +and the lower 16 bits +of ENET1 MAC address

MAC2_ADDR

39

5

0x4f4

contains upper 32 bits +of ENET1 MAC address

+

A complete list and a detailed mapping between the fuses in the OCOTP_CTRL and +the boot/mac/… configuration are available in the section “Fuse Map” of the +i.MX 93 Security Reference Manual.

+
+

7.23.1. Reading Fuse Values in uBoot

+

MAC1_ADDR:

+
u-boot=> fuse read 39 3
+
+
+
+
+

7.23.2. Reading Fuse Values in Linux

+

To access the content of the fuses in Linux NXP provides the NVMEM_IMX_OCOTP +module. All fuse content of the memory-mapped shadow registers is accessible via +sysfs:

+
target:~$ hexdump /sys/devices/platform/soc\@0/47510000.efuse/fsb_s400_fuse0/nvmem
+
+
+
+
+

7.23.3. Burning MAC addresses

+

Let’s say we want to burn the following MAC addresses:

+ + + + + + + + + +

MAC1

12:34:56:78:90:Aa

MAC2

Bb:Cc:Dd:Ee:Ff:D0

+

We would execute this in u-boot:

+
u-boot=> fuse prog 39 3 0x567890Aa
+u-boot=> fuse prog 39 4 0xFfD01234
+u-boot=> fuse prog 39 5 0xBbCcDdEe
+
+
+
+
+

7.23.4. Burning Boot Fuses

+
+

Warning

+

Fuses can only be written once! You can brick your board easily by burning +the wrong boot configuration. It cannot be reversed!

+
+

Which fuse bank/word should be used to program the BOOT_CFGX can be checked in +i.MX 93 Applications Processor Reference Manual attached spreadsheet named +i.MX93_Fusemap.xlsx.

+

These values should be written to the BOOT_CFG0, which can be read/written from +fuses on Bank 3, Word 0.

+ + + + + + + + + + + + + + +

Boot Device

BOOT_CFG0

eMMC

0x20020002

SD Card

0x20000103

+

To set internal fuses to boot from eMMC one can program them with:

+
u-boot=> fuse prog 3 0 0x20020002
+
+
+

In this example we:

+
    +

  • set the Boot_Mode to 0b0010 (eMMC) with BOOT_CFG0[3:0],

    • +

  • set the eMMC Bus width to 0b01 (8 bit) with BOOT_CFG0[18:17]

    • +

  • set the BT_FUSE_SEL (Boot fuses already programmed) bit with BOOT_CFG0[29]

    • +
+

Make sure you set the right bits by reading the Boot Fusemap chapter in +i.MX 93 Applications Processor Reference Manual.

+
+
+
+

7.24. TPM

+

The phyBOARD-Nash i.MX 93 is equipped with a Trusted Platform Module (TPM) +that provides hardware-based security functions.

+

Here are some useful examples to work with the TPM

+

Generate 4-byte random value with TPM2 tools:

+
+
target:~$ tpm2_getrandom --hex 4
+
+
+
+

Generate 4-byte random value with OpenSSL tools:

+
+
target:~$ openssl rand -engine libtpm2tss --hex 4
+
+
+
+

Generate RSA private key and validate its contents:

+
+
target:~$ openssl genrsa -engine libtpm2tss -out /tmp/priv_key 512
+Engine "tpm2tss" set.
+target:~$ openssl rsa -check -in /tmp/priv_key -noout
+RSA key ok
+target:~$ cat /tmp/priv_key
+-----BEGIN PRIVATE KEY-----
+MIIBVQIBADANBgkqhkiG9w0BAQEFAASCAT8wggE7AgEAAkEAxsvmcbxjwuKnYeuZ
+2AVBmuLvYyqF/LpYOD3IB/v+YvEolxdGGmjiFLECU6xZ1j3+dIt4Y1zbcKS1OcWT
+I8mbSwIDAQABAkBoy8wrYNhmP/1kzUJIclznPYJckGoZlFI1M7xjGSA9H1xDK6if
+5g5CYCHPrbBp8e0mEokPRZoihxxzGTxGPiahAiEA/7OYMOpVZ5SD3YcRsWcQlkWI
+MOSPUYg6vxvGG9xp4FcCIQDHB01RoHr+qXJwxIu3/3oQAUBI4ACJ4JRp0KelwhC0
+LQIhANJzSvg/dak5l8pU55/99q3nbm7nPnnZSJiP0F6P62gjAiEAjf7qrfMF7Uyt
+RkEjwbl2t5Z868FNARGGMVxZT4x+aF0CIGxlmP2pL8xFu1bWB282LSedqZUdQwel
+Lxi7+svb2+uJ
+-----END PRIVATE KEY-----
+
+
+
+
+

Note

+

Do NOT share your private RSA keys if you are going to use these keys for any +security purposes.

+
+

Generate RSA public key and validate its contents:

+
+
target:~$ openssl rsa -in /tmp/test_key -pubout -out /tmp/pub_key
+writing RSA key
+target:~$ openssl pkey -inform PEM -pubin -in /tmp/pub_key -noout
+target:~$ cat /tmp/pub_key
+-----BEGIN PUBLIC KEY-----
+MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMbL5nG8Y8Lip2HrmdgFQZri72Mqhfy6
+WDg9yAf7/mLxKJcXRhpo4hSxAlOsWdY9/nSLeGNc23CktTnFkyPJm0sCAwEAAQ==
+-----END PUBLIC KEY-----
+
+
+
+

Device tree TPM configuration can be found here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L151

+
+
+
+

8. i.MX 93 M33 Core

+

In addition to the Cortex-A55 cores, there is a Cortex-M33 Core as MCU +integrated into the i.MX 93 SoC. Our Yocto-Linux-BSP runs on the A55-Cores and +the M33 Core can be used as a secondary core for additional tasks using +bare-metal firmware. +Both cores have access to the same peripherals and thus peripheral +usage needs to be limited either in the M33 Core’s firmware or the devicetree +for the Linux operating system.

+

Our Yocto-BSP contains pre-built firmware examples for M33 Core from NXP.

+

This section describes how to run pre-built M33 Core firmware examples on phyBOARD-Segin/Nash i.MX 93.

+
+

8.1. Running M33 Core Examples

+

There are two ways to run the M33 Core firmware examples, from U-Boot bootloader +and from Remoteproc subsystem within a running Linux.

+

To receive debug messages start your favorite terminal software (e.g. Minicom, +Tio, or Tera Term) on your host PC and configure it for 115200 baud, 8 data +bits, no parity, and 1 stop bit (8n1) with no handshake.

+

On phyBOARD-Segin/Nash i.MX 93 an external “USB TTL to serial adapter” is required. Adapter’s I/O +pins should be able to operate at 3.3V voltage levels.

+

Connect external “USB TTL to serial adapter” signals to the +X16 connector on the board according to the following +table:

+ + + + + + + + + + + + + + + + + + + + + +

USB-TTL adapter pins

X16 signal

X16 pin

RXD

X_UART2_TX

5

TXD

X_UART2_RX

8

GND

GND

4

+
+

8.1.1. Running Examples from U-Boot

+

To load firmware examples using the U-Boot bootloader, the bootaux command +can be used:

+
    +

  1. Prepare an SD Card with our Yocto-BSP

    2. +

  2. Stop the autoboot by pressing any key

    3. +

  3. List available M33 Core firmware examples on the first partition of SD Card:

    4. +
+
u-boot=> ls mmc 1
+
+
+
+

Note

+

Available firmware examples start with imx93-11x11-evk_m33_TCM_* and +end with *.bin. Examples come from NXP’s Yocto layer meta-imx and are +selected based on compatibility with phyBOARD-Segin/Nash i.MX 93 hardware.

+
+
    +

  1. Load desired firmware example:

    2. +
+
u-boot=> fatload mmc 1 ${loadaddr} <firmware.bin>
+u-boot=> cp.b ${loadaddr} 0x201e0000 ${filesize}
+u-boot=> run prepare_mcore
+u-boot=> bootaux 0x1ffe0000 0
+## Starting auxiliary core addr = 0x1FFE0000...
+
+
+

The program’s output should appear on the M33 Core’s debug UART.

+
+
+

8.1.2. Running Examples from Linux using Remoteproc

+

Remoteproc is a module that allows you to control the M33 Core from Linux +during runtime. Firmware examples for M33 Core can be loaded and the execution +started or stopped within Linux. To use Remoteproc a devicetree overlay needs +to be set:

+

Edit the bootenv.txt file located in the /boot directory on the target +by adding imx93-phycore-rpmsg.dtso:

+
overlays=imx93-phyboard-segin-peb-av-02.dtbo imx93-phycore-rpmsg.dtso
+
+
+

Restart the target and execute in U-Boot:

+
u-boot=> run prepare_mcore
+
+
+

Firmware examples *.elf files for the M33 Core can be found under +/lib/firmware. List available firmware examples:

+
target:~$ ls /lib/firmware/*.elf
+
+
+

To load the firmware, type:

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

To load a different firmware, the M33 Core needs to be stopped:

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

Note

+

The samples found in /lib/firmware on the target come from NXP’s +Yocto layer meta-imx and are selected based on compatibility with phyBOARD-Segin/Nash i.MX 93 +hardware.

+
+

Some firmware examples from NXP require additional Linux kernel modules to be +loaded.

+

For example, when loading imx93-11x11-evk_m33_TCM_rpmsg_lite_str_echo_rtos.elf +firmware, one requires corresponding imx_rpmsg_tty module to be loaded:

+
target:~$ modprobe imx_rpmsg_tty
+
+
+

This exposes an RPMsg endpoint as a virtual TTY at /dev/ttyRPMSG30. +Now it is possible to send messages from A55 Core to M33 Core by typing:

+
target:~$ echo "PHYTEC" > /dev/ttyRPMSG30
+
+
+

Observing M33 Core debug UART should result in the following output:

+
RPMSG String Echo FreeRTOS RTOS API Demo...
+
+Nameservice sent, ready for incoming messages...
+Get Message From Master Side : "PHYTEC" [len : 6]
+
+
+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/contributing_links.html b/previews/271/contributing_links.html new file mode 100644 index 000000000..9ad6ee31f --- /dev/null +++ b/previews/271/contributing_links.html @@ -0,0 +1,148 @@ + + + + + + + + + Contribute — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

Contribute

+

Phytec’s Yocto BSPs are released under open source licenses and we welcome +contributions to our Yocto BSPs and this documentation. Please check the Git +repositories for the individual projects and layers for contribution +guidelines.

+

If you have a question related to our Yocto BSPs or notice issues with +this documentation, we encourage you to open an Issue or Pull-Request on the +Github repository doc-bsp-yocto. +Have a look at the Contributing guide for +more information.

+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/genindex.html b/previews/271/genindex.html new file mode 100644 index 000000000..b5b50ca4b --- /dev/null +++ b/previews/271/genindex.html @@ -0,0 +1,138 @@ + + + + + + + + Index — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ + +

Index

+ +
+ +
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/googledd12f2e41658d61e.html b/previews/271/googledd12f2e41658d61e.html new file mode 100644 index 000000000..cb695ae9f --- /dev/null +++ b/previews/271/googledd12f2e41658d61e.html @@ -0,0 +1 @@ +google-site-verification: googledd12f2e41658d61e.html \ No newline at end of file diff --git a/previews/271/index.html b/previews/271/index.html new file mode 100644 index 000000000..219698399 --- /dev/null +++ b/previews/271/index.html @@ -0,0 +1,155 @@ + + + + + + + + + Welcome to the PHYTEC BSP Documentation — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

Welcome to the PHYTEC BSP Documentation

+

Welcome to the Documentation for our Yocto BSPs.

+
+

Contents

+ +
+
+

Contribute

+ +
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/objects.inv b/previews/271/objects.inv new file mode 100644 index 000000000..b3bc94ce5 Binary files /dev/null and b/previews/271/objects.inv differ diff --git a/previews/271/rauc/kirkstone.html b/previews/271/rauc/kirkstone.html new file mode 100644 index 000000000..d2ecc9d0d --- /dev/null +++ b/previews/271/rauc/kirkstone.html @@ -0,0 +1,1280 @@ + + + + + + + + + 1. Introduction — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + +

RAUC Update & Device Management Manual

Document Title

RAUC Update & Device Management Manual Kirkstone

Document Type

RAUC Update & Device Management +Manual

Release Date

XXXX/XX/XX

Is Branch of

RAUC Update & Device Management Manual

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-Ampliphy-i.MX6-PD22.1.0

Major

14.12.2022

released

BSP-Yocto-Ampliphy-i.MX6-PD22.1.1

Minor

20.06.2023

released

BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.0

Major

11.08.2022

released

BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1

Minor

23.05.2023

released

BSP-Yocto-NXP-i.MX8MM-PD23.1.0

Major

12.12.2023

released

BSP-Yocto-NXP-i.MX8MP-PD23.1.0

Major

12.12.2023

released

BSP-Yocto-Ampliphy-AM62x-PD23.2.0

Major

28.09.2023

released

BSP-Yocto-Ampliphy-AM62Ax-PD23.1.0

Major

28.09.2023

released

BSP-Yocto-Ampliphy-AM64x-PD23.2.0

Major

28.09.2023

released

+

This manual was tested using the Yocto version Kirkstone.

+
+

1. Introduction

+

PHYTEC’s Yocto distribution Ampliphy (former Yogurt) supports the RAUC (Robust Auto-Update Controller) +mechanism. RAUC controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. For +eMMC devices only, it can also update the bootloader.

+

This manual describes how RAUC is used and implemented on various PHYTEC +platforms. Note, that different modules use different bootloaders and flash +storage devices, which affects the way things are handled by RAUC. Make sure to +read the correct sections fitting your platform.

+
+

Note

+

This manual contains machine-specific paths and variable contents. Make sure +you are using the correct machine and device names for your application when +executing any commands.

+
+
+
+

2. System Configuration

+

RAUC can be used with both eMMC and NAND flash storage. Using the distro +ampliphy-rauc or ampliphy-vendor-rauc, it is enabled by default and requires +no additional setup to get started. RAUC can be used in different update +scenarios. As an example, we configured the BSP to use an A/B setup to have a +completely redundant system (including the bootloader on eMMC devices). Note, +that there is an additional partition named config storing persistent +configuration data not being changed when updating.

+../_images/rauc-ab-system.png +
+

2.1. RAUC BSP Example Setup

+

The partition layout is defined in the /etc/rauc/system.conf file. As an +example, this is what it looks like for i.MX 8M Mini with eMMC flash storage:

+
+
/etc/rauc/system.conf
+
[system]
+compatible=phyboard-polis-imx8mm-4
+bootloader=uboot
+mountprefix=/mnt/rauc
+
+[handlers]
+pre-install=/usr/lib/rauc/rauc-pre-install.sh
+post-install=/usr/lib/rauc/rauc-post-install.sh
+
+[keyring]
+path=mainca-rsa.crt.pem
+
+[slot.bootloader.0]
+device=/dev/mmcblk2
+type=boot-emmc
+
+# System A
+[slot.rootfs.0]
+device=/dev/mmcblk2p5
+type=ext4
+bootname=system0
+
+[slot.boot.0]
+device=/dev/mmcblk2p1
+type=vfat
+parent=rootfs.0
+
+# System B
+[slot.rootfs.1]
+device=/dev/mmcblk2p6
+type=ext4
+bootname=system1
+
+[slot.boot.1]
+device=/dev/mmcblk2p2
+type=vfat
+parent=rootfs.1
+
+
+
+

Note, that the devices specified in the slots are different depending on the +selected machine.

+
+

Warning

+

Updates with RAUC use an OpenSSL certificate to verify the validity of an +image. The BSP includes a certificate that can be used for development. In a +productive system, however, it is highly recommended to use a self-created +key and certificate. If you need to change the keyring on an existing device, +see Switching RAUC Keyrings for more +information.

+
+
+
+
+

3. Design Considerations

+

In order to prevent the system from locking up, it may be a good idea to utilize +a hardware watchdog. In case the Linux Kernel does not boot or another +catastrophic event occurs that prevents the system from operating normally, the +hardware watchdog then resets the system. By default, the hardware watchdog is +disabled. To enable it, refer to the corresponding BSP manual that fits your +SoM.

+

Other important design considerations, as well as a checklist, can be found in +the official RAUC documentation: +https://rauc.readthedocs.io/en/latest/checklist.html

+
+
+

4. Initial Setup

+

To use RAUC, the flash device needs to be written with a complete Linux system +and bootloader. The preferred method to do this is using the included tool +partup.

+
+

4.1. Flash Storage

+

To flash the device with the correct partitions/volumes, use a partup package +built with the ampliphy-rauc or ampliphy-vendor-rauc distribution. +Prebuilt partup packages can be found in the BSP release. It is also possible to +build a package with this distribution yourself using Yocto. Change +local.conf so separate build directories are created, storing the images and +packages for the RAUC system:

+
+
build/conf/local.conf
+
# When building multiple distros in the same TOPDIR
+TMPDIR = "${TOPDIR}/tmp-${DISTRO}"
+DEPLOY_DIR = "${TOPDIR}/deploy-${DISTRO}"
+
+
+
+

Then initialize the build directory with the OE init script:

+
host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source sources/poky/oe-init-build-env
+
+
+

Change the distribution to ampliphy-rauc (for i.MX6, AM6x) or +ampliphy-vendor-rauc (for i.MX8):

+
+
build/conf/local.conf
+
DISTRO ?= "ampliphy-rauc"
+
+
+
+

Any image built with this distro now includes a full A/B system. Build the image +as usual:

+
host:~$ bitbake phytec-headless-image
+
+
+

The resulting partup package is stored in the deploy-ampliphy-vendor-rauc directory, e.g.:

+
deploy-ampliphy-vendor-rauc/images/phyboard-segin-imx93-2/phytec-headless-image-phyboard-segin-imx93-2.partup
+
+
+

This partup package contains all the necessary data and configuration to flash +an eMMC. Partup can be obtained from its +release page. Also, see its +README for detailed installation instructions. Partup is already installed +in our Ampliphy images, phytec-headless-image and can be directly used e.g. +from an SD card.

+
+

Note

+

To flash the initial RAUC system, a booted non-RAUC system is needed first on +a different flash device. E.g. you could boot a regular +phytec-headless-image image with distro ampliphy from an SD card.

+
+
+

4.1.1. eMMC

+

While running a non-RAUC system from an SD card on the target, copy the +.partup package built with distro ampliphy-rauc or +ampliphy-vendor-rauc to the running target first:

+
host:~$ scp phytec-headless-image-phyboard-segin-imx93-2.partup 192.168.3.11:/root
+
+
+

Then install the partup package to the eMMC:

+
target:~$ partup install phytec-headless-image-phyboard-segin-imx93-2.partup /dev/mmcblk0
+
+
+

Now the target can boot the flashed A/B system.

+
+
+

4.1.2. NAND

+
+

Note

+

There are scripts provided with the bootloader barebox that previously were +used to initialize NAND flash with an A/B system: rauc_init_nand, +rauc_flash_nand_from_tftp and rauc_flash_nand_from_mmc. These scripts +are deprecated. It is advised to use the script rauc-flash-nand provided +in the Linux environment with PHYTEC’s distribution Ampliphy.

+
+

With raw NAND flash the kernel, device tree, and root filesystem are written +individually. Initialize the NAND flash with the correct volumes from a Linux on +the target:

+
target:~$ rauc-flash-nand -k /path/to/zImage -d /path/to/oftree -r /path/to/root.ubifs
+
+
+

The initialization script will automatically utilize all available space of NAND +flash. The NAND device is also determined automatically by finding the device +root in /proc/mtd.

+

On i.MX6 and i.MX6UL devices with barebox, use bbu (barebox update) to flash the +bootloader:

+
target:~$ bbu.sh -f /path/to/barebox.bin
+
+
+

The A/B system on NAND Flash is now ready to be booted.

+
+
+
+

4.2. Bootloader

+
+

4.2.1. Booting the A/B System by Default

+

Booting the A/B system is done mostly automatically by the bootloader since the +Yocto release hardknott. For devices with eMMC flash storage, the +corresponding setting is written into the bootloader environment during the +building of the BSP. In particular, if the distribution ampliphy-rauc or +ampliphy-vendor-rauc is used, as described previously, the bootloader should +automatically start the A/B system and have the variables set for RAUC +accordingly.

+

This automatic setting can be manually changed by setting one variable in the +bootloader. The procedure is described in more detail in the following chapters +for U-Boot and barebox.

+
+
+

4.2.2. U-Boot

+

After a successful boot into a Linux environment, this command is used to view +the available parameters:

+
target:~$ fw_printenv
+
+
+

You may see this parameter along with others in the output:

+
doraucboot=1
+
+
+

To manually disable or enable booting the A/B system with RAUC, set this +variable to 0 or 1:

+
target:~$ fw_setenv doraucboot 1
+
+
+

This parameter can also be edited in U-Boot. Restart your board and hit any key +to stop the automatic boot. The environment variables can now be viewed:

+
u-boot=> printenv
+
+
+

and set:

+
u-boot=> setenv doraucboot 1
+u-boot=> saveenv
+
+
+
+
+

4.2.3. Barebox

+

In barebox, the system to be booted can be selected directly by its name. To +boot the A/B system, including RAUC, bootchooser is used. To boot e.g. a +regular SD card without RAUC use mmc instead, or nand for NAND devices:

+
barebox$ nv boot.default=bootchooser
+
+
+
+
+
+
+

5. Creating RAUC Bundles

+

To update your system with RAUC, a RAUC bundle (.raucb) needs to be created. +It contains all required images and scripts for the update and a RAUC +manifest.raucm that describes the content of the bundle for the RAUC update +on the target. The BSP includes a Yocto target that lets you build a RAUC bundle +from your Yocto build.

+

To create the bundle with Yocto, run the following in build/ with the +distribution ampliphy-rauc or ampliphy-vendor-rauc set up, as described +previously:

+
host:~$ bitbake phytec-headless-bundle
+
+
+

This results in the creation of a .raucb bundle file in +deploy/images/<MACHINE>/ which can be used for updating the system as +described later. There is no need to create a manifest.raucm manually as it +is created automatically during the build of the bundle. As a reference, the +created manifest would look something like this:

+
+
manifest.raucm
+
[update]
+compatible=phyboard-polis-imx8mm-3
+version=r0
+description=PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0
+build=20200624074335
+
+[image.rootfs]
+sha256=cc3f65cd1c1993951d7a39bdb7b7d723617ac46460f8b640cd8d1622ad6e4c17
+size=99942000
+filename=phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz
+
+[image.boot]
+sha256=bafe46679af8c6292dba22b9d402e3119ef78c6f8b458bcb6993326060de3aa4
+size=12410534
+filename=boot.tar.gz.img
+
+
+
+

For more information about the manifest format, see +https://rauc.readthedocs.io/en/latest/reference.html#manifest.

+
+
+

6. Updating with RAUC

+

To update the target system with RAUC, the RAUC bundle file previously created +first needs to be copied to the board or to a memory device that can be mounted +in Linux. One way is to copy the bundle file with scp, but this requires +enough space left on the board’s filesystem. To do this, boot the target board +to Linux and connect it via Ethernet to your host PC.

+

On the host, run:

+
host:~$ scp phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb root@192.168.3.11:/tmp/
+
+
+

On the target, the bundle can be verified:

+
target:~$ rauc info /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+
+
+

and the output should look similar to this:

+
rauc-Message: 12:52:49.821: Reading bundle: /phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+rauc-Message: 12:52:49.830: Verifying bundle...
+Compatible:     'phyboard-polis-imx8mm-3'
+Version:        'r0'
+Description:    'PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0'
+Build:          '20200624073212'
+Hooks:          ''
+2 Images:
+(1)     phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz
+        Slotclass: rootfs
+        Checksum:  342f67f7678d7af3f77710e1b68979f638c7f4d20393f6ffd0c36beff2789070
+        Size:      180407809
+        Hooks:
+(2)     boot.tar.gz.img
+        Slotclass: boot
+        Checksum:  8c84465b4715cc142eca2785fea09804bd970755142c9ff57e08c791e2b71f28
+        Size:      12411786
+        Hooks:
+0 Files
+
+Certificate Chain:
+ 0 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH Development-1
+   Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   SPKI sha256: E2:47:5F:32:05:37:04:D4:8C:48:8D:A6:74:A8:21:2E:97:41:EE:88:74:B5:F4:65:75:97:76:1D:FF:1D:7B:EE
+   Not Before: Jan  1 00:00:00 1970 GMT
+   Not After:  Dec 31 23:59:59 9999 GMT
+ 1 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   SPKI sha256: AB:5C:DB:C6:0A:ED:A4:48:B9:40:AC:B1:48:06:AA:BA:92:09:83:8C:DC:6F:E1:5F:B6:FB:0C:39:3C:3B:E6:A2
+   Not Before: Jan  1 00:00:00 1970 GMT
+   Not After:  Dec 31 23:59:59 9999 GMT
+
+
+

To check the current state of the system, run:

+
target:~$ rauc status
+
+
+

and get output similar to this:

+
=== System Info ===
+Compatible:  phyboard-segin-imx6ul-6
+Variant:
+Booted from: rootfs.0 (system0)
+
+=== Bootloader ===
+Activated: rootfs.0 (system0)
+
+=== Slot States ===
+o [rootfs.1] (/dev/ubi0_6, ubifs, inactive)
+        bootname: system1
+        boot status: good
+    [dtb.1] (/dev/ubi0_3, ubivol, inactive)
+    [kernel.1] (/dev/ubi0_2, ubivol, inactive)
+
+x [rootfs.0] (/dev/ubi0_5, ubifs, booted)
+        bootname: system0
+        boot status: good
+    [kernel.0] (/dev/ubi0_0, ubivol, active)
+    [dtb.0] (/dev/ubi0_1, ubivol, active)
+
+
+

To update the currently inactive system with the downloaded bundle, run:

+
target:~$ rauc install /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+
+
+

and reboot afterward:

+
target:~$ reboot
+
+
+

With the success of the update, RAUC automatically switches the active system to +the newly updated system. Now during reboot, RAUC counts the boot attempts of +the kernel and if it fails more often than specified in the state framework of +the system, RAUC switches back to the old system and marks the new system as +bad. If the boot attempt to the kernel is successful, the new system is marked +as good and the old system can now be updated with the same instructions. After +two successful rauc install and reboot, both systems are updated.

+
+

Tip

+

When you update from a USB stick, make sure to remove the stick after a +successful update before rebooting. If not, an automatic update will be +started after each boot. This is due to the Automatic Update from USB Flash +Drive with RAUC you can find below.

+
+
+

6.1. Changing the Active Boot Slot

+

It is possible to switch the active system manually:

+
target:~$ rauc status mark-active other
+
+
+

After a reboot, the target now starts from the other system.

+
+
+
+

7. Switching RAUC Keyrings

+

PHYTEC’s distribution comes with keys and certificates used for development and +demonstration purposes only. To change to a different PKI when devices are +already rolled out, RAUC’s keyring must be changed. This chapter describes the +full procedure from a development state to a production state. Keep in mind, +that it is always a better idea to roll out your devices with a production +keyring in the first place, instead of relying on a development one for too +long. The following diagram shows the general process of switching keyrings for +RAUC:

+../_images/rauc-switching-keyrings.png +
+

7.1. Keyring Switching Process

+

Create new certificates and keys for your own PKI. See our security manual for a +detailed description on how to create a custom PKI. For this document, we refer +to this newly created PKI as “production”, as opposed to the existing +“development” keys.

+

Move the generated keys and certificates, to your main Yocto build directory +root, alongside with build/ and sources/.

+
+

Warning

+

Be careful where you store the private keys! These should in no way be made +publicly available. E.g. do not store the private keys in a public Git +repository. Otherwise, unauthorized entities could create RAUC bundles that +can be installed on your target system!

+
+

Now, a RAUC bundle must be created that contains the new “production” CA keyring +in its root filesystem but is still signed by the “development” CA. With this, +the system is converted from a “development” system to a “production” system. To +achieve this, exchange the file ca.cert.pem installed by the RAUC recipe in +the Yocto sources. Create a file rauc_%.bbappend in your own Yocto layer:

+
+
recipes-core/rauc/rauc_%.bbappend
+
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+RAUC_KEYRING_FILE = "${CERT_PATH}/rauc-customer/ca.cert.pem"
+
+
+
+

Build the same RAUC bundle as before, now with the exchanged keyring:

+
host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source source/poky/oe-init-build-env
+host:~$ bitbake phytec-headless-bundle  # Build the desired RAUC bundle
+
+
+

Install the resulting RAUC bundle as usual. The target now has the image with +the “production” keyring installed in its other slot (“System B” in the figure +above). Reboot to start that system.

+

All future RAUC bundles for the “production” system must now also be signed by +the “production” CA. For this, change the key and certificate to your newly +generated “production” ones in the bundle recipe:

+
+
recipes-images/bundles/customer-headless-bundle.bb
+
require phytec-base-bundle.inc
+
+RAUC_SLOT_rootfs ?= "phytec-headless-image"
+
+RAUC_KEY_FILE = "${CERT_PATH}/rauc-customer/private/production-1.key.pem"
+RAUC_CERT_FILE = "${CERT_PATH/rauc-customer/production-1.cert.pem"
+
+RAUC_INTERMEDIATE_CERT_FILE = ""
+
+
+
+

Rebuild the RAUC bundle:

+
host:~$ bitbake customer-headless-bundle
+
+
+

These and any future bundles are now ready to be installed on your “production” +target system and have been fully migrated away from the “development” system. +This also means that now only bundles signed by the “production” CA can be +installed on the target (and e.g. “development” bundles cannot).

+
+
+
+

8. Use Case Examples

+
+

8.1. Automatic Updates from USB Flash Drive with RAUC

+

One of the most prominent use cases for RAUC might be an automatic update system +from a USB flash drive. This use case is implemented in the BSP as a reference +example. We combine only standard Linux mechanisms with RAUC to build the +system. The kernel notifies udev when a device gets plugged into the USB port. +We use a custom udev rule to trigger a systemd service when this event +happens.

+
+
10-update-usb.rules
+
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"
+
+# Trigger systemd service
+ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}="update-usb@%k.service"
+
+# Exit
+LABEL="media_by_label_auto_mount_end"
+
+
+
+

The service automatically mounts the USB flash drive and notifies the +application.

+
+
update-usb@.service
+
[Unit]
+Description=usb media RAUC service
+After=multi-user.target
+Requires=rauc.service
+
+[Service]
+Type=oneshot
+Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket
+ExecStartPre=/bin/mkdir -p /media/%I
+ExecStartPre=/bin/mount -t auto /dev/%I /media/%I
+ExecStart=/usr/bin/update_usb.sh %I
+ExecStop=/bin/umount -l /media/%i
+ExecStopPost=-/bin/rmdir /media/%I
+
+
+
+

In our reference implementation, we simply use a shell script for the +application logic.

+
+
update_usb.sh
+
#!/bin/sh
+
+MOUNT=/media/$1
+
+NUMRAUCM=$(find ${MOUNT}/*.raucb -maxdepth 0 | wc -l)
+
+[ "$NUMRAUCM" -eq 0 ] && echo "${MOUNT}*.raucb not found" && exit
+[ "$NUMRAUCM" -ne 1 ] && echo "more than one ${MOUNT}/*.raucb" && exit
+
+rauc install $MOUNT/*.raucb
+if [ "$?" -ne 0 ]; then
+    echo "Failed to install RAUC bundle."
+else
+    echo "Update successful."
+fi
+exit $?
+
+
+
+

The update logic can be integrated into an application using the systemd D-Bus +API. RAUC does not need to be called by its command-line interface but can be +integrated with D-Bus.

+
+

Tip

+

RAUC features a D-Bus API interface (see +https://rauc.readthedocs.io/en/latest/using.html#using-the-d-bus-api).

+
+
+
+

8.2. Security Measurement: Downgrade Barrier

+

As a second reference example, we will implement a security mechanism: a +downgrade barrier. When you detect a security vulnerability on your system, you +will fix it and update your system. The systems with the new software will now +be secure again. If an attacker gets a hold of the old software update bundle, +which still has a valid signature, the attacker might have the possibility to +install the old software and still take advantage of the previously fixed +security vulnerability. To prevent this from happening, you could revoke the +updated certificate for every single update and create a new one. This might be +difficult to handle, depending on the environment. A simpler solution would be +to allow updates only in one direction using a version check.

+
+
rauc_downgrade_barrier.sh
+
#!/bin/sh
+
+VERSION_FILE=/etc/rauc/downgrade_barrier_version
+MANIFEST_FILE=${RAUC_UPDATE_SOURCE}/manifest.raucm
+
+[ ! -f ${VERSION_FILE} ] && exit 1
+[ ! -f ${MANIFEST_FILE} ] && exit 2
+
+VERSION=`cat ${VERSION_FILE} | cut -d 'r' -f 2`
+BUNDLE_VERSION=`grep "version" -rI ${MANIFEST_FILE} | cut -d 'r' -f 3`
+
+# check from empty or unset variables
+[ -z "${VERSION}" ] && exit 3
+[ -z "${BUNDLE_VERSION}" ] && exit 4
+
+# developer mode, allow all updates if version is r0
+#[ ${VERSION} -eq 0 ] && exit 0
+
+# downgrade barrier
+if [ ${VERSION} -gt ${BUNDLE_VERSION} ]; then
+        echo "Downgrade barrier blocked rauc update! CODE5\n"
+else
+        exit 0
+fi
+exit 5
+
+
+
+

The script is installed on the target but it is not activated. You need to +remove the developer mode line in the script to activate it.

+
+
+

8.3. Streaming Bundles over HTTP

+

Instead of copying the bundle to the device, the bundle can be streamed over +HTTP. Using bundle streaming has the advantage of not requiring local storage on +the target. A simple approach to this is running NGINX inside a Docker +container. The following example shows how to implement a minimal download +server enabling HTTP range requests to support this feature.

+

Create a Dockerfile with the following content:

+
+
Dockerfile
+
FROM nginx
+
+COPY bundles /bundles
+COPY nginx.conf /etc/nginx/nginx.conf
+
+
+
+

Configure NGINX to enable HTTP range requests and point it to the bundle file.

+
+
nginx.conf
+
events {}
+http {
+    server {
+        proxy_force_ranges on;
+
+        location / {
+            root /bundles;
+        }
+    }
+}
+
+
+
+

Place a bundle in the bundles sub-directory. The folder structure looks like +the following after creating all configuration files:

+
user@host:rauc-bundle-streaming$ find
+.
+./bundles
+./bundles/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb
+./nginx.conf
+./Dockerfile
+
+
+

Build and run the docker container on the host system:

+
host:~$ sudo docker build -t rauc-bundle-streaming .
+host:~$ sudo docker run --name bundles -p 80:80 -d rauc-bundle-streaming
+
+
+

Install the bundle on the currently inactive target partitions:

+
target:~$ rauc install http://192.168.3.10/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb
+
+
+
+

Note

+

After the update finishes the target may display the following error which +has no impact on the success of the update:

+
[ 7416.336609] block nbd0: NBD_DISCONNECT
+[ 7416.340413] block nbd0: Send disconnect failed -32
+
+
+
+
+
+
+

9. Reference

+
+

9.1. Boot Logic Implementation

+
+

Tip

+

The implementation details described in this chapter serve as a reference +guide. PHYTEC BSPs that have RAUC support include these by default and the +changes are already incorporated.

+
+
+

9.1.1. U-Boot Environment Variables

+

For U-Boot, the boot logic that selects the correct partitions to boot from is +implemented in its environment. As a reference, these are the most important +U-Boot variables that are used for the A/B system with RAUC:

+

For BSP-Yocto-NXP-i.MX8M*-PD23.1.0:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Function

BOOT_ORDER

Contains a space-separated list of boot targets in the +order they should be tried. This parameter is +automatically set by RAUC.

BOOT_<slot>_LEFT

Contains the number of remaining boot attempts to +perform for the respective slot. This parameter is +automatically set by RAUC.

raucboot

Contains the boot logic that sets the partitions so +the correct system is loaded.

doraucboot

Enables booting the A/B system if set to 1 and +disables it if set to 0.

raucslot

Contains the current boot slot used in +BOOT_<slot>_LEFT.

raucargs

Sets the Kernel bootargs like console, root, and RAUC +lot.

raucdev

Sets the eMMC as the boot device.

raucrootpart

Sets the root filesystem partitions of the device.

raucpart

Sets the boot partitions of the device.

loadraucimage

Loads the Kernel image into RAM.

loadraucfdt

Loads the device tree into RAM.

+

These environment variables are defined in include/configs/phycore_<SOC>.h +in the u-boot source code.

+

For BSP-Yocto-Ampliphy-AM6xx-PD23.2.0:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Function

BOOT_ORDER

Contains a space-separated list of boot targets in the +order they should be tried. This parameter is +automatically set by RAUC.

BOOT_<slot>_LEFT

Contains the number of remaining boot attempts to +perform for the respective slot. This parameter is +automatically set by RAUC.

init_rauc

Contains the boot logic that sets the partitions so +the correct system is loaded.

doraucboot

Enables booting the A/B system if set to 1 and +disables it if set to 0.

raucslot

Contains the current boot slot used in +BOOT_<slot>_LEFT.

raucrootpart

Sets the root filesystem partitions of the device.

raucbootpart

Sets the boot partitions of the device.

+

These environment variables are defined in +include/environment/phytec/rauc.env in the u-boot source code.

+
+

Note

+

A change in the partition layout, e.g. when using an additional data +partition, may require changing the variables raucrootpart and +raucpart. Make sure to rebuild your image with the new bootloader +environment after you have made the appropriate changes.

+
+
+
+

9.1.2. Barebox Bootchooser Framework

+

For the barebox, the boot logic that selects the correct partitions to boot from +is implemented using the bootchooser and state framework. See the barebox +documentation for detailed information about these: Barebox Bootchooser +Framework, Barebox +State Framework.

+

First, the state framework configuration needs to be added to the barebox device +tree. Check out the Customizing the BSP +chapter in the Yocto reference manual. The state framework configuration is +already included with our BSP for the supported SoC and can be directly included +in the main barebox device tree. E.g. for i.MX6 based module:

+
#include "imx6qdl-phytec-state.dtsi"
+
+
+

Afterward, rebuild the image and flash the new bootloader.

+
+

Warning

+

Be aware that by adding the state framework configuration, the first 160 +bytes of the EEPROM are occupied and can no longer be used for user-specific +purposes.

+
+

The following device tree snippet shows an example of the state framework +configuration used with the BSP. As can be seen, the EEPROM is used as a backend +for the state information:

+
/ {
+    aliases {
+        state = &state;
+    };
+
+    state: imx6qdl_phytec_boot_state {
+        magic = <0x883b86a6>;
+        compatible = "barebox,state";
+        backend-type = "raw";
+        backend = <&backend_update_eeprom>;
+        backend-stridesize = <54>;
+
+        #address-cells = <1>;
+        #size-cells = <1>;
+        bootstate {
+            #address-cells = <1>;
+            #size-cells = <1>;
+            last_chosen {
+                reg = <0x0 0x4>;
+                type = "uint32";
+            };
+            system0 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                remaining_attempts {
+                    reg = <0x4 0x4>;
+                    type = "uint32";
+                    default = <3>;
+                };
+                priority {
+                    reg = <0x8 0x4>;
+                    type = "uint32";
+                    default = <21>;
+                };
+                ok {
+                    reg = <0xc 0x4>;
+                    type = "uint32";
+                    default = <0>;
+                };
+            };
+            system1 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                remaining_attempts {
+                    reg = <0x10 0x4>;
+                    type = "uint32";
+                    default = <3>;
+                };
+                priority {
+                    reg = <0x14 0x4>;
+                    type = "uint32";
+                    default = <20>;
+                };
+                ok {
+                    reg = <0x18 0x4>;
+                    type = "uint32";
+                    default = <0>;
+                };
+            };
+        };
+    };
+};
+
+&eeprom {
+    status = "okay";
+    partitions {
+        compatible = "fixed-partitions";
+        #size-cells = <1>;
+        #address-cells = <1>;
+        backend_update_eeprom: state@0 {
+            reg = <0x0 0x100>;
+            label = "update-eeprom";
+        };
+    };
+};
+
+
+

To be able to boot from two systems alternately, the bootchooser needs to be +aware of the state framework configuration. For each system, a boot script is +required. For a system with NAND flash, the boot script of the first system may +look like the following:

+
+
/env/boot/system0
+
#!/bin/sh
+
+[ -e /env/config-expansions ] && /env/config-expansions
+
+[ ! -e /dev/nand0.root.ubi ] && ubiattach /dev/nand0.root
+
+global.bootm.image="/dev/nand0.root.ubi.kernel0"
+global.bootm.oftree="/dev/nand0.root.ubi.oftree0"
+global.linux.bootargs.dyn.root="root=ubi0:root0 ubi.mtd=root rootfstype=ubifs"
+
+
+
+

The second boot script has the same structure but uses the partitions containing +the second system. Machines with eMMC flash use similar boot scripts, albeit the +mounting and boot arguments look different.

+

Run the following commands to create the required bootchooser non-volatile +environment variables:

+
barebox$ nv bootchooser.state_prefix=state.bootstate
+barebox$ nv bootchooser.system0.boot=system0
+barebox$ nv bootchooser.system1.boot=system1
+barebox$ nv bootchooser.targets="system0 system1"
+
+
+
+
+
+

9.2. eMMC Boot Partitions

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader.

+

By default, bundles built with our BSP (e.g. phytec-headless-bundle) contain +the bootloader for updating eMMC boot partitions accordingly.

+

Note, that the U-Boot environment still resides in the user area before the +first partition. The user area also still contains the bootloader which the +image first shipped during its initialization process.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=imx-boot of=/dev/mmcblk2boot0 bs=1k seek=33
+target:~$ dd if=imx-boot of=/dev/mmcblk2boot1 bs=1k seek=33
+
+
+

This example is valid for the i.MX 8M Mini SoC. Note, that other SoCs may have +different bootloader files and require different offsets where the bootloader is +expected, specified by the seek parameter. See the following table for the +different offsets being required by each SoC:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

Bootloader

i.MX 6

1 kiB

0 kiB

/dev/mmcblk3

barebox.bin

i.MX 6UL

1 kiB

0 kiB

/dev/mmcblk1

barebox.bin

i.MX 8M

33 kiB

33 kiB

/dev/mmcblk0

imx-boot

i.MX 8M Mini

33 kiB

33 kiB

/dev/mmcblk2

imx-boot

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

AM62x +AM62Ax +AM64x

N/A

0 kiB +512 kiB +2560 kiB

/dev/mmcblk0

tiboot3.bin +tispl.bin +u-boot.img

+
+

9.2.1. Bootloader Offsets

+

Note that the offset is different, depending on whether the bootloader resides +in the user area or the boot partitions of the eMMC.

+

After a bootloader has been written to the eMMC boot partitions, booting from +these can be enabled by using the following command:

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

This also means that only the bootloaders written in the eMMC boot partitions +are used. The bootloader in the user area is not used anymore. These steps are +also executed by RAUC internally when updating the target system with a bundle.

+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

After this command, the eMMC user area is used to provide the bootloader.

+

When using U-Boot, a similar command is also available in the bootloader:

+
u-boot=> mmc partconf 2 0 0 0  # disable
+u-boot=> mmc partconf 2 0 1 0  # enable
+
+
+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/rauc/manual-index.html b/previews/271/rauc/manual-index.html new file mode 100644 index 000000000..46ce4ee04 --- /dev/null +++ b/previews/271/rauc/manual-index.html @@ -0,0 +1,299 @@ + + + + + + + + + RAUC Update & Device Management Manuals — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

RAUC Update & Device Management Manuals

+
+

Kirkstone

+
+

Table of Contents

+ +
+
+
+

Mickledore

+
+

Table of Contents

+ +
+
+
+

Scarthgap

+
+

Table of Contents

+ +
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/rauc/mickledore.html b/previews/271/rauc/mickledore.html new file mode 100644 index 000000000..895ca46ed --- /dev/null +++ b/previews/271/rauc/mickledore.html @@ -0,0 +1,1188 @@ + + + + + + + + + 1. Introduction — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + +

RAUC Update & Device Management Manual

Document Title

RAUC Update & Device Management Manual Mickledore

Document Type

RAUC Update & Device Management +Manual

Release Date

XXXX/XX/XX

Is Branch of

RAUC Update & Device Management Manual

+ + + + + + + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-NXP-i.MX93-PD24.1.0

Major

05.02.2024

released

BSP-Yocto-NXP-i.MX93-PD24.1.1

Minor

08.05.2024

released

+

This manual was tested using the Yocto version Mickledore.

+
+

1. Introduction

+

PHYTEC’s Yocto distribution Ampliphy (former Yogurt) supports the RAUC (Robust Auto-Update Controller) +mechanism. RAUC controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. For +eMMC devices only, it can also update the bootloader.

+

This manual describes how RAUC is used and implemented on various PHYTEC +platforms. Note, that different modules use different bootloaders and flash +storage devices, which affects the way things are handled by RAUC. Make sure to +read the correct sections fitting your platform.

+
+

Note

+

This manual contains machine-specific paths and variable contents. Make sure +you are using the correct machine and device names for your application when +executing any commands.

+
+
+
+

2. System Configuration

+

RAUC can be used with both eMMC and NAND flash storage. Using the distro +ampliphy-rauc or ampliphy-vendor-rauc, it is enabled by default and requires +no additional setup to get started. RAUC can be used in different update +scenarios. As an example, we configured the BSP to use an A/B setup to have a +completely redundant system (including the bootloader on eMMC devices). Note, +that there is an additional partition named config storing persistent +configuration data not being changed when updating.

+../_images/rauc-ab-system.png +
+

2.1. RAUC BSP Example Setup

+

The partition layout is defined in the /etc/rauc/system.conf file. As an +example, this is what it looks like for i.MX 8M Mini with eMMC flash storage:

+
+
/etc/rauc/system.conf
+
[system]
+compatible=phyboard-polis-imx8mm-4
+bootloader=uboot
+mountprefix=/mnt/rauc
+
+[handlers]
+pre-install=/usr/lib/rauc/rauc-pre-install.sh
+post-install=/usr/lib/rauc/rauc-post-install.sh
+
+[keyring]
+path=mainca-rsa.crt.pem
+
+[slot.bootloader.0]
+device=/dev/mmcblk2
+type=boot-emmc
+
+# System A
+[slot.rootfs.0]
+device=/dev/mmcblk2p5
+type=ext4
+bootname=system0
+
+[slot.boot.0]
+device=/dev/mmcblk2p1
+type=vfat
+parent=rootfs.0
+
+# System B
+[slot.rootfs.1]
+device=/dev/mmcblk2p6
+type=ext4
+bootname=system1
+
+[slot.boot.1]
+device=/dev/mmcblk2p2
+type=vfat
+parent=rootfs.1
+
+
+
+

Note, that the devices specified in the slots are different depending on the +selected machine.

+
+

Warning

+

Updates with RAUC use an OpenSSL certificate to verify the validity of an +image. The BSP includes a certificate that can be used for development. In a +productive system, however, it is highly recommended to use a self-created +key and certificate. If you need to change the keyring on an existing device, +see Switching RAUC Keyrings for more +information.

+
+
+
+
+

3. Design Considerations

+

In order to prevent the system from locking up, it may be a good idea to utilize +a hardware watchdog. In case the Linux Kernel does not boot or another +catastrophic event occurs that prevents the system from operating normally, the +hardware watchdog then resets the system. By default, the hardware watchdog is +disabled. To enable it, refer to the corresponding BSP manual that fits your +SoM.

+

Other important design considerations, as well as a checklist, can be found in +the official RAUC documentation: +https://rauc.readthedocs.io/en/latest/checklist.html

+
+
+

4. Initial Setup

+

To use RAUC, the flash device needs to be written with a complete Linux system +and bootloader. The preferred method to do this is using the included tool +partup.

+
+

4.1. Flash Storage

+

To flash the device with the correct partitions/volumes, use a partup package +built with the ampliphy-rauc or ampliphy-vendor-rauc distribution. +Prebuilt partup packages can be found in the BSP release. It is also possible to +build an image with this distribution yourself using Yocto. Separate build +directories are created, storing the images and packages for the RAUC system. +Initialize the build directory with the OE init script:

+
host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source sources/poky/oe-init-build-env
+
+
+

Change the distribution to ampliphy-rauc (for i.MX6, AM6x, i.MX8 mainline BSP) or +ampliphy-vendor-rauc (for i.MX8, i.MX9 vendor BSP):

+
+
build/conf/local.conf
+
DISTRO ?= "ampliphy-rauc"
+
+
+
+

Any image built with this distro now includes a full A/B system. Build the image +as usual:

+
host:~$ bitbake phytec-headless-image
+
+
+

The resulting partup package is stored in the deploy-ampliphy-vendor-rauc directory, e.g.:

+
deploy-ampliphy-vendor-rauc/images/phyboard-segin-imx93-2/phytec-headless-image-phyboard-segin-imx93-2.partup
+
+
+

This partup package contains all the necessary data and configuration to flash +an eMMC. Partup can be obtained from its +release page. Also, see its +README for detailed installation instructions. Partup is already installed +in our Ampliphy images, phytec-headless-image and can be directly used e.g. +from an SD card.

+
+

Note

+

To flash the initial RAUC system, a booted non-RAUC system is needed first on +a different flash device. E.g. you could boot a regular +phytec-headless-image image with distro ampliphy from an SD card.

+
+
+

4.1.1. eMMC

+

While running a non-RAUC system from an SD card on the target, copy the +.partup package built with distro ampliphy-rauc or +ampliphy-vendor-rauc to the running target first:

+
host:~$ scp phytec-headless-image-phyboard-segin-imx93-2.partup 192.168.3.11:/root
+
+
+

Then install the partup package to the eMMC:

+
target:~$ partup install phytec-headless-image-phyboard-segin-imx93-2.partup /dev/mmcblk0
+
+
+

Now the target can boot the flashed A/B system.

+
+
+

4.1.2. NAND

+
+

Note

+

There are scripts provided with the bootloader barebox that previously were +used to initialize NAND flash with an A/B system: rauc_init_nand, +rauc_flash_nand_from_tftp and rauc_flash_nand_from_mmc. These scripts +are deprecated. It is advised to use the script rauc-flash-nand provided +in the Linux environment with PHYTEC’s distribution Ampliphy.

+
+

With raw NAND flash the kernel, device tree, and root filesystem are written +individually. Initialize the NAND flash with the correct volumes from a Linux on +the target:

+
target:~$ rauc-flash-nand -k /path/to/zImage -d /path/to/oftree -r /path/to/root.ubifs
+
+
+

The initialization script will automatically utilize all available space of NAND +flash. The NAND device is also determined automatically by finding the device +root in /proc/mtd.

+

On i.MX6 and i.MX6UL devices with barebox, use bbu (barebox update) to flash the +bootloader:

+
target:~$ bbu.sh -f /path/to/barebox.bin
+
+
+

The A/B system on NAND Flash is now ready to be booted.

+
+
+
+

4.2. Bootloader

+
+

4.2.1. Booting the A/B System by Default

+

Booting the A/B system is done mostly automatically by the bootloader since the +Yocto release hardknott. For devices with eMMC flash storage, the +corresponding setting is written into the bootloader environment during the +building of the BSP. In particular, if the distribution ampliphy-rauc or +ampliphy-vendor-rauc is used, as described previously, the bootloader should +automatically start the A/B system and have the variables set for RAUC +accordingly.

+

This automatic setting can be manually changed by setting one variable in the +bootloader. The procedure is described in more detail in the following chapters +for U-Boot and barebox.

+
+
+

4.2.2. U-Boot

+

After a successful boot into a Linux environment, this command is used to view +the available parameters:

+
target:~$ fw_printenv
+
+
+

You may see this parameter along with others in the output:

+
doraucboot=1
+
+
+

To manually disable or enable booting the A/B system with RAUC, set this +variable to 0 or 1:

+
target:~$ fw_setenv doraucboot 1
+
+
+

This parameter can also be edited in U-Boot. Restart your board and hit any key +to stop the automatic boot. The environment variables can now be viewed:

+
u-boot=> printenv
+
+
+

and set:

+
u-boot=> setenv doraucboot 1
+u-boot=> saveenv
+
+
+
+
+

4.2.3. Barebox

+

In barebox, the system to be booted can be selected directly by its name. To +boot the A/B system, including RAUC, bootchooser is used. To boot e.g. a +regular SD card without RAUC use mmc instead, or nand for NAND devices:

+
barebox$ nv boot.default=bootchooser
+
+
+
+
+
+
+

5. Creating RAUC Bundles

+

To update your system with RAUC, a RAUC bundle (.raucb) needs to be created. +It contains all required images and scripts for the update and a RAUC +manifest.raucm that describes the content of the bundle for the RAUC update +on the target. The BSP includes a Yocto target that lets you build a RAUC bundle +from your Yocto build.

+

To create the bundle with Yocto, run the following in build/ with the +distribution ampliphy-rauc or ampliphy-vendor-rauc set up, as described +previously:

+
host:~$ bitbake phytec-headless-bundle
+
+
+

This results in the creation of a .raucb bundle file in +deploy/images/<MACHINE>/ which can be used for updating the system as +described later. There is no need to create a manifest.raucm manually as it +is created automatically during the build of the bundle. As a reference, the +created manifest would look something like this:

+
+
manifest.raucm
+
[update]
+compatible=phyboard-polis-imx8mm-3
+version=r0
+description=PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0
+build=20200624074335
+
+[image.rootfs]
+sha256=cc3f65cd1c1993951d7a39bdb7b7d723617ac46460f8b640cd8d1622ad6e4c17
+size=99942000
+filename=phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz
+
+[image.boot]
+sha256=bafe46679af8c6292dba22b9d402e3119ef78c6f8b458bcb6993326060de3aa4
+size=12410534
+filename=boot.tar.gz.img
+
+
+
+

For more information about the manifest format, see +https://rauc.readthedocs.io/en/latest/reference.html#manifest.

+
+
+

6. Updating with RAUC

+

To update the target system with RAUC, the RAUC bundle file previously created +first needs to be copied to the board or to a memory device that can be mounted +in Linux. One way is to copy the bundle file with scp, but this requires +enough space left on the board’s filesystem. To do this, boot the target board +to Linux and connect it via Ethernet to your host PC.

+

On the host, run:

+
host:~$ scp phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb root@192.168.3.11:/tmp/
+
+
+

On the target, the bundle can be verified:

+
target:~$ rauc info /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+
+
+

and the output should look similar to this:

+
rauc-Message: 12:52:49.821: Reading bundle: /phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+rauc-Message: 12:52:49.830: Verifying bundle...
+Compatible:     'phyboard-polis-imx8mm-3'
+Version:        'r0'
+Description:    'PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0'
+Build:          '20200624073212'
+Hooks:          ''
+2 Images:
+(1)     phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz
+        Slotclass: rootfs
+        Checksum:  342f67f7678d7af3f77710e1b68979f638c7f4d20393f6ffd0c36beff2789070
+        Size:      180407809
+        Hooks:
+(2)     boot.tar.gz.img
+        Slotclass: boot
+        Checksum:  8c84465b4715cc142eca2785fea09804bd970755142c9ff57e08c791e2b71f28
+        Size:      12411786
+        Hooks:
+0 Files
+
+Certificate Chain:
+ 0 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH Development-1
+   Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   SPKI sha256: E2:47:5F:32:05:37:04:D4:8C:48:8D:A6:74:A8:21:2E:97:41:EE:88:74:B5:F4:65:75:97:76:1D:FF:1D:7B:EE
+   Not Before: Jan  1 00:00:00 1970 GMT
+   Not After:  Dec 31 23:59:59 9999 GMT
+ 1 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   SPKI sha256: AB:5C:DB:C6:0A:ED:A4:48:B9:40:AC:B1:48:06:AA:BA:92:09:83:8C:DC:6F:E1:5F:B6:FB:0C:39:3C:3B:E6:A2
+   Not Before: Jan  1 00:00:00 1970 GMT
+   Not After:  Dec 31 23:59:59 9999 GMT
+
+
+

To check the current state of the system, run:

+
target:~$ rauc status
+
+
+

and get output similar to this:

+
=== System Info ===
+Compatible:  phyboard-segin-imx6ul-6
+Variant:
+Booted from: rootfs.0 (system0)
+
+=== Bootloader ===
+Activated: rootfs.0 (system0)
+
+=== Slot States ===
+o [rootfs.1] (/dev/ubi0_6, ubifs, inactive)
+        bootname: system1
+        boot status: good
+    [dtb.1] (/dev/ubi0_3, ubivol, inactive)
+    [kernel.1] (/dev/ubi0_2, ubivol, inactive)
+
+x [rootfs.0] (/dev/ubi0_5, ubifs, booted)
+        bootname: system0
+        boot status: good
+    [kernel.0] (/dev/ubi0_0, ubivol, active)
+    [dtb.0] (/dev/ubi0_1, ubivol, active)
+
+
+

To update the currently inactive system with the downloaded bundle, run:

+
target:~$ rauc install /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+
+
+

and reboot afterward:

+
target:~$ reboot
+
+
+

With the success of the update, RAUC automatically switches the active system to +the newly updated system. Now during reboot, RAUC counts the boot attempts of +the kernel and if it fails more often than specified in the state framework of +the system, RAUC switches back to the old system and marks the new system as +bad. If the boot attempt to the kernel is successful, the new system is marked +as good and the old system can now be updated with the same instructions. After +two successful rauc install and reboot, both systems are updated.

+
+

Tip

+

When you update from a USB stick, make sure to remove the stick after a +successful update before rebooting. If not, an automatic update will be +started after each boot. This is due to the Automatic Update from USB Flash +Drive with RAUC you can find below.

+
+
+

6.1. Changing the Active Boot Slot

+

It is possible to switch the active system manually:

+
target:~$ rauc status mark-active other
+
+
+

After a reboot, the target now starts from the other system.

+
+
+
+

7. Switching RAUC Keyrings

+

PHYTEC’s distribution comes with keys and certificates used for development and +demonstration purposes only. To change to a different PKI when devices are +already rolled out, RAUC’s keyring must be changed. This chapter describes the +full procedure from a development state to a production state. Keep in mind, +that it is always a better idea to roll out your devices with a production +keyring in the first place, instead of relying on a development one for too +long. The following diagram shows the general process of switching keyrings for +RAUC:

+../_images/rauc-switching-keyrings.png +
+

7.1. Keyring Switching Process

+

Create new certificates and keys for your own PKI. See our security manual for a +detailed description on how to create a custom PKI. For this document, we refer +to this newly created PKI as “production”, as opposed to the existing +“development” keys.

+

Move the generated keys and certificates, to your main Yocto build directory +root, alongside with build/ and sources/.

+
+

Warning

+

Be careful where you store the private keys! These should in no way be made +publicly available. E.g. do not store the private keys in a public Git +repository. Otherwise, unauthorized entities could create RAUC bundles that +can be installed on your target system!

+
+

Now, a RAUC bundle must be created that contains the new “production” CA keyring +in its root filesystem but is still signed by the “development” CA. With this, +the system is converted from a “development” system to a “production” system. To +achieve this, exchange the file ca.cert.pem installed by the RAUC recipe in +the Yocto sources. Create a file rauc_%.bbappend in your own Yocto layer:

+
+
recipes-core/rauc/rauc_%.bbappend
+
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+RAUC_KEYRING_FILE = "${CERT_PATH}/rauc-customer/ca.cert.pem"
+
+
+
+

Build the same RAUC bundle as before, now with the exchanged keyring:

+
host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source source/poky/oe-init-build-env
+host:~$ bitbake phytec-headless-bundle  # Build the desired RAUC bundle
+
+
+

Install the resulting RAUC bundle as usual. The target now has the image with +the “production” keyring installed in its other slot (“System B” in the figure +above). Reboot to start that system.

+

All future RAUC bundles for the “production” system must now also be signed by +the “production” CA. For this, change the key and certificate to your newly +generated “production” ones in the bundle recipe:

+
+
recipes-images/bundles/customer-headless-bundle.bb
+
require phytec-base-bundle.inc
+
+RAUC_SLOT_rootfs ?= "phytec-headless-image"
+
+RAUC_KEY_FILE = "${CERT_PATH}/rauc-customer/private/production-1.key.pem"
+RAUC_CERT_FILE = "${CERT_PATH/rauc-customer/production-1.cert.pem"
+
+RAUC_INTERMEDIATE_CERT_FILE = ""
+
+
+
+

Rebuild the RAUC bundle:

+
host:~$ bitbake customer-headless-bundle
+
+
+

These and any future bundles are now ready to be installed on your “production” +target system and have been fully migrated away from the “development” system. +This also means that now only bundles signed by the “production” CA can be +installed on the target (and e.g. “development” bundles cannot).

+
+
+
+

8. Use Case Examples

+
+

8.1. Automatic Updates from USB Flash Drive with RAUC

+

One of the most prominent use cases for RAUC might be an automatic update system +from a USB flash drive. This use case is implemented in the BSP as a reference +example. We combine only standard Linux mechanisms with RAUC to build the +system. The kernel notifies udev when a device gets plugged into the USB port. +We use a custom udev rule to trigger a systemd service when this event +happens.

+
+
10-update-usb.rules
+
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"
+
+# Trigger systemd service
+ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}="update-usb@%k.service"
+
+# Exit
+LABEL="media_by_label_auto_mount_end"
+
+
+
+

The service automatically mounts the USB flash drive and notifies the +application.

+
+
update-usb@.service
+
[Unit]
+Description=usb media RAUC service
+After=multi-user.target
+Requires=rauc.service
+
+[Service]
+Type=oneshot
+Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket
+ExecStartPre=/bin/mkdir -p /media/%I
+ExecStartPre=/bin/mount -t auto /dev/%I /media/%I
+ExecStart=/usr/bin/update_usb.sh %I
+ExecStop=/bin/umount -l /media/%i
+ExecStopPost=-/bin/rmdir /media/%I
+
+
+
+

In our reference implementation, we simply use a shell script for the +application logic.

+
+
update_usb.sh
+
#!/bin/sh
+
+MOUNT=/media/$1
+
+NUMRAUCM=$(find ${MOUNT}/*.raucb -maxdepth 0 | wc -l)
+
+[ "$NUMRAUCM" -eq 0 ] && echo "${MOUNT}*.raucb not found" && exit
+[ "$NUMRAUCM" -ne 1 ] && echo "more than one ${MOUNT}/*.raucb" && exit
+
+rauc install $MOUNT/*.raucb
+if [ "$?" -ne 0 ]; then
+    echo "Failed to install RAUC bundle."
+else
+    echo "Update successful."
+fi
+exit $?
+
+
+
+

The update logic can be integrated into an application using the systemd D-Bus +API. RAUC does not need to be called by its command-line interface but can be +integrated with D-Bus.

+
+

Tip

+

RAUC features a D-Bus API interface (see +https://rauc.readthedocs.io/en/latest/using.html#using-the-d-bus-api).

+
+
+
+

8.2. Security Measurement: Downgrade Barrier

+

As a second reference example, we will implement a security mechanism: a +downgrade barrier. When you detect a security vulnerability on your system, you +will fix it and update your system. The systems with the new software will now +be secure again. If an attacker gets a hold of the old software update bundle, +which still has a valid signature, the attacker might have the possibility to +install the old software and still take advantage of the previously fixed +security vulnerability. To prevent this from happening, you could revoke the +updated certificate for every single update and create a new one. This might be +difficult to handle, depending on the environment. A simpler solution would be +to allow updates only in one direction using a version check.

+
+
rauc_downgrade_barrier.sh
+
#!/bin/sh
+
+VERSION_FILE=/etc/rauc/downgrade_barrier_version
+MANIFEST_FILE=${RAUC_UPDATE_SOURCE}/manifest.raucm
+
+[ ! -f ${VERSION_FILE} ] && exit 1
+[ ! -f ${MANIFEST_FILE} ] && exit 2
+
+VERSION=`cat ${VERSION_FILE} | cut -d 'r' -f 2`
+BUNDLE_VERSION=`grep "version" -rI ${MANIFEST_FILE} | cut -d 'r' -f 3`
+
+# check from empty or unset variables
+[ -z "${VERSION}" ] && exit 3
+[ -z "${BUNDLE_VERSION}" ] && exit 4
+
+# developer mode, allow all updates if version is r0
+#[ ${VERSION} -eq 0 ] && exit 0
+
+# downgrade barrier
+if [ ${VERSION} -gt ${BUNDLE_VERSION} ]; then
+        echo "Downgrade barrier blocked rauc update! CODE5\n"
+else
+        exit 0
+fi
+exit 5
+
+
+
+

The script is installed on the target but it is not activated. You need to +remove the developer mode line in the script to activate it.

+
+
+

8.3. Streaming Bundles over HTTP

+

Instead of copying the bundle to the device, the bundle can be streamed over +HTTP. Using bundle streaming has the advantage of not requiring local storage on +the target. A simple approach to this is running NGINX inside a Docker +container. The following example shows how to implement a minimal download +server enabling HTTP range requests to support this feature.

+

Create a Dockerfile with the following content:

+
+
Dockerfile
+
FROM nginx
+
+COPY bundles /bundles
+COPY nginx.conf /etc/nginx/nginx.conf
+
+
+
+

Configure NGINX to enable HTTP range requests and point it to the bundle file.

+
+
nginx.conf
+
events {}
+http {
+    server {
+        proxy_force_ranges on;
+
+        location / {
+            root /bundles;
+        }
+    }
+}
+
+
+
+

Place a bundle in the bundles sub-directory. The folder structure looks like +the following after creating all configuration files:

+
user@host:rauc-bundle-streaming$ find
+.
+./bundles
+./bundles/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb
+./nginx.conf
+./Dockerfile
+
+
+

Build and run the docker container on the host system:

+
host:~$ sudo docker build -t rauc-bundle-streaming .
+host:~$ sudo docker run --name bundles -p 80:80 -d rauc-bundle-streaming
+
+
+

Install the bundle on the currently inactive target partitions:

+
target:~$ rauc install http://192.168.3.10/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb
+
+
+
+

Note

+

After the update finishes the target may display the following error which +has no impact on the success of the update:

+
[ 7416.336609] block nbd0: NBD_DISCONNECT
+[ 7416.340413] block nbd0: Send disconnect failed -32
+
+
+
+
+
+
+

9. Reference

+
+

9.1. Boot Logic Implementation

+
+

Tip

+

The implementation details described in this chapter serve as a reference +guide. PHYTEC BSPs that have RAUC support include these by default and the +changes are already incorporated.

+
+
+

9.1.1. U-Boot Environment Variables

+

For U-Boot, the boot logic that selects the correct partitions to boot from is +implemented in its environment. As a reference, these are the most important +U-Boot variables that are used for the A/B system with RAUC:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Function

BOOT_ORDER

Contains a space-separated list of boot targets in the +order they should be tried. This parameter is +automatically set by RAUC.

BOOT_<slot>_LEFT

Contains the number of remaining boot attempts to +perform for the respective slot. This parameter is +automatically set by RAUC.

raucinit

Contains the boot logic that sets the partitions so +the correct system is loaded.

doraucboot

Enables booting the A/B system if set to 1 and +disables it if set to 0.

raucargs

Sets the Kernel bootargs like console, root, and RAUC +slot.

raucrootpart

Sets the root filesystem partitions of the device.

raucbootpart

Sets the boot partitions of the device.

+

These environment variables are defined in include/environment/phytec/rauc.env in +the u-boot source code.

+
+

Note

+

A change in the partition layout, e.g. when using an additional data +partition, may require changing the variables raucrootpart and +raucbootpart. Make sure to rebuild your image with the new bootloader +environment after you have made the appropriate changes.

+
+
+
+

9.1.2. Barebox Bootchooser Framework

+

For the barebox, the boot logic that selects the correct partitions to boot from +is implemented using the bootchooser and state framework. See the barebox +documentation for detailed information about these: Barebox Bootchooser +Framework, Barebox +State Framework.

+

First, the state framework configuration needs to be added to the barebox device +tree. Check out the Customizing the BSP +chapter in the Yocto reference manual. The state framework configuration is +already included with our BSP for the supported SoC and can be directly included +in the main barebox device tree. E.g. for i.MX6 based module:

+
#include "imx6qdl-phytec-state.dtsi"
+
+
+

Afterward, rebuild the image and flash the new bootloader.

+
+

Warning

+

Be aware that by adding the state framework configuration, the first 160 +bytes of the EEPROM are occupied and can no longer be used for user-specific +purposes.

+
+

The following device tree snippet shows an example of the state framework +configuration used with the BSP. As can be seen, the EEPROM is used as a backend +for the state information:

+
/ {
+    aliases {
+        state = &state;
+    };
+
+    state: imx6qdl_phytec_boot_state {
+        magic = <0x883b86a6>;
+        compatible = "barebox,state";
+        backend-type = "raw";
+        backend = <&backend_update_eeprom>;
+        backend-stridesize = <54>;
+
+        #address-cells = <1>;
+        #size-cells = <1>;
+        bootstate {
+            #address-cells = <1>;
+            #size-cells = <1>;
+            last_chosen {
+                reg = <0x0 0x4>;
+                type = "uint32";
+            };
+            system0 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                remaining_attempts {
+                    reg = <0x4 0x4>;
+                    type = "uint32";
+                    default = <3>;
+                };
+                priority {
+                    reg = <0x8 0x4>;
+                    type = "uint32";
+                    default = <21>;
+                };
+                ok {
+                    reg = <0xc 0x4>;
+                    type = "uint32";
+                    default = <0>;
+                };
+            };
+            system1 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                remaining_attempts {
+                    reg = <0x10 0x4>;
+                    type = "uint32";
+                    default = <3>;
+                };
+                priority {
+                    reg = <0x14 0x4>;
+                    type = "uint32";
+                    default = <20>;
+                };
+                ok {
+                    reg = <0x18 0x4>;
+                    type = "uint32";
+                    default = <0>;
+                };
+            };
+        };
+    };
+};
+
+&eeprom {
+    status = "okay";
+    partitions {
+        compatible = "fixed-partitions";
+        #size-cells = <1>;
+        #address-cells = <1>;
+        backend_update_eeprom: state@0 {
+            reg = <0x0 0x100>;
+            label = "update-eeprom";
+        };
+    };
+};
+
+
+

To be able to boot from two systems alternately, the bootchooser needs to be +aware of the state framework configuration. For each system, a boot script is +required. For a system with NAND flash, the boot script of the first system may +look like the following:

+
+
/env/boot/system0
+
#!/bin/sh
+
+[ -e /env/config-expansions ] && /env/config-expansions
+
+[ ! -e /dev/nand0.root.ubi ] && ubiattach /dev/nand0.root
+
+global.bootm.image="/dev/nand0.root.ubi.kernel0"
+global.bootm.oftree="/dev/nand0.root.ubi.oftree0"
+global.linux.bootargs.dyn.root="root=ubi0:root0 ubi.mtd=root rootfstype=ubifs"
+
+
+
+

The second boot script has the same structure but uses the partitions containing +the second system. Machines with eMMC flash use similar boot scripts, albeit the +mounting and boot arguments look different.

+

Run the following commands to create the required bootchooser non-volatile +environment variables:

+
barebox$ nv bootchooser.state_prefix=state.bootstate
+barebox$ nv bootchooser.system0.boot=system0
+barebox$ nv bootchooser.system1.boot=system1
+barebox$ nv bootchooser.targets="system0 system1"
+
+
+
+
+
+

9.2. eMMC Boot Partitions

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader.

+

By default, bundles built with our BSP (e.g. phytec-headless-bundle) contain +the bootloader for updating eMMC boot partitions accordingly.

+

Note, that the U-Boot environment still resides in the user area before the +first partition. The user area also still contains the bootloader which the +image first shipped during its initialization process.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=imx-boot of=/dev/mmcblk2boot0 bs=1k seek=33
+target:~$ dd if=imx-boot of=/dev/mmcblk2boot1 bs=1k seek=33
+
+
+

This example is valid for the i.MX 8M Mini SoC. Note, that other SoCs may have +different bootloader files and require different offsets where the bootloader is +expected, specified by the seek parameter. See the following table for the +different offsets being required by each SoC:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

Bootloader

i.MX 6

1 kiB

0 kiB

/dev/mmcblk3

barebox.bin

i.MX 6UL

1 kiB

0 kiB

/dev/mmcblk1

barebox.bin

i.MX 8M

33 kiB

33 kiB

/dev/mmcblk0

imx-boot

i.MX 8M Mini

33 kiB

33 kiB

/dev/mmcblk2

imx-boot

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

i.MX 93

32 kiB

0 kiB

/dev/mmcblk0

imx-boot

AM62x +AM62Ax +AM64x

N/A

0 kiB +512 kiB +2560 kiB

/dev/mmcblk0

tiboot3.bin +tispl.bin +u-boot.img

+
+

9.2.1. Bootloader Offsets

+

Note that the offset is different, depending on whether the bootloader resides +in the user area or the boot partitions of the eMMC.

+

After a bootloader has been written to the eMMC boot partitions, booting from +these can be enabled by using the following command:

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

This also means that only the bootloaders written in the eMMC boot partitions +are used. The bootloader in the user area is not used anymore. These steps are +also executed by RAUC internally when updating the target system with a bundle.

+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

After this command, the eMMC user area is used to provide the bootloader.

+

When using U-Boot, a similar command is also available in the bootloader:

+
u-boot=> mmc partconf 2 0 0 0  # disable
+u-boot=> mmc partconf 2 0 1 0  # enable
+
+
+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/rauc/scarthgap.html b/previews/271/rauc/scarthgap.html new file mode 100644 index 000000000..60992e798 --- /dev/null +++ b/previews/271/rauc/scarthgap.html @@ -0,0 +1,1239 @@ + + + + + + + + + 1. Introduction — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + +

RAUC Update & Device Management Manual

Document Title

RAUC Update & Device Management Manual Scarthgap

Document Type

RAUC Update & Device Management +Manual

Release Date

XXXX/XX/XX

Is Branch of

RAUC Update & Device Management Manual

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.0

Major

2024-04-02

released

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1

Minor

2024-04-09

released

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2

Minor

2024-06-26

released

BSP-Yocto-NXP-i.MX8MP-PD24.1.0

Major

2024-11-07

released

BSP-Yocto-NXP-i.MX93-PD24.2.0

Major

2024-10-08

released

BSP-Yocto-Ampliphy-i.MX6UL-PD24.1.0

Major

2024-07-19

released

BSP-Yocto-Ampliphy-AM62Ax-PD24.1.0

Major

2024-06-27

released

BSP-Yocto-Ampliphy-AM62x-PD24.1.0

Major

2024-06-27

released

BSP-Yocto-Ampliphy-AM64x-PD24.1.0

Major

2024-06-27

released

+

This manual was tested using the Yocto version Scarthgap.

+
+

1. Introduction

+

PHYTEC’s Yocto distribution Ampliphy (former Yogurt) supports the RAUC (Robust Auto-Update Controller) +mechanism. RAUC controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. For +eMMC devices only, it can also update the bootloader.

+

This manual describes how RAUC is used and implemented on various PHYTEC +platforms. Note, that different modules use different bootloaders and flash +storage devices, which affects the way things are handled by RAUC. Make sure to +read the correct sections fitting your platform.

+
+

Note

+

This manual contains machine-specific paths and variable contents. Make sure +you are using the correct machine and device names for your application when +executing any commands.

+
+
+
+

2. System Configuration

+

RAUC can be used with both eMMC and NAND flash storage. Using the distro +ampliphy-rauc or ampliphy-vendor-rauc, it is enabled by default and requires +no additional setup to get started. RAUC can be used in different update +scenarios. As an example, we configured the BSP to use an A/B setup to have a +completely redundant system (including the bootloader on eMMC devices). Note, +that there is an additional partition named config storing persistent +configuration data not being changed when updating.

+../_images/rauc-ab-system.png +
+

2.1. RAUC BSP Example Setup

+

The partition layout is defined in the /etc/rauc/system.conf file. As an +example, this is what it looks like for i.MX 8M Mini with eMMC flash storage:

+
+
/etc/rauc/system.conf
+
[system]
+compatible=phyboard-polis-imx8mm-4
+bootloader=uboot
+mountprefix=/mnt/rauc
+
+[handlers]
+pre-install=/usr/lib/rauc/rauc-pre-install.sh
+post-install=/usr/lib/rauc/rauc-post-install.sh
+
+[keyring]
+path=mainca-rsa.crt.pem
+
+[slot.bootloader.0]
+device=/dev/mmcblk2
+type=boot-emmc
+
+# System A
+[slot.rootfs.0]
+device=/dev/mmcblk2p5
+type=ext4
+bootname=system0
+
+[slot.boot.0]
+device=/dev/mmcblk2p1
+type=vfat
+parent=rootfs.0
+
+# System B
+[slot.rootfs.1]
+device=/dev/mmcblk2p6
+type=ext4
+bootname=system1
+
+[slot.boot.1]
+device=/dev/mmcblk2p2
+type=vfat
+parent=rootfs.1
+
+
+
+

Note, that the devices specified in the slots are different depending on the +selected machine.

+
+

Warning

+

Updates with RAUC use an OpenSSL certificate to verify the validity of an +image. The BSP includes a certificate that can be used for development. In a +productive system, however, it is highly recommended to use a self-created +key and certificate. If you need to change the keyring on an existing device, +see Switching RAUC Keyrings for more +information.

+
+
+
+
+

3. Design Considerations

+

In order to prevent the system from locking up, it may be a good idea to utilize +a hardware watchdog. In case the Linux Kernel does not boot or another +catastrophic event occurs that prevents the system from operating normally, the +hardware watchdog then resets the system. By default, the hardware watchdog is +disabled. To enable it, refer to the corresponding BSP manual that fits your +SoM.

+

Other important design considerations, as well as a checklist, can be found in +the official RAUC documentation: +https://rauc.readthedocs.io/en/latest/checklist.html

+
+
+

4. Initial Setup

+

To use RAUC, the flash device needs to be written with a complete Linux system +and bootloader. The preferred method to do this is using the included tool +partup.

+
+

4.1. Flash Storage

+

To flash the device with the correct partitions/volumes, use a partup package +built with the ampliphy-rauc or ampliphy-vendor-rauc distribution. +Prebuilt partup packages can be found in the BSP release. It is also possible to +build an image with this distribution yourself using Yocto. Separate build +directories are created, storing the images and packages for the RAUC system. +Initialize the build directory with the OE init script:

+
host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source sources/poky/oe-init-build-env
+
+
+

Change the distribution to ampliphy-rauc (for i.MX6, AM6x, i.MX8 mainline BSP) or +ampliphy-vendor-rauc (for i.MX8, i.MX9 vendor BSP):

+
+
build/conf/local.conf
+
DISTRO ?= "ampliphy-rauc"
+
+
+
+

Any image built with this distro now includes a full A/B system. Build the image +as usual:

+
host:~$ bitbake phytec-headless-image
+
+
+

The resulting partup package is stored in the deploy-ampliphy-vendor-rauc directory, e.g.:

+
deploy-ampliphy-vendor-rauc/images/phyboard-segin-imx93-2/phytec-headless-image-phyboard-segin-imx93-2.partup
+
+
+

This partup package contains all the necessary data and configuration to flash +an eMMC. Partup can be obtained from its +release page. Also, see its +README for detailed installation instructions. Partup is already installed +in our Ampliphy images, phytec-headless-image and can be directly used e.g. +from an SD card.

+
+

Note

+

To flash the initial RAUC system, a booted non-RAUC system is needed first on +a different flash device. E.g. you could boot a regular +phytec-headless-image image with distro ampliphy from an SD card.

+
+
+

4.1.1. eMMC

+

While running a non-RAUC system from an SD card on the target, copy the +.partup package built with distro ampliphy-rauc or +ampliphy-vendor-rauc to the running target first:

+
host:~$ scp phytec-headless-image-phyboard-segin-imx93-2.partup 192.168.3.11:/root
+
+
+

Then install the partup package to the eMMC:

+
target:~$ partup install phytec-headless-image-phyboard-segin-imx93-2.partup /dev/mmcblk0
+
+
+

Now the target can boot the flashed A/B system.

+
+
+

4.1.2. NAND

+
+

Note

+

There are scripts provided with the bootloader barebox that previously were +used to initialize NAND flash with an A/B system: rauc_init_nand, +rauc_flash_nand_from_tftp and rauc_flash_nand_from_mmc. These scripts +are deprecated. It is advised to use the script rauc-flash-nand provided +in the Linux environment with PHYTEC’s distribution Ampliphy.

+
+

With raw NAND flash the kernel, device tree, and root filesystem are written +individually. Initialize the NAND flash with the correct volumes from a Linux on +the target:

+
target:~$ rauc-flash-nand -k /path/to/zImage -d /path/to/oftree -r /path/to/root.ubifs
+
+
+

The initialization script will automatically utilize all available space of NAND +flash. The NAND device is also determined automatically by finding the device +root in /proc/mtd.

+

On i.MX6 and i.MX6UL devices with barebox, use bbu (barebox update) to flash the +bootloader:

+
target:~$ bbu.sh -f /path/to/barebox.bin
+
+
+

The A/B system on NAND Flash is now ready to be booted.

+
+
+
+

4.2. Bootloader

+
+

4.2.1. Booting the A/B System by Default

+

Booting the A/B system is done mostly automatically by the bootloader since the +Yocto release hardknott. For devices with eMMC flash storage, the +corresponding setting is written into the bootloader environment during the +building of the BSP. In particular, if the distribution ampliphy-rauc or +ampliphy-vendor-rauc is used, as described previously, the bootloader should +automatically start the A/B system and have the variables set for RAUC +accordingly.

+

This automatic setting can be manually changed by setting one variable in the +bootloader. The procedure is described in more detail in the following chapters +for U-Boot and barebox.

+
+
+

4.2.2. U-Boot

+

After a successful boot into a Linux environment, this command is used to view +the available parameters:

+
target:~$ fw_printenv
+
+
+

You may see this parameter along with others in the output:

+
doraucboot=1
+
+
+

To manually disable or enable booting the A/B system with RAUC, set this +variable to 0 or 1:

+
target:~$ fw_setenv doraucboot 1
+
+
+

This parameter can also be edited in U-Boot. Restart your board and hit any key +to stop the automatic boot. The environment variables can now be viewed:

+
u-boot=> printenv
+
+
+

and set:

+
u-boot=> setenv doraucboot 1
+u-boot=> saveenv
+
+
+
+
+

4.2.3. Barebox

+

In barebox, the system to be booted can be selected directly by its name. To +boot the A/B system, including RAUC, bootchooser is used. To boot e.g. a +regular SD card without RAUC use mmc instead, or nand for NAND devices:

+
barebox$ nv boot.default=bootchooser
+
+
+
+
+
+
+

5. Creating RAUC Bundles

+

To update your system with RAUC, a RAUC bundle (.raucb) needs to be created. +It contains all required images and scripts for the update and a RAUC +manifest.raucm that describes the content of the bundle for the RAUC update +on the target. The BSP includes a Yocto target that lets you build a RAUC bundle +from your Yocto build.

+

To create the bundle with Yocto, run the following in build/ with the +distribution ampliphy-rauc or ampliphy-vendor-rauc set up, as described +previously:

+
host:~$ bitbake phytec-headless-bundle
+
+
+

This results in the creation of a .raucb bundle file in +deploy/images/<MACHINE>/ which can be used for updating the system as +described later. There is no need to create a manifest.raucm manually as it +is created automatically during the build of the bundle. As a reference, the +created manifest would look something like this:

+
+
manifest.raucm
+
[update]
+compatible=phyboard-polis-imx8mm-3
+version=r0
+description=PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0
+build=20200624074335
+
+[image.rootfs]
+sha256=cc3f65cd1c1993951d7a39bdb7b7d723617ac46460f8b640cd8d1622ad6e4c17
+size=99942000
+filename=phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz
+
+[image.boot]
+sha256=bafe46679af8c6292dba22b9d402e3119ef78c6f8b458bcb6993326060de3aa4
+size=12410534
+filename=boot.tar.gz.img
+
+
+
+

For more information about the manifest format, see +https://rauc.readthedocs.io/en/latest/reference.html#manifest.

+
+

5.1. Creating transition bundles

+

Updating to a new major release can require a special RAUC bundle.

+

When updating to a Scarthgap based release, add the following to your +local.conf and rebuild the RAUC bundle:

+
+
build/conf/local.conf
+
RAUC_IMAGE_FSTYPE = "tar.gz"
+RAUC_SLOT_rootfs[adaptive] = ""
+
+
+
+
+
+
+

6. Updating with RAUC

+

To update the target system with RAUC, the RAUC bundle file previously created +first needs to be copied to the board or to a memory device that can be mounted +in Linux. One way is to copy the bundle file with scp, but this requires +enough space left on the board’s filesystem. To do this, boot the target board +to Linux and connect it via Ethernet to your host PC.

+

On the host, run:

+
host:~$ scp phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb root@192.168.3.11:/tmp/
+
+
+

On the target, the bundle can be verified:

+
target:~$ rauc info /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+
+
+

and the output should look similar to this:

+
rauc-Message: 12:52:49.821: Reading bundle: /phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+rauc-Message: 12:52:49.830: Verifying bundle...
+Compatible:     'phyboard-polis-imx8mm-3'
+Version:        'r0'
+Description:    'PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0'
+Build:          '20200624073212'
+Hooks:          ''
+2 Images:
+(1)     phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz
+        Slotclass: rootfs
+        Checksum:  342f67f7678d7af3f77710e1b68979f638c7f4d20393f6ffd0c36beff2789070
+        Size:      180407809
+        Hooks:
+(2)     boot.tar.gz.img
+        Slotclass: boot
+        Checksum:  8c84465b4715cc142eca2785fea09804bd970755142c9ff57e08c791e2b71f28
+        Size:      12411786
+        Hooks:
+0 Files
+
+Certificate Chain:
+ 0 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH Development-1
+   Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   SPKI sha256: E2:47:5F:32:05:37:04:D4:8C:48:8D:A6:74:A8:21:2E:97:41:EE:88:74:B5:F4:65:75:97:76:1D:FF:1D:7B:EE
+   Not Before: Jan  1 00:00:00 1970 GMT
+   Not After:  Dec 31 23:59:59 9999 GMT
+ 1 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   SPKI sha256: AB:5C:DB:C6:0A:ED:A4:48:B9:40:AC:B1:48:06:AA:BA:92:09:83:8C:DC:6F:E1:5F:B6:FB:0C:39:3C:3B:E6:A2
+   Not Before: Jan  1 00:00:00 1970 GMT
+   Not After:  Dec 31 23:59:59 9999 GMT
+
+
+

To check the current state of the system, run:

+
target:~$ rauc status
+
+
+

and get output similar to this:

+
=== System Info ===
+Compatible:  phyboard-segin-imx6ul-6
+Variant:
+Booted from: rootfs.0 (system0)
+
+=== Bootloader ===
+Activated: rootfs.0 (system0)
+
+=== Slot States ===
+o [rootfs.1] (/dev/ubi0_6, ubifs, inactive)
+        bootname: system1
+        boot status: good
+    [dtb.1] (/dev/ubi0_3, ubivol, inactive)
+    [kernel.1] (/dev/ubi0_2, ubivol, inactive)
+
+x [rootfs.0] (/dev/ubi0_5, ubifs, booted)
+        bootname: system0
+        boot status: good
+    [kernel.0] (/dev/ubi0_0, ubivol, active)
+    [dtb.0] (/dev/ubi0_1, ubivol, active)
+
+
+

To update the currently inactive system with the downloaded bundle, run:

+
target:~$ rauc install /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+
+
+

and reboot afterward:

+
target:~$ reboot
+
+
+

With the success of the update, RAUC automatically switches the active system to +the newly updated system. Now during reboot, RAUC counts the boot attempts of +the kernel and if it fails more often than specified in the state framework of +the system, RAUC switches back to the old system and marks the new system as +bad. If the boot attempt to the kernel is successful, the new system is marked +as good and the old system can now be updated with the same instructions. After +two successful rauc install and reboot, both systems are updated.

+
+

Tip

+

When you update from a USB stick, make sure to remove the stick after a +successful update before rebooting. If not, an automatic update will be +started after each boot. This is due to the Automatic Update from USB Flash +Drive with RAUC you can find below.

+
+
+

6.1. Changing the Active Boot Slot

+

It is possible to switch the active system manually:

+
target:~$ rauc status mark-active other
+
+
+

After a reboot, the target now starts from the other system.

+
+
+
+

7. Switching RAUC Keyrings

+

PHYTEC’s distribution comes with keys and certificates used for development and +demonstration purposes only. To change to a different PKI when devices are +already rolled out, RAUC’s keyring must be changed. This chapter describes the +full procedure from a development state to a production state. Keep in mind, +that it is always a better idea to roll out your devices with a production +keyring in the first place, instead of relying on a development one for too +long. The following diagram shows the general process of switching keyrings for +RAUC:

+../_images/rauc-switching-keyrings.png +
+

7.1. Keyring Switching Process

+

Create new certificates and keys for your own PKI. See our security manual for a +detailed description on how to create a custom PKI. For this document, we refer +to this newly created PKI as “production”, as opposed to the existing +“development” keys.

+

Move the generated keys and certificates, to your main Yocto build directory +root, alongside with build/ and sources/.

+
+

Warning

+

Be careful where you store the private keys! These should in no way be made +publicly available. E.g. do not store the private keys in a public Git +repository. Otherwise, unauthorized entities could create RAUC bundles that +can be installed on your target system!

+
+

Now, a RAUC bundle must be created that contains the new “production” CA keyring +in its root filesystem but is still signed by the “development” CA. With this, +the system is converted from a “development” system to a “production” system. To +achieve this, exchange the file ca.cert.pem installed by the RAUC recipe in +the Yocto sources. Create a file rauc_%.bbappend in your own Yocto layer:

+
+
recipes-core/rauc/rauc_%.bbappend
+
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+RAUC_KEYRING_FILE = "${CERT_PATH}/rauc-customer/ca.cert.pem"
+
+
+
+

Build the same RAUC bundle as before, now with the exchanged keyring:

+
host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source source/poky/oe-init-build-env
+host:~$ bitbake phytec-headless-bundle  # Build the desired RAUC bundle
+
+
+

Install the resulting RAUC bundle as usual. The target now has the image with +the “production” keyring installed in its other slot (“System B” in the figure +above). Reboot to start that system.

+

All future RAUC bundles for the “production” system must now also be signed by +the “production” CA. For this, change the key and certificate to your newly +generated “production” ones in the bundle recipe:

+
+
recipes-images/bundles/customer-headless-bundle.bb
+
require phytec-base-bundle.inc
+
+RAUC_SLOT_rootfs ?= "phytec-headless-image"
+
+RAUC_KEY_FILE = "${CERT_PATH}/rauc-customer/private/production-1.key.pem"
+RAUC_CERT_FILE = "${CERT_PATH/rauc-customer/production-1.cert.pem"
+
+RAUC_INTERMEDIATE_CERT_FILE = ""
+
+
+
+

Rebuild the RAUC bundle:

+
host:~$ bitbake customer-headless-bundle
+
+
+

These and any future bundles are now ready to be installed on your “production” +target system and have been fully migrated away from the “development” system. +This also means that now only bundles signed by the “production” CA can be +installed on the target (and e.g. “development” bundles cannot).

+
+
+
+

8. Use Case Examples

+
+

8.1. Automatic Updates from USB Flash Drive with RAUC

+

One of the most prominent use cases for RAUC might be an automatic update system +from a USB flash drive. This use case is implemented in the BSP as a reference +example. We combine only standard Linux mechanisms with RAUC to build the +system. The kernel notifies udev when a device gets plugged into the USB port. +We use a custom udev rule to trigger a systemd service when this event +happens.

+
+
10-update-usb.rules
+
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"
+
+# Trigger systemd service
+ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}="update-usb@%k.service"
+
+# Exit
+LABEL="media_by_label_auto_mount_end"
+
+
+
+

The service automatically mounts the USB flash drive and notifies the +application.

+
+
update-usb@.service
+
[Unit]
+Description=usb media RAUC service
+After=multi-user.target
+Requires=rauc.service
+
+[Service]
+Type=oneshot
+Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket
+ExecStartPre=/bin/mkdir -p /media/%I
+ExecStartPre=/bin/mount -t auto /dev/%I /media/%I
+ExecStart=/usr/bin/update_usb.sh %I
+ExecStop=/bin/umount -l /media/%i
+ExecStopPost=-/bin/rmdir /media/%I
+
+
+
+

In our reference implementation, we simply use a shell script for the +application logic.

+
+
update_usb.sh
+
#!/bin/sh
+
+MOUNT=/media/$1
+
+NUMRAUCM=$(find ${MOUNT}/*.raucb -maxdepth 0 | wc -l)
+
+[ "$NUMRAUCM" -eq 0 ] && echo "${MOUNT}*.raucb not found" && exit
+[ "$NUMRAUCM" -ne 1 ] && echo "more than one ${MOUNT}/*.raucb" && exit
+
+rauc install $MOUNT/*.raucb
+if [ "$?" -ne 0 ]; then
+    echo "Failed to install RAUC bundle."
+else
+    echo "Update successful."
+fi
+exit $?
+
+
+
+

The update logic can be integrated into an application using the systemd D-Bus +API. RAUC does not need to be called by its command-line interface but can be +integrated with D-Bus.

+
+

Tip

+

RAUC features a D-Bus API interface (see +https://rauc.readthedocs.io/en/latest/using.html#using-the-d-bus-api).

+
+
+
+

8.2. Security Measurement: Downgrade Barrier

+

As a second reference example, we will implement a security mechanism: a +downgrade barrier. When you detect a security vulnerability on your system, you +will fix it and update your system. The systems with the new software will now +be secure again. If an attacker gets a hold of the old software update bundle, +which still has a valid signature, the attacker might have the possibility to +install the old software and still take advantage of the previously fixed +security vulnerability. To prevent this from happening, you could revoke the +updated certificate for every single update and create a new one. This might be +difficult to handle, depending on the environment. A simpler solution would be +to allow updates only in one direction using a version check.

+
+
rauc_downgrade_barrier.sh
+
#!/bin/sh
+
+VERSION_FILE=/etc/rauc/downgrade_barrier_version
+MANIFEST_FILE=${RAUC_UPDATE_SOURCE}/manifest.raucm
+
+[ ! -f ${VERSION_FILE} ] && exit 1
+[ ! -f ${MANIFEST_FILE} ] && exit 2
+
+VERSION=`cat ${VERSION_FILE} | cut -d 'r' -f 2`
+BUNDLE_VERSION=`grep "version" -rI ${MANIFEST_FILE} | cut -d 'r' -f 3`
+
+# check from empty or unset variables
+[ -z "${VERSION}" ] && exit 3
+[ -z "${BUNDLE_VERSION}" ] && exit 4
+
+# developer mode, allow all updates if version is r0
+#[ ${VERSION} -eq 0 ] && exit 0
+
+# downgrade barrier
+if [ ${VERSION} -gt ${BUNDLE_VERSION} ]; then
+        echo "Downgrade barrier blocked rauc update! CODE5\n"
+else
+        exit 0
+fi
+exit 5
+
+
+
+

The script is installed on the target but it is not activated. You need to +remove the developer mode line in the script to activate it.

+
+
+

8.3. Streaming Bundles over HTTP

+

Instead of copying the bundle to the device, the bundle can be streamed over +HTTP. Using bundle streaming has the advantage of not requiring local storage on +the target. A simple approach to this is running NGINX inside a Docker +container. The following example shows how to implement a minimal download +server enabling HTTP range requests to support this feature.

+

Create a Dockerfile with the following content:

+
+
Dockerfile
+
FROM nginx
+
+COPY bundles /bundles
+COPY nginx.conf /etc/nginx/nginx.conf
+
+
+
+

Configure NGINX to enable HTTP range requests and point it to the bundle file.

+
+
nginx.conf
+
events {}
+http {
+    server {
+        proxy_force_ranges on;
+
+        location / {
+            root /bundles;
+        }
+    }
+}
+
+
+
+

Place a bundle in the bundles sub-directory. The folder structure looks like +the following after creating all configuration files:

+
user@host:rauc-bundle-streaming$ find
+.
+./bundles
+./bundles/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb
+./nginx.conf
+./Dockerfile
+
+
+

Build and run the docker container on the host system:

+
host:~$ sudo docker build -t rauc-bundle-streaming .
+host:~$ sudo docker run --name bundles -p 80:80 -d rauc-bundle-streaming
+
+
+

Install the bundle on the currently inactive target partitions:

+
target:~$ rauc install http://192.168.3.10/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb
+
+
+
+

Note

+

After the update finishes the target may display the following error which +has no impact on the success of the update:

+
[ 7416.336609] block nbd0: NBD_DISCONNECT
+[ 7416.340413] block nbd0: Send disconnect failed -32
+
+
+
+
+
+
+

9. Reference

+
+

9.1. Boot Logic Implementation

+
+

Tip

+

The implementation details described in this chapter serve as a reference +guide. PHYTEC BSPs that have RAUC support include these by default and the +changes are already incorporated.

+
+
+

9.1.1. U-Boot Environment Variables

+

For U-Boot, the boot logic that selects the correct partitions to boot from is +implemented in its environment. As a reference, these are the most important +U-Boot variables that are used for the A/B system with RAUC:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Function

BOOT_ORDER

Contains a space-separated list of boot targets in the +order they should be tried. This parameter is +automatically set by RAUC.

BOOT_<slot>_LEFT

Contains the number of remaining boot attempts to +perform for the respective slot. This parameter is +automatically set by RAUC.

raucinit

Contains the boot logic that sets the partitions so +the correct system is loaded.

doraucboot

Enables booting the A/B system if set to 1 and +disables it if set to 0.

raucargs

Sets the Kernel bootargs like console, root, and RAUC +slot.

raucrootpart

Sets the root filesystem partitions of the device.

raucbootpart

Sets the boot partitions of the device.

+

These environment variables are defined in include/env/phytec/rauc.env in +the u-boot source code.

+
+

Note

+

A change in the partition layout, e.g. when using an additional data +partition, may require changing the variables raucrootpart and +raucbootpart. Make sure to rebuild your image with the new bootloader +environment after you have made the appropriate changes.

+
+
+
+

9.1.2. Barebox Bootchooser Framework

+

For the barebox, the boot logic that selects the correct partitions to boot from +is implemented using the bootchooser and state framework. See the barebox +documentation for detailed information about these: Barebox Bootchooser +Framework, Barebox +State Framework.

+

First, the state framework configuration needs to be added to the barebox device +tree. Check out the Customizing the BSP +chapter in the Yocto reference manual. The state framework configuration is +already included with our BSP for the supported SoC and can be directly included +in the main barebox device tree. E.g. for i.MX6 based module:

+
#include "imx6qdl-phytec-state.dtsi"
+
+
+

Afterward, rebuild the image and flash the new bootloader.

+
+

Warning

+

Be aware that by adding the state framework configuration, the first 160 +bytes of the EEPROM are occupied and can no longer be used for user-specific +purposes.

+
+

The following device tree snippet shows an example of the state framework +configuration used with the BSP. As can be seen, the EEPROM is used as a backend +for the state information:

+
/ {
+    aliases {
+        state = &state;
+    };
+
+    state: imx6qdl_phytec_boot_state {
+        magic = <0x883b86a6>;
+        compatible = "barebox,state";
+        backend-type = "raw";
+        backend = <&backend_update_eeprom>;
+        backend-stridesize = <54>;
+
+        #address-cells = <1>;
+        #size-cells = <1>;
+        bootstate {
+            #address-cells = <1>;
+            #size-cells = <1>;
+            last_chosen {
+                reg = <0x0 0x4>;
+                type = "uint32";
+            };
+            system0 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                remaining_attempts {
+                    reg = <0x4 0x4>;
+                    type = "uint32";
+                    default = <3>;
+                };
+                priority {
+                    reg = <0x8 0x4>;
+                    type = "uint32";
+                    default = <21>;
+                };
+                ok {
+                    reg = <0xc 0x4>;
+                    type = "uint32";
+                    default = <0>;
+                };
+            };
+            system1 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                remaining_attempts {
+                    reg = <0x10 0x4>;
+                    type = "uint32";
+                    default = <3>;
+                };
+                priority {
+                    reg = <0x14 0x4>;
+                    type = "uint32";
+                    default = <20>;
+                };
+                ok {
+                    reg = <0x18 0x4>;
+                    type = "uint32";
+                    default = <0>;
+                };
+            };
+        };
+    };
+};
+
+&eeprom {
+    status = "okay";
+    partitions {
+        compatible = "fixed-partitions";
+        #size-cells = <1>;
+        #address-cells = <1>;
+        backend_update_eeprom: state@0 {
+            reg = <0x0 0x100>;
+            label = "update-eeprom";
+        };
+    };
+};
+
+
+

To be able to boot from two systems alternately, the bootchooser needs to be +aware of the state framework configuration. For each system, a boot script is +required. For a system with NAND flash, the boot script of the first system may +look like the following:

+
+
/env/boot/system0
+
#!/bin/sh
+
+[ -e /env/config-expansions ] && /env/config-expansions
+
+[ ! -e /dev/nand0.root.ubi ] && ubiattach /dev/nand0.root
+
+global.bootm.image="/dev/nand0.root.ubi.kernel0"
+global.bootm.oftree="/dev/nand0.root.ubi.oftree0"
+global.linux.bootargs.dyn.root="root=ubi0:root0 ubi.mtd=root rootfstype=ubifs"
+
+
+
+

The second boot script has the same structure but uses the partitions containing +the second system. Machines with eMMC flash use similar boot scripts, albeit the +mounting and boot arguments look different.

+

Run the following commands to create the required bootchooser non-volatile +environment variables:

+
barebox$ nv bootchooser.state_prefix=state.bootstate
+barebox$ nv bootchooser.system0.boot=system0
+barebox$ nv bootchooser.system1.boot=system1
+barebox$ nv bootchooser.targets="system0 system1"
+
+
+
+
+
+

9.2. eMMC Boot Partitions

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader.

+

By default, bundles built with our BSP (e.g. phytec-headless-bundle) contain +the bootloader for updating eMMC boot partitions accordingly.

+

Note, that the U-Boot environment still resides in the user area before the +first partition. The user area also still contains the bootloader which the +image first shipped during its initialization process.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=imx-boot of=/dev/mmcblk2boot0 bs=1k seek=33
+target:~$ dd if=imx-boot of=/dev/mmcblk2boot1 bs=1k seek=33
+
+
+

This example is valid for the i.MX 8M Mini SoC. Note, that other SoCs may have +different bootloader files and require different offsets where the bootloader is +expected, specified by the seek parameter. See the following table for the +different offsets being required by each SoC:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

Bootloader

i.MX 6

1 kiB

0 kiB

/dev/mmcblk3

barebox.bin

i.MX 6UL

1 kiB

0 kiB

/dev/mmcblk1

barebox.bin

i.MX 8M

33 kiB

33 kiB

/dev/mmcblk0

imx-boot

i.MX 8M Mini

33 kiB

33 kiB

/dev/mmcblk2

imx-boot

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

i.MX 93

32 kiB

0 kiB

/dev/mmcblk0

imx-boot

AM62x +AM62Ax +AM64x

N/A

0 kiB +512 kiB +2560 kiB

/dev/mmcblk0

tiboot3.bin +tispl.bin +u-boot.img

+
+

9.2.1. Bootloader Offsets

+

Note that the offset is different, depending on whether the bootloader resides +in the user area or the boot partitions of the eMMC.

+

After a bootloader has been written to the eMMC boot partitions, booting from +these can be enabled by using the following command:

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

This also means that only the bootloaders written in the eMMC boot partitions +are used. The bootloader in the user area is not used anymore. These steps are +also executed by RAUC internally when updating the target system with a bundle.

+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

After this command, the eMMC user area is used to provide the bootloader.

+

When using U-Boot, a similar command is also available in the bootloader:

+
u-boot=> mmc partconf 2 0 0 0  # disable
+u-boot=> mmc partconf 2 0 1 0  # enable
+
+
+
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/robots.txt b/previews/271/robots.txt new file mode 100644 index 000000000..ea27bb96d --- /dev/null +++ b/previews/271/robots.txt @@ -0,0 +1,3 @@ +User-agent: * + +Sitemap: https://phytec.github.io/doc-bsp-yocto/sitemap.xml diff --git a/previews/271/search.html b/previews/271/search.html new file mode 100644 index 000000000..600dc970d --- /dev/null +++ b/previews/271/search.html @@ -0,0 +1,152 @@ + + + + + + + + Search — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+
    +
    • +
  • Search
    • +
  • +
    • +
+
+
+
+
+ + + + +
+ +
+ +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + + + + + + \ No newline at end of file diff --git a/previews/271/searchindex.js b/previews/271/searchindex.js new file mode 100644 index 000000000..7906fad63 --- /dev/null +++ b/previews/271/searchindex.js @@ -0,0 +1 @@ +Search.setIndex({"alltitles": {"ADC": [[23, "adc"], [24, "adc"]], "ALSA configuration": [[1, "alsa-configuration"], [3, "alsa-configuration"], [4, "alsa-configuration"], [9, "alsa-configuration"], [11, "alsa-configuration"], [14, "alsa-configuration"], [15, "alsa-configuration"], [16, "alsa-configuration"], [17, "alsa-configuration"], [23, "alsa-configuration"], [24, "alsa-configuration"]], "Accessing Peripherals": [[1, "accessing-peripherals"], [3, "accessing-peripherals"], [4, "accessing-peripherals"], [5, "accessing-peripherals"], [7, "accessing-peripherals"], [8, "accessing-peripherals"], [9, "accessing-peripherals"], [11, "accessing-peripherals"], [13, "accessing-peripherals"], [14, "accessing-peripherals"], [15, "accessing-peripherals"], [16, "accessing-peripherals"], [17, "accessing-peripherals"], [18, "accessing-peripherals"], [19, "accessing-peripherals"], [22, "accessing-peripherals"], [23, "accessing-peripherals"], [24, "accessing-peripherals"]], "Accessing the Development States between Releases": [[31, "accessing-the-development-states-between-releases"], [33, "accessing-the-development-states-between-releases"], [34, "accessing-the-development-states-between-releases"]], "Accessing the Development states": [[1, "accessing-the-development-states"], [3, "accessing-the-development-states"], [4, "accessing-the-development-states"], [5, "accessing-the-development-states"], [7, "accessing-the-development-states"], [8, "accessing-the-development-states"], [9, "accessing-the-development-states"], [11, "accessing-the-development-states"], [13, "accessing-the-development-states"], [14, "accessing-the-development-states"], [15, "accessing-the-development-states"], [16, "accessing-the-development-states"], [17, "accessing-the-development-states"], [18, "accessing-the-development-states"], [19, "accessing-the-development-states"]], "Accessing the Latest Upstream Support": [[1, "accessing-the-latest-upstream-support"], [3, "accessing-the-latest-upstream-support"], [4, "accessing-the-latest-upstream-support"], [5, "accessing-the-latest-upstream-support"], [7, "accessing-the-latest-upstream-support"], [8, "accessing-the-latest-upstream-support"], [9, "accessing-the-latest-upstream-support"], [11, "accessing-the-latest-upstream-support"], [13, "accessing-the-latest-upstream-support"], [14, "accessing-the-latest-upstream-support"], [15, "accessing-the-latest-upstream-support"], [16, "accessing-the-latest-upstream-support"], [17, "accessing-the-latest-upstream-support"], [18, "accessing-the-latest-upstream-support"], [19, "accessing-the-latest-upstream-support"]], "Add Additional Software for the BSP Image": [[31, "add-additional-software-for-the-bsp-image"], [33, "add-additional-software-for-the-bsp-image"], [34, "add-additional-software-for-the-bsp-image"]], "Add Existing Software with \u201cSustainable Method\u201d": [[31, "add-existing-software-with-sustainable-method"], [33, "add-existing-software-with-sustainable-method"], [34, "add-existing-software-with-sustainable-method"]], "Add Linux Firmware Files to the Root Filesystem": [[31, "add-linux-firmware-files-to-the-root-filesystem"], [33, "add-linux-firmware-files-to-the-root-filesystem"], [34, "add-linux-firmware-files-to-the-root-filesystem"]], "Add Minimal PHP web runtime with lightpd": [[31, "add-minimal-php-web-runtime-with-lightpd"], [33, "add-minimal-php-web-runtime-with-lightpd"], [34, "add-minimal-php-web-runtime-with-lightpd"]], "Add OpenCV Libraries and Examples": [[31, "add-opencv-libraries-and-examples"], [33, "add-opencv-libraries-and-examples"], [34, "add-opencv-libraries-and-examples"]], "Add a Complete Default Configuration (defconfig) to a Recipe": [[31, "add-a-complete-default-configuration-defconfig-to-a-recipe"], [33, "add-a-complete-default-configuration-defconfig-to-a-recipe"], [34, "add-a-complete-default-configuration-defconfig-to-a-recipe"]], "Add a Configuration Fragment to a Recipe": [[31, "add-a-configuration-fragment-to-a-recipe"], [33, "add-a-configuration-fragment-to-a-recipe"], [34, "add-a-configuration-fragment-to-a-recipe"]], "Add an Additional Layer": [[31, "add-an-additional-layer"], [33, "add-an-additional-layer"], [34, "add-an-additional-layer"]], "Adding Chromium to Your local.conf": [[1, "adding-chromium-to-your-local-conf"], [3, "adding-chromium-to-your-local-conf"], [4, "adding-chromium-to-your-local-conf"], [7, "adding-chromium-to-your-local-conf"], [14, "adding-chromium-to-your-local-conf"], [15, "adding-chromium-to-your-local-conf"], [16, "adding-chromium-to-your-local-conf"]], "Advanced Usage": [[31, "advanced-usage"], [33, "advanced-usage"], [34, "advanced-usage"]], "Alsamixer": [[1, "alsamixer"], [3, "alsamixer"], [4, "alsamixer"], [9, "alsamixer"], [11, "alsamixer"], [14, "alsamixer"], [15, "alsamixer"], [16, "alsamixer"], [17, "alsamixer"], [22, "alsamixer"], [23, "alsamixer"], [23, "id3"], [24, "alsamixer"], [24, "id3"]], "Audio": [[1, "audio"], [3, "audio"], [4, "audio"], [9, "audio"], [11, "audio"], [14, "audio"], [15, "audio"], [16, "audio"], [17, "audio"], [22, "audio"]], "Audio on phyBOARD-Nash": [[23, "audio-on-phyboard-nash"]], "Audio on phyBOARD-Nash i.MX 93": [[24, "audio-on-sbc-nash"]], "Audio on phyBOARD-Segin": [[23, "audio-on-phyboard-segin"]], "Audio on phyBOARD-Segin i.MX 93": [[24, "audio-on-sbc-segin"]], "Automatic Updates from USB Flash Drive with RAUC": [[27, "automatic-updates-from-usb-flash-drive-with-rauc"], [29, "automatic-updates-from-usb-flash-drive-with-rauc"], [30, "automatic-updates-from-usb-flash-drive-with-rauc"]], "Available container": [[31, "available-container"], [33, "available-container"], [34, "available-container"]], "BSP Content": [[31, "bsp-content"], [33, "bsp-content"], [34, "bsp-content"]], "BSP Customization": [[31, "bsp-customization"], [33, "bsp-customization"], [34, "bsp-customization"]], "BSP Extensions": [[1, "bsp-extensions"], [3, "bsp-extensions"], [4, "bsp-extensions"], [7, "bsp-extensions"], [14, "bsp-extensions"], [15, "bsp-extensions"], [16, "bsp-extensions"]], "BSP Features of meta-phytec and meta-ampliphy": [[31, "bsp-features-of-meta-phytec-and-meta-ampliphy"], [33, "bsp-features-of-meta-phytec-and-meta-ampliphy"], [34, "bsp-features-of-meta-phytec-and-meta-ampliphy"]], "BSP Images": [[1, "bsp-images"], [3, "bsp-images"], [4, "bsp-images"], [5, "bsp-images"], [7, "bsp-images"], [8, "bsp-images"], [9, "bsp-images"], [11, "bsp-images"], [13, "bsp-images"], [14, "bsp-images"], [15, "bsp-images"], [16, "bsp-images"], [17, "bsp-images"], [18, "bsp-images"], [19, "bsp-images"], [22, "bsp-images"], [23, "bsp-images"], [24, "bsp-images"]], "BSP Management": [[31, "bsp-management"], [33, "bsp-management"], [34, "bsp-management"]], "BSP Metadata": [[31, "bsp-metadata"], [33, "bsp-metadata"], [34, "bsp-metadata"]], "BSP Structure": [[31, "bsp-structure"], [33, "bsp-structure"], [34, "bsp-structure"]], "BSP Workspace Installation": [[31, "bsp-workspace-installation"], [33, "bsp-workspace-installation"], [34, "bsp-workspace-installation"]], "BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1": [[12, "bsp-yocto-ampliphy-i-mx8mp-pd24-1-1"]], "BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2": [[12, "bsp-yocto-ampliphy-i-mx8mp-pd24-1-2"]], "BSP-Yocto-NXP-i.MX8MM-PD22.1.1": [[2, "bsp-yocto-nxp-i-mx8mm-pd22-1-1"], [6, "bsp-yocto-nxp-i-mx8mm-pd22-1-1"]], "BSP-Yocto-NXP-i.MX8MM-PD23.1.0": [[2, "bsp-yocto-nxp-i-mx8mm-pd23-1-0"], [6, "bsp-yocto-nxp-i-mx8mm-pd23-1-0"]], "BSP-Yocto-NXP-i.MX8MP-PD22.1.1": [[12, "bsp-yocto-nxp-i-mx8mp-pd22-1-1"]], "BSP-Yocto-NXP-i.MX8MP-PD22.1.2": [[12, "bsp-yocto-nxp-i-mx8mp-pd22-1-2"]], "BSP-Yocto-NXP-i.MX8MP-PD23.1.0": [[12, "bsp-yocto-nxp-i-mx8mp-pd23-1-0"]], "BSP-Yocto-NXP-i.MX8MP-PD24.1.0": [[12, "bsp-yocto-nxp-i-mx8mp-pd24-1-0"]], "BSP-Yocto-NXP-i.MX93-PD24.1.0": [[21, "bsp-yocto-nxp-i-mx93-pd24-1-0"]], "BSP-Yocto-NXP-i.MX93-PD24.1.1": [[21, "bsp-yocto-nxp-i-mx93-pd24-1-1"]], "BSP-Yocto-NXP-i.MX93-PD24.2.0": [[21, "bsp-yocto-nxp-i-mx93-pd24-2-0"]], "Backlight Control": [[1, "backlight-control"], [3, "backlight-control"], [4, "backlight-control"], [9, "backlight-control"], [11, "backlight-control"], [13, "backlight-control"], [14, "backlight-control"], [15, "backlight-control"], [16, "backlight-control"], [17, "backlight-control"], [18, "backlight-control"], [19, "backlight-control"], [22, "backlight-control"], [23, "backlight-control"], [24, "backlight-control"]], "Barebox": [[27, "barebox"], [29, "barebox"], [30, "barebox"]], "Barebox Bootchooser Framework": [[27, "barebox-bootchooser-framework"], [29, "barebox-bootchooser-framework"], [30, "barebox-bootchooser-framework"]], "Basic Set-Up": [[1, "basic-set-up"], [3, "basic-set-up"], [4, "basic-set-up"], [5, "basic-set-up"], [7, "basic-set-up"], [8, "basic-set-up"], [9, "basic-set-up"], [11, "basic-set-up"], [13, "basic-set-up"], [14, "basic-set-up"], [15, "basic-set-up"], [16, "basic-set-up"], [17, "basic-set-up"], [18, "basic-set-up"], [19, "basic-set-up"], [22, "basic-set-up"], [23, "basic-set-up"], [24, "basic-set-up"]], "Basic Usage": [[31, "basic-usage"], [33, "basic-usage"], [34, "basic-usage"]], "Bitbake": [[31, "bitbake"], [33, "bitbake"], [34, "bitbake"]], "Bluetooth": [[1, "bluetooth"], [3, "bluetooth"], [4, "bluetooth"], [5, "bluetooth"], [7, "bluetooth"], [8, "bluetooth"], [9, "bluetooth"], [11, "bluetooth"], [14, "bluetooth"], [15, "bluetooth"], [16, "bluetooth"], [17, "bluetooth"]], "Boot Logic Implementation": [[27, "boot-logic-implementation"], [29, "boot-logic-implementation"], [30, "boot-logic-implementation"]], "Booting from an Embedded Board": [[1, "booting-from-an-embedded-board"], [3, "booting-from-an-embedded-board"], [4, "booting-from-an-embedded-board"], [5, "booting-from-an-embedded-board"], [7, "booting-from-an-embedded-board"], [8, "booting-from-an-embedded-board"], [9, "booting-from-an-embedded-board"], [11, "booting-from-an-embedded-board"], [13, "booting-from-an-embedded-board"], [14, "booting-from-an-embedded-board"], [15, "booting-from-an-embedded-board"], [16, "booting-from-an-embedded-board"], [17, "booting-from-an-embedded-board"], [18, "booting-from-an-embedded-board"], [19, "booting-from-an-embedded-board"], [22, "booting-from-an-embedded-board"], [23, "booting-from-an-embedded-board"], [24, "booting-from-an-embedded-board"]], "Booting the A/B System by Default": [[27, "booting-the-a-b-system-by-default"], [29, "booting-the-a-b-system-by-default"], [30, "booting-the-a-b-system-by-default"]], "Booting the Kernel from a Network": [[1, "booting-the-kernel-from-a-network"], [3, "booting-the-kernel-from-a-network"], [4, "booting-the-kernel-from-a-network"], [5, "booting-the-kernel-from-a-network"], [7, "booting-the-kernel-from-a-network"], [8, "booting-the-kernel-from-a-network"], [9, "booting-the-kernel-from-a-network"], [11, "booting-the-kernel-from-a-network"], [13, "booting-the-kernel-from-a-network"], [14, "booting-the-kernel-from-a-network"], [15, "booting-the-kernel-from-a-network"], [16, "booting-the-kernel-from-a-network"], [17, "booting-the-kernel-from-a-network"], [18, "booting-the-kernel-from-a-network"], [19, "booting-the-kernel-from-a-network"], [22, "booting-the-kernel-from-a-network"], [23, "booting-the-kernel-from-a-network"], [24, "booting-the-kernel-from-a-network"]], "Bootloader": [[27, "bootloader"], [29, "bootloader"], [30, "bootloader"]], "Bootloader Offsets": [[27, "bootloader-offsets"], [29, "bootloader-offsets"], [30, "bootloader-offsets"]], "Bootmode Selection": [[1, "id5"], [1, "id7"], [3, "id4"], [3, "id6"], [4, "id4"], [4, "id6"], [5, "id5"], [5, "id7"], [7, "id4"], [7, "id6"], [8, "id4"], [8, "id6"]], "Bootmode Switch (S1)": [[1, "bootmode-switch-s1"], [3, "bootmode-switch-s1"], [4, "bootmode-switch-s1"], [5, "bootmode-switch-s1"], [7, "bootmode-switch-s1"], [8, "bootmode-switch-s1"]], "Bootmode Switch (S3)": [[9, "bootmode-switch-s3"], [11, "bootmode-switch-s3"], [13, "bootmode-switch-s3"], [14, "bootmode-switch-s3"], [15, "bootmode-switch-s3"], [16, "bootmode-switch-s3"], [17, "bootmode-switch-s3"], [18, "bootmode-switch-s3"], [19, "bootmode-switch-s3"], [22, "bootmode-switch-s3"], [23, "bootmode-switch-s3"], [24, "bootmode-switch-s3"]], "Build Configuration": [[31, "build-configuration"], [33, "build-configuration"], [34, "build-configuration"]], "Build U-Boot With a Fixed RAM Frequency": [[11, "build-u-boot-with-a-fixed-ram-frequency"], [13, "build-u-boot-with-a-fixed-ram-frequency"], [17, "build-u-boot-with-a-fixed-ram-frequency"], [19, "build-u-boot-with-a-fixed-ram-frequency"]], "Build U-Boot With a Fixed RAM Size": [[1, "build-u-boot-with-a-fixed-ram-size"], [3, "build-u-boot-with-a-fixed-ram-size"], [4, "build-u-boot-with-a-fixed-ram-size"], [9, "build-u-boot-with-a-fixed-ram-size"], [11, "build-u-boot-with-a-fixed-ram-size"], [13, "build-u-boot-with-a-fixed-ram-size"], [14, "build-u-boot-with-a-fixed-ram-size"], [15, "build-u-boot-with-a-fixed-ram-size"], [16, "build-u-boot-with-a-fixed-ram-size"], [17, "build-u-boot-with-a-fixed-ram-size"], [19, "build-u-boot-with-a-fixed-ram-size"]], "Build U-Boot With a Fixed RAM Size and Frequency": [[11, "build-u-boot-with-a-fixed-ram-size-and-frequency"], [13, "build-u-boot-with-a-fixed-ram-size-and-frequency"], [17, "build-u-boot-with-a-fixed-ram-size-and-frequency"], [19, "build-u-boot-with-a-fixed-ram-size-and-frequency"]], "Build final flash.bin with imx-mkimage": [[22, "build-final-flash-bin-with-imx-mkimage"], [23, "build-final-flash-bin-with-imx-mkimage"], [24, "build-final-flash-bin-with-imx-mkimage"]], "Build the SDK": [[18, "build-the-sdk"]], "Build the bootloader": [[1, "build-the-bootloader"], [3, "build-the-bootloader"], [4, "build-the-bootloader"], [5, "build-the-bootloader"], [7, "build-the-bootloader"], [8, "build-the-bootloader"], [9, "build-the-bootloader"], [11, "build-the-bootloader"], [13, "build-the-bootloader"], [14, "build-the-bootloader"], [15, "build-the-bootloader"], [16, "build-the-bootloader"], [17, "build-the-bootloader"], [18, "build-the-bootloader"], [19, "build-the-bootloader"], [22, "build-the-bootloader"], [23, "build-the-bootloader"], [24, "build-the-bootloader"]], "Build the kernel": [[1, "build-the-kernel"], [3, "build-the-kernel"], [4, "build-the-kernel"], [5, "build-the-kernel"], [7, "build-the-kernel"], [8, "build-the-kernel"], [9, "build-the-kernel"], [11, "build-the-kernel"], [13, "build-the-kernel"], [14, "build-the-kernel"], [15, "build-the-kernel"], [16, "build-the-kernel"], [17, "build-the-kernel"], [18, "build-the-kernel"], [19, "build-the-kernel"], [22, "build-the-kernel"], [23, "build-the-kernel"], [24, "build-the-kernel"]], "Buildinfo": [[31, "buildinfo"], [33, "buildinfo"], [34, "buildinfo"]], "Building the BSP": [[1, "building-the-bsp"], [3, "building-the-bsp"], [4, "building-the-bsp"], [5, "building-the-bsp"], [7, "building-the-bsp"], [8, "building-the-bsp"], [9, "building-the-bsp"], [11, "building-the-bsp"], [13, "building-the-bsp"], [14, "building-the-bsp"], [15, "building-the-bsp"], [16, "building-the-bsp"], [17, "building-the-bsp"], [18, "building-the-bsp"], [19, "building-the-bsp"], [22, "building-the-bsp"], [23, "building-the-bsp"], [24, "building-the-bsp"]], "Building the Firmware": [[1, "building-the-firmware"], [3, "building-the-firmware"], [4, "building-the-firmware"], [9, "building-the-firmware"], [11, "building-the-firmware"], [14, "building-the-firmware"], [15, "building-the-firmware"], [16, "building-the-firmware"], [17, "building-the-firmware"]], "Burning Boot Fuses": [[22, "burning-boot-fuses"], [23, "burning-boot-fuses"], [24, "burning-boot-fuses"]], "Burning MAC addresses": [[22, "burning-mac-addresses"], [23, "burning-mac-addresses"], [24, "burning-mac-addresses"]], "CAN FD": [[1, "can-fd"], [3, "can-fd"], [4, "can-fd"], [5, "can-fd"], [7, "can-fd"], [8, "can-fd"], [9, "can-fd"], [11, "can-fd"], [13, "can-fd"], [14, "can-fd"], [15, "can-fd"], [16, "can-fd"], [17, "can-fd"], [18, "can-fd"], [19, "can-fd"], [22, "can-fd"], [23, "can-fd"], [24, "can-fd"]], "CPU Core Frequency Scaling": [[1, "cpu-core-frequency-scaling"], [3, "cpu-core-frequency-scaling"], [4, "cpu-core-frequency-scaling"], [5, "cpu-core-frequency-scaling"], [7, "cpu-core-frequency-scaling"], [8, "cpu-core-frequency-scaling"], [9, "cpu-core-frequency-scaling"], [11, "cpu-core-frequency-scaling"], [13, "cpu-core-frequency-scaling"], [14, "cpu-core-frequency-scaling"], [15, "cpu-core-frequency-scaling"], [16, "cpu-core-frequency-scaling"], [17, "cpu-core-frequency-scaling"], [18, "cpu-core-frequency-scaling"], [19, "cpu-core-frequency-scaling"], [22, "cpu-core-frequency-scaling"], [23, "cpu-core-frequency-scaling"], [24, "cpu-core-frequency-scaling"]], "CPU Core Management": [[1, "cpu-core-management"], [3, "cpu-core-management"], [4, "cpu-core-management"], [5, "cpu-core-management"], [7, "cpu-core-management"], [8, "cpu-core-management"], [9, "cpu-core-management"], [11, "cpu-core-management"], [13, "cpu-core-management"], [14, "cpu-core-management"], [15, "cpu-core-management"], [16, "cpu-core-management"], [17, "cpu-core-management"], [18, "cpu-core-management"], [19, "cpu-core-management"], [22, "cpu-core-management"], [23, "cpu-core-management"], [24, "cpu-core-management"]], "Capture": [[1, "capture"], [3, "capture"], [4, "capture"], [9, "capture"], [11, "capture"], [14, "capture"], [15, "capture"], [16, "capture"], [17, "capture"], [22, "capture"], [23, "capture"], [23, "id6"], [24, "capture"], [24, "id6"]], "Change U-boot Environment from Linux on Target": [[1, "change-u-boot-environment-from-linux-on-target"], [3, "change-u-boot-environment-from-linux-on-target"], [4, "change-u-boot-environment-from-linux-on-target"], [5, "change-u-boot-environment-from-linux-on-target"], [7, "change-u-boot-environment-from-linux-on-target"], [8, "change-u-boot-environment-from-linux-on-target"], [9, "change-u-boot-environment-from-linux-on-target"], [11, "change-u-boot-environment-from-linux-on-target"], [14, "change-u-boot-environment-from-linux-on-target"], [15, "change-u-boot-environment-from-linux-on-target"], [16, "change-u-boot-environment-from-linux-on-target"], [17, "change-u-boot-environment-from-linux-on-target"], [22, "change-u-boot-environment-from-linux-on-target"], [23, "change-u-boot-environment-from-linux-on-target"], [24, "change-u-boot-environment-from-linux-on-target"]], "Change the barebox Environment via bbappend Files": [[31, "change-the-barebox-environment-via-bbappend-files"], [33, "change-the-barebox-environment-via-bbappend-files"], [34, "change-the-barebox-environment-via-bbappend-files"]], "Change the u-boot Environment via bbappend Files": [[31, "change-the-u-boot-environment-via-bbappend-files"], [33, "change-the-u-boot-environment-via-bbappend-files"], [34, "change-the-u-boot-environment-via-bbappend-files"]], "Changes in U-Boot environment": [[1, "changes-in-u-boot-environment"], [9, "changes-in-u-boot-environment"], [11, "changes-in-u-boot-environment"], [17, "changes-in-u-boot-environment"]], "Changes in Yocto": [[1, "changes-in-yocto"], [9, "changes-in-yocto"], [11, "changes-in-yocto"], [17, "changes-in-yocto"]], "Changing the Active Boot Slot": [[27, "changing-the-active-boot-slot"], [29, "changing-the-active-boot-slot"], [30, "changing-the-active-boot-slot"]], "Changing the Environment (depending on Machines)": [[31, "changing-the-environment-depending-on-machines"], [33, "changing-the-environment-depending-on-machines"], [34, "changing-the-environment-depending-on-machines"]], "Changing the Network Configuration": [[31, "changing-the-network-configuration"], [33, "changing-the-network-configuration"], [34, "changing-the-network-configuration"]], "Changing the Wireless Network Configuration": [[31, "changing-the-wireless-network-configuration"], [33, "changing-the-wireless-network-configuration"], [34, "changing-the-wireless-network-configuration"]], "Chromium": [[1, "chromium"], [3, "chromium"], [4, "chromium"], [7, "chromium"], [14, "chromium"], [15, "chromium"], [16, "chromium"]], "Classes": [[31, "classes"], [33, "classes"], [34, "classes"]], "Common Tasks": [[31, "common-tasks"], [33, "common-tasks"], [34, "common-tasks"]], "Compatible Linux Distributions": [[31, "compatible-linux-distributions"], [33, "compatible-linux-distributions"], [34, "compatible-linux-distributions"]], "Compiling on the Target": [[31, "compiling-on-the-target"], [33, "compiling-on-the-target"], [34, "compiling-on-the-target"]], "Connect": [[1, "connect"], [3, "connect"], [4, "connect"], [5, "connect"], [7, "connect"], [8, "connect"], [9, "connect"], [11, "connect"], [14, "connect"], [14, "id2"], [15, "connect"], [16, "connect"], [17, "connect"]], "Connecting to a WLAN Network": [[1, "connecting-to-a-wlan-network"], [3, "connecting-to-a-wlan-network"], [4, "connecting-to-a-wlan-network"], [5, "connecting-to-a-wlan-network"], [7, "connecting-to-a-wlan-network"], [8, "connecting-to-a-wlan-network"], [9, "connecting-to-a-wlan-network"], [11, "connecting-to-a-wlan-network"], [14, "connecting-to-a-wlan-network"], [15, "connecting-to-a-wlan-network"], [16, "connecting-to-a-wlan-network"], [17, "connecting-to-a-wlan-network"], [24, "connecting-to-a-wlan-network"], [31, "connecting-to-a-wlan-network"], [33, "connecting-to-a-wlan-network"], [34, "connecting-to-a-wlan-network"]], "Contents": [[26, null]], "Contribute": [[25, null], [26, null]], "Copy FIT image and kernel modules to SD Card": [[1, "copy-fit-image-and-kernel-modules-to-sd-card"], [9, "copy-fit-image-and-kernel-modules-to-sd-card"], [11, "copy-fit-image-and-kernel-modules-to-sd-card"], [17, "copy-fit-image-and-kernel-modules-to-sd-card"]], "Copy Kernel to SD Card": [[3, "copy-kernel-to-sd-card"], [4, "copy-kernel-to-sd-card"], [5, "copy-kernel-to-sd-card"], [7, "copy-kernel-to-sd-card"], [8, "copy-kernel-to-sd-card"], [13, "copy-kernel-to-sd-card"], [14, "copy-kernel-to-sd-card"], [15, "copy-kernel-to-sd-card"], [16, "copy-kernel-to-sd-card"], [18, "copy-kernel-to-sd-card"], [19, "copy-kernel-to-sd-card"], [22, "copy-kernel-to-sd-card"], [23, "copy-kernel-to-sd-card"], [24, "copy-kernel-to-sd-card"]], "Core Components": [[31, "core-components"], [33, "core-components"], [34, "core-components"]], "Create the Third Partition": [[1, "create-the-third-partition"], [3, "create-the-third-partition"], [4, "create-the-third-partition"], [5, "create-the-third-partition"], [7, "create-the-third-partition"], [8, "create-the-third-partition"], [9, "create-the-third-partition"], [11, "create-the-third-partition"], [13, "create-the-third-partition"], [14, "create-the-third-partition"], [15, "create-the-third-partition"], [16, "create-the-third-partition"], [17, "create-the-third-partition"], [18, "create-the-third-partition"], [19, "create-the-third-partition"], [22, "create-the-third-partition"], [23, "create-the-third-partition"], [24, "create-the-third-partition"]], "Create your own layer": [[31, "create-your-own-layer"], [33, "create-your-own-layer"], [34, "create-your-own-layer"]], "Creating RAUC Bundles": [[27, "creating-rauc-bundles"], [29, "creating-rauc-bundles"], [30, "creating-rauc-bundles"]], "Creating a WLAN Access Point": [[31, "creating-a-wlan-access-point"], [33, "creating-a-wlan-access-point"], [34, "creating-a-wlan-access-point"]], "Creating transition bundles": [[30, "creating-transition-bundles"]], "DHCP Server setup": [[1, "dhcp-server-setup"], [3, "dhcp-server-setup"], [4, "dhcp-server-setup"], [5, "dhcp-server-setup"], [7, "dhcp-server-setup"], [8, "dhcp-server-setup"], [9, "dhcp-server-setup"], [11, "dhcp-server-setup"], [13, "dhcp-server-setup"], [14, "dhcp-server-setup"], [15, "dhcp-server-setup"], [16, "dhcp-server-setup"], [17, "dhcp-server-setup"], [18, "dhcp-server-setup"], [19, "dhcp-server-setup"], [22, "dhcp-server-setup"], [23, "dhcp-server-setup"], [24, "dhcp-server-setup"]], "Debugging Using J-Link": [[1, "debugging-using-j-link"], [3, "debugging-using-j-link"], [4, "debugging-using-j-link"], [9, "debugging-using-j-link"], [11, "debugging-using-j-link"], [14, "debugging-using-j-link"], [15, "debugging-using-j-link"], [16, "debugging-using-j-link"], [17, "debugging-using-j-link"]], "Debugging a User Space Application": [[31, "debugging-a-user-space-application"], [33, "debugging-a-user-space-application"], [34, "debugging-a-user-space-application"]], "Debugging the Environment": [[31, "debugging-the-environment"], [33, "debugging-the-environment"], [34, "debugging-the-environment"]], "Design Considerations": [[27, "design-considerations"], [29, "design-considerations"], [30, "design-considerations"]], "Development": [[1, "development"], [3, "development"], [4, "development"], [5, "development"], [7, "development"], [8, "development"], [9, "development"], [11, "development"], [13, "development"], [14, "development"], [15, "development"], [16, "development"], [17, "development"], [18, "development"], [19, "development"], [22, "development"], [23, "development"], [24, "development"]], "Development state of current release": [[1, "development-state-of-current-release"], [3, "development-state-of-current-release"], [4, "development-state-of-current-release"], [5, "development-state-of-current-release"], [7, "development-state-of-current-release"], [8, "development-state-of-current-release"], [9, "development-state-of-current-release"], [11, "development-state-of-current-release"], [13, "development-state-of-current-release"], [14, "development-state-of-current-release"], [15, "development-state-of-current-release"], [16, "development-state-of-current-release"], [17, "development-state-of-current-release"], [18, "development-state-of-current-release"], [19, "development-state-of-current-release"]], "Development state of upcoming release": [[1, "development-state-of-upcoming-release"], [3, "development-state-of-upcoming-release"], [4, "development-state-of-upcoming-release"], [5, "development-state-of-upcoming-release"], [7, "development-state-of-upcoming-release"], [8, "development-state-of-upcoming-release"], [9, "development-state-of-upcoming-release"], [11, "development-state-of-upcoming-release"], [13, "development-state-of-upcoming-release"], [14, "development-state-of-upcoming-release"], [15, "development-state-of-upcoming-release"], [16, "development-state-of-upcoming-release"], [17, "development-state-of-upcoming-release"], [18, "development-state-of-upcoming-release"], [19, "development-state-of-upcoming-release"]], "Device Tree (DT)": [[1, "device-tree-dt"], [3, "device-tree-dt"], [4, "device-tree-dt"], [5, "device-tree-dt"], [7, "device-tree-dt"], [8, "device-tree-dt"], [9, "device-tree-dt"], [11, "device-tree-dt"], [13, "device-tree-dt"], [14, "device-tree-dt"], [15, "device-tree-dt"], [16, "device-tree-dt"], [17, "device-tree-dt"], [18, "device-tree-dt"], [19, "device-tree-dt"], [22, "device-tree-dt"], [23, "device-tree-dt"], [24, "device-tree-dt"]], "Device Tree Overlay": [[1, "device-tree-overlay"], [3, "device-tree-overlay"], [4, "device-tree-overlay"], [5, "device-tree-overlay"], [7, "device-tree-overlay"], [8, "device-tree-overlay"], [9, "device-tree-overlay"], [11, "device-tree-overlay"], [13, "device-tree-overlay"], [14, "device-tree-overlay"], [15, "device-tree-overlay"], [16, "device-tree-overlay"], [17, "device-tree-overlay"], [18, "device-tree-overlay"], [19, "device-tree-overlay"], [22, "device-tree-overlay"], [23, "device-tree-overlay"], [24, "device-tree-overlay"]], "Device Tree Structure": [[1, "device-tree-structure"], [3, "device-tree-structure"], [4, "device-tree-structure"], [5, "device-tree-structure"], [7, "device-tree-structure"], [8, "device-tree-structure"], [9, "device-tree-structure"], [11, "device-tree-structure"], [13, "device-tree-structure"], [14, "device-tree-structure"], [15, "device-tree-structure"], [16, "device-tree-structure"], [17, "device-tree-structure"], [18, "device-tree-structure"], [19, "device-tree-structure"], [22, "device-tree-structure"], [23, "device-tree-structure"], [24, "device-tree-structure"]], "Different Toolchains": [[31, "different-toolchains"], [33, "different-toolchains"], [34, "different-toolchains"]], "Disable Qt Demo": [[31, "disable-qt-demo"], [33, "disable-qt-demo"], [34, "disable-qt-demo"]], "Disable booting with efi": [[1, "disable-booting-with-efi"], [9, "disable-booting-with-efi"], [11, "disable-booting-with-efi"], [17, "disable-booting-with-efi"]], "Display": [[1, "display"], [3, "display"], [4, "display"], [9, "display"], [11, "display"], [13, "display"], [14, "display"], [15, "display"], [16, "display"], [17, "display"], [18, "display"], [19, "display"], [22, "display"], [23, "display"], [24, "display"]], "Distribution (Distro)": [[31, "distribution-distro"], [33, "distribution-distro"], [34, "distribution-distro"]], "Download/Pull container": [[31, "download-pull-container"], [33, "download-pull-container"], [34, "download-pull-container"]], "Dual Display": [[9, "dual-display"], [11, "dual-display"], [16, "dual-display"], [17, "dual-display"]], "EEPROM": [[1, "eeprom"], [3, "eeprom"], [4, "eeprom"], [5, "eeprom"], [7, "eeprom"], [8, "eeprom"], [9, "eeprom"], [11, "eeprom"], [13, "eeprom"], [14, "eeprom"], [15, "eeprom"], [16, "eeprom"], [17, "eeprom"], [18, "eeprom"], [19, "eeprom"], [22, "eeprom"], [23, "eeprom"], [24, "eeprom"]], "EEPROM SoM Detection": [[1, "eeprom-som-detection"], [3, "eeprom-som-detection"], [4, "eeprom-som-detection"], [5, "eeprom-som-detection"], [7, "eeprom-som-detection"], [8, "eeprom-som-detection"], [9, "eeprom-som-detection"], [11, "eeprom-som-detection"], [13, "eeprom-som-detection"], [14, "eeprom-som-detection"], [15, "eeprom-som-detection"], [16, "eeprom-som-detection"], [17, "eeprom-som-detection"], [18, "eeprom-som-detection"], [19, "eeprom-som-detection"], [22, "eeprom-som-detection"], [23, "eeprom-som-detection"], [24, "eeprom-som-detection"]], "EFI Boot": [[1, "efi-boot"], [9, "efi-boot"], [11, "efi-boot"], [17, "efi-boot"]], "Enable pseudo-SLC Mode": [[1, "enable-pseudo-slc-mode"], [3, "enable-pseudo-slc-mode"], [4, "enable-pseudo-slc-mode"], [5, "enable-pseudo-slc-mode"], [7, "enable-pseudo-slc-mode"], [8, "enable-pseudo-slc-mode"], [9, "enable-pseudo-slc-mode"], [11, "enable-pseudo-slc-mode"], [13, "enable-pseudo-slc-mode"], [14, "enable-pseudo-slc-mode"], [15, "enable-pseudo-slc-mode"], [16, "enable-pseudo-slc-mode"], [17, "enable-pseudo-slc-mode"], [18, "enable-pseudo-slc-mode"], [19, "enable-pseudo-slc-mode"], [22, "enable-pseudo-slc-mode"], [23, "enable-pseudo-slc-mode"], [24, "enable-pseudo-slc-mode"]], "Enabling Background Operations (BKOPS)": [[1, "enabling-background-operations-bkops"], [3, "enabling-background-operations-bkops"], [4, "enabling-background-operations-bkops"], [5, "enabling-background-operations-bkops"], [7, "enabling-background-operations-bkops"], [8, "enabling-background-operations-bkops"], [9, "enabling-background-operations-bkops"], [11, "enabling-background-operations-bkops"], [13, "enabling-background-operations-bkops"], [14, "enabling-background-operations-bkops"], [15, "enabling-background-operations-bkops"], [16, "enabling-background-operations-bkops"], [17, "enabling-background-operations-bkops"], [18, "enabling-background-operations-bkops"], [19, "enabling-background-operations-bkops"], [22, "enabling-background-operations-bkops"], [23, "enabling-background-operations-bkops"], [24, "enabling-background-operations-bkops"]], "Erasing the Device": [[1, "erasing-the-device"], [3, "erasing-the-device"], [4, "erasing-the-device"], [5, "erasing-the-device"], [7, "erasing-the-device"], [8, "erasing-the-device"], [9, "erasing-the-device"], [11, "erasing-the-device"], [13, "erasing-the-device"], [14, "erasing-the-device"], [15, "erasing-the-device"], [16, "erasing-the-device"], [17, "erasing-the-device"], [18, "erasing-the-device"], [19, "erasing-the-device"], [22, "erasing-the-device"], [23, "erasing-the-device"], [24, "erasing-the-device"]], "Expand rootfs": [[1, "expand-rootfs"], [3, "expand-rootfs"], [4, "expand-rootfs"], [5, "expand-rootfs"], [7, "expand-rootfs"], [8, "expand-rootfs"], [9, "expand-rootfs"], [11, "expand-rootfs"], [13, "expand-rootfs"], [14, "expand-rootfs"], [15, "expand-rootfs"], [16, "expand-rootfs"], [17, "expand-rootfs"], [18, "expand-rootfs"], [19, "expand-rootfs"], [22, "expand-rootfs"], [23, "expand-rootfs"], [24, "expand-rootfs"]], "Extended CSD Register": [[1, "extended-csd-register"], [3, "extended-csd-register"], [4, "extended-csd-register"], [5, "extended-csd-register"], [7, "extended-csd-register"], [8, "extended-csd-register"], [9, "extended-csd-register"], [11, "extended-csd-register"], [13, "extended-csd-register"], [14, "extended-csd-register"], [15, "extended-csd-register"], [16, "extended-csd-register"], [17, "extended-csd-register"], [18, "extended-csd-register"], [19, "extended-csd-register"], [22, "extended-csd-register"], [23, "extended-csd-register"], [24, "extended-csd-register"]], "Extension Command": [[3, "extension-command"], [4, "extension-command"], [5, "extension-command"], [7, "extension-command"], [8, "extension-command"], [14, "extension-command"], [15, "extension-command"], [16, "extension-command"]], "Finding the Correct Device": [[1, "finding-the-correct-device"], [4, "finding-the-correct-device"], [5, "finding-the-correct-device"], [8, "finding-the-correct-device"], [9, "finding-the-correct-device"], [11, "finding-the-correct-device"], [13, "finding-the-correct-device"], [16, "finding-the-correct-device"], [17, "finding-the-correct-device"], [18, "finding-the-correct-device"], [19, "finding-the-correct-device"], [22, "finding-the-correct-device"], [23, "finding-the-correct-device"], [24, "finding-the-correct-device"]], "First Start-up": [[1, "first-start-up"], [3, "first-start-up"], [4, "first-start-up"], [5, "first-start-up"], [7, "first-start-up"], [8, "first-start-up"], [9, "first-start-up"], [11, "first-start-up"], [13, "first-start-up"], [14, "first-start-up"], [15, "first-start-up"], [16, "first-start-up"], [17, "first-start-up"], [18, "first-start-up"], [19, "first-start-up"], [22, "first-start-up"], [23, "first-start-up"], [24, "first-start-up"]], "Flash SPI NOR Flash": [[1, "flash-spi-nor-flash"], [3, "flash-spi-nor-flash"], [4, "flash-spi-nor-flash"], [5, "flash-spi-nor-flash"], [7, "flash-spi-nor-flash"], [8, "flash-spi-nor-flash"], [9, "flash-spi-nor-flash"], [11, "flash-spi-nor-flash"], [14, "flash-spi-nor-flash"], [15, "flash-spi-nor-flash"], [16, "flash-spi-nor-flash"], [17, "flash-spi-nor-flash"]], "Flash SPI NOR Flash from Network": [[1, "flash-spi-nor-flash-from-network"], [3, "flash-spi-nor-flash-from-network"], [4, "flash-spi-nor-flash-from-network"], [5, "flash-spi-nor-flash-from-network"], [7, "flash-spi-nor-flash-from-network"], [8, "flash-spi-nor-flash-from-network"], [9, "flash-spi-nor-flash-from-network"], [11, "flash-spi-nor-flash-from-network"], [14, "flash-spi-nor-flash-from-network"], [15, "flash-spi-nor-flash-from-network"], [16, "flash-spi-nor-flash-from-network"], [17, "flash-spi-nor-flash-from-network"]], "Flash SPI NOR Flash from SD Card": [[1, "flash-spi-nor-flash-from-sd-card"], [3, "flash-spi-nor-flash-from-sd-card"], [4, "flash-spi-nor-flash-from-sd-card"], [5, "flash-spi-nor-flash-from-sd-card"], [7, "flash-spi-nor-flash-from-sd-card"], [8, "flash-spi-nor-flash-from-sd-card"], [9, "flash-spi-nor-flash-from-sd-card"], [11, "flash-spi-nor-flash-from-sd-card"], [14, "flash-spi-nor-flash-from-sd-card"], [15, "flash-spi-nor-flash-from-sd-card"], [16, "flash-spi-nor-flash-from-sd-card"], [17, "flash-spi-nor-flash-from-sd-card"]], "Flash SPI NOR from Network in U-Boot on Target": [[1, "flash-spi-nor-from-network-in-u-boot-on-target"], [4, "flash-spi-nor-from-network-in-u-boot-on-target"], [5, "flash-spi-nor-from-network-in-u-boot-on-target"], [8, "flash-spi-nor-from-network-in-u-boot-on-target"], [9, "flash-spi-nor-from-network-in-u-boot-on-target"], [11, "flash-spi-nor-from-network-in-u-boot-on-target"], [16, "flash-spi-nor-from-network-in-u-boot-on-target"], [17, "flash-spi-nor-from-network-in-u-boot-on-target"]], "Flash SPI NOR from Network in kernel on Target": [[1, "flash-spi-nor-from-network-in-kernel-on-target"], [3, "flash-spi-nor-from-network-in-kernel-on-target"], [4, "flash-spi-nor-from-network-in-kernel-on-target"], [5, "flash-spi-nor-from-network-in-kernel-on-target"], [7, "flash-spi-nor-from-network-in-kernel-on-target"], [8, "flash-spi-nor-from-network-in-kernel-on-target"], [9, "flash-spi-nor-from-network-in-kernel-on-target"], [11, "flash-spi-nor-from-network-in-kernel-on-target"], [14, "flash-spi-nor-from-network-in-kernel-on-target"], [15, "flash-spi-nor-from-network-in-kernel-on-target"], [16, "flash-spi-nor-from-network-in-kernel-on-target"], [17, "flash-spi-nor-from-network-in-kernel-on-target"]], "Flash SPI NOR from Network in u-boot on Target": [[3, "flash-spi-nor-from-network-in-u-boot-on-target"], [7, "flash-spi-nor-from-network-in-u-boot-on-target"], [14, "flash-spi-nor-from-network-in-u-boot-on-target"], [15, "flash-spi-nor-from-network-in-u-boot-on-target"]], "Flash SPI NOR from SD Card in U-Boot on Target": [[1, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [4, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [5, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [8, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [9, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [11, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [16, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [17, "flash-spi-nor-from-sd-card-in-u-boot-on-target"]], "Flash SPI NOR from SD Card in kernel on Target": [[1, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [3, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [4, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [5, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [7, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [8, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [9, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [11, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [14, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [15, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [16, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [17, "flash-spi-nor-from-sd-card-in-kernel-on-target"]], "Flash SPI NOR from SD Card in u-boot on Target": [[3, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [7, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [14, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [15, "flash-spi-nor-from-sd-card-in-u-boot-on-target"]], "Flash Storage": [[27, "flash-storage"], [29, "flash-storage"], [30, "flash-storage"]], "Flash eMMC": [[1, "flash-emmc"], [3, "flash-emmc"], [4, "flash-emmc"], [5, "flash-emmc"], [7, "flash-emmc"], [8, "flash-emmc"], [9, "flash-emmc"], [11, "flash-emmc"], [13, "flash-emmc"], [14, "flash-emmc"], [15, "flash-emmc"], [16, "flash-emmc"], [17, "flash-emmc"], [18, "flash-emmc"], [19, "flash-emmc"], [22, "flash-emmc"], [23, "flash-emmc"], [24, "flash-emmc"]], "Flash eMMC U-Boot image via Network from running U-Boot": [[1, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [4, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [5, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [8, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [9, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [11, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [13, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [16, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [17, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [18, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [19, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [22, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [23, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [24, "flash-emmc-u-boot-image-via-network-from-running-u-boot"]], "Flash eMMC from Network": [[1, "flash-emmc-from-network"], [3, "flash-emmc-from-network"], [4, "flash-emmc-from-network"], [5, "flash-emmc-from-network"], [7, "flash-emmc-from-network"], [8, "flash-emmc-from-network"], [9, "flash-emmc-from-network"], [11, "flash-emmc-from-network"], [13, "flash-emmc-from-network"], [14, "flash-emmc-from-network"], [15, "flash-emmc-from-network"], [16, "flash-emmc-from-network"], [17, "flash-emmc-from-network"], [18, "flash-emmc-from-network"], [19, "flash-emmc-from-network"], [22, "flash-emmc-from-network"], [23, "flash-emmc-from-network"], [24, "flash-emmc-from-network"]], "Flash eMMC from Network in U-Boot on Target": [[1, "flash-emmc-from-network-in-u-boot-on-target"], [4, "flash-emmc-from-network-in-u-boot-on-target"], [5, "flash-emmc-from-network-in-u-boot-on-target"], [8, "flash-emmc-from-network-in-u-boot-on-target"], [9, "flash-emmc-from-network-in-u-boot-on-target"], [11, "flash-emmc-from-network-in-u-boot-on-target"], [13, "flash-emmc-from-network-in-u-boot-on-target"], [16, "flash-emmc-from-network-in-u-boot-on-target"], [17, "flash-emmc-from-network-in-u-boot-on-target"], [18, "flash-emmc-from-network-in-u-boot-on-target"], [19, "flash-emmc-from-network-in-u-boot-on-target"]], "Flash eMMC from Network in u-boot on Target": [[3, "flash-emmc-from-network-in-u-boot-on-target"], [7, "flash-emmc-from-network-in-u-boot-on-target"], [14, "flash-emmc-from-network-in-u-boot-on-target"], [15, "flash-emmc-from-network-in-u-boot-on-target"]], "Flash eMMC from SD Card": [[1, "flash-emmc-from-sd-card"], [3, "flash-emmc-from-sd-card"], [4, "flash-emmc-from-sd-card"], [5, "flash-emmc-from-sd-card"], [7, "flash-emmc-from-sd-card"], [8, "flash-emmc-from-sd-card"], [9, "flash-emmc-from-sd-card"], [11, "flash-emmc-from-sd-card"], [13, "flash-emmc-from-sd-card"], [14, "flash-emmc-from-sd-card"], [15, "flash-emmc-from-sd-card"], [16, "flash-emmc-from-sd-card"], [17, "flash-emmc-from-sd-card"], [18, "flash-emmc-from-sd-card"], [19, "flash-emmc-from-sd-card"], [22, "flash-emmc-from-sd-card"], [23, "flash-emmc-from-sd-card"], [24, "flash-emmc-from-sd-card"]], "Flash eMMC from SD card in Linux on Target": [[1, "flash-emmc-from-sd-card-in-linux-on-target"], [3, "flash-emmc-from-sd-card-in-linux-on-target"], [4, "flash-emmc-from-sd-card-in-linux-on-target"], [5, "flash-emmc-from-sd-card-in-linux-on-target"], [7, "flash-emmc-from-sd-card-in-linux-on-target"], [8, "flash-emmc-from-sd-card-in-linux-on-target"], [9, "flash-emmc-from-sd-card-in-linux-on-target"], [11, "flash-emmc-from-sd-card-in-linux-on-target"], [13, "flash-emmc-from-sd-card-in-linux-on-target"], [14, "flash-emmc-from-sd-card-in-linux-on-target"], [15, "flash-emmc-from-sd-card-in-linux-on-target"], [16, "flash-emmc-from-sd-card-in-linux-on-target"], [17, "flash-emmc-from-sd-card-in-linux-on-target"], [18, "flash-emmc-from-sd-card-in-linux-on-target"], [19, "flash-emmc-from-sd-card-in-linux-on-target"], [22, "flash-emmc-from-sd-card-in-linux-on-target"], [23, "flash-emmc-from-sd-card-in-linux-on-target"], [24, "flash-emmc-from-sd-card-in-linux-on-target"]], "Flash eMMC from SD card in U-Boot on Target": [[1, "flash-emmc-from-sd-card-in-u-boot-on-target"], [4, "flash-emmc-from-sd-card-in-u-boot-on-target"], [5, "flash-emmc-from-sd-card-in-u-boot-on-target"], [8, "flash-emmc-from-sd-card-in-u-boot-on-target"], [9, "flash-emmc-from-sd-card-in-u-boot-on-target"], [11, "flash-emmc-from-sd-card-in-u-boot-on-target"], [13, "flash-emmc-from-sd-card-in-u-boot-on-target"], [16, "flash-emmc-from-sd-card-in-u-boot-on-target"], [17, "flash-emmc-from-sd-card-in-u-boot-on-target"], [18, "flash-emmc-from-sd-card-in-u-boot-on-target"], [19, "flash-emmc-from-sd-card-in-u-boot-on-target"]], "Flash eMMC from SD card in u-boot on Target": [[3, "flash-emmc-from-sd-card-in-u-boot-on-target"], [7, "flash-emmc-from-sd-card-in-u-boot-on-target"], [14, "flash-emmc-from-sd-card-in-u-boot-on-target"], [15, "flash-emmc-from-sd-card-in-u-boot-on-target"]], "Flash eMMC from USB": [[3, "flash-emmc-from-usb"], [7, "flash-emmc-from-usb"], [14, "flash-emmc-from-usb"], [15, "flash-emmc-from-usb"], [18, "flash-emmc-from-usb"], [22, "flash-emmc-from-usb"], [23, "flash-emmc-from-usb"], [24, "flash-emmc-from-usb"]], "Flash eMMC from USB in Linux": [[1, "flash-emmc-from-usb-in-linux"], [3, "flash-emmc-from-usb-in-linux"], [4, "flash-emmc-from-usb-in-linux"], [5, "flash-emmc-from-usb-in-linux"], [7, "flash-emmc-from-usb-in-linux"], [8, "flash-emmc-from-usb-in-linux"], [9, "flash-emmc-from-usb-in-linux"], [11, "flash-emmc-from-usb-in-linux"], [13, "flash-emmc-from-usb-in-linux"], [14, "flash-emmc-from-usb-in-linux"], [15, "flash-emmc-from-usb-in-linux"], [16, "flash-emmc-from-usb-in-linux"], [17, "flash-emmc-from-usb-in-linux"], [18, "flash-emmc-from-usb-in-linux"], [19, "flash-emmc-from-usb-in-linux"], [22, "flash-emmc-from-usb-in-linux"], [23, "flash-emmc-from-usb-in-linux"], [24, "flash-emmc-from-usb-in-linux"]], "Flash eMMC from USB in U-Boot on Target": [[18, "flash-emmc-from-usb-in-u-boot-on-target"]], "Flash eMMC from USB in u-boot on Target": [[3, "flash-emmc-from-usb-in-u-boot-on-target"], [7, "flash-emmc-from-usb-in-u-boot-on-target"], [14, "flash-emmc-from-usb-in-u-boot-on-target"], [15, "flash-emmc-from-usb-in-u-boot-on-target"]], "Flash eMMC from USB stick": [[1, "flash-emmc-from-usb-stick"], [4, "flash-emmc-from-usb-stick"], [5, "flash-emmc-from-usb-stick"], [8, "flash-emmc-from-usb-stick"], [9, "flash-emmc-from-usb-stick"], [11, "flash-emmc-from-usb-stick"], [13, "flash-emmc-from-usb-stick"], [16, "flash-emmc-from-usb-stick"], [17, "flash-emmc-from-usb-stick"], [19, "flash-emmc-from-usb-stick"]], "Flash eMMC from USB stick in U-Boot on Target": [[1, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [4, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [5, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [8, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [9, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [11, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [13, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [16, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [17, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [19, "flash-emmc-from-usb-stick-in-u-boot-on-target"]], "Flash eMMC u-boot image via Network from running u-boot": [[3, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [7, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [14, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [15, "flash-emmc-u-boot-image-via-network-from-running-u-boot"]], "Flash eMMC via Network in Linux on Host": [[1, "flash-emmc-via-network-in-linux-on-host"], [3, "flash-emmc-via-network-in-linux-on-host"], [4, "flash-emmc-via-network-in-linux-on-host"], [5, "flash-emmc-via-network-in-linux-on-host"], [7, "flash-emmc-via-network-in-linux-on-host"], [8, "flash-emmc-via-network-in-linux-on-host"], [9, "flash-emmc-via-network-in-linux-on-host"], [11, "flash-emmc-via-network-in-linux-on-host"], [13, "flash-emmc-via-network-in-linux-on-host"], [14, "flash-emmc-via-network-in-linux-on-host"], [15, "flash-emmc-via-network-in-linux-on-host"], [16, "flash-emmc-via-network-in-linux-on-host"], [17, "flash-emmc-via-network-in-linux-on-host"], [18, "flash-emmc-via-network-in-linux-on-host"], [19, "flash-emmc-via-network-in-linux-on-host"], [22, "flash-emmc-via-network-in-linux-on-host"], [23, "flash-emmc-via-network-in-linux-on-host"], [24, "flash-emmc-via-network-in-linux-on-host"]], "Flash eMMC via Network in Linux on Target": [[1, "flash-emmc-via-network-in-linux-on-target"], [3, "flash-emmc-via-network-in-linux-on-target"], [4, "flash-emmc-via-network-in-linux-on-target"], [5, "flash-emmc-via-network-in-linux-on-target"], [7, "flash-emmc-via-network-in-linux-on-target"], [8, "flash-emmc-via-network-in-linux-on-target"], [9, "flash-emmc-via-network-in-linux-on-target"], [11, "flash-emmc-via-network-in-linux-on-target"], [13, "flash-emmc-via-network-in-linux-on-target"], [14, "flash-emmc-via-network-in-linux-on-target"], [15, "flash-emmc-via-network-in-linux-on-target"], [16, "flash-emmc-via-network-in-linux-on-target"], [17, "flash-emmc-via-network-in-linux-on-target"], [18, "flash-emmc-via-network-in-linux-on-target"], [19, "flash-emmc-via-network-in-linux-on-target"], [22, "flash-emmc-via-network-in-linux-on-target"], [23, "flash-emmc-via-network-in-linux-on-target"], [24, "flash-emmc-via-network-in-linux-on-target"]], "Flash the bootloader to a block device": [[1, "flash-the-bootloader-to-a-block-device"], [3, "flash-the-bootloader-to-a-block-device"], [4, "flash-the-bootloader-to-a-block-device"], [5, "flash-the-bootloader-to-a-block-device"], [7, "flash-the-bootloader-to-a-block-device"], [8, "flash-the-bootloader-to-a-block-device"], [9, "flash-the-bootloader-to-a-block-device"], [11, "flash-the-bootloader-to-a-block-device"], [13, "flash-the-bootloader-to-a-block-device"], [14, "flash-the-bootloader-to-a-block-device"], [15, "flash-the-bootloader-to-a-block-device"], [16, "flash-the-bootloader-to-a-block-device"], [17, "flash-the-bootloader-to-a-block-device"], [18, "flash-the-bootloader-to-a-block-device"], [19, "flash-the-bootloader-to-a-block-device"], [22, "flash-the-bootloader-to-a-block-device"], [23, "flash-the-bootloader-to-a-block-device"], [24, "flash-the-bootloader-to-a-block-device"]], "Flashing SPI NOR Flash via UUU-Tool": [[1, "flashing-spi-nor-flash-via-uuu-tool"], [5, "flashing-spi-nor-flash-via-uuu-tool"], [9, "flashing-spi-nor-flash-via-uuu-tool"], [11, "flashing-spi-nor-flash-via-uuu-tool"], [17, "flashing-spi-nor-flash-via-uuu-tool"]], "Flashing U-boot Image to eMMC via UUU-Tool": [[1, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [3, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [4, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [5, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [7, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [8, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [9, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [11, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [13, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [14, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [15, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [16, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [17, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [18, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [19, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [22, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [23, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [24, "flashing-u-boot-image-to-emmc-via-uuu-tool"]], "Flashing wic Image to eMMC via UUU-Tool": [[1, "flashing-wic-image-to-emmc-via-uuu-tool"], [3, "flashing-wic-image-to-emmc-via-uuu-tool"], [4, "flashing-wic-image-to-emmc-via-uuu-tool"], [5, "flashing-wic-image-to-emmc-via-uuu-tool"], [7, "flashing-wic-image-to-emmc-via-uuu-tool"], [8, "flashing-wic-image-to-emmc-via-uuu-tool"], [9, "flashing-wic-image-to-emmc-via-uuu-tool"], [11, "flashing-wic-image-to-emmc-via-uuu-tool"], [13, "flashing-wic-image-to-emmc-via-uuu-tool"], [14, "flashing-wic-image-to-emmc-via-uuu-tool"], [15, "flashing-wic-image-to-emmc-via-uuu-tool"], [16, "flashing-wic-image-to-emmc-via-uuu-tool"], [17, "flashing-wic-image-to-emmc-via-uuu-tool"], [18, "flashing-wic-image-to-emmc-via-uuu-tool"], [19, "flashing-wic-image-to-emmc-via-uuu-tool"], [22, "flashing-wic-image-to-emmc-via-uuu-tool"], [23, "flashing-wic-image-to-emmc-via-uuu-tool"], [24, "flashing-wic-image-to-emmc-via-uuu-tool"]], "Format SD-Card": [[1, "format-sd-card"], [3, "format-sd-card"], [4, "format-sd-card"], [5, "format-sd-card"], [7, "format-sd-card"], [8, "format-sd-card"], [9, "format-sd-card"], [11, "format-sd-card"], [13, "format-sd-card"], [14, "format-sd-card"], [15, "format-sd-card"], [16, "format-sd-card"], [17, "format-sd-card"], [18, "format-sd-card"], [19, "format-sd-card"], [22, "format-sd-card"], [23, "format-sd-card"], [24, "format-sd-card"]], "Framebuffer Console": [[31, "framebuffer-console"], [33, "framebuffer-console"], [34, "framebuffer-console"]], "GPIO Fan": [[1, "gpio-fan"], [3, "gpio-fan"], [4, "gpio-fan"], [5, "gpio-fan"], [7, "gpio-fan"], [8, "gpio-fan"], [9, "gpio-fan"], [11, "gpio-fan"], [14, "gpio-fan"], [15, "gpio-fan"], [16, "gpio-fan"], [17, "gpio-fan"]], "GPIOs": [[1, "gpios"], [3, "gpios"], [4, "gpios"], [5, "gpios"], [7, "gpios"], [8, "gpios"], [9, "gpios"], [11, "gpios"], [13, "gpios"], [14, "gpios"], [15, "gpios"], [16, "gpios"], [17, "gpios"], [18, "gpios"], [19, "gpios"], [22, "gpios"], [23, "gpios"], [24, "gpios"]], "GPIOs via sysfs": [[1, "gpios-via-sysfs"], [3, "gpios-via-sysfs"], [4, "gpios-via-sysfs"], [5, "gpios-via-sysfs"], [7, "gpios-via-sysfs"], [8, "gpios-via-sysfs"], [9, "gpios-via-sysfs"], [11, "gpios-via-sysfs"], [13, "gpios-via-sysfs"], [14, "gpios-via-sysfs"], [15, "gpios-via-sysfs"], [16, "gpios-via-sysfs"], [17, "gpios-via-sysfs"], [18, "gpios-via-sysfs"], [19, "gpios-via-sysfs"], [22, "gpios-via-sysfs"], [23, "gpios-via-sysfs"], [24, "gpios-via-sysfs"]], "Generating Source Mirrors, working Offline": [[31, "generating-source-mirrors-working-offline"], [33, "generating-source-mirrors-working-offline"], [34, "generating-source-mirrors-working-offline"]], "Get Chromium Running on the Target": [[1, "get-chromium-running-on-the-target"], [3, "get-chromium-running-on-the-target"], [4, "get-chromium-running-on-the-target"], [7, "get-chromium-running-on-the-target"], [14, "get-chromium-running-on-the-target"], [15, "get-chromium-running-on-the-target"], [16, "get-chromium-running-on-the-target"]], "Get Images": [[1, "get-images"], [3, "get-images"], [4, "get-images"], [5, "get-images"], [7, "get-images"], [8, "get-images"], [9, "get-images"], [11, "get-images"], [13, "get-images"], [14, "get-images"], [15, "get-images"], [16, "get-images"], [17, "get-images"], [18, "get-images"], [19, "get-images"], [22, "get-images"], [23, "get-images"], [24, "get-images"]], "Get phyLinux": [[31, "get-phylinux"], [33, "get-phylinux"], [34, "get-phylinux"]], "Get the BSP": [[1, "get-the-bsp"], [3, "get-the-bsp"], [4, "get-the-bsp"], [5, "get-the-bsp"], [7, "get-the-bsp"], [8, "get-the-bsp"], [9, "get-the-bsp"], [11, "get-the-bsp"], [13, "get-the-bsp"], [14, "get-the-bsp"], [15, "get-the-bsp"], [16, "get-the-bsp"], [17, "get-the-bsp"], [18, "get-the-bsp"], [19, "get-the-bsp"], [22, "get-the-bsp"], [23, "get-the-bsp"], [24, "get-the-bsp"]], "Get the Image": [[1, "get-the-image"], [3, "get-the-image"], [4, "get-the-image"], [5, "get-the-image"], [7, "get-the-image"], [8, "get-the-image"], [9, "get-the-image"], [11, "get-the-image"], [13, "get-the-image"], [14, "get-the-image"], [15, "get-the-image"], [16, "get-the-image"], [17, "get-the-image"], [18, "get-the-image"], [19, "get-the-image"], [22, "get-the-image"], [23, "get-the-image"], [24, "get-the-image"]], "Get the SDK": [[1, "get-the-sdk"], [3, "get-the-sdk"], [4, "get-the-sdk"], [5, "get-the-sdk"], [7, "get-the-sdk"], [8, "get-the-sdk"], [9, "get-the-sdk"], [11, "get-the-sdk"], [13, "get-the-sdk"], [14, "get-the-sdk"], [15, "get-the-sdk"], [16, "get-the-sdk"], [17, "get-the-sdk"], [19, "get-the-sdk"], [22, "get-the-sdk"], [23, "get-the-sdk"], [24, "get-the-sdk"]], "Get the needed binaries": [[1, "get-the-needed-binaries"], [3, "get-the-needed-binaries"], [4, "get-the-needed-binaries"], [5, "get-the-needed-binaries"], [7, "get-the-needed-binaries"], [8, "get-the-needed-binaries"], [9, "get-the-needed-binaries"], [11, "get-the-needed-binaries"], [13, "get-the-needed-binaries"], [14, "get-the-needed-binaries"], [15, "get-the-needed-binaries"], [16, "get-the-needed-binaries"], [17, "get-the-needed-binaries"], [18, "get-the-needed-binaries"], [19, "get-the-needed-binaries"], [22, "get-the-needed-binaries"], [23, "get-the-needed-binaries"], [24, "get-the-needed-binaries"]], "Get the source code": [[1, "get-the-source-code"], [3, "get-the-source-code"], [4, "get-the-source-code"], [5, "get-the-source-code"], [7, "get-the-source-code"], [8, "get-the-source-code"], [9, "get-the-source-code"], [11, "get-the-source-code"], [13, "get-the-source-code"], [14, "get-the-source-code"], [15, "get-the-source-code"], [16, "get-the-source-code"], [17, "get-the-source-code"], [18, "get-the-source-code"], [19, "get-the-source-code"], [22, "get-the-source-code"], [23, "get-the-source-code"], [24, "get-the-source-code"]], "Getting Started": [[1, "getting-started"], [3, "getting-started"], [4, "getting-started"], [5, "getting-started"], [7, "getting-started"], [8, "getting-started"], [9, "getting-started"], [11, "getting-started"], [13, "getting-started"], [14, "getting-started"], [15, "getting-started"], [16, "getting-started"], [17, "getting-started"], [18, "getting-started"], [19, "getting-started"], [22, "getting-started"], [23, "getting-started"], [24, "getting-started"]], "Getting the Firmware Examples": [[1, "getting-the-firmware-examples"], [3, "getting-the-firmware-examples"], [4, "getting-the-firmware-examples"], [9, "getting-the-firmware-examples"], [11, "getting-the-firmware-examples"], [14, "getting-the-firmware-examples"], [15, "getting-the-firmware-examples"], [16, "getting-the-firmware-examples"], [17, "getting-the-firmware-examples"]], "Getting the Sources": [[1, "getting-the-sources"], [3, "getting-the-sources"], [4, "getting-the-sources"], [9, "getting-the-sources"], [11, "getting-the-sources"], [14, "getting-the-sources"], [15, "getting-the-sources"], [16, "getting-the-sources"], [17, "getting-the-sources"]], "Git Configuration": [[31, "git-configuration"], [33, "git-configuration"], [34, "git-configuration"]], "Git Repositories": [[1, "git-repositories"], [3, "git-repositories"], [4, "git-repositories"], [5, "git-repositories"], [7, "git-repositories"], [8, "git-repositories"], [9, "git-repositories"], [11, "git-repositories"], [13, "git-repositories"], [14, "git-repositories"], [15, "git-repositories"], [16, "git-repositories"], [17, "git-repositories"], [18, "git-repositories"], [19, "git-repositories"], [22, "git-repositories"], [23, "git-repositories"], [24, "git-repositories"]], "Gparted": [[1, "gparted"], [3, "gparted"], [4, "gparted"], [5, "gparted"], [7, "gparted"], [8, "gparted"], [9, "gparted"], [11, "gparted"], [13, "gparted"], [14, "gparted"], [15, "gparted"], [16, "gparted"], [17, "gparted"], [18, "gparted"], [19, "gparted"], [22, "gparted"], [23, "gparted"], [24, "gparted"]], "HEAD": [[2, "head"], [6, "head"], [10, "head"], [12, "head"]], "Host Network Preparation": [[1, "host-network-preparation"], [3, "host-network-preparation"], [4, "host-network-preparation"], [5, "host-network-preparation"], [7, "host-network-preparation"], [8, "host-network-preparation"], [9, "host-network-preparation"], [11, "host-network-preparation"], [13, "host-network-preparation"], [14, "host-network-preparation"], [15, "host-network-preparation"], [16, "host-network-preparation"], [17, "host-network-preparation"], [18, "host-network-preparation"], [19, "host-network-preparation"], [22, "host-network-preparation"], [23, "host-network-preparation"], [24, "host-network-preparation"]], "Host preparations for UUU-Tool Usage": [[1, "host-preparations-for-uuu-tool-usage"], [3, "host-preparations-for-uuu-tool-usage"], [4, "host-preparations-for-uuu-tool-usage"], [5, "host-preparations-for-uuu-tool-usage"], [7, "host-preparations-for-uuu-tool-usage"], [8, "host-preparations-for-uuu-tool-usage"], [9, "host-preparations-for-uuu-tool-usage"], [11, "host-preparations-for-uuu-tool-usage"], [13, "host-preparations-for-uuu-tool-usage"], [14, "host-preparations-for-uuu-tool-usage"], [15, "host-preparations-for-uuu-tool-usage"], [16, "host-preparations-for-uuu-tool-usage"], [17, "host-preparations-for-uuu-tool-usage"], [18, "host-preparations-for-uuu-tool-usage"], [19, "host-preparations-for-uuu-tool-usage"], [22, "host-preparations-for-uuu-tool-usage"], [23, "host-preparations-for-uuu-tool-usage"], [24, "host-preparations-for-uuu-tool-usage"]], "I2C EEPROM on phyCORE-i.MX8MM": [[1, "i2c-eeprom-on-som"], [3, "i2c-eeprom-on-som"], [4, "i2c-eeprom-on-som"]], "I2C EEPROM on phyCORE-i.MX8MN": [[5, "i2c-eeprom-on-som"], [7, "i2c-eeprom-on-som"], [8, "i2c-eeprom-on-som"]], "I2C EEPROM on phyCORE-i.MX8MP": [[11, "i2c-eeprom-on-som"], [13, "i2c-eeprom-on-som"], [14, "i2c-eeprom-on-som"], [15, "i2c-eeprom-on-som"], [16, "i2c-eeprom-on-som"], [17, "i2c-eeprom-on-som"], [18, "i2c-eeprom-on-som"], [19, "i2c-eeprom-on-som"]], "I2C EEPROM on phyCORE-i.MX8MP-FPSC": [[9, "i2c-eeprom-on-som"]], "I2C EEPROM on phyCORE-i.MX93": [[22, "i2c-eeprom-on-som"], [23, "i2c-eeprom-on-som"], [24, "i2c-eeprom-on-som"]], "ISP": [[9, "isp"], [11, "isp"], [14, "isp"], [15, "isp"], [16, "isp"], [17, "isp"]], "Images": [[31, "images"], [33, "images"], [34, "images"]], "Initial Setup": [[27, "initial-setup"], [29, "initial-setup"], [30, "initial-setup"]], "Initialization": [[31, "initialization"], [33, "initialization"], [34, "initialization"]], "Inspect your Build Configuration": [[31, "inspect-your-build-configuration"], [33, "inspect-your-build-configuration"], [34, "inspect-your-build-configuration"]], "Install the SDK": [[1, "install-the-sdk"], [3, "install-the-sdk"], [4, "install-the-sdk"], [5, "install-the-sdk"], [7, "install-the-sdk"], [8, "install-the-sdk"], [9, "install-the-sdk"], [11, "install-the-sdk"], [13, "install-the-sdk"], [14, "install-the-sdk"], [15, "install-the-sdk"], [16, "install-the-sdk"], [17, "install-the-sdk"], [18, "install-the-sdk"], [19, "install-the-sdk"], [22, "install-the-sdk"], [23, "install-the-sdk"], [24, "install-the-sdk"]], "Installation": [[31, "installation"], [33, "installation"], [34, "installation"]], "Installing Required Tools": [[1, "installing-required-tools"], [3, "installing-required-tools"], [4, "installing-required-tools"], [5, "installing-required-tools"], [7, "installing-required-tools"], [8, "installing-required-tools"], [9, "installing-required-tools"], [11, "installing-required-tools"], [13, "installing-required-tools"], [14, "installing-required-tools"], [15, "installing-required-tools"], [16, "installing-required-tools"], [17, "installing-required-tools"], [18, "installing-required-tools"], [19, "installing-required-tools"], [22, "installing-required-tools"], [23, "installing-required-tools"], [24, "installing-required-tools"]], "Installing a distro": [[1, "installing-a-distro"], [9, "installing-a-distro"], [11, "installing-a-distro"], [17, "installing-a-distro"]], "Installing the OS": [[1, "installing-the-os"], [3, "installing-the-os"], [4, "installing-the-os"], [5, "installing-the-os"], [7, "installing-the-os"], [8, "installing-the-os"], [9, "installing-the-os"], [11, "installing-the-os"], [13, "installing-the-os"], [14, "installing-the-os"], [15, "installing-the-os"], [16, "installing-the-os"], [17, "installing-the-os"], [18, "installing-the-os"], [19, "installing-the-os"], [22, "installing-the-os"], [23, "installing-the-os"], [24, "installing-the-os"]], "Introduction": [[1, "introduction"], [3, "introduction"], [4, "introduction"], [5, "introduction"], [7, "introduction"], [8, "introduction"], [9, "introduction"], [11, "introduction"], [13, "introduction"], [14, "introduction"], [15, "introduction"], [16, "introduction"], [17, "introduction"], [18, "introduction"], [19, "introduction"], [22, "introduction"], [23, "introduction"], [24, "introduction"], [27, null], [29, null], [30, null]], "I\u00b2C Bus": [[1, "i2c-bus"], [3, "i2c-bus"], [4, "i2c-bus"], [5, "i2c-bus"], [7, "i2c-bus"], [8, "i2c-bus"], [9, "i2c-bus"], [11, "i2c-bus"], [13, "i2c-bus"], [14, "i2c-bus"], [15, "i2c-bus"], [16, "i2c-bus"], [17, "i2c-bus"], [18, "i2c-bus"], [19, "i2c-bus"], [22, "i2c-bus"], [23, "i2c-bus"], [24, "i2c-bus"]], "Kernel": [[1, "kernel"], [3, "kernel"], [4, "kernel"], [5, "kernel"], [7, "kernel"], [8, "kernel"], [9, "kernel"], [11, "kernel"], [13, "kernel"], [14, "kernel"], [15, "kernel"], [16, "kernel"], [17, "kernel"], [18, "kernel"], [19, "kernel"], [22, "kernel"], [23, "kernel"], [24, "kernel"]], "Kernel and Bootloader Configuration": [[31, "kernel-and-bootloader-configuration"], [33, "kernel-and-bootloader-configuration"], [34, "kernel-and-bootloader-configuration"]], "Kernel and Bootloader Recipe and Version": [[31, "kernel-and-bootloader-recipe-and-version"], [33, "kernel-and-bootloader-recipe-and-version"], [34, "kernel-and-bootloader-recipe-and-version"]], "Kernel network-environment": [[1, "kernel-network-environment"], [3, "kernel-network-environment"], [4, "kernel-network-environment"], [5, "kernel-network-environment"], [7, "kernel-network-environment"], [8, "kernel-network-environment"], [9, "kernel-network-environment"], [11, "kernel-network-environment"], [13, "kernel-network-environment"], [14, "kernel-network-environment"], [15, "kernel-network-environment"], [16, "kernel-network-environment"], [17, "kernel-network-environment"], [18, "kernel-network-environment"], [19, "kernel-network-environment"], [22, "kernel-network-environment"], [23, "kernel-network-environment"], [24, "kernel-network-environment"]], "Kernel standalone build": [[1, "kernel-standalone-build"], [3, "kernel-standalone-build"], [4, "kernel-standalone-build"], [5, "kernel-standalone-build"], [7, "kernel-standalone-build"], [8, "kernel-standalone-build"], [9, "kernel-standalone-build"], [11, "kernel-standalone-build"], [13, "kernel-standalone-build"], [14, "kernel-standalone-build"], [15, "kernel-standalone-build"], [16, "kernel-standalone-build"], [17, "kernel-standalone-build"], [18, "kernel-standalone-build"], [19, "kernel-standalone-build"], [22, "kernel-standalone-build"], [23, "kernel-standalone-build"], [24, "kernel-standalone-build"]], "Keyring Switching Process": [[27, "keyring-switching-process"], [29, "keyring-switching-process"], [30, "keyring-switching-process"]], "Kirkstone": [[28, "kirkstone"], [32, "kirkstone"]], "LEDs": [[1, "leds"], [3, "leds"], [4, "leds"], [5, "leds"], [7, "leds"], [8, "leds"], [9, "leds"], [11, "leds"], [13, "leds"], [14, "leds"], [15, "leds"], [16, "leds"], [17, "leds"], [18, "leds"], [19, "leds"], [22, "leds"], [23, "leds"], [24, "leds"]], "Layers": [[31, "layers"], [33, "layers"], [34, "layers"]], "Libra Components": [[9, "sbc-components"]], "Libra i.MX 8M Plus FPSC Manuals": [[10, null]], "Machine": [[31, "machine"], [33, "machine"], [34, "machine"]], "Mainline HEAD": [[12, "mainline-head"]], "Mickledore": [[28, "mickledore"], [32, "mickledore"]], "Mini": [[1, "mini"], [3, "mini"], [4, "mini"]], "NAND": [[27, "nand"], [29, "nand"], [30, "nand"]], "NFS Server Setup": [[1, "nfs-server-setup"], [3, "nfs-server-setup"], [4, "nfs-server-setup"], [5, "nfs-server-setup"], [7, "nfs-server-setup"], [8, "nfs-server-setup"], [9, "nfs-server-setup"], [11, "nfs-server-setup"], [13, "nfs-server-setup"], [14, "nfs-server-setup"], [15, "nfs-server-setup"], [16, "nfs-server-setup"], [17, "nfs-server-setup"], [18, "nfs-server-setup"], [19, "nfs-server-setup"], [22, "nfs-server-setup"], [23, "nfs-server-setup"], [24, "nfs-server-setup"]], "NPU": [[9, "npu"], [11, "npu"], [14, "npu"], [15, "npu"], [16, "npu"], [17, "npu"]], "NXP Examples for eIQ": [[14, "nxp-examples-for-eiq"], [15, "nxp-examples-for-eiq"]], "Network": [[1, "network"], [3, "network"], [4, "network"], [5, "network"], [7, "network"], [8, "network"], [9, "network"], [11, "network"], [13, "network"], [14, "network"], [15, "network"], [16, "network"], [17, "network"], [18, "network"], [19, "network"], [22, "network"], [23, "network"], [24, "network"]], "Network Environment Customization": [[1, "network-environment-customization"], [3, "network-environment-customization"], [4, "network-environment-customization"], [5, "network-environment-customization"], [7, "network-environment-customization"], [8, "network-environment-customization"], [9, "network-environment-customization"], [11, "network-environment-customization"], [13, "network-environment-customization"], [14, "network-environment-customization"], [15, "network-environment-customization"], [16, "network-environment-customization"], [17, "network-environment-customization"], [18, "network-environment-customization"], [19, "network-environment-customization"], [22, "network-environment-customization"], [23, "network-environment-customization"], [24, "network-environment-customization"]], "Network Settings on Target": [[1, "network-settings-on-target"], [3, "network-settings-on-target"], [4, "network-settings-on-target"], [5, "network-settings-on-target"], [7, "network-settings-on-target"], [8, "network-settings-on-target"], [9, "network-settings-on-target"], [11, "network-settings-on-target"], [14, "network-settings-on-target"], [15, "network-settings-on-target"], [16, "network-settings-on-target"], [17, "network-settings-on-target"], [22, "network-settings-on-target"], [23, "network-settings-on-target"], [24, "network-settings-on-target"]], "Notes about Packages and Recipes": [[31, "notes-about-packages-and-recipes"], [33, "notes-about-packages-and-recipes"], [34, "notes-about-packages-and-recipes"]], "Official Documentation": [[31, "official-documentation"], [33, "official-documentation"], [34, "official-documentation"]], "On-Chip OTP Controller (OCOTP_CTRL) - eFuses": [[1, "on-chip-otp-controller-ocotp-ctrl-efuses"], [3, "on-chip-otp-controller-ocotp-ctrl-efuses"], [4, "on-chip-otp-controller-ocotp-ctrl-efuses"], [5, "on-chip-otp-controller-ocotp-ctrl-efuses"], [7, "on-chip-otp-controller-ocotp-ctrl-efuses"], [8, "on-chip-otp-controller-ocotp-ctrl-efuses"], [9, "on-chip-otp-controller-ocotp-ctrl-efuses"], [11, "on-chip-otp-controller-ocotp-ctrl-efuses"], [13, "on-chip-otp-controller-ocotp-ctrl-efuses"], [14, "on-chip-otp-controller-ocotp-ctrl-efuses"], [15, "on-chip-otp-controller-ocotp-ctrl-efuses"], [16, "on-chip-otp-controller-ocotp-ctrl-efuses"], [17, "on-chip-otp-controller-ocotp-ctrl-efuses"], [18, "on-chip-otp-controller-ocotp-ctrl-efuses"], [19, "on-chip-otp-controller-ocotp-ctrl-efuses"], [22, "on-chip-otp-controller-ocotp-ctrl-efuses"], [23, "on-chip-otp-controller-ocotp-ctrl-efuses"], [24, "on-chip-otp-controller-ocotp-ctrl-efuses"]], "PCIe": [[1, "pcie"], [3, "pcie"], [4, "pcie"], [9, "pcie"], [11, "pcie"], [14, "pcie"], [15, "pcie"], [16, "pcie"], [17, "pcie"]], "PHYTEC BSP Introduction": [[31, "phytec-bsp-introduction"], [33, "phytec-bsp-introduction"], [34, "phytec-bsp-introduction"]], "PHYTEC Documentation": [[1, null], [3, null], [4, null], [5, null], [7, null], [8, null], [9, null], [11, null], [13, null], [14, null], [15, null], [16, null], [17, null], [18, null], [19, null], [22, null], [23, null], [24, null], [31, "phytec-documentation"], [33, "phytec-documentation"], [34, "phytec-documentation"]], "PHYTEC i.MX 8M Mini BSP Device Tree Concept": [[1, "phytec-soc-bsp-device-tree-concept"], [3, "phytec-soc-bsp-device-tree-concept"], [4, "phytec-soc-bsp-device-tree-concept"]], "PHYTEC i.MX 8M Nano BSP Device Tree Concept": [[5, "phytec-soc-bsp-device-tree-concept"], [7, "phytec-soc-bsp-device-tree-concept"], [8, "phytec-soc-bsp-device-tree-concept"]], "PHYTEC i.MX 8M Plus BSP Device Tree Concept": [[9, "phytec-soc-bsp-device-tree-concept"], [11, "phytec-soc-bsp-device-tree-concept"], [13, "phytec-soc-bsp-device-tree-concept"], [14, "phytec-soc-bsp-device-tree-concept"], [15, "phytec-soc-bsp-device-tree-concept"], [16, "phytec-soc-bsp-device-tree-concept"], [17, "phytec-soc-bsp-device-tree-concept"], [18, "phytec-soc-bsp-device-tree-concept"], [19, "phytec-soc-bsp-device-tree-concept"]], "PHYTEC i.MX 93 BSP Device Tree Concept": [[22, "phytec-soc-bsp-device-tree-concept"], [23, "phytec-soc-bsp-device-tree-concept"], [24, "phytec-soc-bsp-device-tree-concept"]], "PWM Fan": [[22, "pwm-fan"], [23, "pwm-fan"], [24, "pwm-fan"]], "PXP": [[22, "pxp"], [23, "pxp"], [24, "pxp"]], "Package the kernel in a FIT image": [[1, "package-the-kernel-in-a-fit-image"], [9, "package-the-kernel-in-a-fit-image"], [11, "package-the-kernel-in-a-fit-image"], [17, "package-the-kernel-in-a-fit-image"]], "Patch the Kernel or Bootloader using the \u201cTemporary Method\u201d": [[31, "patch-the-kernel-or-bootloader-using-the-temporary-method"], [33, "patch-the-kernel-or-bootloader-using-the-temporary-method"], [34, "patch-the-kernel-or-bootloader-using-the-temporary-method"]], "Patch the Kernel or Bootloader with devtool": [[31, "patch-the-kernel-or-bootloader-with-devtool"], [33, "patch-the-kernel-or-bootloader-with-devtool"], [34, "patch-the-kernel-or-bootloader-with-devtool"]], "Place Images on Host for Netboot": [[1, "place-images-on-host-for-netboot"], [3, "place-images-on-host-for-netboot"], [4, "place-images-on-host-for-netboot"], [5, "place-images-on-host-for-netboot"], [7, "place-images-on-host-for-netboot"], [8, "place-images-on-host-for-netboot"], [9, "place-images-on-host-for-netboot"], [11, "place-images-on-host-for-netboot"], [13, "place-images-on-host-for-netboot"], [14, "place-images-on-host-for-netboot"], [15, "place-images-on-host-for-netboot"], [16, "place-images-on-host-for-netboot"], [17, "place-images-on-host-for-netboot"], [18, "place-images-on-host-for-netboot"], [19, "place-images-on-host-for-netboot"], [22, "place-images-on-host-for-netboot"], [23, "place-images-on-host-for-netboot"], [24, "place-images-on-host-for-netboot"]], "Playback": [[1, "playback"], [3, "playback"], [4, "playback"], [9, "playback"], [11, "playback"], [14, "playback"], [15, "playback"], [16, "playback"], [17, "playback"], [22, "playback"], [23, "playback"], [23, "id5"], [24, "playback"], [24, "id5"]], "Poky": [[31, "poky"], [31, "id1"], [33, "poky"], [33, "id1"], [34, "poky"], [34, "id1"]], "Power Management": [[1, "power-management"], [3, "power-management"], [4, "power-management"], [5, "power-management"], [7, "power-management"], [8, "power-management"], [9, "power-management"], [11, "power-management"], [13, "power-management"], [14, "power-management"], [15, "power-management"], [16, "power-management"], [17, "power-management"], [18, "power-management"], [19, "power-management"], [22, "power-management"], [23, "power-management"], [24, "power-management"]], "Pre-built Images": [[31, "pre-built-images"], [33, "pre-built-images"], [34, "pre-built-images"]], "Prepare Target": [[1, "prepare-target"], [3, "prepare-target"], [4, "prepare-target"], [5, "prepare-target"], [7, "prepare-target"], [8, "prepare-target"], [9, "prepare-target"], [11, "prepare-target"], [13, "prepare-target"], [14, "prepare-target"], [15, "prepare-target"], [16, "prepare-target"], [17, "prepare-target"], [18, "prepare-target"], [19, "prepare-target"], [22, "prepare-target"], [23, "prepare-target"], [24, "prepare-target"]], "Pulseaudio Configuration": [[1, "pulseaudio-configuration"], [3, "pulseaudio-configuration"], [4, "pulseaudio-configuration"], [9, "pulseaudio-configuration"], [11, "pulseaudio-configuration"], [14, "pulseaudio-configuration"], [15, "pulseaudio-configuration"], [16, "pulseaudio-configuration"], [17, "pulseaudio-configuration"], [23, "pulseaudio-configuration"], [24, "pulseaudio-configuration"]], "Qt Demo": [[1, "qt-demo"], [3, "qt-demo"], [4, "qt-demo"], [9, "qt-demo"], [11, "qt-demo"], [13, "qt-demo"], [14, "qt-demo"], [15, "qt-demo"], [16, "qt-demo"], [17, "qt-demo"], [18, "qt-demo"], [19, "qt-demo"], [22, "qt-demo"], [23, "qt-demo"], [24, "qt-demo"]], "RAM Benchmark": [[31, "ram-benchmark"], [33, "ram-benchmark"], [34, "ram-benchmark"]], "RAUC": [[1, "rauc"], [3, "rauc"], [4, "rauc"], [5, "rauc"], [7, "rauc"], [8, "rauc"], [9, "rauc"], [11, "rauc"], [13, "rauc"], [14, "rauc"], [15, "rauc"], [16, "rauc"], [17, "rauc"], [18, "rauc"], [19, "rauc"], [22, "rauc"], [23, "rauc"], [24, "rauc"]], "RAUC BSP Example Setup": [[27, "rauc-bsp-example-setup"], [29, "rauc-bsp-example-setup"], [30, "rauc-bsp-example-setup"]], "RAUC Update & Device Management Manuals": [[28, null]], "RS232": [[1, "rs232"], [3, "rs232"], [4, "rs232"], [5, "rs232"], [7, "rs232"], [8, "rs232"], [9, "rs232"], [11, "rs232"], [13, "rs232"], [14, "rs232"], [15, "rs232"], [16, "rs232"], [17, "rs232"], [18, "rs232"], [19, "rs232"], [23, "rs232"], [24, "rs232"]], "RS232/RS485": [[1, "rs232-rs485"], [3, "rs232-rs485"], [4, "rs232-rs485"], [5, "rs232-rs485"], [7, "rs232-rs485"], [8, "rs232-rs485"], [9, "rs232-rs485"], [11, "rs232-rs485"], [13, "rs232-rs485"], [14, "rs232-rs485"], [15, "rs232-rs485"], [16, "rs232-rs485"], [17, "rs232-rs485"], [18, "rs232-rs485"], [19, "rs232-rs485"], [23, "rs232-rs485"], [24, "rs232-rs485"]], "RS485": [[1, "rs485"], [3, "rs485"], [4, "rs485"], [5, "rs485"], [7, "rs485"], [8, "rs485"], [9, "rs485"], [11, "rs485"], [13, "rs485"], [14, "rs485"], [15, "rs485"], [16, "rs485"], [17, "rs485"], [18, "rs485"], [19, "rs485"], [23, "rs485"], [24, "rs485"]], "RS485 full-duplex": [[9, "rs485-full-duplex"], [11, "rs485-full-duplex"], [13, "rs485-full-duplex"], [16, "rs485-full-duplex"], [17, "rs485-full-duplex"], [19, "rs485-full-duplex"]], "RS485 half-duplex": [[1, "rs485-half-duplex"], [4, "rs485-half-duplex"], [5, "rs485-half-duplex"], [8, "rs485-half-duplex"], [9, "rs485-half-duplex"], [11, "rs485-half-duplex"], [13, "rs485-half-duplex"], [16, "rs485-half-duplex"], [17, "rs485-half-duplex"], [19, "rs485-half-duplex"]], "RTC": [[1, "rtc"], [3, "rtc"], [4, "rtc"], [5, "rtc"], [7, "rtc"], [8, "rtc"], [9, "rtc"], [11, "rtc"], [13, "rtc"], [14, "rtc"], [15, "rtc"], [16, "rtc"], [17, "rtc"], [18, "rtc"], [19, "rtc"], [22, "rtc"], [23, "rtc"], [24, "rtc"]], "RTC Parameters": [[1, "rtc-parameters"], [4, "rtc-parameters"], [5, "rtc-parameters"], [8, "rtc-parameters"], [9, "rtc-parameters"], [11, "rtc-parameters"], [13, "rtc-parameters"], [16, "rtc-parameters"], [17, "rtc-parameters"], [18, "rtc-parameters"], [19, "rtc-parameters"], [22, "rtc-parameters"], [23, "rtc-parameters"], [24, "rtc-parameters"]], "RTC Wakealarm": [[1, "rtc-wakealarm"], [3, "rtc-wakealarm"], [4, "rtc-wakealarm"], [5, "rtc-wakealarm"], [7, "rtc-wakealarm"], [8, "rtc-wakealarm"], [9, "rtc-wakealarm"], [11, "rtc-wakealarm"], [14, "rtc-wakealarm"], [15, "rtc-wakealarm"], [16, "rtc-wakealarm"], [17, "rtc-wakealarm"], [22, "rtc-wakealarm"], [23, "rtc-wakealarm"], [24, "rtc-wakealarm"]], "Reading Fuse Values in Linux": [[1, "reading-fuse-values-in-linux"], [3, "reading-fuse-values-in-linux"], [4, "reading-fuse-values-in-linux"], [5, "reading-fuse-values-in-linux"], [7, "reading-fuse-values-in-linux"], [8, "reading-fuse-values-in-linux"], [9, "reading-fuse-values-in-linux"], [11, "reading-fuse-values-in-linux"], [13, "reading-fuse-values-in-linux"], [14, "reading-fuse-values-in-linux"], [15, "reading-fuse-values-in-linux"], [16, "reading-fuse-values-in-linux"], [17, "reading-fuse-values-in-linux"], [18, "reading-fuse-values-in-linux"], [19, "reading-fuse-values-in-linux"], [22, "reading-fuse-values-in-linux"], [23, "reading-fuse-values-in-linux"], [24, "reading-fuse-values-in-linux"]], "Reading Fuse Values in uBoot": [[1, "reading-fuse-values-in-uboot"], [3, "reading-fuse-values-in-uboot"], [4, "reading-fuse-values-in-uboot"], [5, "reading-fuse-values-in-uboot"], [7, "reading-fuse-values-in-uboot"], [8, "reading-fuse-values-in-uboot"], [9, "reading-fuse-values-in-uboot"], [11, "reading-fuse-values-in-uboot"], [13, "reading-fuse-values-in-uboot"], [14, "reading-fuse-values-in-uboot"], [15, "reading-fuse-values-in-uboot"], [16, "reading-fuse-values-in-uboot"], [17, "reading-fuse-values-in-uboot"], [18, "reading-fuse-values-in-uboot"], [19, "reading-fuse-values-in-uboot"], [22, "reading-fuse-values-in-uboot"], [23, "reading-fuse-values-in-uboot"], [24, "reading-fuse-values-in-uboot"]], "Recipes": [[31, "recipes"], [33, "recipes"], [34, "recipes"]], "Reference": [[27, "reference"], [29, "reference"], [30, "reference"]], "Reliable Write": [[1, "reliable-write"], [3, "reliable-write"], [4, "reliable-write"], [5, "reliable-write"], [7, "reliable-write"], [8, "reliable-write"], [9, "reliable-write"], [11, "reliable-write"], [13, "reliable-write"], [14, "reliable-write"], [15, "reliable-write"], [16, "reliable-write"], [17, "reliable-write"], [18, "reliable-write"], [19, "reliable-write"], [22, "reliable-write"], [23, "reliable-write"], [24, "reliable-write"]], "Repo": [[31, "repo"], [33, "repo"], [34, "repo"]], "Rescue EEPROM Data": [[3, "rescue-eeprom-data"], [4, "rescue-eeprom-data"], [7, "rescue-eeprom-data"], [8, "rescue-eeprom-data"], [14, "rescue-eeprom-data"], [15, "rescue-eeprom-data"], [16, "rescue-eeprom-data"], [22, "rescue-eeprom-data"], [23, "rescue-eeprom-data"], [24, "rescue-eeprom-data"]], "Resizing ext4 Root Filesystem": [[1, "resizing-ext4-root-filesystem"], [1, "id2"], [3, "resizing-ext4-root-filesystem"], [3, "id1"], [4, "resizing-ext4-root-filesystem"], [4, "id1"], [5, "resizing-ext4-root-filesystem"], [5, "id2"], [7, "resizing-ext4-root-filesystem"], [7, "id1"], [8, "resizing-ext4-root-filesystem"], [8, "id1"], [9, "resizing-ext4-root-filesystem"], [9, "id2"], [11, "resizing-ext4-root-filesystem"], [11, "id2"], [13, "resizing-ext4-root-filesystem"], [13, "id2"], [14, "resizing-ext4-root-filesystem"], [14, "id3"], [15, "resizing-ext4-root-filesystem"], [15, "id1"], [16, "resizing-ext4-root-filesystem"], [16, "id1"], [17, "resizing-ext4-root-filesystem"], [17, "id2"], [18, "resizing-ext4-root-filesystem"], [18, "id2"], [19, "resizing-ext4-root-filesystem"], [19, "id2"], [22, "resizing-ext4-root-filesystem"], [22, "id2"], [23, "resizing-ext4-root-filesystem"], [23, "id2"], [24, "resizing-ext4-root-filesystem"], [24, "id2"]], "Restore default volumes": [[1, "restore-default-volumes"], [4, "restore-default-volumes"], [9, "restore-default-volumes"], [11, "restore-default-volumes"], [16, "restore-default-volumes"], [17, "restore-default-volumes"], [22, "restore-default-volumes"], [23, "restore-default-volumes"], [23, "id4"], [24, "restore-default-volumes"], [24, "id4"]], "Run container": [[31, "run-container"], [33, "run-container"], [34, "run-container"]], "Running Examples from Linux using Remoteproc": [[1, "running-examples-from-linux-using-remoteproc"], [3, "running-examples-from-linux-using-remoteproc"], [4, "running-examples-from-linux-using-remoteproc"], [9, "running-examples-from-linux-using-remoteproc"], [11, "running-examples-from-linux-using-remoteproc"], [14, "running-examples-from-linux-using-remoteproc"], [15, "running-examples-from-linux-using-remoteproc"], [16, "running-examples-from-linux-using-remoteproc"], [17, "running-examples-from-linux-using-remoteproc"], [22, "running-examples-from-linux-using-remoteproc"], [23, "running-examples-from-linux-using-remoteproc"], [24, "running-examples-from-linux-using-remoteproc"]], "Running Examples from U-Boot": [[1, "running-examples-from-u-boot"], [3, "running-examples-from-u-boot"], [4, "running-examples-from-u-boot"], [9, "running-examples-from-u-boot"], [11, "running-examples-from-u-boot"], [14, "running-examples-from-u-boot"], [15, "running-examples-from-u-boot"], [16, "running-examples-from-u-boot"], [17, "running-examples-from-u-boot"], [22, "running-examples-from-u-boot"], [23, "running-examples-from-u-boot"], [24, "running-examples-from-u-boot"]], "Running M33 Core Examples": [[22, "running-mcore-examples"], [23, "running-mcore-examples"], [24, "running-mcore-examples"]], "Running M4 Core Examples": [[1, "running-mcore-examples"], [3, "running-mcore-examples"], [4, "running-mcore-examples"]], "Running M7 Core Examples": [[9, "running-mcore-examples"], [11, "running-mcore-examples"], [14, "running-mcore-examples"], [15, "running-mcore-examples"], [16, "running-mcore-examples"], [17, "running-mcore-examples"]], "SD/MMC Card": [[1, "sd-mmc-card"], [3, "sd-mmc-card"], [4, "sd-mmc-card"], [5, "sd-mmc-card"], [7, "sd-mmc-card"], [8, "sd-mmc-card"], [9, "sd-mmc-card"], [11, "sd-mmc-card"], [13, "sd-mmc-card"], [14, "sd-mmc-card"], [15, "sd-mmc-card"], [16, "sd-mmc-card"], [17, "sd-mmc-card"], [18, "sd-mmc-card"], [19, "sd-mmc-card"], [22, "sd-mmc-card"], [23, "sd-mmc-card"], [24, "sd-mmc-card"]], "SPI Master": [[1, "spi-master"], [3, "spi-master"], [4, "spi-master"], [5, "spi-master"], [7, "spi-master"], [8, "spi-master"], [9, "spi-master"], [11, "spi-master"], [13, "spi-master"], [14, "spi-master"], [15, "spi-master"], [16, "spi-master"], [17, "spi-master"], [18, "spi-master"], [19, "spi-master"]], "SPI NOR Flash": [[1, "spi-nor-flash"], [3, "spi-nor-flash"], [4, "spi-nor-flash"], [5, "spi-nor-flash"], [7, "spi-nor-flash"], [8, "spi-nor-flash"], [9, "spi-nor-flash"], [11, "spi-nor-flash"], [14, "spi-nor-flash"], [15, "spi-nor-flash"], [16, "spi-nor-flash"], [17, "spi-nor-flash"]], "Scarthgap": [[28, "scarthgap"], [32, "scarthgap"]], "Security Measurement: Downgrade Barrier": [[27, "security-measurement-downgrade-barrier"], [29, "security-measurement-downgrade-barrier"], [30, "security-measurement-downgrade-barrier"]], "Set ${overlays} variable": [[1, "set-overlays-variable"], [3, "set-overlays-variable"], [4, "set-overlays-variable"], [5, "set-overlays-variable"], [7, "set-overlays-variable"], [8, "set-overlays-variable"], [9, "set-overlays-variable"], [11, "set-overlays-variable"], [14, "set-overlays-variable"], [15, "set-overlays-variable"], [16, "set-overlays-variable"], [17, "set-overlays-variable"], [22, "set-overlays-variable"], [23, "set-overlays-variable"], [24, "set-overlays-variable"]], "Set the bootenv.txt for Netboot": [[1, "set-the-bootenv-txt-for-netboot"], [3, "set-the-bootenv-txt-for-netboot"], [4, "set-the-bootenv-txt-for-netboot"], [5, "set-the-bootenv-txt-for-netboot"], [7, "set-the-bootenv-txt-for-netboot"], [8, "set-the-bootenv-txt-for-netboot"], [9, "set-the-bootenv-txt-for-netboot"], [11, "set-the-bootenv-txt-for-netboot"], [14, "set-the-bootenv-txt-for-netboot"], [15, "set-the-bootenv-txt-for-netboot"], [16, "set-the-bootenv-txt-for-netboot"], [17, "set-the-bootenv-txt-for-netboot"], [22, "set-the-bootenv-txt-for-netboot"], [23, "set-the-bootenv-txt-for-netboot"], [24, "set-the-bootenv-txt-for-netboot"]], "Setscene Task Warning": [[31, "setscene-task-warning"], [33, "setscene-task-warning"], [34, "setscene-task-warning"]], "Setting Up the Host": [[31, "setting-up-the-host"], [33, "setting-up-the-host"], [34, "setting-up-the-host"]], "Setup sources": [[1, "setup-sources"], [3, "setup-sources"], [4, "setup-sources"], [5, "setup-sources"], [7, "setup-sources"], [8, "setup-sources"], [9, "setup-sources"], [11, "setup-sources"], [13, "setup-sources"], [14, "setup-sources"], [15, "setup-sources"], [16, "setup-sources"], [17, "setup-sources"], [18, "setup-sources"], [19, "setup-sources"], [22, "setup-sources"], [23, "setup-sources"], [24, "setup-sources"]], "Single Display": [[9, "single-display"], [11, "single-display"], [14, "single-display"], [15, "single-display"], [16, "single-display"], [17, "single-display"]], "SoM Variants": [[1, "som-variants"], [9, "som-variants"], [11, "som-variants"], [17, "som-variants"]], "Standalone Build preparation": [[1, "standalone-build-preparation"], [3, "standalone-build-preparation"], [4, "standalone-build-preparation"], [5, "standalone-build-preparation"], [7, "standalone-build-preparation"], [8, "standalone-build-preparation"], [9, "standalone-build-preparation"], [11, "standalone-build-preparation"], [13, "standalone-build-preparation"], [14, "standalone-build-preparation"], [15, "standalone-build-preparation"], [16, "standalone-build-preparation"], [17, "standalone-build-preparation"], [18, "standalone-build-preparation"], [19, "standalone-build-preparation"], [22, "standalone-build-preparation"], [23, "standalone-build-preparation"], [24, "standalone-build-preparation"]], "Start the Build": [[31, "start-the-build"], [33, "start-the-build"], [34, "start-the-build"]], "Starting bootloader via UUU-Tool": [[1, "starting-bootloader-via-uuu-tool"], [3, "starting-bootloader-via-uuu-tool"], [4, "starting-bootloader-via-uuu-tool"], [5, "starting-bootloader-via-uuu-tool"], [7, "starting-bootloader-via-uuu-tool"], [8, "starting-bootloader-via-uuu-tool"], [9, "starting-bootloader-via-uuu-tool"], [11, "starting-bootloader-via-uuu-tool"], [13, "starting-bootloader-via-uuu-tool"], [14, "starting-bootloader-via-uuu-tool"], [15, "starting-bootloader-via-uuu-tool"], [16, "starting-bootloader-via-uuu-tool"], [17, "starting-bootloader-via-uuu-tool"], [18, "starting-bootloader-via-uuu-tool"], [19, "starting-bootloader-via-uuu-tool"], [22, "starting-bootloader-via-uuu-tool"], [23, "starting-bootloader-via-uuu-tool"], [24, "starting-bootloader-via-uuu-tool"]], "Starting the Build Process": [[1, "starting-the-build-process"], [3, "starting-the-build-process"], [4, "starting-the-build-process"], [5, "starting-the-build-process"], [7, "starting-the-build-process"], [8, "starting-the-build-process"], [9, "starting-the-build-process"], [11, "starting-the-build-process"], [13, "starting-the-build-process"], [14, "starting-the-build-process"], [15, "starting-the-build-process"], [16, "starting-the-build-process"], [17, "starting-the-build-process"], [18, "starting-the-build-process"], [19, "starting-the-build-process"], [22, "starting-the-build-process"], [23, "starting-the-build-process"], [24, "starting-the-build-process"]], "Streaming Bundles over HTTP": [[27, "streaming-bundles-over-http"], [29, "streaming-bundles-over-http"], [30, "streaming-bundles-over-http"]], "Supported Hardware": [[1, "supported-hardware"], [3, "supported-hardware"], [4, "supported-hardware"], [5, "supported-hardware"], [7, "supported-hardware"], [8, "supported-hardware"], [9, "supported-hardware"], [11, "supported-hardware"], [13, "supported-hardware"], [14, "supported-hardware"], [15, "supported-hardware"], [16, "supported-hardware"], [17, "supported-hardware"], [18, "supported-hardware"], [19, "supported-hardware"], [22, "supported-hardware"], [23, "supported-hardware"], [24, "supported-hardware"]], "Suspend to RAM": [[1, "suspend-to-ram"], [3, "suspend-to-ram"], [4, "suspend-to-ram"], [5, "suspend-to-ram"], [7, "suspend-to-ram"], [8, "suspend-to-ram"], [9, "suspend-to-ram"], [11, "suspend-to-ram"], [14, "suspend-to-ram"], [15, "suspend-to-ram"], [16, "suspend-to-ram"], [17, "suspend-to-ram"], [22, "suspend-to-ram"], [23, "suspend-to-ram"], [24, "suspend-to-ram"]], "Switch back to legacyboot": [[1, "switch-back-to-legacyboot"], [9, "switch-back-to-legacyboot"], [11, "switch-back-to-legacyboot"], [17, "switch-back-to-legacyboot"]], "Switch between UART1 RS485/RS232": [[1, "id12"], [1, "id15"], [3, "id11"], [3, "id14"], [4, "id11"], [4, "id14"], [5, "id19"], [7, "id18"], [8, "id18"]], "Switch between UART1 RS485/RS232 using Pos4 of switch(S1)": [[5, "id16"], [7, "id15"], [8, "id15"]], "Switch between USB HOST/OTG using Pos5 of switch(S1)": [[5, "id13"], [7, "id12"], [8, "id12"]], "Switch to only efi boot": [[1, "switch-to-only-efi-boot"], [9, "switch-to-only-efi-boot"], [11, "switch-to-only-efi-boot"], [17, "switch-to-only-efi-boot"]], "Switching RAUC Keyrings": [[27, "switching-rauc-keyrings"], [29, "switching-rauc-keyrings"], [30, "switching-rauc-keyrings"]], "System Configuration": [[27, "system-configuration"], [29, "system-configuration"], [30, "system-configuration"]], "TFTP Server Setup": [[1, "tftp-server-setup"], [3, "tftp-server-setup"], [4, "tftp-server-setup"], [5, "tftp-server-setup"], [7, "tftp-server-setup"], [8, "tftp-server-setup"], [9, "tftp-server-setup"], [11, "tftp-server-setup"], [13, "tftp-server-setup"], [14, "tftp-server-setup"], [15, "tftp-server-setup"], [16, "tftp-server-setup"], [17, "tftp-server-setup"], [18, "tftp-server-setup"], [19, "tftp-server-setup"], [22, "tftp-server-setup"], [23, "tftp-server-setup"], [24, "tftp-server-setup"]], "TPM": [[23, "tpm"], [24, "tpm"]], "Table of Contents": [[2, null], [2, null], [2, null], [6, null], [6, null], [6, null], [10, null], [12, null], [12, null], [12, null], [12, null], [12, null], [12, null], [12, null], [12, null], [21, null], [21, null], [21, null], [28, null], [28, null], [28, null], [32, null], [32, null], [32, null]], "The Yocto Project": [[31, null], [33, null], [34, null]], "Thermal Management": [[1, "thermal-management"], [3, "thermal-management"], [4, "thermal-management"], [5, "thermal-management"], [7, "thermal-management"], [8, "thermal-management"], [9, "thermal-management"], [11, "thermal-management"], [13, "thermal-management"], [14, "thermal-management"], [15, "thermal-management"], [16, "thermal-management"], [17, "thermal-management"], [18, "thermal-management"], [19, "thermal-management"], [22, "thermal-management"], [23, "thermal-management"], [24, "thermal-management"]], "Toaster": [[31, "toaster"], [33, "toaster"], [34, "toaster"]], "Tools Provided in the Prebuild Image": [[31, "tools-provided-in-the-prebuild-image"], [33, "tools-provided-in-the-prebuild-image"], [34, "tools-provided-in-the-prebuild-image"]], "Triple Display": [[16, "triple-display"]], "Troubleshooting": [[31, "troubleshooting"], [33, "troubleshooting"], [34, "troubleshooting"]], "U-Boot": [[1, "u-boot"], [3, "u-boot"], [4, "u-boot"], [5, "u-boot"], [7, "u-boot"], [8, "u-boot"], [9, "u-boot"], [11, "u-boot"], [13, "u-boot"], [14, "u-boot"], [15, "u-boot"], [16, "u-boot"], [17, "u-boot"], [18, "u-boot"], [19, "u-boot"], [22, "u-boot"], [23, "u-boot"], [24, "u-boot"], [27, "u-boot"], [29, "u-boot"], [30, "u-boot"]], "U-Boot Environment Variables": [[27, "u-boot-environment-variables"], [29, "u-boot-environment-variables"], [30, "u-boot-environment-variables"]], "U-Boot standalone build": [[1, "u-boot-standalone-build"], [3, "u-boot-standalone-build"], [4, "u-boot-standalone-build"], [5, "u-boot-standalone-build"], [7, "u-boot-standalone-build"], [8, "u-boot-standalone-build"], [9, "u-boot-standalone-build"], [11, "u-boot-standalone-build"], [13, "u-boot-standalone-build"], [14, "u-boot-standalone-build"], [15, "u-boot-standalone-build"], [16, "u-boot-standalone-build"], [17, "u-boot-standalone-build"], [18, "u-boot-standalone-build"], [19, "u-boot-standalone-build"], [22, "u-boot-standalone-build"], [23, "u-boot-standalone-build"], [24, "u-boot-standalone-build"]], "U-boot External Environment": [[1, "u-boot-external-environment"], [3, "u-boot-external-environment"], [4, "u-boot-external-environment"], [5, "u-boot-external-environment"], [7, "u-boot-external-environment"], [8, "u-boot-external-environment"], [9, "u-boot-external-environment"], [11, "u-boot-external-environment"], [14, "u-boot-external-environment"], [15, "u-boot-external-environment"], [16, "u-boot-external-environment"], [17, "u-boot-external-environment"], [22, "u-boot-external-environment"], [23, "u-boot-external-environment"], [24, "u-boot-external-environment"]], "U-boot network-environment": [[1, "u-boot-network-environment"], [3, "u-boot-network-environment"], [4, "u-boot-network-environment"], [5, "u-boot-network-environment"], [7, "u-boot-network-environment"], [8, "u-boot-network-environment"], [9, "u-boot-network-environment"], [11, "u-boot-network-environment"], [13, "u-boot-network-environment"], [14, "u-boot-network-environment"], [15, "u-boot-network-environment"], [16, "u-boot-network-environment"], [17, "u-boot-network-environment"], [18, "u-boot-network-environment"], [19, "u-boot-network-environment"], [22, "u-boot-network-environment"], [23, "u-boot-network-environment"], [24, "u-boot-network-environment"]], "USB Device": [[1, "usb-device"], [3, "usb-device"], [4, "usb-device"], [5, "usb-device"], [7, "usb-device"], [8, "usb-device"]], "USB Host Controller": [[1, "usb-host-controller"], [3, "usb-host-controller"], [4, "usb-host-controller"], [5, "usb-host-controller"], [7, "usb-host-controller"], [8, "usb-host-controller"], [9, "usb-host-controller"], [11, "usb-host-controller"], [13, "usb-host-controller"], [14, "usb-host-controller"], [15, "usb-host-controller"], [16, "usb-host-controller"], [17, "usb-host-controller"], [18, "usb-host-controller"], [19, "usb-host-controller"], [22, "usb-host-controller"], [23, "usb-host-controller"], [24, "usb-host-controller"]], "USB OTG": [[1, "usb-otg"], [3, "usb-otg"], [4, "usb-otg"], [5, "usb-otg"], [7, "usb-otg"], [8, "usb-otg"]], "Updating with RAUC": [[27, "updating-with-rauc"], [29, "updating-with-rauc"], [30, "updating-with-rauc"]], "Upgrading the barebox Environment from Previous BSP Releases": [[31, "upgrading-the-barebox-environment-from-previous-bsp-releases"], [33, "upgrading-the-barebox-environment-from-previous-bsp-releases"], [34, "upgrading-the-barebox-environment-from-previous-bsp-releases"]], "Use Case Examples": [[27, "use-case-examples"], [29, "use-case-examples"], [30, "use-case-examples"]], "Using bmap-tools": [[1, "using-bmap-tools"], [4, "using-bmap-tools"], [5, "using-bmap-tools"], [8, "using-bmap-tools"], [9, "using-bmap-tools"], [11, "using-bmap-tools"], [13, "using-bmap-tools"], [16, "using-bmap-tools"], [17, "using-bmap-tools"], [18, "using-bmap-tools"], [19, "using-bmap-tools"], [22, "using-bmap-tools"], [23, "using-bmap-tools"], [24, "using-bmap-tools"]], "Using build-container": [[31, "using-build-container"], [33, "using-build-container"], [34, "using-build-container"]], "Using dd": [[1, "using-dd"], [4, "using-dd"], [5, "using-dd"], [8, "using-dd"], [9, "using-dd"], [11, "using-dd"], [13, "using-dd"], [16, "using-dd"], [17, "using-dd"], [18, "using-dd"], [19, "using-dd"], [22, "using-dd"], [23, "using-dd"], [24, "using-dd"]], "Using partup": [[1, "using-partup"], [4, "using-partup"], [5, "using-partup"], [8, "using-partup"], [9, "using-partup"], [11, "using-partup"], [13, "using-partup"], [16, "using-partup"], [17, "using-partup"], [18, "using-partup"], [19, "using-partup"], [22, "using-partup"], [23, "using-partup"], [24, "using-partup"]], "Using the SDK": [[1, "using-the-sdk"], [3, "using-the-sdk"], [4, "using-the-sdk"], [5, "using-the-sdk"], [7, "using-the-sdk"], [8, "using-the-sdk"], [9, "using-the-sdk"], [11, "using-the-sdk"], [13, "using-the-sdk"], [14, "using-the-sdk"], [15, "using-the-sdk"], [16, "using-the-sdk"], [17, "using-the-sdk"], [18, "using-the-sdk"], [19, "using-the-sdk"], [22, "using-the-sdk"], [23, "using-the-sdk"], [24, "using-the-sdk"], [31, "using-the-sdk"], [33, "using-the-sdk"], [34, "using-the-sdk"]], "Using the SDK with GNU Autotools": [[31, "using-the-sdk-with-gnu-autotools"], [33, "using-the-sdk-with-gnu-autotools"], [34, "using-the-sdk-with-gnu-autotools"]], "Via userspace Commands": [[1, "via-userspace-commands"], [3, "via-userspace-commands"], [4, "via-userspace-commands"], [5, "via-userspace-commands"], [7, "via-userspace-commands"], [8, "via-userspace-commands"], [9, "via-userspace-commands"], [11, "via-userspace-commands"], [13, "via-userspace-commands"], [14, "via-userspace-commands"], [15, "via-userspace-commands"], [16, "via-userspace-commands"], [17, "via-userspace-commands"], [18, "via-userspace-commands"], [19, "via-userspace-commands"], [22, "via-userspace-commands"], [23, "via-userspace-commands"], [24, "via-userspace-commands"]], "Video": [[1, "video"], [3, "video"], [4, "video"], [9, "video"], [11, "video"], [13, "video"], [14, "video"], [15, "video"], [16, "video"], [17, "video"], [18, "video"], [19, "video"], [22, "video"], [23, "video"], [24, "video"]], "Videos with Gstreamer": [[1, "videos-with-gstreamer"], [3, "videos-with-gstreamer"], [4, "videos-with-gstreamer"], [9, "videos-with-gstreamer"], [11, "videos-with-gstreamer"], [13, "videos-with-gstreamer"], [14, "videos-with-gstreamer"], [15, "videos-with-gstreamer"], [16, "videos-with-gstreamer"], [17, "videos-with-gstreamer"], [18, "videos-with-gstreamer"], [19, "videos-with-gstreamer"], [22, "videos-with-gstreamer"], [23, "videos-with-gstreamer"], [24, "videos-with-gstreamer"]], "Visibility": [[1, "visibility"], [3, "visibility"], [4, "visibility"], [5, "visibility"], [7, "visibility"], [8, "visibility"], [9, "visibility"], [11, "visibility"], [14, "visibility"], [14, "id1"], [15, "visibility"], [16, "visibility"], [17, "visibility"]], "Vocabulary": [[31, "vocabulary"], [33, "vocabulary"], [34, "vocabulary"]], "WLAN": [[1, "wlan"], [3, "wlan"], [4, "wlan"], [5, "wlan"], [7, "wlan"], [8, "wlan"], [9, "wlan"], [11, "wlan"], [14, "wlan"], [15, "wlan"], [16, "wlan"], [17, "wlan"], [24, "wlan"]], "Watchdog": [[1, "watchdog"], [3, "watchdog"], [4, "watchdog"], [5, "watchdog"], [7, "watchdog"], [8, "watchdog"], [9, "watchdog"], [11, "watchdog"], [13, "watchdog"], [14, "watchdog"], [15, "watchdog"], [16, "watchdog"], [17, "watchdog"], [18, "watchdog"], [19, "watchdog"], [22, "watchdog"], [23, "watchdog"], [24, "watchdog"]], "Watchdog Support in systemd": [[1, "watchdog-support-in-systemd"], [3, "watchdog-support-in-systemd"], [4, "watchdog-support-in-systemd"], [5, "watchdog-support-in-systemd"], [7, "watchdog-support-in-systemd"], [8, "watchdog-support-in-systemd"], [9, "watchdog-support-in-systemd"], [11, "watchdog-support-in-systemd"], [13, "watchdog-support-in-systemd"], [14, "watchdog-support-in-systemd"], [15, "watchdog-support-in-systemd"], [16, "watchdog-support-in-systemd"], [17, "watchdog-support-in-systemd"], [18, "watchdog-support-in-systemd"], [19, "watchdog-support-in-systemd"], [22, "watchdog-support-in-systemd"], [23, "watchdog-support-in-systemd"], [24, "watchdog-support-in-systemd"]], "Welcome to the PHYTEC BSP Documentation": [[26, null]], "Weston Configuration": [[9, "weston-configuration"], [11, "weston-configuration"], [13, "weston-configuration"], [14, "weston-configuration"], [15, "weston-configuration"], [16, "weston-configuration"], [17, "weston-configuration"], [18, "weston-configuration"], [19, "weston-configuration"]], "Working with Kernel Modules": [[31, "working-with-kernel-modules"], [33, "working-with-kernel-modules"], [34, "working-with-kernel-modules"]], "Working with Poky and Bitbake": [[31, "working-with-poky-and-bitbake"], [33, "working-with-poky-and-bitbake"], [34, "working-with-poky-and-bitbake"]], "Working with UUU-Tool": [[1, "working-with-uuu-tool"], [3, "working-with-uuu-tool"], [4, "working-with-uuu-tool"], [5, "working-with-uuu-tool"], [7, "working-with-uuu-tool"], [8, "working-with-uuu-tool"], [9, "working-with-uuu-tool"], [11, "working-with-uuu-tool"], [13, "working-with-uuu-tool"], [14, "working-with-uuu-tool"], [15, "working-with-uuu-tool"], [16, "working-with-uuu-tool"], [17, "working-with-uuu-tool"], [18, "working-with-uuu-tool"], [19, "working-with-uuu-tool"], [22, "working-with-uuu-tool"], [23, "working-with-uuu-tool"], [24, "working-with-uuu-tool"]], "Working with the Kernel and Bootloader using SRC_URI in local.conf": [[31, "working-with-the-kernel-and-bootloader-using-src-uri-in-local-conf"], [33, "working-with-the-kernel-and-bootloader-using-src-uri-in-local-conf"], [34, "working-with-the-kernel-and-bootloader-using-src-uri-in-local-conf"]], "Working with udev": [[31, "working-with-udev"], [33, "working-with-udev"], [34, "working-with-udev"]], "Write the Image to SD Card": [[1, "write-the-image-to-sd-card"], [3, "write-the-image-to-sd-card"], [4, "write-the-image-to-sd-card"], [5, "write-the-image-to-sd-card"], [7, "write-the-image-to-sd-card"], [8, "write-the-image-to-sd-card"], [9, "write-the-image-to-sd-card"], [11, "write-the-image-to-sd-card"], [13, "write-the-image-to-sd-card"], [14, "write-the-image-to-sd-card"], [15, "write-the-image-to-sd-card"], [16, "write-the-image-to-sd-card"], [17, "write-the-image-to-sd-card"], [18, "write-the-image-to-sd-card"], [19, "write-the-image-to-sd-card"], [22, "write-the-image-to-sd-card"], [23, "write-the-image-to-sd-card"], [24, "write-the-image-to-sd-card"]], "Yocto Documentation": [[31, "yocto-documentation"], [33, "yocto-documentation"], [34, "yocto-documentation"]], "Yocto Introduction": [[31, "yocto-introduction"], [33, "yocto-introduction"], [34, "yocto-introduction"]], "Yocto Reference Manuals": [[32, null]], "base (fsl-community-bsp-base)": [[31, "base-fsl-community-bsp-base"], [33, "base-fsl-community-bsp-base"], [34, "base-fsl-community-bsp-base"]], "bbnsm Power Key": [[22, "bbnsm-power-key"], [23, "bbnsm-power-key"], [24, "bbnsm-power-key"]], "eMMC": [[27, "emmc"], [29, "emmc"], [30, "emmc"]], "eMMC Boot Partitions": [[1, "emmc-boot-partitions"], [3, "emmc-boot-partitions"], [4, "emmc-boot-partitions"], [5, "emmc-boot-partitions"], [7, "emmc-boot-partitions"], [8, "emmc-boot-partitions"], [9, "emmc-boot-partitions"], [11, "emmc-boot-partitions"], [13, "emmc-boot-partitions"], [14, "emmc-boot-partitions"], [15, "emmc-boot-partitions"], [16, "emmc-boot-partitions"], [17, "emmc-boot-partitions"], [18, "emmc-boot-partitions"], [19, "emmc-boot-partitions"], [22, "emmc-boot-partitions"], [23, "emmc-boot-partitions"], [24, "emmc-boot-partitions"], [27, "emmc-boot-partitions"], [29, "emmc-boot-partitions"], [30, "emmc-boot-partitions"]], "eMMC Devices": [[1, "emmc-devices"], [3, "emmc-devices"], [4, "emmc-devices"], [5, "emmc-devices"], [7, "emmc-devices"], [8, "emmc-devices"], [9, "emmc-devices"], [11, "emmc-devices"], [13, "emmc-devices"], [14, "emmc-devices"], [15, "emmc-devices"], [16, "emmc-devices"], [17, "emmc-devices"], [18, "emmc-devices"], [19, "emmc-devices"], [22, "emmc-devices"], [23, "emmc-devices"], [24, "emmc-devices"]], "i.MX 8 Manuals": [[0, null], [0, null]], "i.MX 8M Mini M4 Core": [[1, "soc-mcore"], [3, "soc-mcore"], [4, "soc-mcore"]], "i.MX 8M Mini Manuals": [[2, null]], "i.MX 8M Mini Pin Muxing": [[1, "soc-pin-muxing"], [3, "soc-pin-muxing"], [4, "soc-pin-muxing"]], "i.MX 8M Nano Manuals": [[6, null]], "i.MX 8M Nano Pin Muxing": [[5, "soc-pin-muxing"], [7, "soc-pin-muxing"], [8, "soc-pin-muxing"]], "i.MX 8M Plus M7 Core": [[9, "soc-mcore"], [11, "soc-mcore"], [14, "soc-mcore"], [15, "soc-mcore"], [16, "soc-mcore"], [17, "soc-mcore"]], "i.MX 8M Plus Manuals": [[12, null]], "i.MX 8M Plus Pin Muxing": [[9, "soc-pin-muxing"], [11, "soc-pin-muxing"], [13, "soc-pin-muxing"], [14, "soc-pin-muxing"], [15, "soc-pin-muxing"], [16, "soc-pin-muxing"], [17, "soc-pin-muxing"], [18, "soc-pin-muxing"], [19, "soc-pin-muxing"]], "i.MX 9 Manuals": [[20, null], [20, null]], "i.MX 93 M33 Core": [[22, "soc-mcore"], [23, "soc-mcore"], [24, "soc-mcore"]], "i.MX 93 Manuals": [[21, null]], "i.MX 93 Pin Muxing": [[22, "soc-pin-muxing"], [23, "soc-pin-muxing"], [24, "soc-pin-muxing"]], "kmssink Plugin ID Evaluation": [[3, "kmssink-plugin-id-evaluation"], [14, "kmssink-plugin-id-evaluation"], [15, "kmssink-plugin-id-evaluation"]], "meta-ampliphy": [[31, "meta-ampliphy"], [33, "meta-ampliphy"], [34, "meta-ampliphy"]], "meta-browser": [[31, "meta-browser"], [33, "meta-browser"], [34, "meta-browser"]], "meta-freescale": [[31, "meta-freescale"], [33, "meta-freescale"], [34, "meta-freescale"]], "meta-freescale-3rdparty": [[31, "meta-freescale-3rdparty"], [33, "meta-freescale-3rdparty"], [34, "meta-freescale-3rdparty"]], "meta-freescale-distro": [[31, "meta-freescale-distro"], [33, "meta-freescale-distro"], [34, "meta-freescale-distro"]], "meta-fsl-bsp-release": [[31, "meta-fsl-bsp-release"], [33, "meta-fsl-bsp-release"], [34, "meta-fsl-bsp-release"]], "meta-gstreamer1.0": [[31, "meta-gstreamer1-0"], [33, "meta-gstreamer1-0"], [34, "meta-gstreamer1-0"]], "meta-nodejs": [[31, "meta-nodejs"], [33, "meta-nodejs"], [34, "meta-nodejs"]], "meta-openembedded": [[31, "meta-openembedded"], [33, "meta-openembedded"], [34, "meta-openembedded"]], "meta-phytec": [[31, "meta-phytec"], [33, "meta-phytec"], [34, "meta-phytec"]], "meta-qt6": [[31, "meta-qt6"], [33, "meta-qt6"], [34, "meta-qt6"]], "meta-qt6-phytec": [[31, "meta-qt6-phytec"], [33, "meta-qt6-phytec"], [34, "meta-qt6-phytec"]], "meta-rauc": [[31, "meta-rauc"], [33, "meta-rauc"], [34, "meta-rauc"]], "meta-rust": [[31, "meta-rust"], [33, "meta-rust"], [34, "meta-rust"]], "meta-security": [[31, "meta-security"], [33, "meta-security"], [34, "meta-security"]], "meta-selinux": [[31, "meta-selinux"], [33, "meta-selinux"], [34, "meta-selinux"]], "meta-timesys": [[31, "meta-timesys"], [33, "meta-timesys"], [34, "meta-timesys"]], "meta-virtualization": [[31, "meta-virtualization"], [33, "meta-virtualization"], [34, "meta-virtualization"]], "phyBOARD-Nash i.MX 93 Components": [[22, "phyboard-nash-i-mx-93-components"], [23, "phyboard-nash-i-mx-93-components"], [24, "phyboard-nash-i-mx-93-components"]], "phyBOARD-Polis Components": [[1, "sbc-components"], [3, "sbc-components"], [4, "sbc-components"], [5, "sbc-components"], [7, "sbc-components"], [8, "sbc-components"]], "phyBOARD-Pollux Components": [[11, "sbc-components"], [13, "sbc-components"], [14, "sbc-components"], [15, "sbc-components"], [16, "sbc-components"], [17, "sbc-components"], [18, "sbc-components"], [19, "sbc-components"]], "phyBOARD-Segin i.MX 93 Components": [[22, "phyboard-segin-i-mx-93-components"], [23, "phyboard-segin-i-mx-93-components"], [24, "phyboard-segin-i-mx-93-components"]], "phyCORE-i.MX 6UL/ULL Bluetooth": [[31, "phycore-i-mx-6ul-ull-bluetooth"], [33, "phycore-i-mx-6ul-ull-bluetooth"], [34, "phycore-i-mx-6ul-ull-bluetooth"]], "phyLinux": [[31, "phylinux"], [33, "phylinux"], [34, "phylinux"]], "phyLinux Documentation": [[31, "phylinux-documentation"], [33, "phylinux-documentation"], [34, "phylinux-documentation"]], "site.conf Setup": [[31, "site-conf-setup"], [33, "site-conf-setup"], [34, "site-conf-setup"]], "snvs Power Key": [[9, "snvs-power-key"], [11, "snvs-power-key"], [13, "snvs-power-key"], [14, "snvs-power-key"], [15, "snvs-power-key"], [16, "snvs-power-key"], [17, "snvs-power-key"], [18, "snvs-power-key"], [19, "snvs-power-key"]]}, "docnames": ["bsp/imx8/imx8", "bsp/imx8/imx8mm/head", "bsp/imx8/imx8mm/imx8mm", "bsp/imx8/imx8mm/pd22.1.1", "bsp/imx8/imx8mm/pd23.1.0", "bsp/imx8/imx8mn/head", "bsp/imx8/imx8mn/imx8mn", "bsp/imx8/imx8mn/pd22.1.1", "bsp/imx8/imx8mn/pd23.1.0", "bsp/imx8/imx8mp-libra-fpsc/head", "bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc", "bsp/imx8/imx8mp/head", "bsp/imx8/imx8mp/imx8mp", "bsp/imx8/imx8mp/mainline-head", "bsp/imx8/imx8mp/pd22.1.1", "bsp/imx8/imx8mp/pd22.1.2", "bsp/imx8/imx8mp/pd23.1.0", "bsp/imx8/imx8mp/pd24.1.0_nxp", "bsp/imx8/imx8mp/pd24.1.1", "bsp/imx8/imx8mp/pd24.1.2", "bsp/imx9/imx9", "bsp/imx9/imx93/imx93", "bsp/imx9/imx93/pd24.1.0", "bsp/imx9/imx93/pd24.1.1", "bsp/imx9/imx93/pd24.2.0", "contributing_links", "index", "rauc/kirkstone", "rauc/manual-index", "rauc/mickledore", "rauc/scarthgap", "yocto/kirkstone", "yocto/manual-index", "yocto/mickledore", "yocto/scarthgap"], "envversion": {"sphinx": 64, "sphinx.domains.c": 3, "sphinx.domains.changeset": 1, "sphinx.domains.citation": 1, "sphinx.domains.cpp": 9, "sphinx.domains.index": 1, "sphinx.domains.javascript": 3, "sphinx.domains.math": 2, "sphinx.domains.python": 4, "sphinx.domains.rst": 2, "sphinx.domains.std": 2}, "filenames": ["bsp/imx8/imx8.rst", "bsp/imx8/imx8mm/head.rst", "bsp/imx8/imx8mm/imx8mm.rst", "bsp/imx8/imx8mm/pd22.1.1.rst", "bsp/imx8/imx8mm/pd23.1.0.rst", "bsp/imx8/imx8mn/head.rst", "bsp/imx8/imx8mn/imx8mn.rst", "bsp/imx8/imx8mn/pd22.1.1.rst", "bsp/imx8/imx8mn/pd23.1.0.rst", "bsp/imx8/imx8mp-libra-fpsc/head.rst", "bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.rst", "bsp/imx8/imx8mp/head.rst", "bsp/imx8/imx8mp/imx8mp.rst", "bsp/imx8/imx8mp/mainline-head.rst", "bsp/imx8/imx8mp/pd22.1.1.rst", "bsp/imx8/imx8mp/pd22.1.2.rst", "bsp/imx8/imx8mp/pd23.1.0.rst", "bsp/imx8/imx8mp/pd24.1.0_nxp.rst", "bsp/imx8/imx8mp/pd24.1.1.rst", "bsp/imx8/imx8mp/pd24.1.2.rst", "bsp/imx9/imx9.rst", "bsp/imx9/imx93/imx93.rst", "bsp/imx9/imx93/pd24.1.0.rst", "bsp/imx9/imx93/pd24.1.1.rst", "bsp/imx9/imx93/pd24.2.0.rst", "contributing_links.rst", "index.rst", "rauc/kirkstone.rst", "rauc/manual-index.rst", "rauc/mickledore.rst", "rauc/scarthgap.rst", "yocto/kirkstone.rst", "yocto/manual-index.rst", "yocto/mickledore.rst", "yocto/scarthgap.rst"], "indexentries": {}, "objects": {}, "objnames": {}, "objtypes": {}, "terms": {"": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 27, 29, 30, 31, 33, 34], "0": [0, 1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 20, 22, 23, 24, 27, 29, 30], "00": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "0000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0001": [31, 33, 34], "001": [31, 33, 34], "0050": [22, 23, 24], "0051": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "0052": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0058": [22, 23, 24], "0059": [3, 4, 7, 8, 14, 15, 16], "00d": [31, 33, 34], "01": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "010": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 23], "0100": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "012": [14, 15, 16], "0123456789": [1, 3, 4, 5, 7, 8], "02": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 29, 30, 31, 33, 34], "02013": 31, "02029": 33, "03": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "03123": 34, "03513": 31, "04": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "04729": 33, "04_2": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23], "05": [1, 3, 7, 9, 11, 14, 15, 16, 17, 23, 24, 27, 29, 30, 31, 33], "06": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 34], "063": 31, "0644": [31, 33, 34], "07": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 30, 34], "070": 15, "077": 33, "08": [15, 17, 18, 24, 27, 29, 30, 31, 33, 34], "09": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 27, 29, 30, 31, 34], "0a": [27, 29, 30], "0b0010": [22, 23, 24], "0b01": [22, 23, 24], "0c": [27, 29, 30], "0d": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0f": 15, "0pointer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "0x00": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x000000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x000004cd": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0x000764": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x01": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x0104": [1, 3, 4, 5, 7, 8], "0x1": [1, 3, 4, 5, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x10": [27, 29, 30], "0x100": [27, 29, 30], "0x100000": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "0x11": [4, 8, 16], "0x14": [27, 29, 30], "0x140": [9, 11, 13, 16, 17, 18, 19], "0x16": [1, 3, 4, 5, 7, 8], "0x18": [27, 29, 30], "0x1c0b20": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "0x1d6b": [1, 3, 4, 5, 7, 8], "0x1f": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x1ffe0000": [22, 23, 24], "0x2": [1, 3, 4, 5, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x200": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x20000103": [22, 23, 24], "0x20020000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0x20020002": [22, 23, 24], "0x201e0000": [22, 23, 24], "0x30350000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "0x30e": [22, 23, 24], "0x31e": [22, 23, 24], "0x4": [27, 29, 30], "0x40": [5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x400000": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "0x40480000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "0x409": [1, 3, 4, 5, 7, 8], "0x42": [1, 3, 4], "0x43810080": [22, 23, 24], "0x43820080": [22, 23, 24], "0x43830080": [22, 23, 24], "0x47400080": [22, 23, 24], "0x47510000": [22, 23, 24], "0x48000000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0x49": [14, 15], "0x4ec": [22, 23, 24], "0x4f0": [22, 23, 24], "0x4f4": [22, 23, 24], "0x50": [22, 23, 24], "0x51": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "0x567890aa": [22, 23, 24], "0x58": [22, 23, 24], "0x58000000": [1, 5, 9, 11, 17], "0x59": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "0x60": [22, 23, 24], "0x64": [22, 23, 24], "0x640": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "0x650": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "0x660": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "0x68": [22, 23, 24], "0x6c": [22, 23, 24], "0x71": [1, 5, 9, 11, 13, 17, 18, 19, 22, 23, 24], "0x7e0000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0x8": [27, 29, 30], "0x80000000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0x80000539": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0x80400000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0x883b86a6": [27, 29, 30], "0x920000": 3, "0x960000": 7, "0x970000": [14, 15], "0xbbccddee": [22, 23, 24], "0xc": [27, 29, 30], "0xffd01234": [22, 23, 24], "1": [0, 1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 20, 22, 23, 24, 27, 29, 30, 31, 33, 34], "10": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "100": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "1000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1001m": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1002e": [1, 5], "1006e": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "101": [13, 18, 19], "1015e": [9, 11, 14, 15, 16, 17], "1017e": 11, "102": [31, 33, 34], "1021": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "1023": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1024": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1024000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "105c": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "10min": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "10sec": [9, 11, 13, 16, 17, 19], "10u": [1, 5, 9, 11, 13, 17, 18, 19], "11": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "110": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "110i": 31, "11231010i": 33, "114660": [9, 11, 13, 16, 17, 19], "115": [22, 23, 24], "115200": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "116224": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "118755": [9, 11, 13, 16, 17, 19], "1198": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "11x11": [22, 23, 24], "12": [4, 8, 14, 15, 16, 22, 23, 24, 27, 29, 30, 31, 33, 34], "120": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1200000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "1219619": [14, 15], "123": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "12345678": [31, 33, 34], "12410534": [27, 29, 30], "12411786": [27, 29, 30], "124396": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "125kb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "128": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1280": [3, 14, 15], "1280x800": [3, 14, 15], "128k": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "13": [1, 3, 4, 5, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "1305998": [14, 15], "131": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "131072": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "1380": [3, 14, 15], "1392": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "1399": [3, 14, 15], "14": [3, 4, 7, 8, 14, 15, 16, 27, 31, 33, 34], "140": [1, 3, 4, 9, 11, 14, 15, 16, 17], "140779": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "141312": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "141456": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1440": [3, 14, 15], "1472": [22, 23, 24], "14735216": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "148": [1, 3, 4, 9, 11, 14, 15, 16, 17], "14876671": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "14876672": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "14c9c3e477d4": [31, 33, 34], "15": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "1500": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1531": [1, 3, 4, 22, 23, 24], "1532": [4, 5, 7, 8], "1549": [11, 13, 16, 17, 19], "1552": [9, 11, 13, 14, 15, 16, 17, 18, 19], "15sec": [9, 11, 13, 16, 17, 19], "16": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "160": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 27, 29, 30, 31, 33, 34], "1600000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "1616": [23, 24], "163": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "16384": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "164": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1641248": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "168": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "17": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "175412": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "178": [31, 33, 34], "1780942": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "179": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "179846": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1799": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "18": [22, 23, 24, 31, 33, 34], "18000000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "180407809": [27, 29, 30], "18100000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "181fffff": [1, 3, 4, 9, 11, 14, 15, 16, 17], "18200000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "183": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1866": [22, 23, 24], "19": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 30, 31, 33, 34], "191657": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "192": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "196608": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "1970": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "1974": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1d": [27, 29, 30], "1e": [1, 3, 4, 9, 11, 14, 15, 16, 17], "1gb": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 18], "1gib": [5, 7, 8, 22, 23, 24], "1k": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "1kzujiclznpyjckgozlfi1m7xjgsa9h1xdk6if": [23, 24], "1m": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "1w": [22, 23, 24], "2": [0, 1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 20, 22, 23, 24, 27, 29, 30, 31, 33, 34], "20": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 24, 27, 29, 30, 31, 33, 34], "20000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "20000000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "2010": [31, 33, 34], "2019": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "2020": [1, 3, 4, 9, 11, 14, 15, 16, 17], "20200624073212": [27, 29, 30], "20200624074335": [27, 29, 30], "2021": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "2022": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 31, 33, 34], "2023": [3, 4, 7, 8, 14, 16, 27, 31], "2024": [4, 8, 15, 16, 17, 18, 19, 22, 23, 24, 29, 30, 33, 34], "2050702": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "20910ci": 31, "20a": [1, 3, 4, 9, 11, 14, 15, 16, 17], "20v7_2": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "21": [13, 18, 19, 22, 23, 24, 27, 29, 30, 31, 34], "2160": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "216x135": [3, 14, 15], "218": [1, 3, 4, 9, 11, 14, 15, 16, 17], "2192013": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "22": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "225": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "23": [3, 7, 9, 11, 14, 17, 24, 27, 29, 30, 31, 34], "232": [9, 11, 13, 14, 15, 16, 17, 18, 19], "23231211i": 33, "23300ci": 31, "2331": [1, 3, 4, 9, 11, 14, 15, 16, 17], "23900ci": 31, "24": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "240": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "2400": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "2483": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "25": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 34], "255": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "256": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "2560": [27, 29, 30], "25mhz": [9, 11, 14, 15, 16, 17], "26": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 30, 31, 33, 34], "27": [30, 31, 34], "28": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 31, 34], "28800": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "28c73e13ab4f": [31, 33, 34], "28gb": [13, 19], "29": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 34], "29360128": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "2_addr": [22, 23, 24], "2avbmulvyyqf": [23, 24], "2ch": [3, 14, 15], "2d": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "2e": [27, 29, 30], "2f": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "2ghz": [11, 13, 16, 17, 19], "2gib": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19], "2mb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "3": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "30": [31, 34], "30000000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "30200000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "30210000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "30220000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "30230000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "30240000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "3028": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "30350000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "30370000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "30436": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "30bb0000": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "30be0000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "31": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 34], "310i": 31, "31577": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "31742492672b": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "32": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "32mb": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "33": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "336609": [27, 29, 30], "33c": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "34": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 34], "340413": [27, 29, 30], "342f67f7678d7af3f77710e1b68979f638c7f4d20393f6ffd0c36beff2789070": [27, 29, 30], "35": [3, 14, 15, 34], "36": 34, "3632": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "36599c00": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "36_2": 22, "37": [22, 23, 24, 27, 29, 30, 34], "3719168": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "3733": [22, 23, 24], "3782656": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "38": 34, "3840k": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "39": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30, 34], "39253": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "3932160": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "394459": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "3b": [27, 29, 30], "3c": [27, 29, 30], "3oqaubi4acj4jrp0kelwhc0": [23, 24], "3v": [22, 23, 24], "4": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "40": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "4000000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "40000000": [22, 23, 24], "4096": [22, 23, 24], "40c": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "41": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 34], "4194kb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "42": 34, "43": 34, "43810080": [22, 23, 24], "43820080": [22, 23, 24], "43830080": [22, 23, 24], "44": 34, "44100": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "44100hz": [3, 14, 15], "443a0000": [22, 23, 24], "443i": 15, "448": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "45": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 34], "454136": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "458908": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "46": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 34], "465mb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "467286": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "47": [23, 24, 27, 29, 30, 34], "47400080": [22, 23, 24], "47510000": [22, 23, 24], "48": [27, 29, 30, 34], "480": [1, 3, 4, 5, 7, 8, 22, 23, 24], "485": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "49": [23, 24, 27, 29, 30], "49000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "497444864": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "4gb": 34, "4kib": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "4mb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "4mib": [1, 9, 11, 17], "5": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "50": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "500000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "504607": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "505012": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "5100": [1, 3, 4, 9, 11, 14, 15, 16, 17], "512": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "512b": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "512mb": 31, "5150": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "515283": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "52": [27, 29, 30], "523285": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "5250": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "528509": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "533889": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "5350": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "537mb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "54": [27, 29, 30], "5470": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "55": 23, "55_2": 23, "56": [22, 23, 24], "567": [31, 33, 34], "57": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "57000": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "5725": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "57330": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "58": [1, 3, 4, 9, 11, 14, 15, 16, 17], "59": [3, 14, 15, 27, 29, 30], "599": [31, 33, 34], "5a0ef4b41935": [31, 33, 34], "5c": [27, 29, 30], "5d": [3, 4, 7, 8, 14, 15, 16, 31, 33, 34], "5f": [27, 29, 30], "5g5cychprbbp8e0meokprzoihxxzgtxgpiahaiea": [23, 24], "5ghz": 16, "5mm": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "6": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "60": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "60704": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "609512": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "61": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "62453760": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "625": [22, 23, 24], "627": [31, 33, 34], "63232": [31, 33, 34], "63652757504": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "63652757504b": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "64": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "64bit": [1, 3, 4, 9, 11, 14, 15, 16, 17], "64k": [1, 3, 4, 9, 11, 14, 15, 16, 17], "64m": [31, 33, 34], "65": [27, 29, 30], "65535": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "65536": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "6593e2c7b8f6": [31, 33, 34], "66000": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "665969": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "67": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "672284": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "68": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "680": [31, 33, 34], "682104": [1, 3, 4, 9, 11, 14, 15, 16, 17], "69": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "690822": [1, 3, 4, 9, 11, 14, 15, 16, 17], "696577": [1, 3, 4, 9, 11, 14, 15, 16, 17], "6f": [27, 29, 30], "6ul": [27, 29, 30], "7": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "70": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "70000": [3, 14, 15], "7194m": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "71_2": [1, 4, 5, 8, 16], "72": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "7264": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "72_2": [3, 7, 14, 15], "7367680": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "74": [9, 11, 14, 15, 16, 17, 27, 29, 30], "7416": [27, 29, 30], "75": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "7545mb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "76": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30], "7616856064": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "7617mb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "768": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "777": [31, 33, 34], "78": [22, 23, 24], "7b": [27, 29, 30], "7btype": [33, 34], "7d": [33, 34], "7fe12e65d770f7e657e683849681f339a996418b": [31, 33, 34], "7m": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "7oymopvz5sd3ycrswcqlkwi": [23, 24], "8": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 26, 31, 33, 34], "80": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "800": [3, 14, 15], "8000": [31, 33, 34], "800mv": [22, 23, 24], "804": [3, 14, 15], "808": [3, 14, 15], "813e": [3, 7, 14, 15], "821": [27, 29, 30], "823": [3, 14, 15], "83": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "830": [27, 29, 30], "831022": [1, 3, 4, 9, 11, 14, 15, 16, 17], "839679": [1, 3, 4, 9, 11, 14, 15, 16, 17], "84": [1, 3, 4, 9, 11, 14, 15, 16, 17], "844e": [31, 33, 34], "845435": [1, 3, 4, 9, 11, 14, 15, 16, 17], "85": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "850385": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "850mv": [22, 23, 24], "875": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "88": [3, 4, 7, 8, 14, 15, 16, 27, 29, 30, 31, 33, 34], "8c": [27, 29, 30], "8c84465b4715cc142eca2785fea09804bd970755142c9ff57e08c791e2b71f28": [27, 29, 30], "8d": [27, 29, 30], "8k": [1, 3, 4, 9, 11, 14, 15, 16, 17], "8m": [0, 27, 29, 30, 31, 33, 34], "8mplu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "8n1": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "9": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 26, 27, 29, 30, 31, 33, 34], "90": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "900": [22, 23, 24, 31, 33, 34], "900mv": [22, 23, 24], "902797": [1, 3, 4, 9, 11, 14, 15, 16, 17], "91": [22, 23, 24], "911842304": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "92": [27, 29, 30], "93": [20, 29, 30], "935": [31, 33, 34], "94": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "95": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "96": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "97": [27, 29, 30], "970278": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "99942000": [27, 29, 30], "9999": [27, 29, 30], "99q3nbm7npnnzsjip0f6p62gjaieajf7qrfmf7uyt": [23, 24], "A": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "And": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "As": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "At": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19, 31, 33, 34], "Be": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "But": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "By": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "For": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "IN": [22, 23, 24], "If": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 27, 29, 30, 31, 33, 34], "In": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "It": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "NO": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "NOT": [23, 24], "No": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "Not": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "ON": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "OR": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "On": [2, 6, 10, 12, 21, 27, 29, 30, 31, 33, 34], "One": [1, 3, 4, 5, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "Or": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "That": [1, 9, 11, 17, 31, 33, 34], "The": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "Their": [31, 33, 34], "Then": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "There": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "These": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "To": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "With": [5, 7, 8, 18, 22, 23, 24, 27, 29, 30, 31, 33, 34], "_": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "_4gb": 15, "_4gb_2ghz": 15, "_defconfig": [15, 16], "_left": [27, 29, 30], "a0": [14, 15, 31, 33, 34], "a1": [9, 11, 16, 17, 22, 23, 24, 31, 33], "a12": [7, 14, 15], "a13": 3, "a2": [27, 29, 30, 31], "a3": [3, 7, 14, 15, 34], "a4": [27, 29, 30], "a5": [4, 8, 16, 22, 23, 24, 31, 33, 34], "a53": [1, 3, 4, 9, 11, 14, 15, 16, 17], "a55": [22, 23, 24], "a6": [1, 5, 9, 11, 13, 17, 18, 19, 27, 29, 30], "a8": [27, 29, 30], "aa": [22, 23, 24, 27, 29, 30], "ab": [27, 29, 30], "abbrevi": [31, 33, 34], "abcd": [1, 3, 4, 9, 11, 14, 15, 16, 17], "abi": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "abil": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "abl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "abort": [1, 5, 9, 11, 13, 17, 18, 19], "about": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "abov": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "abstract": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ac": [27, 29, 30], "acceler": [1, 3, 4, 7, 9, 11, 14, 15, 16, 17], "accept": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "accept_fsl_eula": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "access": [2, 6, 10, 12, 21, 32], "accident": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "accompani": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "accomplish": [31, 33, 34], "accord": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "accordingli": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "account": [9, 11, 13, 16, 17, 19], "achiev": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "acl": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 31, 33, 34], "acm": [1, 3, 4, 5, 7, 8], "act": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "action": [27, 29, 30], "activ": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "actual": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ad": [5, 8, 9, 11, 13, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "adapt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 30, 31, 33, 34], "adc": 21, "adc_in0": [23, 24], "adc_in2": [23, 24], "add": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "addit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "addition": [1, 4, 5, 8, 9, 11, 16, 17, 31, 33, 34], "addr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "addrconf": [1, 3, 4, 9, 11, 14, 15, 16, 17], "address": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30, 31, 33, 34], "adjust": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "admin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ads7846": [31, 33, 34], "adt": [31, 33, 34], "advanc": [1, 3, 4, 9, 11, 14, 15, 16, 17, 32], "advantag": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "advis": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "af0cigxlmp2pl8xfu1bwb282lsedqzudqwel": [23, 24], "affect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "after": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "afterward": [9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30, 31, 33, 34], "again": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "against": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "agent": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "aggress": [31, 33, 34], "agn": [1, 3, 4, 9, 11, 14, 15, 16, 17], "ago": [31, 33, 34], "agreement": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "ahab": [22, 23, 24], "ai": [9, 11, 14, 15, 16, 17], "aid": [31, 33, 34], "air": [31, 33, 34], "alarm": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "albeit": [27, 29, 30], "algorithm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "alia": [31, 33, 34], "alias": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "align": [9, 11, 13, 14, 15, 16, 17, 18, 19], "all": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "allmulti": [22, 23, 24], "alloc": [22, 23, 24], "allow": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "allow_color": [31, 33, 34], "almost": [9, 11, 13, 16, 17, 19], "along": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "alongsid": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "alpha1": [31, 33, 34], "alpha2": [31, 34], "alreadi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "alsa": 22, "alsa_output": [3, 14, 15], "alsactl": [1, 4, 9, 11, 16, 17, 22, 23, 24], "also": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "alter": [31, 33, 34], "altern": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "although": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "alwai": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "am335x": [31, 33, 34], "am57x": [31, 33, 34], "am62ax": [27, 29, 30, 31, 33, 34], "am62x": [27, 29, 30, 31, 33, 34], "am64x": [27, 29, 30, 31, 33, 34], "am68x": [31, 33, 34], "am6x": [27, 29, 30], "am6xx": 27, "amazonaw": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "amix": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "among": [31, 33, 34], "amount": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ampliphi": [0, 1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "an": [25, 27, 29, 30], "an13829": [22, 23, 24], "an13917": [22, 23, 24], "analog": [23, 24], "analyz": [31, 33, 34], "ani": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "anoth": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "ansi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "anymor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "anyth": [1, 9, 11, 17], "anywai": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "ap": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "apart": [31, 33, 34], "api": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "aplai": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "appear": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "append": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "appli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "applic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "approach": [27, 29, 30, 31, 33, 34], "appropri": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "approxim": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "apt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "ar": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 27, 29, 30, 31, 33, 34], "arbit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "arbitrari": [31, 33, 34], "arch": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "architectur": [31, 33, 34], "archiv": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "archlinux": [31, 33, 34], "area": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "arecord": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "argument": [1, 3, 4, 7, 9, 11, 14, 15, 16, 17, 27, 29, 30, 31, 33, 34], "arm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "arm64": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "armgcc": [1, 3, 4, 9, 11, 14, 15, 16, 17], "armgcc_dir": [1, 3, 4, 9, 11, 14, 15, 16, 17], "around": [31, 33, 34], "arp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "arrai": [14, 15], "artefact": [22, 23, 24], "articl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "artifici": [9, 11, 14, 15, 16, 17], "ask": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "asound": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "aspect": [31, 33, 34], "assembl": [31, 33, 34], "assembli": [31, 33, 34], "assign": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "associ": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 31, 33, 34], "assum": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "asym": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "async": [3, 14, 15], "atf_load_addr": [3, 7, 14, 15], "attach": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "attack": [27, 29, 30], "attempt": [27, 29, 30, 31, 33, 34], "attent": [31, 33, 34], "attr": [31, 33, 34], "attribut": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "audibl": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "audio": [2, 10, 12, 21], "author": [31, 33, 34], "auto": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "auto_en": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "autoboot": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "autodetect": [1, 3, 4, 9, 11, 14, 15, 16, 17], "autogen": [31, 33, 34], "autoload": [31, 33, 34], "automat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "autorev": [31, 33, 34], "autostart": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "auxiliari": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "av": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "avail": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "avoid": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "awai": [27, 29, 30], "awar": [9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30, 31, 33, 34], "ax": [1, 5, 11], "b": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "b1": [3, 4, 7, 8, 14, 15, 16, 27, 29, 30, 31, 33, 34], "b5": [27, 29, 30], "b5a26a86c39f": [31, 33, 34], "b6": [27, 29, 30], "b9": [27, 29, 30], "ba": [14, 15, 27, 29, 30], "back": [2, 3, 4, 5, 7, 8, 10, 12, 13, 14, 15, 16, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "backend": [27, 29, 30, 31, 33, 34], "backend_update_eeprom": [27, 29, 30], "backlight0": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "backlight1": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "backtrac": [31, 33, 34], "backup": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "bad": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "bafe46679af8c6292dba22b9d402e3119ef78c6f8b458bcb6993326060de3aa4": [27, 29, 30], "bandwidth": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "bang": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "bank": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "banner": [1, 5, 9, 11, 13, 17, 18, 19], "bar": [1, 3, 4, 5, 7, 8], "bare": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "barebox_": [31, 33, 34], "barebox_2022": [31, 33, 34], "barrier": 28, "base": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "baseboard": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "bash": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "bashrc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "basi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "basic": [2, 6, 10, 12, 21, 32], "baud": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "baudrat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "bb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "bb_env_passthrough_addit": [31, 33, 34], "bb_generate_mirror_tarbal": [31, 33, 34], "bb_no_network": [31, 33, 34], "bbappend": [27, 29, 30], "bbclass": [31, 33, 34], "bblayer": [31, 33, 34], "bbnsm": 21, "bbnsm_pwrkei": [22, 23, 24], "bbu": [27, 29, 30], "bd": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "beagleboneblack": [31, 33, 34], "becaus": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "been": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "befor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "begin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "behav": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "behavior": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "behaviour": [1, 9, 11, 17], "behind": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "being": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "below": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "benefici": [31, 33, 34], "benefit": [31, 33, 34], "berr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "best": [1, 9, 11, 17, 31, 33, 34], "better": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30, 31, 33, 34], "between": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 32], "bia": [1, 5, 9, 11, 13, 17, 18, 19], "bidirect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "bigger": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "bin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30, 31, 33, 34], "binari": [31, 33, 34], "bind": [1, 3, 4, 5, 7, 8, 22, 23, 24, 31, 33, 34], "binutil": [1, 3, 4, 9, 11, 14, 15, 16, 17], "bison": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "bitbak": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "bitrat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bkops_en": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bkops_start": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bl31": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "blacklist": [31, 33, 34], "blkdiscard": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "blkid": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "blob": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "block": [27, 29, 30, 31, 33, 34], "blog": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "blue": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "bluetooth": 24, "bluetoothctl": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "bluez": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "bmap": [3, 7, 14, 15], "bmaptool": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "board": [27, 29, 30, 31, 33, 34], "boardenv": [31, 33, 34], "bodi": [31, 33, 34], "boot": [2, 6, 10, 12, 21, 28], "boot0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "boot1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "boot2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "boot_": [27, 29, 30], "boot_ack": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "boot_cfg0": [22, 23, 24], "boot_cfg1": [22, 23, 24], "boot_cfg2": [22, 23, 24], "boot_cfg3": [22, 23, 24], "boot_cfgx": [22, 23, 24], "boot_mod": [22, 23, 24], "boot_ord": [27, 29, 30], "boot_partition_en": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "boot_target": [1, 9, 11, 17], "bootabl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "bootarg": [27, 29, 30, 31, 33, 34], "bootaux": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "bootcmd_mfg": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bootenv": [13, 18, 19], "bootfil": [3, 4, 5, 7, 8, 14, 15, 16, 22, 23, 24], "bootflow": [1, 9, 11, 17], "bootload": 28, "bootloader_seek": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bootloader_seek_emmc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bootlog": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bootm": [27, 29, 30], "bootmeth": [1, 9, 11, 17], "bootmod": [2, 6, 10, 12, 21], "bootnam": [27, 29, 30], "bootp": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19], "bootpart": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "bootscript": [1, 9, 11, 17], "bootsourc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bootstat": [27, 29, 30], "bootstrap": [31, 33, 34], "both": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "bottom": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bought": [22, 23, 24], "bound": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19], "box": [31, 33, 34], "br": [31, 33, 34], "branch": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "branch_pn": [31, 33, 34], "brd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "break": [31, 33, 34], "brick": [22, 23, 24], "bridg": [1, 3, 4, 9, 11, 14, 15, 16, 17], "brief": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "briefli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bright": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bring": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "broadcast": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "broken": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "brought": [9, 11, 13, 14, 15, 16, 17, 18, 19], "brp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "brp_inc": [22, 23, 24], "bsd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bsm": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "bsp": [0, 10, 20, 25, 28, 32], "bspdir": [31, 33, 34], "bt_fuse_sel": [22, 23, 24], "bu": [2, 6, 10, 12, 21, 27, 29, 30], "buffer": [31, 33, 34], "bug": [23, 24], "build": [2, 6, 10, 12, 21, 27, 29, 30, 32], "build_ddr_releas": [1, 3, 4, 9, 11, 14, 15, 16, 17], "build_releas": [1, 3, 4, 9, 11, 14, 15, 16, 17], "buildhistori": [31, 33, 34], "built": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "bundl": [22, 23, 24, 28, 31, 33, 34], "bundle_vers": [27, 29, 30], "button": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "byt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "byte": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "c": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "c6": [27, 29, 30], "c8": [1, 3, 4, 9, 11, 14, 15, 16, 17], "ca": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30], "cabl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "cach": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "calcul": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "calib3d2": [31, 33, 34], "call": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "callback": [3, 4, 5, 7, 8, 14, 15, 16], "came": [1, 9, 11, 17], "camera": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 31, 33, 34], "caminand": [3, 14, 15], "caminandes_3_llamigos_720p_vp9": [1, 4, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "can": [2, 6, 10, 12, 21, 27, 29, 30, 31, 33, 34], "can0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "can1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "cancel": [31, 33, 34], "candump": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "canfd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "cangen": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cannot": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "cansend": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "capabl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "capac": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "capacit": [22, 23, 24], "card": [2, 6, 10, 12, 21, 27, 29, 30, 31, 33, 34], "care": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "carefulli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cargo": [31, 33, 34], "carri": [31, 33, 34], "carrier": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "carrierboard": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "case": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "cat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "catastroph": [27, 29, 30], "categori": [31, 33, 34], "caus": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cc": [22, 23, 24, 31, 33, 34], "cc3f65cd1c1993951d7a39bdb7b7d723617ac46460f8b640cd8d1622ad6e4c17": [27, 29, 30], "ccach": [31, 33, 34], "ccmp": [31, 33, 34], "cd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "cdc": [1, 3, 4, 5, 7, 8], "cdimag": [1, 9, 11, 17], "cell": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "cert": [27, 29, 30], "cert_path": [27, 29, 30], "certain": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "certif": [27, 29, 30], "cfg": [31, 33, 34], "cfj": [31, 33, 34], "cflag": [31, 33, 34], "cgi": [31, 33, 34], "chain": [27, 29, 30], "chang": [13, 18, 19, 28], "channel": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "chao": [31, 33, 34], "chapter": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "char": [31, 33, 34], "charact": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "characterist": [3, 7, 14, 15], "check": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 27, 29, 30, 31, 33, 34], "checklist": [27, 29, 30], "checkout": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "checksum": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "chip": [2, 6, 10, 12, 21], "chip0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "chipmak": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "chmod": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "choic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "choos": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "chosen": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "chromium": [2, 6, 12, 31, 33, 34], "chrpath": [31, 33, 34], "ci": [22, 23, 24, 31, 33, 34], "ci_hdrc": [1, 3, 4, 5, 7, 8], "circuit": [22, 23, 24], "class": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "classic": [31, 33, 34], "clean": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "cleanal": [1, 9, 11, 17], "cleansstat": [31, 33, 34], "clear": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "click": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "client": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 24], "clk": [14, 15], "clock": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "clone": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "close": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "closer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cma": [31, 33, 34], "cmake": [1, 3, 4, 9, 11, 14, 15, 16, 17], "cmd23": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cn": [27, 29, 30], "co": [31, 33, 34], "code": [27, 29, 30, 31, 33, 34], "code5": [27, 29, 30], "codec": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "codenam": [31, 33, 34], "collabor": [31, 33, 34], "collect": [31, 33, 34], "collis": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "collsn": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "colon": [31, 33, 34], "color": [22, 23, 24, 31, 33, 34], "column": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "com": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "combin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "come": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "command": [27, 29, 30, 31, 33, 34], "commandlin": [31, 33, 34], "commerci": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "commercial_libav": [31, 33, 34], "commercial_x264": [31, 33, 34], "commit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "common": 32, "commonli": [31, 33, 34], "commun": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "compani": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "compar": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "comparison": [31, 33, 34], "compat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "compil": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "complain": [31, 33, 34], "complet": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "complex": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "compli": [31, 33, 34], "compon": 32, "comprehens": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "compress": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "compris": [31, 33, 34], "comput": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "con": [31, 33, 34], "concept": [2, 6, 10, 12, 21], "conclus": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "condit": [31, 33, 34], "conf": [5, 8, 9, 11, 13, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "config": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "config_expert": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "config_extra_env_set": [31, 33, 34], "config_gpio_sysf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "config_imx8mp_libra_ram_size_1gb": 9, "config_imx8mp_libra_ram_size_2gb": 9, "config_imx8mp_libra_ram_size_4gb": 9, "config_imx8mp_libra_ram_size_fix": 9, "config_iwlwifi": [1, 3, 4, 9, 11, 14, 15, 16, 17], "config_phycore_imx8mm_ram_size_1gb": [1, 3, 4], "config_phycore_imx8mm_ram_size_2gb": [1, 3, 4], "config_phycore_imx8mm_ram_size_4gb": [1, 3, 4], "config_phycore_imx8mm_ram_size_fix": [1, 3, 4], "config_phycore_imx8mp_ram_freq_fix": [11, 13, 17, 19], "config_phycore_imx8mp_ram_size_1gb": [11, 13, 14, 15, 16, 17, 19], "config_phycore_imx8mp_ram_size_2gb": [11, 13, 14, 15, 16, 17, 19], "config_phycore_imx8mp_ram_size_4gb": [11, 13, 14, 15, 16, 17, 19], "config_phycore_imx8mp_ram_size_4gb_2ghz": 15, "config_phycore_imx8mp_ram_size_fix": [11, 13, 14, 15, 16, 17, 19], "config_phycore_imx8mp_use_1_5ghz_ram_tim": [11, 13, 17, 19], "config_phycore_imx8mp_use_2ghz_ram_tim": [11, 13, 16, 17, 19], "config_target_imx8mp_libra": 9, "config_target_phycore_imx8mm": [1, 3, 4], "config_target_phycore_imx8mp": [11, 13, 14, 15, 16, 17, 19], "configf": [1, 3, 4, 5, 7, 8], "configur": [5, 7, 8, 22, 28, 32], "configure_flag": [31, 33, 34], "confirm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "conflict": [31, 33, 34], "confluenc": [31, 33, 34], "confus": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "connect": [13, 18, 19, 22, 23, 27, 29, 30], "connector": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "consequ": [31, 33, 34], "conserv": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "consid": [31, 33, 34], "consider": [28, 31, 33, 34], "consist": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "consol": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "consoleblank": [31, 33, 34], "constant": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "construct": [31, 33, 34], "consult": [31, 33, 34], "consum": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "consumpt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "contact": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "contain": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "content": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "continu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "contrast": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "contrib2": [31, 33, 34], "control": [2, 6, 10, 12, 21, 27, 29, 30, 31, 33, 34], "conv": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "conveni": [31, 33, 34], "convent": [9, 11, 13, 14, 15, 16, 17, 18, 19], "convers": [22, 23, 24], "convert": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24, 27, 29, 30, 31, 33, 34], "cool": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "copi": [27, 29, 30, 31, 33, 34], "core": [2, 10, 12, 21, 27, 29, 30, 32], "core2": [31, 33, 34], "corner": [31, 33, 34], "corpor": [1, 3, 4, 9, 11, 14, 15, 16, 17], "correct": [3, 7, 14, 15, 27, 29, 30, 31, 33, 34], "correctli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "correspond": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "corrupt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cortex": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "cortexa53": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "cortexa55": [22, 23, 24], "cortexa9hf": [31, 33, 34], "cost": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "could": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "count": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "counter": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "countri": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "country_cod": [31, 33, 34], "cp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "cp2105": [9, 11, 13, 14, 15, 16, 17, 18, 19], "cpio": [31, 33, 34], "cpp": [31, 33, 34], "cpu0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cpu1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cpu2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "cpu3": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "cpufreq": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "creat": 28, "creation": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "creator": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "credenti": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "critic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cross": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "crt": [27, 29, 30], "crtsct": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "crypto": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "csc": [22, 23, 24], "csc2": [22, 23, 24], "csi": 15, "csi1": [1, 9, 11, 14, 15, 16, 17], "csi2": [1, 9, 11, 14, 15, 16, 17], "ctrl": [31, 33, 34], "curr": [1, 3, 4], "current": [22, 23, 24, 27, 29, 30, 31, 33, 34], "custom": [27, 29, 30, 32], "cut": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "cve": [31, 33, 34], "cxx": [31, 33, 34], "cxxflag": [31, 33, 34], "cycl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cylind": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "d": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "d0": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "d4": [27, 29, 30], "d6": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "d626178e448d": [31, 33, 34], "d_": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "daemon": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "dak5l8pu55": [23, 24], "damag": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 19, 22, 23, 24], "data": [1, 5, 9, 11, 13, 17, 18, 19, 27, 29, 30, 31, 33, 34], "databas": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "datar": [1, 3, 4, 5, 7, 8], "datasheet": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "date": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "db": [3, 4, 7, 8, 14, 15, 16, 27, 29, 30, 31, 33, 34], "dbatch": [31, 33, 34], "dbg": [31, 33, 34], "dbitrat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dbrp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dbrp_inc": [22, 23, 24], "dbu": [27, 29, 30], "dbus_session_bus_address": [27, 29, 30], "dc": [1, 3, 4, 27, 29, 30], "dcach": [1, 3, 4, 9, 11, 14, 15, 16, 17], "dd": [3, 7, 14, 15, 27, 29, 30, 31, 33, 34], "ddr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ddr_releas": [1, 3, 4, 9, 11, 14, 15, 16, 17], "de": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "deactiv": [31, 33, 34], "deb": [31, 33, 34], "debian": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "debianutil": [31, 33, 34], "debug": [5, 7, 8, 13, 18, 19, 22, 23, 24], "debug_build": [31, 33, 34], "debug_optim": [31, 33, 34], "debugg": [31, 33, 34], "dec": [27, 29, 30], "declar": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "decod": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "decodebin": [1, 4, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "decompress": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 19], "decreas": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "dedic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "def": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "default": [3, 5, 7, 8, 13, 14, 15, 18, 19], "defconfig": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "defin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "definit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "del": [31, 33, 34], "delai": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "delet": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "deliv": [31, 33, 34], "demand": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "demo": [5, 7, 8], "demonstr": [27, 29, 30, 31, 33, 34], "depend": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "deploi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "deploy_dir": 27, "deploydir": [1, 9, 11, 17], "deprec": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "describ": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "descript": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "descriptor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "design": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "desir": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "desktop": [1, 3, 4, 7, 14, 15, 16], "destdir": [31, 33, 34], "destin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "destroi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "detach": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "detail": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "detect": [27, 29, 30, 31, 33, 34], "determin": [27, 29, 30], "determinist": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "dev": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "develop": [2, 6, 10, 12, 21, 27, 29, 30, 32], "devic": [2, 6, 10, 12, 21, 26, 27, 29, 30, 31, 33, 34], "devicetre": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "devicex": [23, 24], "devsel": [1, 3, 4, 9, 11, 14, 15, 16, 17], "devshel": [31, 33, 34], "devtool": [14, 15], "df": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "dhcp": [31, 33, 34], "dhcp4": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dhcpserver": [31, 33, 34], "diagram": [27, 29, 30], "did": [31, 33, 34], "didn": [31, 33, 34], "die": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "diff": [31, 33, 34], "diffconfig": [31, 33, 34], "differ": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "difficult": [27, 29, 30], "diffstat": [31, 33, 34], "digit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dip": [5, 7, 8], "direct": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "directli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "directori": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "dirti": [31, 33, 34], "disabl": [3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 22, 23, 24, 27, 29, 30], "disc": [1, 9, 11, 17], "discard": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "disconnect": [27, 29, 30], "discover": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "disk": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "displai": [2, 5, 7, 8, 10, 12, 21, 27, 29, 30, 31, 33, 34], "distinct": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "distribut": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "distro": [3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 22, 23, 24, 27, 29, 30], "dit4y1zbcks1ocwt": [23, 24], "divid": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dl_dir": [31, 33, 34], "dmesg": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dnl80211": [31, 33, 34], "dnopaus": [31, 33, 34], "do": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "do_env": [31, 33, 34], "do_env_append_phyboard": [31, 33, 34], "do_env_writ": [31, 33, 34], "do_instal": [31, 33, 34], "doc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 31, 33, 34], "docker": [27, 29, 30, 31, 33, 34], "dockerfil": [27, 29, 30], "document": [2, 6, 10, 12, 21, 25, 27, 29, 30, 32], "doe": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "doefiboot": [1, 9, 11, 17], "doesn": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "dolegacyboot": [1, 9, 11, 17], "domain": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "don": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "done": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "dont": [31, 33, 34], "doraucboot": [27, 29, 30], "dot": [31, 33, 34], "down": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "downgrad": 28, "downgrade_barrier_vers": [27, 29, 30], "download": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "dpm": [3, 14, 15], "dpython_execut": [14, 15], "dr_mode": [1, 3, 4], "drag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "drain": [1, 5, 9, 11, 13, 17, 18, 19], "dram": [1, 3, 4, 9, 11, 14, 15, 16, 17], "drive": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "driven": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "driver": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "drm": [3, 14, 15], "drop": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "dry": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "dsampl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dsi": [3, 7, 14, 15], "dsjw": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dsm": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "dsnoop": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "dt": [2, 6, 10, 12, 21, 31, 33, 34], "dtb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "dtbo": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dtc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dtseg1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dtseg2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dtsi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "dtso": [1, 3, 4, 5, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dual": [1, 3, 4, 5, 7, 8, 13, 14, 15, 18, 19], "duckerhub": [31, 33, 34], "due": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "dummi": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24, 31, 33, 34], "dump": [31, 33, 34], "dumpimag": [1, 9, 11, 17], "dunfel": 34, "duplex": [14, 15, 18], "duplic": [31, 33, 34], "dure": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "duti": [22, 23, 24], "dvd": [1, 9, 11, 17], "dvf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dwc3": [1, 3, 4, 9, 11, 14, 15, 16, 17], "dyn": [27, 29, 30], "dynam": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "e": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "e0": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "e1": [27, 29, 30], "e2": [27, 29, 30], "e29a88b7172a": [31, 33, 34], "e6": [27, 29, 30], "eabi": [1, 3, 4, 9, 11, 14, 15, 16, 17], "each": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "earli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "easi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "easier": [22, 23, 24], "easiest": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "easili": [3, 4, 5, 7, 8, 14, 15, 16, 22, 23, 24, 31, 33, 34], "east": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "ecc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "echo": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "eclips": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "ecm": [1, 3, 4, 5, 7, 8], "ecspi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ed": [27, 29, 30], "edid": [3, 14, 15], "edit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "editor": [31, 33, 34], "edt": [9, 11, 14, 15, 16, 17, 22, 23, 24], "ee": [22, 23, 24, 27, 29, 30], "eeprom": [2, 6, 10, 12, 21, 27, 29, 30], "effect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "efi": [2, 10, 12], "efi_mgr": [1, 9, 11, 17], "eficonfig": [1, 9, 11, 17], "efus": [2, 6, 10, 12, 21], "egl": [31, 33, 34], "eglf": [31, 33, 34], "egrep": [31, 33, 34], "ehci": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "eight": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "either": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "electr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "electron": [31, 33, 34], "elf": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "els": [27, 29, 30, 31, 33, 34], "emac": [31, 33, 34], "email": [31, 33, 34], "embed": [31, 33, 34], "emitdn": [31, 33, 34], "emmc": [2, 6, 10, 12, 21, 28, 31, 33], "emmc_al": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "emp": [1, 3, 4], "emploi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "empti": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "en": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "enabl": [27, 29, 30, 31, 33, 34], "encap": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "encapsul": [31, 33, 34], "encod": [1, 3, 4, 5, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "encourag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25], "encrypt": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "end": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "endch": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "endlba": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "endpoint": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "enet0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "enet1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "engin": [22, 23, 24, 31, 33, 34], "english": [1, 3, 4, 5, 7, 8, 31, 33, 34], "enh_area": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "enh_size_mult": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "enh_usr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "enhanc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "enlarg": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "enough": [27, 29, 30], "ensur": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "ent": [3, 4, 7, 8, 14, 15, 16, 31, 33, 34], "enter": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "entiti": [27, 29, 30], "entri": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "enum": [3, 14, 15], "enumer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "env": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "env_add": [31, 33, 34], "env_redund": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "env_rm": [31, 33, 34], "env_verbos": [31, 33, 34], "epoch": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "eq": [27, 29, 30], "eqo": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "equat": [31, 33, 34], "equip": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 23, 24], "equival": [1, 5, 9, 11, 13, 17, 18, 19, 31, 33, 34], "eras": [31, 33, 34], "eraseblock": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "err": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "error": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "especi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "essenti": [31, 33, 34], "establish": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "etc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "eth": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 23, 24], "eth0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "eth1": [9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "ethernet": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "ethernet0": [9, 11, 13, 14, 15, 16, 17, 18, 19], "ethernet1": [9, 11, 13, 14, 15, 16, 17, 18, 19], "etm0700g0edh6": [22, 23, 24], "etml1010g0dka": [9, 11, 14, 15, 16, 17], "etml1010g3dra": [22, 23, 24], "etsi": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "eula": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "eval": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "evalu": [1, 4, 5, 7, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "even": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "event": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "everi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "everyth": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "evk_m33_": [22, 23, 24], "evk_m33_tcm_": [22, 23, 24], "evk_m33_tcm_rpmsg_lite_str_echo_rto": [22, 23, 24], "exampl": [2, 5, 7, 8, 10, 12, 13, 18, 19, 21, 28], "example_categori": [1, 3, 4, 9, 11, 14, 15, 16, 17], "exce": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "excel": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "except": [31, 33, 34], "exchang": [27, 29, 30], "exclud": [31, 33, 34], "exec": [31, 33, 34], "execstart": [27, 29, 30], "execstartpr": [27, 29, 30], "execstop": [27, 29, 30], "execstoppost": [27, 29, 30], "execut": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "exemplari": [31, 33, 34], "exist": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "exit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "expans": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "expect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "experi": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "explain": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "explan": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "export": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "exportf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "expos": [22, 23, 24], "express": [1, 3, 4, 9, 11, 14, 15, 16, 17], "ext4": [27, 29, 30], "ext4load": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "ext_csd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ext_csd_wr_rel_set": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "extcsd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "extend": [31, 33, 34], "extens": [2, 6, 9, 11, 12, 13, 17, 18, 19, 22, 23, 24], "extension_board_scan": [3, 4, 5, 7, 8, 14, 15, 16], "extern": [31, 33, 34], "externalsrc": [31, 33, 34], "externalsrc_build": [31, 33, 34], "extra": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "extra_image_featur": [31, 33, 34], "extra_oecmak": [14, 15], "extract": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "f": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "f4": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "face": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fact": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fail": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "failur": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fair": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "fall": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "fallback": [1, 3, 4, 9, 11, 14, 15, 16, 17], "fals": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 19, 31, 33, 34], "famili": [22, 23, 24], "fan": [13, 18, 19], "fancontrol": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "far": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fast": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fastboot": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "faster": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fat": [3, 7, 14, 15, 18], "fat16": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fat32": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fatal": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fatload": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "favorit": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "fb": [27, 29, 30, 31, 33, 34], "fbcon": [31, 33, 34], "fd": [2, 6, 10, 12, 21], "fdatasync": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fdisk": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fdt_file": [3, 4, 5, 7, 8, 14, 15, 16, 22, 23, 24], "featur": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "feb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fec": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fed": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fedora": [1, 9, 11, 17], "fetch": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "fetcher": [31, 33, 34], "few": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "ff": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30], "fi": [27, 29, 30, 31, 33, 34], "fido": [31, 33, 34], "field": [1, 9, 11, 17, 31, 33, 34], "fight": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "figur": [27, 29, 30], "file": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "filenam": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "files": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "filesextrapath": [31, 33, 34], "filesextrapaths_prepend": [27, 29, 30], "filesrc": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "filesystem": [27, 29, 30], "fill": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "final": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "find": [3, 7, 14, 15, 27, 29, 30, 31, 33, 34], "fine": [31, 33, 34], "finish": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "firefox": [31, 33, 34], "firewal": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "firmwar": [2, 5, 7, 8, 10, 12, 13, 18, 19, 22, 23, 24, 27, 29, 30], "firmware_": [31, 33, 34], "first": [2, 6, 10, 12, 21, 27, 29, 30, 31, 33, 34], "fit": [3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 27, 29, 30, 31, 33, 34], "fit_extens": [1, 9, 11, 17], "fitimag": [1, 9, 11, 17], "five": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fix": [5, 7, 8, 18, 22, 23, 24, 27, 29, 30, 31, 33, 34], "flag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "flann2": [31, 33, 34], "flash": [2, 6, 10, 12, 21, 28, 31, 33, 34], "flash_eras": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "flash_evk_flexspi": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "flash_singleboot": [22, 23, 24], "flashcp": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "flex": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "flexcan": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "flexibl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "flexspi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "flicker": [13, 18, 19], "float": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "floppi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "flow": [23, 24], "flush": [1, 3, 4, 9, 11, 14, 15, 16, 17], "focu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "folder": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "follow": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "foo": [1, 3, 4, 5, 7, 8], "footprint": [22, 23, 24], "forc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "force_ro": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "foreground": [31, 33, 34], "forget": [31, 33, 34], "fork": [31, 33, 34], "form": [31, 33, 34], "format": [2, 6, 10, 12, 21, 27, 29, 30, 31, 33, 34], "former": [27, 29, 30], "formula": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "forward": [31, 33, 34], "found": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "foundat": [31, 33, 34], "four": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fpdlink": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "fpsc": 0, "fragment": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "frame": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "framework": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "free": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "freedesktop": [31, 33, 34], "freerto": [22, 23, 24], "freescal": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "freq": [22, 23, 24], "fresh": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "from": [2, 6, 10, 12, 21, 28], "frontend": [31, 33, 34], "fsb_s400_fuse0": [22, 23, 24], "fsck": [31, 33, 34], "fsl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "fsl_sdhc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "fspi": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "fstab": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fsync": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "ftl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ftp": [31, 33, 34], "fulfil": [31, 33, 34], "full": [1, 3, 4, 5, 7, 8, 14, 15, 18, 22, 23, 24, 27, 29, 30, 31, 33, 34], "full_optim": [31, 33, 34], "fulli": [3, 7, 14, 15, 27, 29, 30, 31, 33, 34], "fullscreen": [13, 18, 19], "function": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "further": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "furthermor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "fusemap": [22, 23, 24], "futur": [1, 9, 11, 17, 27, 29, 30, 31, 33, 34], "fw_env": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "fw_printenv": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30], "fw_setenv": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30], "g": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "g1": [1, 3, 4, 5, 7, 8], "gadget": [1, 3, 4, 5, 7, 8], "gain": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "gatewai": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "gatewayip": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "gather": [22, 23, 24], "gawk": [31, 33, 34], "gb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "gbit": [9, 11, 13, 14, 15, 16, 17, 18, 19], "gcc": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "gdb": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "gen": [1, 3, 4, 9, 11, 14, 15, 16, 17], "gener": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "genrsa": [23, 24], "german": [9, 11, 14, 15, 16, 17, 31, 33, 34], "get": [2, 6, 10, 12, 21, 27, 29, 30, 32], "ghostscript": [31, 33, 34], "ghz": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gib": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gigabit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "git": [25, 27, 29, 30, 32], "git2": [31, 33, 34], "gitconfig": [31, 33, 34], "github": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25], "gitignor": [31, 33, 34], "give": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "given": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "gl": [1, 3, 4, 7, 14, 15, 16], "glibc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "global": [27, 29, 30, 31, 33, 34], "gmbh": [27, 29, 30], "gmt": [27, 29, 30], "gnd": [22, 23, 24], "gnome": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gnu": [1, 3, 4, 9, 11, 14, 15, 16, 17], "gnueabi": [31, 33, 34], "gnuplot": [31, 33, 34], "go": [1, 3, 4, 7, 9, 11, 14, 15, 16, 17, 23, 24, 31, 33, 34], "goal": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "good": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "googl": [31, 33, 34], "goto": [27, 29, 30], "govern": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "governor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpio": [2, 6, 10, 12, 21], "gpio1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpio4": [22, 23, 24], "gpio4_07": [22, 23, 24], "gpio5": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "gpio5_07": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "gpiochip": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiochip0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiochip1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiochip128": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "gpiochip2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiochip3": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiochip32": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiochip4": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiochip64": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiochip96": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiodetect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpioget": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpioinfo": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpioset": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gplai": [3, 14, 15], "gpt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "gpu2": [31, 33, 34], "gracefulli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "grade": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "graphic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "green": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "grep": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "gro_max_s": [22, 23, 24], "group": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "grub": [1, 9, 11, 17], "grubaa64": [1, 9, 11, 17], "gs0": [1, 3, 4, 5, 7, 8], "gso_max_s": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gso_max_seg": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gst": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gstreamer": [31, 33, 34], "gt": [27, 29, 30], "gtk": [31, 33, 34], "guarante": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "guess": [31, 33, 34], "gui": [31, 33, 34], "guid": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 27, 29, 30, 31, 33, 34], "guidelin": 25, "gz": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "h": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 31, 33, 34], "h264pars": [3, 14, 15], "ha": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "halv": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hand": [31, 33, 34], "handl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "handlepowerkei": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "handler": [27, 29, 30], "handshak": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hang": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hap": [1, 3, 4, 9, 11, 14, 15, 16, 17], "happen": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "hard": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "harden": [31, 33, 34], "hardknott": [3, 7, 14, 15, 27, 29, 30], "hardnkott": 34, "hardwar": [2, 6, 10, 12, 21, 27, 29, 30, 31, 33, 34], "hashtag": [1, 9, 11, 17], "have": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 27, 29, 30, 31, 33, 34], "hci0": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "hciconfig": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "hcitool": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "hdisp": [3, 14, 15], "hdmi": [9, 11, 14, 15, 16, 17], "hdrc": [22, 23, 24], "head": [0, 1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "header": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24, 31, 33, 34], "headless": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "headphon": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "headset": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "heartbeat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "heat": [22, 23, 24], "heavi": [31, 33, 34], "heavili": [31, 33, 34], "help": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "helper": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "henc": [22, 23, 24], "here": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "herein": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hex": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hexadecim": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hexdump": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hh": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "high": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "higher": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "highest": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "highgui2": [31, 33, 34], "highli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "highspe": [1, 3, 4, 5, 7, 8, 22, 23, 24], "histori": [31, 33, 34], "hit": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30, 31, 33, 34], "hold": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "home": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "homepag": [31, 33, 34], "hook": [27, 29, 30], "host": [2, 6, 10, 12, 21, 27, 29, 30, 32], "host0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hostapd": [31, 33, 34], "hostnam": [31, 33, 34], "hosttool": [31, 33, 34], "hot": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hour": [31, 33, 34], "how": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "howev": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "howto": [31, 33, 34], "hpa": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hse": [3, 14, 15], "hss": [3, 14, 15], "html": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "htop": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "htot": [3, 14, 15], "http": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "hub": [31, 33, 34], "human": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "hw": [22, 23, 24], "hw_mode": [31, 33, 34], "hwaddr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hwclock": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hwmon": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "hz": [3, 14, 15], "i": [26, 27, 29, 30], "i2": [1, 3, 4, 22, 23, 24], "i386": [31, 33, 34], "i7": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "i8mbswidaqabakboy8wrynhmp": [23, 24], "ic": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "id": [1, 4, 5, 7, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "id_str": [3, 4, 7, 8, 14, 15, 16, 31, 33, 34], "idea": [27, 29, 30], "ident": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "identifi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "idl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "idproduct": [1, 3, 4, 5, 7, 8], "idvendor": [1, 3, 4, 5, 7, 8], "ieee80211d": [31, 33, 34], "ieee80211n": [31, 33, 34], "ifconfig": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "ignor": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "iio": [23, 24], "illeg": [31, 33, 34], "imag": [2, 6, 10, 12, 21, 27, 29, 30, 32], "image_boot_fil": [1, 9, 11, 17], "image_featur": [31, 33, 34], "image_instal": [1, 4, 16, 31, 33, 34], "image_install_append": [3, 7, 14, 15], "imageext": [1, 5, 9, 11, 17], "imagenam": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "img": [1, 3, 4, 5, 7, 8, 22, 23, 24, 27, 29, 30], "imgproc2": [31, 33, 34], "iminfo": [1, 9, 11, 17], "immedi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "immut": [3, 14, 15], "impact": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "implement": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "import": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "importantli": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "imx": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30, 31, 33, 34], "imx6": [31, 33, 34], "imx6qdl": [27, 29, 30], "imx6qdl_phytec_boot_st": [27, 29, 30], "imx6ul": [27, 29, 30, 31, 33, 34], "imx7": [31, 33, 34], "imx8": [31, 33, 34], "imx8_phytec_defconfig": [1, 9, 11, 17], "imx8_phytec_distro": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "imx8_phytec_platform": [3, 4, 5, 7, 8, 14, 15, 16], "imx8m": [31, 33, 34], "imx8mm": [1, 3, 4, 5, 7, 8, 14, 15, 27, 29, 30, 31, 33, 34], "imx8mm_defconfig": [1, 3, 4, 7], "imx8mn": [5, 7, 8, 27, 29, 30], "imx8mn_defconfig": [5, 7, 8], "imx8mp": [1, 9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "imx8mp_clk_ocotp_root": [14, 15], "imx8mp_defconfig": [11, 13, 14, 15, 16, 17, 18, 19], "imx8mp_libra": 9, "imx8x": [31, 33, 34], "imx9": [22, 23, 24], "imx93": [22, 23, 24, 27, 29, 30, 31, 33, 34], "imx9301": [22, 23, 24], "imx9302": [22, 23, 24], "imx93_defconfig": 22, "imx9_phytec_defconfig": 24, "imx9_phytec_distro": [22, 23, 24], "imx9_phytec_platform": [22, 23], "imx_": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "imx_rpmsg_tti": [22, 23, 24], "imx_therm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "imx_v7_defconfig": [31, 33, 34], "imx_v8_defconfig": [3, 4, 5, 7, 8, 14, 15, 16, 22, 23], "imxdrm": [31, 33, 34], "in_voltagey_raw": [23, 24], "inact": [1, 5, 9, 11, 13, 17, 18, 19, 27, 29, 30], "inc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "includ": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "incom": [22, 23, 24], "incompat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "incorpor": [27, 29, 30, 31, 33, 34], "increas": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "independ": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "index": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "individu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 27, 29, 30], "industri": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "inet": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "influenc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "info": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30, 31, 33, 34], "inform": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 27, 29, 30, 31, 33, 34], "informationon": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "infrastructur": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "inherit": [31, 33, 34], "inhibit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ini": [9, 11, 13, 14, 15, 16, 17, 18, 19], "init": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "init_rauc": 27, "initi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 32], "input": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "insan": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "insert": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "insid": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30, 31, 33, 34], "inspect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 32], "instal": [2, 6, 10, 12, 21, 27, 29, 30, 32], "install_mod_path": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "instanc": [31, 33, 34], "instead": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "instruct": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "integ": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "integr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "intel": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "intellig": [9, 11, 14, 15, 16, 17], "intent": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "interact": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "interfac": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "interfer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "intergrad": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "intern": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "internet": [14, 15, 31, 33, 34], "interpret": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "interrupt": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "intervent": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "introduc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "introduct": [2, 6, 10, 12, 21, 28, 32], "introspect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 19, 22, 23, 24], "intuit": [31, 33, 34], "investig": [31, 33, 34], "invoic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "invok": [31, 33, 34], "involv": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "io": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "ioctl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "ip": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "ip_dyn": [13, 18, 19], "ipaddr": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "ipk": [31, 33, 34], "iputil": [31, 33, 34], "ipv6": [1, 3, 4, 9, 11, 14, 15, 16, 17], "irq": [1, 3, 4, 9, 11, 14, 15, 16, 17], "isi": [1, 9, 11, 14, 15, 16, 17], "isn": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "iso": [1, 9, 11, 17], "isp": [1, 10, 12], "issu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25], "issuer": [27, 29, 30], "its": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "itself": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "iw": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "iwlan0": [31, 33, 34], "iwlwifi": [1, 3, 4, 9, 11, 14, 15, 16, 17], "i\u00b2c": [2, 6, 10, 12, 21], "i\u00b2c1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23], "i\u00b2c2": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "i\u00b2c3": [5, 7, 8, 24], "i\u00b2c4": [1, 3, 4], "j": [5, 7, 8, 13, 18, 19, 22, 23, 24, 31, 33, 34], "jack": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "jan": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "januari": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "jedec": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "jethro": [31, 33], "jinja2": [31, 33, 34], "jlink": [1, 3, 4, 9, 11, 14, 15, 16, 17], "jlinkgdbserv": [1, 3, 4, 9, 11, 14, 15, 16, 17], "journal": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "journalctl": [31, 33, 34], "jp3": [9, 11, 13, 14, 15, 16, 17, 18, 19], "jp4": [9, 11, 13, 14, 15, 16, 17, 18, 19], "jtag": [1, 3, 4, 9, 11, 14, 15, 16, 17, 24], "jump": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 31, 33, 34], "jumper": [9, 11, 13, 14, 15, 16, 17, 18, 19], "just": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "k": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "kde": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "kea": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "keep": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "kei": [1, 3, 4, 5, 7, 8, 10, 12, 21, 27, 29, 30, 31, 33, 34], "kept": [1, 9, 11, 17], "kernel": [2, 6, 10, 12, 21, 27, 29, 30], "kernel0": [27, 29, 30], "kernel_devicetre": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "kernel_devicetree_deploi": [1, 9, 11, 17], "kernel_module_autoload": [31, 33, 34], "kernel_module_probeconf": [31, 33, 34], "key_pow": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "keyboard": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "keymap": [31, 33, 34], "keyr": 28, "keyword": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "kib": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "kill": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "kind": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "kirkston": [4, 5, 8, 16, 27, 31, 34], "kit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "know": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "known": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "krogoth": [31, 33], "kvm": [31, 33, 34], "l": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "l1": [1, 3, 4, 9, 11, 14, 15, 16, 17], "l105": 24, "l106": [13, 18, 19], "l113": [9, 11, 17, 24], "l114": 24, "l122": 24, "l130": [13, 18, 19], "l133": [9, 11, 17], "l145": [13, 18, 19], "l147": 24, "l151": 24, "l155": 24, "l160": [13, 18, 19], "l169": [13, 18, 19], "l172": 24, "l173": 24, "l174": 24, "l175": [13, 18, 19], "l179": [9, 11, 17], "l181": [13, 18, 19, 24], "l182": [13, 18, 19], "l193": 24, "l194": 24, "l201": [9, 11, 17], "l202": 24, "l203": [9, 11, 17], "l208": [9, 11, 17], "l213": 24, "l214": [9, 11, 17], "l218": [9, 11, 17], "l220": [13, 18, 19], "l239": [9, 11, 17], "l251": [13, 18, 19], "l255": [9, 11, 17], "l259": 24, "l261": [13, 18, 19], "l294": [9, 11, 17], "l33": 24, "l345": [9, 11, 17], "l35": [9, 11, 17], "l373": [9, 11, 17], "l380": [9, 11, 17], "l387": [13, 18, 19], "l41": [13, 18, 19], "l412": [9, 11, 17], "l422": [9, 11, 17], "l5": [14, 15], "l50": [9, 11, 17], "l56": 24, "l58": [9, 11, 17], "l61": 24, "l62": 24, "l67": [13, 18, 19], "l76": [9, 11, 17], "l81": [13, 18, 19], "l83": 24, "l88": 24, "lab": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "label": [22, 23, 24, 27, 29, 30], "lan": 15, "languag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "laptop": [31, 33, 34], "larg": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "larger": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "last": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "last_chosen": [27, 29, 30], "latenc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "later": [22, 23, 24, 27, 29, 30, 31, 33, 34], "latest": [2, 6, 10, 12, 22, 23, 24, 27, 29, 30, 31, 33, 34], "latin1": [31, 33, 34], "launch": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "layer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 27, 29, 30], "layerindex": [31, 33, 34], "layerscap": [31, 33, 34], "layout": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30, 31, 33, 34], "lb": [1, 9, 11, 17], "lba": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ld": [22, 23, 24, 31, 33, 34], "ldd": [31, 33, 34], "ldflag": [31, 33, 34], "lead": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "learn": [14, 15, 31, 33, 34], "leas": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "least": [31, 33, 34], "leav": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "led": [2, 6, 10, 12, 21], "led1": [3, 7, 14, 15], "led2": [3, 7, 14, 15], "led3": [3, 7, 14, 15], "leds1grp": [1, 3, 4, 5, 7, 8], "left": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "legacy2": [31, 33, 34], "legacyboot": [2, 10, 12], "legacyfb_depth": [31, 33, 34], "len": [22, 23, 24], "less": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "let": [22, 23, 24, 27, 29, 30], "level": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "level_cel": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lf": [22, 23, 24], "lib": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "libcomposit": [1, 3, 4, 5, 7, 8], "libcrypto": [31, 33, 34], "libegl1": [31, 33, 34], "libexec": 34, "libgl": [31, 33, 34], "libgpiod": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "liblz4": [31, 33, 34], "libopencv": [31, 33, 34], "libra": 0, "libra_defconfig": 9, "librari": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "libsdl1": [31, 33, 34], "libssl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "libtpm2tss": [23, 24], "libubootenv": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "libvirt": [31, 33, 34], "libyaml": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "licens": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 31, 33, 34], "license_flags_accept": [31, 33, 34], "lifetim": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lighttpd": [31, 33, 34], "like": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "lilo": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "limit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "line": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "link": [5, 7, 8, 13, 18, 19, 22, 23, 24, 31, 33, 34], "linker": [31, 33, 34], "linux": [27, 29, 30, 32], "list": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "listen": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "littl": [31, 33, 34], "lmsensor": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "ln": [1, 3, 4, 5, 7, 8, 9, 11, 17, 31, 33, 34], "load": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "loadaddr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "loader": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "loadkei": [31, 33, 34], "loadraucfdt": 27, "loadraucimag": 27, "local": [5, 8, 9, 11, 13, 17, 18, 19, 22, 23, 24, 27, 29, 30], "localhost": [1, 3, 4, 9, 11, 14, 15, 16, 17], "locat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "lock": [27, 29, 30], "log": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "logic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28], "logind": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "long": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "longer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "look": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 27, 29, 30, 31, 33, 34], "loss": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lost": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "lot": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 31, 33, 34], "low": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "low_power_mode_use_cas": [22, 23, 24], "lowdriv": [22, 23, 24], "lower": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "lower_up": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lowest": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lpddr4_": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lpddr4_dmem_1d_": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lpddr4_dmem_1d_v202201": [22, 23, 24], "lpddr4_dmem_2d_": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lpddr4_dmem_2d_v202201": [22, 23, 24], "lpddr4_imem_1d_": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lpddr4_imem_1d_v202201": [22, 23, 24], "lpddr4_imem_2d_": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lpddr4_imem_2d_v202201": [22, 23, 24], "lpddr4_pmu_train_1d_dmem_202006": [13, 18, 19], "lpddr4_pmu_train_1d_imem_202006": [13, 18, 19], "lpddr4_pmu_train_2d_dmem_202006": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "lpddr4_pmu_train_2d_imem_202006": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "lpm": [22, 23, 24], "lpuart1_rx": [22, 23, 24], "lpyod3ib": [23, 24], "lqihanjzsvg": [23, 24], "lsblk": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lsm": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "lsof": [31, 33, 34], "lspci": [1, 3, 4, 9, 11, 14, 15, 16, 17], "lsr": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "lt": [31, 33, 34], "ltr": [1, 3, 4, 9, 11, 14, 15, 16, 17], "lun": [1, 3, 4, 5, 7, 8], "lvd": [3, 7, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lvds0": [9, 11, 14, 15, 16, 17], "lvds1": [9, 11, 13, 14, 15, 16, 17, 18, 19], "lwb": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "lxi7": [23, 24], "m": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "m33": 21, "m4": [2, 5, 7, 8], "m7": [10, 12, 13, 18, 19], "mac": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "mac1": [22, 23, 24], "mac1_addr": [22, 23, 24], "mac2": [22, 23, 24], "mac2_addr": [22, 23, 24], "machin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "machineenv": [31, 33, 34], "machinenam": [1, 5, 9, 11, 17], "made": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "magic": [27, 29, 30], "mai": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "mail": [31, 33, 34], "main": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "mainca": [27, 29, 30], "mainli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "mainlin": [0, 11, 13, 17, 18, 19, 29, 30, 31, 33, 34], "mainline_": [31, 33, 34], "maintain": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mainten": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "major": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 18, 22, 24, 27, 29, 30, 31, 33, 34], "make": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "makefil": [31, 33, 34], "man": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "manag": [2, 6, 10, 12, 21, 26, 27, 29, 30], "mani": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "manifest": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30, 31, 33, 34], "manifest_fil": [27, 29, 30], "manipul": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "manner": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "manual": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 26, 27, 29, 30, 31, 33, 34], "manual_en": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "manualhead": [9, 11, 13], "manufactur": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "map": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "mar": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "march": [31, 33, 34], "mark": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "maskabl": [1, 3, 4, 9, 11, 14, 15, 16, 17], "mass": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mass_storag": [1, 3, 4, 5, 7, 8], "master": [2, 6, 10, 12, 22, 23, 24, 31, 33, 34], "match": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "max": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "max_bright": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "max_enh_size_mult": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "maxdepth": [27, 29, 30], "maximum": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "maxmtu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mayb": [31, 33, 34], "mb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "mbp": [1, 3, 4, 5, 7, 8, 22, 23, 24], "mbr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mcast": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mcp2518fd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "mcp25xxfd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "mcu": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "mcux": [1, 3, 4, 9, 11, 14, 15, 16, 17], "mcuxpresso": [1, 3, 4, 9, 11, 14, 15, 16, 17], "mcuxsdk": [1, 3, 4, 9, 11, 14, 15, 16, 17], "mean": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "meant": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "measur": [28, 31, 33, 34], "mechan": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "media": [1, 9, 11, 17, 27, 29, 30], "media_by_label_auto_mount_end": [27, 29, 30], "medium": [1, 9, 11, 17, 31, 33, 34], "meet": [22, 23, 24], "mega": [31, 33, 34], "megabit": [22, 23, 24], "mem": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "mem_": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "memfil": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "memori": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "mention": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "menu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "menuconfig": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "merg": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "mesa": [31, 33, 34], "meson": 34, "messag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "messtechnik": [27, 29, 30], "meta": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "metal": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "method": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "metric": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "mfgtool": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mfloat": [31, 33, 34], "mfwwdqyjkozihvcnaqebbqadswawsajbambl5ng8y8lip2hrmdgfqzri72mqhfy6": [23, 24], "mhz": [22, 23, 24], "mib": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "mic3r": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "mickledor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 29, 33, 34], "micro": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "micron": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "microphon": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "microsecond": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "midnight": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "might": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "migrat": [27, 29, 30], "miibvqibadanbgkqhkig9w0baqefaascat8wgge7ageaakeaxsvmcbxjwuknyeuz": [23, 24], "milli": [31, 33, 34], "millicelsiu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "millisecond": [1, 5, 9, 11, 13, 17, 18, 19], "mimx8ml8_m7": [9, 11, 13, 14, 15, 16, 17, 18, 19], "mimx8mm6_m4": [1, 3, 4, 22, 23, 24], "mimx8mm_phyboard_poli": [1, 3, 4], "mimx8mp_phyboard_pollux": [9, 11, 13, 14, 15, 16, 17, 18, 19], "min": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "mind": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "mini": [0, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30, 31, 33, 34], "minicom": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "minim": [22, 23, 24, 27, 29, 30], "minimum": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "minmtu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "minnow": [31, 33, 34], "minor": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 19, 23, 27, 29, 30, 31, 33, 34], "minut": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "mipi": [3, 7, 14, 15, 16], "mira": [31, 33, 34], "mirco": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "miscellan": [31, 33, 34], "miss": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "mix": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "mixer": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "mkdir": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "mkimag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ml": [14, 15], "ml2": [31, 33, 34], "mlc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mlxkjcxrhpo4hsxaloswdy9": [23, 24], "mm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mmc": [2, 6, 10, 12, 21, 27, 29, 30, 31, 33, 34], "mmc0": [3, 7, 14, 15, 22, 23, 24], "mmc1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mmc2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "mmcarg": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "mmcblk0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "mmcblk0boot0": [22, 23, 24], "mmcblk0boot1": [22, 23, 24], "mmcblk0p1": [22, 23, 24], "mmcblk0p2": [22, 23, 24], "mmcblk0rpmb": [22, 23, 24], "mmcblk1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "mmcblk1p": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mmcblk1p1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mmcblk1p2": [3, 7, 14, 15, 18, 22, 23, 24], "mmcblk2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "mmcblk2boot0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "mmcblk2boot1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "mmcblk2p1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "mmcblk2p2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "mmcblk2p5": [27, 29, 30], "mmcblk2p6": [27, 29, 30], "mmcblk2rpmb": [3, 7, 14, 15, 18], "mmcblk3": [27, 29, 30], "mmcblkp1": [3, 7, 14, 15], "mmcblkxp0": [22, 23, 24], "mmcdev": [1, 9, 11, 17], "mnt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "modalia": [31, 33, 34], "mode": [27, 29, 30, 31, 33, 34], "model": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "modern": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "modetest": [3, 14, 15], "modif": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "modifi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "modprob": [1, 3, 4, 5, 7, 8, 22, 23, 24, 31, 33, 34], "modul": [3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 22, 23, 24, 27, 29, 30], "modular": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "module_conf_your": [31, 33, 34], "modules_instal": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "moment": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 31, 33, 34], "monitor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "mono": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "month": [31, 33, 34], "more": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 27, 29, 30, 31, 33, 34], "mospuyg6vxvgg9xp4fcciqdhb01rohr": [23, 24], "most": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "mostli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "mount": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "mountprefix": [27, 29, 30], "move": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "mp3": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "mp4": [3, 14, 15], "mr": [1, 3, 4, 9, 11, 14, 15, 16, 17], "msdo": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "msi": [1, 3, 4, 9, 11, 14, 15, 16, 17], "mt": [22, 23, 24], "mt25qu512a": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "mtd": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30], "mtd0": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "mtd1": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "mtd2": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "mtd3": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "mtdinfo": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "mtdpart": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "mtu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "much": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "multi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "multiarch": [1, 3, 4, 9, 11, 14, 15, 16, 17], "multicast": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "multilin": [31, 33, 34], "multimast": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "multimedia": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "multipl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 31, 33, 34], "multiplex": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "must": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "mute": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "mux": [2, 6, 10, 12, 21, 31, 33, 34], "mv": [31, 33, 34], "mx": [26, 27, 29, 30], "mx6": [27, 29, 30, 31, 33, 34], "mx6ul": [27, 29, 30, 31, 34], "mx7": 31, "mx8": [22, 23, 24, 27, 29, 30], "mx8m": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 31, 33, 34], "mx8mm": [0, 5, 7, 8, 27, 29, 30, 31], "mx8mm_iomuxc_gpio1_io01_gpio1_io1": [1, 3, 4], "mx8mm_iomuxc_gpio1_io14_gpio1_io14": [1, 3, 4], "mx8mm_iomuxc_gpio1_io15_gpio1_io15": [1, 3, 4], "mx8mm_iomuxc_sai2_rxc_uart1_dce_rx": [1, 3, 4], "mx8mm_iomuxc_sai2_rxd0_uart1_dce_rts_b": [1, 3, 4], "mx8mm_iomuxc_sai2_rxfs_uart1_dce_tx": [1, 3, 4], "mx8mm_iomuxc_sai2_txfs_uart1_dce_cts_b": [1, 3, 4], "mx8mn_iomuxc_gpio1_io01_gpio1_io1": [5, 7, 8], "mx8mn_iomuxc_gpio1_io14_gpio1_io14": [5, 7, 8], "mx8mn_iomuxc_gpio1_io15_gpio1_io15": [5, 7, 8], "mx8mn_iomuxc_sai2_rxc_uart1_dce_rx": [5, 7, 8], "mx8mn_iomuxc_sai2_rxd0_uart1_dce_rts_b": [5, 7, 8], "mx8mn_iomuxc_sai2_rxfs_uart1_dce_tx": [5, 7, 8], "mx8mn_iomuxc_sai2_txfs_uart1_dce_cts_b": [5, 7, 8], "mx8mp": [0, 1, 3, 4, 5, 7, 8, 27, 30, 31, 34], "mx8mp_iomuxc_uart1_rxd_uart1_dce_rx": [9, 11, 13, 14, 15, 16, 17, 18, 19], "mx8mp_iomuxc_uart1_txd_uart1_dce_tx": [9, 11, 13, 14, 15, 16, 17, 18, 19], "mx9": [29, 30], "mx93": [20, 29, 30, 33, 34], "mx93_fusemap": [22, 23, 24], "mx93_pad_uart1_rxd__lpuart1_rx": [22, 23, 24], "mx93_pad_uart1_txd__lpuart1_tx": [22, 23, 24], "mx93a1": [22, 23, 24], "n": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "n102": 3, "n104": 7, "n105": [14, 15, 23], "n106": [3, 5, 8], "n110": 16, "n113": 23, "n114": [22, 23], "n119": [1, 4], "n122": 23, "n125": [5, 8], "n132": [14, 15], "n133": 16, "n141": [14, 15], "n147": [7, 22, 23], "n149": 3, "n150": 16, "n151": 23, "n155": [22, 23], "n165": [14, 15], "n166": 7, "n172": 23, "n173": [22, 23], "n175": [1, 4, 16], "n180": [14, 15, 23], "n188": 3, "n190": [22, 23], "n191": 16, "n194": 23, "n195": 22, "n196": [5, 8], "n199": 16, "n201": [14, 15, 23], "n206": 7, "n207": [14, 15, 16], "n212": 16, "n216": [14, 15, 22, 23], "n220": [5, 8, 14, 15], "n223": 16, "n228": 3, "n229": 16, "n238": 7, "n240": 3, "n244": [1, 4], "n248": 7, "n254": 7, "n255": [14, 15], "n257": 1, "n259": [5, 8], "n25q256ax1": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "n26": [14, 15], "n262": 23, "n264": [5, 8, 16], "n266": 3, "n267": [5, 8, 22], "n271": 3, "n277": [3, 14, 15], "n287": 16, "n291": [1, 4], "n293": 7, "n301": [5, 8], "n309": [5, 8], "n311": [1, 4], "n315": 3, "n319": [1, 4], "n33": [16, 22, 23], "n331": [14, 15], "n335": [1, 4], "n341": [14, 15, 16], "n347": [1, 4], "n35": 7, "n351": 16, "n36": [1, 4], "n367": [14, 15], "n37": 3, "n380": 16, "n383": [1, 4], "n41": [14, 15], "n45": [5, 8], "n47": 7, "n50": [5, 8, 16], "n53": 3, "n536": 16, "n54": [1, 4], "n56": 3, "n57": [14, 15, 23], "n58": 16, "n59": [1, 4], "n61": [22, 23], "n62": [22, 23], "n71": 3, "n72": [14, 15], "n75": 7, "n76": 16, "n78": [5, 8], "n83": 23, "n87": [1, 4], "n88": [22, 23], "n98": 7, "name": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "nameservic": [22, 23, 24], "nand": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31], "nand0": [27, 29, 30], "nano": [0, 1, 3, 4, 27, 29, 30], "nash": [21, 33], "nash_defconfig": 23, "nativ": [14, 15, 31, 33, 34], "natur": [31, 33, 34], "nbd0": [27, 29, 30], "nbd_disconnect": [27, 29, 30], "nblk": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "nd": [22, 23, 24], "ne": [27, 29, 30], "necessari": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "necessarili": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "need": [27, 29, 30, 31, 33, 34], "neon": [31, 33, 34], "net": [31, 33, 34], "netarg": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "netdev_up": [1, 3, 4, 9, 11, 14, 15, 16, 17], "netmask": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "network": [2, 6, 10, 12, 21], "networkctl": [31, 33, 34], "networkd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "neural": [9, 11, 14, 15, 16, 17], "never": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "nevertheless": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "new": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "new_desc_block": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "newer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "newest": [1, 3, 4, 9, 11, 14, 15, 16, 17], "newli": [27, 29, 30], "newlin": [31, 33, 34], "newvari": [31, 33, 34], "next": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "nfsroot": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "nfssrc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "nginx": [27, 29, 30], "nice": [31, 33, 34], "nightli": [31, 33, 34], "nl80211": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "nmap": [31, 33, 34], "no_bootenv": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "no_extens": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "no_overlai": [3, 4, 5, 7, 8, 14, 15, 16, 22, 23, 24], "no_root_squash": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "no_subtree_check": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "noarp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "node": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "nomin": [22, 23, 24], "nominaldr": [22, 23, 24], "non": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "none": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "nonfree2": [31, 33, 34], "noout": [23, 24], "nor": [2, 6, 10, 12, 13, 18, 19, 31, 33, 34], "normal": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "noscan": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "nostop": [31, 33, 34], "notabl": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "note": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "noth": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "notic": [13, 18, 19, 25, 31, 33, 34], "notif": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "notifi": [27, 29, 30, 31, 33, 34], "now": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "nproc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "npu": [10, 12], "nslegnc23ckttnfkypjm0scaweaaq": [23, 24], "number": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "numer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "numraucm": [27, 29, 30], "numrxqueu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "numtxqueu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "nv": [27, 29, 30, 31, 33, 34], "nvmem": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "nvmem_imx_ocotp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "nvram": [1, 9, 11, 17], "nxp": [0, 1, 3, 4, 5, 7, 8, 9, 11, 13, 16, 17, 18, 19, 20, 22, 23, 24, 27, 29, 30, 31, 33, 34], "o": [2, 6, 10, 12, 21, 27, 29, 30, 31, 33, 34], "objdetect2": [31, 33, 34], "observ": [22, 23, 24], "obtain": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "occupi": [27, 29, 30], "occur": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "occurr": [31, 33, 34], "ocl2": [31, 33, 34], "ocotp0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ocotp_ctrl": [2, 6, 10, 12, 21], "ocotp_mac_addr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ocotp_mac_addr0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ocotp_mac_addr1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ocotp_mac_addr2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ocotp_root_clk": [14, 15], "octal": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "od": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "oe": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "oecore_native_sysroot": 34, "off": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "offer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "offici": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "offset": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "offset1": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "offset2": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "often": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "oftre": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "oftree0": [27, 29, 30], "ohm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "ok": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24, 27, 29, 30], "okai": [1, 3, 4, 27, 29, 30], "old": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "old_desc_block": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "older": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "omtp": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "onboard": [9, 11, 14, 15, 16, 17], "onc": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "ondemand": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "one": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "ones": [27, 29, 30], "oneshot": [27, 29, 30], "onli": [3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "onlin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "open": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 31, 33, 34], "opencl": [31, 33, 34], "opencv": [14, 15], "opengl": [31, 33, 34], "opensourc": [31, 33, 34], "openssl": [23, 24, 27, 29, 30, 31, 33, 34], "opensus": [1, 9, 11, 17], "oper": [27, 29, 30, 31, 33, 34], "oppos": [27, 29, 30], "opt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "opte": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "optim": [31, 33, 34], "option": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "order": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "ordinari": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "org": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "organ": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "origin": [31, 33, 34], "oss": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "otg": [2, 6, 15, 22, 23, 24], "other": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "otherwis": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "otp": [2, 6, 10, 12, 21], "our": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 26, 27, 29, 30, 31, 33, 34], "out": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "outdoor": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "output": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "over": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "overal": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "overdr": [22, 23, 24], "overhead": [31, 33, 34], "overlay1": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "overlay2": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "overlayconfignam": [1, 9, 11, 17], "overlayfilenam": [3, 4, 5, 7, 8, 14, 15, 16, 22, 23, 24], "overrid": [31, 33, 34], "overrun": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "overview": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "overwrit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "overwritten": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "own": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "ownership": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ozon": [1, 3, 4, 7, 14, 15, 16], "p": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "p1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "p2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "packag": [3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 22, 23, 24, 27, 29, 30], "package1": [31, 33, 34], "package2": [31, 33, 34], "packagegroup": [14, 15], "packet": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "pactl": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "pad": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "page": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "pai": [31, 33, 34], "paid": [31, 33, 34], "pair": [31, 33, 34], "pairabl": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "panel": [31, 33, 34], "parallel": [22, 23, 24, 31, 33, 34], "param": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "paramet": [3, 7, 14, 15, 27, 29, 30, 31, 33, 34], "parameternam": [31, 33, 34], "parametervalu": [31, 33, 34], "parent": [27, 29, 30, 31, 33, 34], "parentbu": [22, 23, 24], "parentdev": [22, 23, 24], "pariti": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "pars": [1, 5, 9, 11, 13, 17, 18, 19, 31, 33, 34], "part": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "partconf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "parti": [31, 33, 34], "particular": [1, 5, 9, 11, 13, 17, 18, 19, 27, 29, 30], "particularli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "partit": 28, "partition_access": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "partition_config": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "partition_setting_complet": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "partup": [3, 7, 14, 15, 27, 29, 30], "pass": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "passiv": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "password": [31, 33, 34], "past": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "patch": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "path": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "path_to_fil": [3, 7, 14, 15, 18, 22, 23, 24], "pattern": [31, 33, 34], "pb": [31, 33, 34], "pc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "pcb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "pci": [1, 3, 4, 9, 11, 14, 15, 16, 17], "pcie": [2, 10, 12, 31, 33, 34], "pcl": [31, 33], "pcm": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "pd15": [31, 33, 34], "pd16": [31, 33, 34], "pd17": 31, "pd19": 31, "pd20": [27, 29, 30], "pd21": [31, 34], "pd22": [0, 3, 7, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 31, 34], "pd23": [0, 1, 4, 5, 8, 11, 13, 16, 17, 19, 27, 31, 34], "pd24": [0, 1, 9, 11, 13, 17, 18, 19, 20, 22, 23, 24, 29, 30, 33, 34], "pd25": 9, "pdf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "pdxx": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 34], "peb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "pebav10": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "pem": [23, 24, 27, 29, 30], "per": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "perat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "perform": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "period": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "peripher": [2, 6, 10, 12, 21, 31, 33, 34], "perl": [31, 33, 34], "perm": [31, 33, 34], "perman": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "permiss": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "persist": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "person": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "pexpect": [31, 33, 34], "pfifo_fast": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "pga": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "phase": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "phoni": [31, 33, 34], "photo2": [31, 33, 34], "phpinfo": [31, 33, 34], "phsync": [3, 14, 15], "phy": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "phy1": [13, 18, 19, 22, 31, 33, 34], "phy10": [9, 11, 17], "phy13": [3, 7, 14], "phy17": [3, 7, 14, 15], "phy18": 15, "phy2": [31, 33, 34], "phy3": [1, 4, 5, 8, 16, 18, 23], "phy4": [13, 19], "phy5": [1, 4, 5, 8, 16], "phy6": 24, "phy7": [9, 11, 17], "phy8": 24, "phy9": [3, 7], "phyboard": [9, 21, 27, 29, 30, 31, 33, 34], "phyboard_mira_imx6_11": [31, 33, 34], "phybuild": [31, 33, 34], "phycore_": 27, "phycore_defconfig": 24, "phycore_fitimage_env_bootlog": [31, 33, 34], "phycore_imx8m": [31, 33, 34], "phycore_imx8mm": [1, 3, 4], "phycore_imx8mn": [5, 7, 8], "phycore_imx8mp": [11, 13, 14, 15, 16, 17, 18, 19], "phycore_imx93": [22, 23, 24], "phyflex": [31, 33, 34], "phygat": 31, "phylinux": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 32], "phylinx": [31, 33, 34], "physic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "phytec": [2, 6, 10, 12, 21, 25, 27, 29, 30, 32], "phytec_": [13, 18, 19], "phy\u00b2octo": [31, 33, 34], "pick": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "picophi": [1, 3, 4], "pid": [31, 33, 34], "piec": [31, 33, 34], "pin": [2, 6, 10, 12, 21, 31, 33, 34], "pinctrl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "pinctrl_l": [1, 3, 4, 5, 7, 8], "pinctrl_uart1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ping": [31, 33, 34], "pinmux": [1, 3, 4, 5, 7, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "pip": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "pip3": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "pipelin": [22, 23, 24], "piscan": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "pixel": [9, 11, 14, 15, 16, 17, 22, 23, 24], "pkei": [23, 24], "pkg": [31, 33, 34], "pki": [27, 29, 30], "pl1552": 34, "place": [27, 29, 30, 31, 33, 34], "plai": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "platform": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "playback": [13, 18, 19], "playbin": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "pleas": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 31, 33, 34], "plenti": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "plot": [31, 33, 34], "plu": [0, 27, 29, 30, 34], "plug": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "pluggabl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "plugin": [31, 33, 34], "pm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "pmbw": [31, 33, 34], "pmic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "pn": [31, 33, 34], "png": [31, 33, 34], "png16m": [31, 33, 34], "podman": [31, 33, 34], "point": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "poki": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "polar": [22, 23, 24], "poli": [14, 15, 27, 29, 30], "polici": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "poll": [22, 23, 24], "pollux": [1, 3, 4, 5, 7, 8, 9, 34], "pool": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "popul": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "populate_sdk": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "port": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "port0": [1, 9, 11, 17], "port1": [1, 9, 11, 17], "portabl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "posit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "possibl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "post": [27, 29, 30], "power": [2, 6, 10, 12, 21, 31, 33, 34], "poweroff": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "powersav": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "pq": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "practic": [3, 7, 14, 15, 22, 23, 24], "pre": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "prebuilt": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "preconfigur": [31, 33, 34], "prefer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "preferred_provider_virtu": [31, 33, 34], "prefetch": [1, 3, 4, 9, 11, 14, 15, 16, 17], "prefix": [31, 33, 34], "prepar": [2, 6, 10, 12, 21, 31, 33, 34], "prepare_mcor": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "prepend": [31, 33, 34], "preselect": [31, 33, 34], "present": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "preserv": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "press": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "prevent": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "previou": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "previous": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "primari": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "print": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "printenv": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "prior": [31, 33, 34], "prioriti": [27, 29, 30, 31, 33, 34], "priv_kei": [23, 24], "privat": [23, 24, 27, 29, 30], "privileg": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "pro": [31, 33, 34], "probabl": [13, 18, 19, 31, 33, 34], "probe": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 31, 33, 34], "problem": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "proc": [27, 29, 30], "proce": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "procedur": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "process": [28, 31, 33, 34], "processor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "produc": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "product": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "produkt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "prog": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "program": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "programm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "progress": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "project": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 32], "promin": [27, 29, 30], "promiscu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "prompt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "prone": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "prop": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "properli": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "properti": 4, "proprietari": [31, 33, 34], "protect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "proto": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "protocol": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "provid": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "provis": [31, 34], "proxy_force_rang": [27, 29, 30], "pscan": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "psci": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "psk": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "pub_kei": [23, 24], "pubin": [23, 24], "public": [23, 24, 27, 29, 30, 31, 33, 34], "publicli": [27, 29, 30], "pubout": [23, 24], "pull": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 32], "pulseaudio": [5, 7, 8], "purpos": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "push": [1, 5, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "put": [3, 7, 14, 15, 22, 23, 24], "pvsync": [3, 14, 15], "pwd": [31, 33, 34], "pwm": [9, 11, 13, 14, 15, 16, 17, 18, 19], "pxp": 21, "pybind11": [14, 15], "pyeiq": [14, 15], "pylint3": 31, "python": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "python2": [31, 33, 34], "python3": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "q": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "q2j55l": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "q4": [1, 3, 4, 9, 11, 14, 15, 16, 17], "qdisc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "qemu": [31, 33, 34], "qlen": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "qml": [31, 33, 34], "qo": [3, 14, 15], "qoriq": [31, 33, 34], "qspi": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "qt": [5, 7, 8], "qt5demo": [3, 14, 15, 31], "qt6": [1, 4, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "qt6demo": [1, 4, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "qtdemo": [3, 14, 15, 31, 33, 34], "qtdemo_git": [31, 33, 34], "qtdemux": [3, 14, 15], "qtphy": [1, 4, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "quad": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "queri": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "question": [25, 31, 33, 34], "queue": [3, 14, 15], "quick": [31, 33, 34], "quickstart": [9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "quit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "quot": [1, 5, 9, 11, 13, 17, 18, 19], "qwertz": [31, 33, 34], "qxjwxiu3": [23, 24], "r": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "r0": [27, 29, 30, 31, 33, 34], "r150": [31, 33, 34], "r7": [31, 33, 34], "r8169": [31, 33, 34], "ra": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "racer": [31, 33, 34], "radio": [1, 3, 4, 9, 11, 14, 15, 16, 17], "ram": [18, 27], "rand": [23, 24], "random": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rang": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "rate": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rather": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rauc": [2, 6, 10, 12, 21, 26], "rauc_": [27, 29, 30], "rauc_cert_fil": [27, 29, 30], "rauc_downgrade_barri": [27, 29, 30], "rauc_flash_nand_from_mmc": [27, 29, 30], "rauc_flash_nand_from_tftp": [27, 29, 30], "rauc_image_fstyp": 30, "rauc_init_nand": [27, 29, 30], "rauc_intermediate_cert_fil": [27, 29, 30], "rauc_key_fil": [27, 29, 30], "rauc_keyring_fil": [27, 29, 30], "rauc_slot_rootf": [27, 29, 30], "rauc_update_sourc": [27, 29, 30], "raucarg": [27, 29, 30], "raucb": [27, 29, 30], "raucboot": 27, "raucbootpart": [27, 29, 30], "raucdev": 27, "raucinit": [29, 30], "raucm": [27, 29, 30], "raucpart": 27, "raucrootpart": [27, 29, 30], "raucslot": 27, "raw": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "rc": [31, 33, 34], "rc1": [31, 33, 34], "rc2": [31, 33, 34], "rc3": [31, 33, 34], "rc4": [31, 34], "rc5": [31, 34], "rc6": 34, "rdk": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19], "re": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "reach": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "reachabl": [1, 3, 4, 9, 11, 14, 15, 16, 17], "read": [27, 29, 30, 31, 33, 34], "readabl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "readi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "readm": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "readthedoc": [27, 29, 30], "real": [31, 33, 34], "realiz": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "realli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "reason": [31, 33, 34], "reboot": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "rebuild": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "receiv": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "recent": [31, 33, 34], "recip": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "recipe_sysroot_n": [14, 15], "recogn": [1, 3, 4, 7, 9, 11, 14, 15, 16, 17, 18, 22, 23, 24, 31, 33, 34], "recommend": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "recommit": [31, 33, 34], "recompil": [31, 33, 34], "record": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "recov": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "recoveri": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "red": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "redeploi": [31, 33, 34], "reduc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "redund": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30], "redundantli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "ref": [31, 33, 34], "refer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 26, 28, 31, 33, 34], "referenc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "reflect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "refresh": [3, 14, 15], "reg": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "reg_usdhc2_vmmc": 4, "regardless": [31, 33, 34], "region": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "regul": [4, 22, 23, 24], "regular": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "regularli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "regulator_summari": [22, 23, 24], "regulatori": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "rel": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "relat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25], "releas": [22, 23, 24, 25, 27, 29, 30, 32], "relev": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "reli": [27, 29, 30], "reload": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "remain": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 19, 27, 29, 30], "remaining_attempt": [27, 29, 30], "rememb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "remot": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "remoteproc0": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "remov": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "renam": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "render": [13, 18, 19, 31, 33, 34], "repair": [31, 33, 34], "repeat": [1, 5, 9, 11, 13, 17, 18, 19], "replac": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "repo": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "reporepo": [31, 33, 34], "reporepo_branch": [31, 33, 34], "report": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "repositori": [25, 27, 29, 30, 31, 33, 34], "repres": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "represent": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "reproduc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "req_meta": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "request": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 27, 29, 30], "requir": [27, 29, 30, 31, 33, 34], "rerun": [31, 33, 34], "reserv": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "reset": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "resid": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "resistor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "resize2f": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "resizepart": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "resolv": [31, 33, 34], "resourc": [31, 33, 34], "respect": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24, 27, 29, 30], "restart": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "restrict": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "result": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "resum": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "retriev": [31, 33, 34], "return": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "reus": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "reusabl": [31, 33, 34], "rev": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "revers": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "revert": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "revis": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "revok": [27, 29, 30], "rework": [31, 33, 34], "rf": [31, 33, 34], "ri": [27, 29, 30], "right": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "river": [31, 33, 34], "rk3288": [31, 33, 34], "rkejwbl2t5z868fnarggmvxzt4x": [23, 24], "rm": [31, 33, 34], "rmdir": [27, 29, 30], "ro": [31, 33, 34], "robust": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "role": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "roll": [27, 29, 30], "rom": [1, 3, 4, 9, 11, 14, 15, 16, 17], "root": [27, 29, 30], "root0": [27, 29, 30], "rootf": [27, 29, 30, 31, 33, 34], "rootfspath": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rootfstyp": [27, 29, 30], "rootwait": [31, 33, 34], "rotat": [22, 23, 24], "roughli": [31, 33, 34], "round": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "rout": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "routin": [31, 33, 34], "rpmb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rpmsg": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 18, 22, 23, 24], "rs232": [2, 6, 10, 12, 21], "rs485": [2, 6, 10, 12, 21], "rs485conf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "rs485test": [9, 11, 13, 14, 15, 16, 17, 18, 19], "rsa": [23, 24, 27, 29, 30], "rst": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "rsync": [31, 33, 34], "rt": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19, 31, 33, 34], "rtc": [2, 6, 10, 12, 21], "rtc0": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "rtc_bsm_direct": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_bsm_disabl": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_bsm_level": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_bsm_standbi": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_feature_alarm": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_feature_alarm_res_2": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_feature_alarm_res_minut": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_feature_alarm_wakeup_onli": [1, 5, 9, 11, 13, 17, 18, 19, 22, 23, 24], "rtc_feature_backup_switch_mod": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_feature_cnt": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_feature_correct": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_feature_need_week_dai": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_feature_update_interrupt": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rto": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "rule": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "run": [2, 10, 12, 21, 27, 29, 30, 32], "run1": [31, 33, 34], "runal": [31, 33, 34], "runtim": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "runtimewatchdogsec": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rv": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rv3028": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rw": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rwx": [31, 33, 34], "rx": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rxd": [22, 23, 24], "s0j58x": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "s1": [2, 6], "s16_le": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "s16le": [3, 14, 15], "s2": [22, 23, 24], "s3": [1, 3, 4, 5, 7, 8, 10, 12, 21], "s5": [1, 3, 4, 5, 7, 8], "s_cmd_set": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "safe": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "sai": [22, 23, 24], "sai2_rxf": [1, 3, 4, 5, 7, 8], "said": [22, 23, 24, 31, 33, 34], "same": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "sampl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "sandbox": [1, 3, 4, 7, 14, 15, 16], "saniti": [31, 33, 34], "satisfactori": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "satisfi": [31, 33, 34], "save": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "savedefconfig": [31, 33, 34], "saveenv": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "scaling_available_frequ": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "scaling_available_governor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "scaling_cur_freq": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "scaling_governor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "scaling_setspe": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "scan": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 24, 31, 33, 34], "scanner": [31, 33, 34], "scarthgap": [1, 9, 11, 13, 17, 18, 19, 24, 30, 34], "scenario": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "schedul": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "schedutil": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "schemat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "scheme": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "scl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "scm": [31, 33, 34], "sco": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "sconf_vers": [31, 33, 34], "scope": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "scp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "scr": [1, 9, 11, 17], "scratch": [31, 33, 34], "script": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "scsi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sd": [2, 6, 10, 12, 21, 27, 29, 30, 31, 33, 34], "sda": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sda1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sdb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sdb1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sdb2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sdcard": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sde": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "sde1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sde2": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "sde3": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sdevic": [31, 33, 34], "sdktargetsysroot": [31, 33, 34], "sdl": [31, 33, 34], "sdp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sdx": [1, 3, 7, 9, 11, 14, 15, 17], "se": [31, 33, 34], "search": [1, 9, 11, 17, 31, 33, 34], "sec": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 19, 22, 23, 24], "second": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "secondari": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "secondli": [31, 33, 34], "sect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "section": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "sector": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "secur": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28], "securiphi": 34, "see": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "seek": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "seen": [27, 29, 30, 31, 33, 34], "seg": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "seg1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "seg2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "segger": [1, 3, 4, 9, 11, 14, 15, 16, 17], "segin": [21, 27, 29, 30, 31, 33], "segin_defconfig": 23, "select": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "selector": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "self": [27, 29, 30], "send": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "sens": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sensor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sent": [1, 9, 11, 13, 16, 17, 19, 22, 23, 24], "separ": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "sequenc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sequenti": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "serial": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "serialnumb": [1, 3, 4, 5, 7, 8], "serv": [27, 29, 30], "server": [27, 29, 30, 31, 33, 34], "serveraddr": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "serverip": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "servic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "session": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19, 31, 33, 34], "set": [2, 6, 10, 12, 21, 27, 29, 30, 32], "setenv": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "setexpr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "setfacl": [31, 33, 34], "setscen": 32, "setup": [28, 32], "sever": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "sf": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "sh": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "sha256": [27, 29, 30], "shadow": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "share": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "shell": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "ship": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "short": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "should": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "shouldn": [22, 23, 24], "show": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "shown": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "shut": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "shutdown": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "shutdownwatchdogsec": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "si": [31, 33, 34], "side": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "sigil": [31, 33, 34], "sigint": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "sign": [1, 9, 11, 17, 27, 29, 30, 31, 33, 34], "signal": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "signatur": [27, 29, 30, 31, 33, 34], "sigterm": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "silicon": [9, 11, 13, 14, 15, 16, 17, 18, 19, 33], "similar": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 23, 24, 27, 29, 30, 31, 33, 34], "simpl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "simpler": [27, 29, 30, 31, 33, 34], "simplest": [1, 3, 4, 9, 11, 14, 15, 16, 17], "simpli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "simul": [31, 33, 34], "simultan": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 19, 22, 23, 24], "sinc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "singl": [1, 3, 4, 5, 7, 8, 13, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "singleindex": [31, 33, 34], "sink": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "sink_numb": [1, 4, 9, 11, 16, 17, 23, 24], "site": 32, "situat": [31, 33, 34], "six": [1, 3, 4, 5, 7, 8, 31, 33, 34], "size": [5, 7, 8, 18, 22, 23, 24, 27, 29, 30, 31, 33, 34], "sjw": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "skeleton": [31, 33, 34], "skip": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sleep": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "slider": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "slot": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28], "slotclass": [27, 29, 30], "slower": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "small": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "smaller": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "smallest": [31, 33, 34], "smartphon": [31, 33, 34], "snd_dummi": [3, 14, 15], "sndpebav10": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "snip": [31, 33, 34], "snippet": [3, 4, 7, 8, 14, 15, 16, 27, 29, 30, 31, 33, 34], "snv": [1, 3, 4, 5, 7, 8, 10, 12, 22, 23, 24], "snvs_pwrkei": [9, 11, 13, 14, 15, 16, 17, 18, 19], "snvs_rtc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "so": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "soc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "socat": [31, 33, 34], "socket": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "softvol": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "softvol_hdmi": [14, 15], "softvol_pebav10": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "softwar": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "solder": 24, "solut": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "solv": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "som": [27, 29, 30, 31, 33, 34], "some": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "someth": [1, 3, 9, 11, 14, 15, 17, 27, 29, 30, 31, 33, 34], "soon": [31, 33, 34], "sophist": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sort": [31, 33, 34], "sound": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "soundcard": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "sourc": [25, 27, 29, 30], "source_mirror_url": [31, 33, 34], "soutputfil": [31, 33, 34], "space": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "speak": [31, 33, 34], "speaker": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "special": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 30, 31, 33, 34], "specif": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "specifi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "speed": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "spi": [2, 6, 10, 12, 22, 23, 24], "spiflash": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "spki": [27, 29, 30], "spl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "split": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "spreadsheet": [22, 23, 24], "src_mirror": [31, 33, 34], "srcrev": [31, 33, 34], "srctreecoveredtask": [31, 33, 34], "srv": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ss": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ssd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sset": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "ssh": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "ssid": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "sstate": [31, 33, 34], "sstate_dir": [31, 33, 34], "st": [31, 33, 34], "stabl": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "stack": [1, 3, 4, 9, 11, 14, 15, 16, 17], "stackexchang": [31, 33, 34], "stage": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "stand": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "standalon": [2, 6, 10, 12, 21, 31, 33, 34], "standard": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "standardboot": [1, 9, 11, 17], "standbi": [3, 14, 15], "start": [2, 6, 10, 12, 21, 27, 29, 30, 32], "startch": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "startlba": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "startup": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "stat": [31, 33, 34], "state": [2, 6, 10, 12, 22, 23, 24, 27, 29, 30, 32], "state_prefix": [27, 29, 30], "static": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "statist": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "stats2gnuplot": [31, 33, 34], "statu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "step": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "step_wis": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "stereo": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "sterl": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "sterlinglwb": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "stick": [3, 7, 14, 15, 18, 22, 23, 24, 27, 29, 30], "still": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "stitching2": [31, 33, 34], "stm32mp13x": [31, 33, 34], "stm32mp15x": [31, 33, 34], "stop": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "storag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "store": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "strace": [31, 33, 34], "straightforward": [1, 9, 11, 17, 31, 33, 34], "stream": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28], "strict": [1, 5, 9, 11, 13, 17, 18, 19], "strictli": [31, 33, 34], "strides": [27, 29, 30], "string": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "strip": [31, 33, 34], "strongli": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "structur": [27, 29, 30, 32], "stty": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "style": [1, 9, 11, 17], "sub": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30], "subdev25": [31, 33, 34], "subdirectori": [31, 33, 34], "subfold": [3, 4, 7, 8, 14, 15, 16, 31, 33, 34], "subject": [27, 29, 30], "subnet": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "subnet4": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "subordin": [1, 3, 4, 9, 11, 14, 15, 16, 17], "subproject": [31, 33, 34], "subsect": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 18, 22, 23, 24], "subsequ": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "substat": [1, 3, 4, 9, 11, 14, 15, 16, 17], "subsystem": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "subunit": [31, 33, 34], "succeed": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 31, 33, 34], "success": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "successfulli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "sudo": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "suffer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "suffici": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "suggest": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "suit": [31, 33, 34], "suitabl": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 31, 33, 34], "summar": [31, 33, 34], "summari": [31, 33, 34], "sumo": [31, 33, 34], "superior": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "superres2": [31, 33, 34], "superspe": [9, 11, 13, 14, 15, 16, 17, 18, 19], "supervisor": [22, 23, 24], "suppli": 4, "supplic": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "support": [2, 6, 10, 12, 21, 27, 29, 30, 31, 33, 34], "suppos": [1, 3, 4, 9, 11, 14, 15, 16, 17], "sure": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "surnam": [31, 33, 34], "svb2": [23, 24], "sw": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "swffc": [22, 23, 24], "switch": [2, 6, 10, 12, 21, 28, 31, 33, 34], "switchabl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "switchov": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "sy": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "symbol": [31, 33, 34], "symlink": [31, 33, 34], "sync": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "synopsi": [1, 3, 4, 9, 11, 14, 15, 16, 17], "syntax": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "sysadmin": [31, 33, 34], "syslog": [31, 33, 34], "sysroot": [31, 33, 34], "system": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "system0": [27, 29, 30], "system1": [27, 29, 30], "system_bus_socket": [27, 29, 30], "systemctl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "systemd": [27, 29, 30, 31, 33, 34], "systemd_auto_en": [31, 33, 34], "systemd_w": [27, 29, 30, 31, 33, 34], "t": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "t5": [14, 15], "tab": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "tabl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "tag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "tail": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "take": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "taken": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tar": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "tarbal": [31, 33, 34], "target": [27, 29, 30], "target1": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "target2": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "targettool": [31, 33, 34], "task": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 32], "tauri": 31, "tcm": [1, 3, 4, 9, 11, 14, 15, 16, 17], "team": [31, 33, 34], "technic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "technologi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tee": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tell": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "temp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "temperatur": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "templat": [27, 29, 30, 31, 33, 34], "templateconf": [27, 29, 30], "temporari": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "temporarili": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "tend": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "tera": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "term": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "termin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "test": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "test_kei": [23, 24], "texinfo": [31, 33, 34], "text": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "tftp_address": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tftp_directori": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tftp_option": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tftp_usernam": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tftpd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tftproot": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "than": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "thei": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "them": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "therefor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "thermal": [2, 6, 10, 12, 21], "thermal_zone0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "thi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 27, 29, 30, 31, 33, 34], "thing": [27, 29, 30, 31, 33, 34], "third": [31, 33, 34], "thisdir": [27, 29, 30, 31, 33, 34], "those": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "though": [31, 33, 34], "three": [14, 15, 16, 31, 33, 34], "threshold": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "throttl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "through": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "thu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ti": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "ti33x": [31, 33, 34], "ti_": [31, 33, 34], "tiboot3": [27, 29, 30], "tick": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tile": [3, 14, 15], "time": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "timeout": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "timezon": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tio": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "tiocsrs485": [9, 11, 13, 14, 15, 16, 17, 18, 19], "tispl": [27, 29, 30], "titl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "tlc": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "tlv320": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "tlv320aic3007": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "tmp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "tmpdir": 27, "togeth": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "toggl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "too": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "tool": [2, 6, 10, 12, 21, 27, 29, 30], "toolchain": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "toolkit": [31, 33, 34], "toolset": [31, 33, 34], "top": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "topdir": [27, 31, 33, 34], "topic": [22, 23, 24, 31, 33, 34], "topmost": [31, 33, 34], "total": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "touch": [31, 33, 34], "touchscreen": [22, 23, 24, 31, 33, 34], "touchscreen0": [31, 33, 34], "tpm": 21, "tpm2": [23, 24], "tpm2_getrandom": [23, 24], "tpm2tss": [23, 24], "tq": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "track": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "tradit": [31, 33, 34], "traffic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "transact": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "transceiv": [9, 11, 13, 14, 15, 16, 17, 18, 19], "transfer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "transit": 28, "translat": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "transmiss": [22, 23, 24], "transmit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "transmitt": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "transpar": [31, 33, 34], "transport": [31, 33, 34], "trap": [31, 33, 34], "treat": [1, 5, 9, 11, 13, 17, 18, 19], "tree": [2, 6, 10, 12, 21, 27, 29, 30, 31, 33, 34], "tri": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "trigger": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "trip": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "trip_point_0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "trip_point_1": [22, 23, 24], "tripl": [1, 4, 5, 8, 9, 11, 13, 17, 18, 19, 22, 23, 24], "troubleshoot": 32, "true": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "trust": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "try": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "tseg1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tseg2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tso_max_s": [22, 23, 24], "tso_max_seg": [22, 23, 24], "ttl": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tty": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "ttygs0": [1, 3, 4, 5, 7, 8], "ttylp0": [22, 23, 24], "ttylp6": [23, 24], "ttymxc0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ttymxc1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "ttymxc2": [1, 3, 4, 5, 7, 8], "ttyrpmsg30": [22, 23, 24], "ttyusb": [1, 3, 4, 9, 11, 14, 15, 16, 17], "ttyusb2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "turn": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "tweak": [31, 33, 34], "two": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "tx": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "txd": [22, 23, 24], "txqueuelen": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "txt": [13, 18, 19, 31, 33, 34], "type": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "u": [2, 6, 10, 12, 21], "uart": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "uart1": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "uart1_dce_rx": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "uart1_rxd": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "uart1grp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "uart2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "uart3": [9, 11, 13, 14, 15, 16, 17, 18, 19], "uart4": [9, 11, 13, 14, 15, 16, 17, 18, 19], "ubi": [27, 29, 30], "ubi0": [27, 29, 30], "ubi0_0": [27, 29, 30], "ubi0_1": [27, 29, 30], "ubi0_2": [27, 29, 30], "ubi0_3": [27, 29, 30], "ubi0_5": [27, 29, 30], "ubi0_6": [27, 29, 30], "ubiattach": [27, 29, 30], "ubif": [27, 29, 30], "ubivol": [27, 29, 30], "uboot": [27, 29, 30], "ubuntu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "udc": [1, 3, 4, 5, 7, 8], "udev": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "udevadm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "uf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ui": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "uimg": [1, 9, 11, 17], "uint32": [27, 29, 30], "uj": [23, 24], "ultimat": [1, 3, 4, 9, 11, 14, 15, 16, 17], "ultralit": 31, "umask": [31, 33, 34], "umbrella": [31, 33, 34], "umount": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "unalloc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "unattach": [31, 33, 34], "unauthor": [27, 29, 30], "unbind": [1, 3, 4, 5, 7, 8], "unchang": [1, 5, 9, 11, 13, 17, 18, 19], "uncom": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "uncompress": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "uncondition": [31, 33, 34], "undefin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "under": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 31, 33, 34], "underli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "underscor": [31, 33, 34], "understand": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 33, 34], "unexpect": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 19], "unifi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "uniniti": [31, 33, 34], "uniqu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "unit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "univers": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "unix": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30, 31, 33, 34], "unknown": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "unless": [1, 4, 5, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "unlik": [22, 23, 24], "unmount": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "unpack": [31, 33, 34], "unplug": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "unquot": [1, 5, 9, 11, 13, 17, 18, 19], "unrevers": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "unset": [1, 9, 11, 17, 27, 29, 30], "unstag": [31, 33, 34], "untest": [31, 33, 34], "until": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "unus": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "unxz": [1, 5, 9, 11, 13, 17, 19, 22, 23, 24], "unzip": [31, 33, 34], "up": [2, 6, 10, 12, 21, 27, 29, 30, 32], "updat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 26, 31, 33, 34], "update_usb": [27, 29, 30], "upon": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "upper": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "upstream": [2, 6, 10, 12, 31, 33, 34], "uri": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "url": [31, 33, 34], "us": [28, 32], "usabl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "usag": 32, "usb": [2, 6, 10, 12, 21, 28, 31, 33, 34], "usb0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "usb2": [1, 3, 4, 22, 23, 24], "usb_gadget": [1, 3, 4, 5, 7, 8], "usbotg2": [1, 3, 4], "usec": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "user": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "usern": [31, 33, 34], "usernam": [31, 33, 34], "userspac": [31, 33, 34], "usr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "usual": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "utc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "util": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "uuid": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "uuu": [2, 6, 10, 12, 21], "v": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "v2015": [31, 33, 34], "v2021": [3, 7, 14, 15], "v2022": [1, 4, 5, 8, 16, 31, 33, 34], "v2023": [22, 23], "v2024": [9, 11, 13, 17, 18, 19, 24], "v3": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "v4": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "v4l": [31, 33, 34], "v5": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "v6": [9, 11, 13, 17, 18, 19, 22, 23, 24], "v7": [1, 3, 4, 9, 11, 14, 15, 16, 17], "vaapivideodecod": [1, 3, 4, 7, 14, 15, 16], "val": [31, 33, 34], "valid": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "valu": [31, 33, 34], "value1": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "value2": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "vanilla": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "var": [1, 4, 9, 11, 16, 17, 22, 23, 24, 31, 33, 34], "vari": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "variabl": [13, 18, 19, 31, 33, 34], "variant": [3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 22, 23, 24, 27, 29, 30], "varieti": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "variou": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "vdd_soc": [22, 23, 24], "vdisp": [3, 14, 15], "vendor": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30, 31, 33, 34], "vendor_id": [31, 33, 34], "venv": [1, 3, 4, 9, 11, 14, 15, 16, 17], "verbos": [31, 33, 34], "veri": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "verifi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "version": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "version_fil": [27, 29, 30], "vf": [22, 23, 24], "vfat": [27, 29, 30], "vfp": [31, 33, 34], "vi": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "via": [27, 29, 30], "video": [2, 10, 12, 21, 31, 33, 34], "video2": [31, 33, 34], "videoconvert": [1, 4, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "videosink": [1, 4, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "videostab2": [31, 33, 34], "view": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "vigil": [31, 33, 34], "vim": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "vimdiff": [31, 33, 34], "virtual": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "visibl": [13, 18, 19, 22, 23, 24], "vision": [31, 33, 34], "visit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "vm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "vm016": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "vm017": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "vm020": [1, 9, 11, 17], "vmmc": 4, "vocabulari": 32, "vol": [1, 3, 4], "volatil": [27, 29, 30, 31, 33, 34], "voltag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "volum": [3, 14, 15, 27, 29, 30], "vpu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "vpudec": [3, 14, 15], "vse": [3, 14, 15], "vss": [3, 14, 15], "vtcon1": [31, 33, 34], "vtconsol": [31, 33, 34], "vtot": [3, 14, 15], "vulner": [27, 29, 30], "w": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "w1": [31, 33, 34], "wa": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "wai": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "wait": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "wake": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "waken": [22, 23, 24], "wakeup": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "want": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "warn": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 32], "warrior": 34, "watchdog": [2, 6, 10, 12, 21, 27, 29, 30], "wav": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "wayland": [1, 3, 4, 7, 14, 15, 16, 22, 23, 24, 33], "waylandsink": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "wc": [27, 29, 30], "wdg9yaf7": [23, 24], "we": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 27, 29, 30, 31, 33, 34], "wear": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "web": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "webm": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "webpag": [31, 33, 34], "websit": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "wed": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "wega": [31, 33, 34], "weight": [31, 33, 34], "welcom": 25, "well": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "wep": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "were": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "west": [1, 3, 4, 9, 11, 14, 15, 16, 17], "weston": [1, 3, 4, 7, 22, 23, 24], "wget": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "what": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "whatev": [1, 9, 11, 17], "when": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "whenev": [31, 33, 34], "where": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "whether": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "which": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "while": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "whitespac": [31, 33, 34], "who": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "whole": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "wic": [31, 33, 34], "widget": [31, 33, 34], "width": [22, 23, 24], "wifi": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "wiki": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "wikipedia": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "win95": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "wind": [31, 33, 34], "window": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "wire": 24, "wireless": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "wirless": 15, "wise": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "within": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "without": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "wlan0": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "wlbt": [1, 9, 11, 14, 15, 16, 17, 24], "wlp1s0": [1, 3, 4, 9, 11, 14, 15, 16, 17], "won": [1, 4, 5, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "word": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "work": [2, 6, 10, 12, 21, 32], "workaround": [14, 15], "workdir": [31, 33, 34], "workflow": [31, 33, 34], "workspac": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 32], "worst": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "would": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "wpa": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "wpa2": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "wpa_key_mgmt": [31, 33, 34], "wpa_pairwis": [31, 33, 34], "wpa_passphras": [31, 33, 34], "wpa_supplic": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "wr_rel_set": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "wrapper": [31, 33, 34], "writabl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "write": [2, 6, 10, 12, 21, 27, 29, 30, 31, 33, 34], "write_reli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "written": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "wrong": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "www": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "x": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "x1": [9, 11, 13, 14, 15, 16, 17, 18, 19], "x16": [22, 23, 24], "x2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "x30": [1, 3, 4, 5, 7, 8], "x48": [22, 23, 24], "x5": [9, 11, 13, 14, 15, 16, 17, 18, 19], "x6": [9, 11, 13, 14, 15, 16, 17, 18, 19], "x8": [1, 3, 4, 22, 23, 24], "x86_64": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "x_onoff": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "x_uart2_rx": [22, 23, 24], "x_uart2_tx": [22, 23, 24], "xdg": [9, 11, 13, 14, 15, 16, 17, 18, 19], "xen": [31, 33, 34], "xlsx": [22, 23, 24], "xml": [31, 33, 34], "xterm": 31, "xvzf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "xwayland": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "xx": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 27, 29, 30, 31, 33, 34], "xxx": [9, 11, 16, 17], "xxxx": [1, 5, 9, 11, 13, 27, 29, 30, 31, 33, 34], "xxxxx": [9, 13], "xz": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "xzcat": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "y": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "yaml": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "yamltre": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ye": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "year": [31, 33, 34], "yellow": [22, 23, 24], "yet": [24, 31, 33, 34], "yocto": [0, 3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 20, 22, 23, 24, 25, 26, 27, 29, 30], "yocto_dir": [1, 3, 4, 7, 14, 15, 16], "yocto_download": [31, 33, 34], "yocto_sst": [31, 33, 34], "yoctoproject": [31, 33, 34], "yoctoprojectq": [31, 33, 34], "yogurt": [27, 29, 30], "you": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 27, 29, 30, 31, 33, 34], "your": [5, 8, 9, 11, 13, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "your_devic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "your_directori": [31, 33, 34], "your_email": [31, 33, 34], "your_imag": [31, 33, 34], "yourself": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "yveolxdggmjiflecu6xz1j3": [23, 24], "yyyi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "z": [1, 5, 9, 11, 13, 17, 18, 19, 27, 29, 30], "zephyr": [1, 3, 4, 9, 11, 14, 15, 16, 17], "zephyrproject": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19], "zero": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "zeu": 34, "zimag": [27, 29, 30], "zstd": [31, 33, 34], "zstdcat": [22, 23, 24]}, "titles": ["i.MX 8 Manuals", "1. PHYTEC Documentation", "i.MX 8M Mini Manuals", "1. PHYTEC Documentation", "1. PHYTEC Documentation", "1. PHYTEC Documentation", "i.MX 8M Nano Manuals", "1. PHYTEC Documentation", "1. PHYTEC Documentation", "1. PHYTEC Documentation", "Libra i.MX 8M Plus FPSC Manuals", "1. PHYTEC Documentation", "i.MX 8M Plus Manuals", "1. PHYTEC Documentation", "1. PHYTEC Documentation", "1. PHYTEC Documentation", "1. PHYTEC Documentation", "1. PHYTEC Documentation", "1. PHYTEC Documentation", "1. PHYTEC Documentation", "i.MX 9 Manuals", "i.MX 93 Manuals", "1. PHYTEC Documentation", "1. PHYTEC Documentation", "1. PHYTEC Documentation", "Contribute", "Welcome to the PHYTEC BSP Documentation", "1. Introduction", "RAUC Update & Device Management Manuals", "1. Introduction", "1. Introduction", "1. The Yocto Project", "Yocto Reference Manuals", "1. The Yocto Project", "1. The Yocto Project"], "titleterms": {"0": [2, 6, 12, 21, 31, 33, 34], "1": [2, 6, 12, 21], "2": [12, 21], "3rdparti": [31, 33, 34], "6ul": [31, 33, 34], "8": 0, "8m": [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19], "9": 20, "93": [21, 22, 23, 24], "A": [27, 29, 30], "On": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "The": [31, 33, 34], "With": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 19], "about": [31, 33, 34], "access": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "activ": [27, 29, 30], "ad": [1, 3, 4, 7, 14, 15, 16], "adc": [23, 24], "add": [31, 33, 34], "addit": [31, 33, 34], "address": [22, 23, 24], "advanc": [31, 33, 34], "alsa": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "alsamix": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "ampliphi": [12, 31, 33, 34], "an": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "applic": [31, 33, 34], "audio": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "automat": [27, 29, 30], "autotool": [31, 33, 34], "avail": [31, 33, 34], "b": [27, 29, 30], "back": [1, 9, 11, 17], "background": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "backlight": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "barebox": [27, 29, 30, 31, 33, 34], "barrier": [27, 29, 30], "base": [31, 33, 34], "basic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "bbappend": [31, 33, 34], "bbnsm": [22, 23, 24], "benchmark": [31, 33, 34], "between": [1, 3, 4, 5, 7, 8, 31, 33, 34], "bin": [22, 23, 24], "binari": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bitbak": [31, 33, 34], "bkop": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "block": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bluetooth": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 31, 33, 34], "bmap": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "board": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "boot": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "bootchoos": [27, 29, 30], "bootenv": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "bootload": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "bootmod": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "browser": [31, 33, 34], "bsp": [1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 12, 13, 14, 15, 16, 17, 18, 19, 21, 22, 23, 24, 26, 27, 29, 30, 31, 33, 34], "bu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "build": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "buildinfo": [31, 33, 34], "built": [31, 33, 34], "bundl": [27, 29, 30], "burn": [22, 23, 24], "can": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "captur": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "card": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "case": [27, 29, 30], "chang": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30, 31, 33, 34], "chip": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "chromium": [1, 3, 4, 7, 14, 15, 16], "class": [31, 33, 34], "code": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "command": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "common": [31, 33, 34], "commun": [31, 33, 34], "compat": [31, 33, 34], "compil": [31, 33, 34], "complet": [31, 33, 34], "compon": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "concept": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "conf": [1, 3, 4, 7, 14, 15, 16, 31, 33, 34], "configur": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24, 27, 29, 30, 31, 33, 34], "connect": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "consider": [27, 29, 30], "consol": [31, 33, 34], "contain": [31, 33, 34], "content": [2, 6, 10, 12, 21, 26, 28, 31, 32, 33, 34], "contribut": [25, 26], "control": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "copi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "core": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "correct": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "cpu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "creat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "csd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "current": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "custom": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "data": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "dd": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "debug": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "default": [1, 4, 9, 11, 16, 17, 22, 23, 24, 27, 29, 30, 31, 33, 34], "defconfig": [31, 33, 34], "demo": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "depend": [31, 33, 34], "design": [27, 29, 30], "detect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "develop": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "devic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28], "devtool": [31, 33, 34], "dhcp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "differ": [31, 33, 34], "disabl": [1, 9, 11, 17, 31, 33, 34], "displai": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "distribut": [31, 33, 34], "distro": [1, 9, 11, 17, 31, 33, 34], "document": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 26, 31, 33, 34], "downgrad": [27, 29, 30], "download": [31, 33, 34], "drive": [27, 29, 30], "dt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dual": [9, 11, 16, 17], "duplex": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "eeprom": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "efi": [1, 9, 11, 17], "efus": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "eiq": [14, 15], "embed": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "emmc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "enabl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "environ": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "eras": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "evalu": [3, 14, 15], "exampl": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30, 31, 33, 34], "exist": [31, 33, 34], "expand": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ext4": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "extend": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "extens": [1, 3, 4, 5, 7, 8, 14, 15, 16], "extern": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "fan": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "fd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "featur": [31, 33, 34], "file": [31, 33, 34], "filesystem": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "final": [22, 23, 24], "find": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "firmwar": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "first": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fit": [1, 9, 11, 17], "fix": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 19], "flash": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "format": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fpsc": [9, 10], "fragment": [31, 33, 34], "framebuff": [31, 33, 34], "framework": [27, 29, 30], "freescal": [31, 33, 34], "frequenc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "from": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "fsl": [31, 33, 34], "full": [9, 11, 13, 16, 17, 19], "fuse": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gener": [31, 33, 34], "get": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "git": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "gnu": [31, 33, 34], "gpart": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpio": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gstreamer": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gstreamer1": [31, 33, 34], "half": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "hardwar": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "head": [2, 6, 10, 12], "host": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "http": [27, 29, 30], "i": [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 31, 33, 34], "i2c": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "id": [3, 14, 15], "imag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "implement": [27, 29, 30], "imx": [22, 23, 24], "initi": [27, 29, 30, 31, 33, 34], "inspect": [31, 33, 34], "instal": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "introduct": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "isp": [9, 11, 14, 15, 16, 17], "i\u00b2c": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "j": [1, 3, 4, 9, 11, 14, 15, 16, 17], "kei": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "kernel": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "keyr": [27, 29, 30], "kirkston": [28, 32], "kmssink": [3, 14, 15], "latest": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "layer": [31, 33, 34], "led": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "legacyboot": [1, 9, 11, 17], "libra": [9, 10], "librari": [31, 33, 34], "lightpd": [31, 33, 34], "link": [1, 3, 4, 9, 11, 14, 15, 16, 17], "linux": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "local": [1, 3, 4, 7, 14, 15, 16, 31, 33, 34], "logic": [27, 29, 30], "m33": [22, 23, 24], "m4": [1, 3, 4], "m7": [9, 11, 14, 15, 16, 17], "mac": [22, 23, 24], "machin": [31, 33, 34], "mainlin": 12, "manag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "manual": [0, 2, 6, 10, 12, 20, 21, 28, 32], "master": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "measur": [27, 29, 30], "meta": [31, 33, 34], "metadata": [31, 33, 34], "method": [31, 33, 34], "mickledor": [28, 32], "mini": [1, 2, 3, 4], "minim": [31, 33, 34], "mirror": [31, 33, 34], "mkimag": [22, 23, 24], "mmc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mode": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "modul": [1, 9, 11, 17, 31, 33, 34], "mux": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mx": [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 31, 33, 34], "mx8mm": [1, 2, 3, 4, 6], "mx8mn": [5, 7, 8], "mx8mp": [9, 11, 12, 13, 14, 15, 16, 17, 18, 19], "mx93": [21, 22, 23, 24], "nand": [27, 29, 30], "nano": [5, 6, 7, 8], "nash": [22, 23, 24], "need": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "netboot": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "network": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "nf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "nodej": [31, 33, 34], "nor": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "note": [31, 33, 34], "npu": [9, 11, 14, 15, 16, 17], "nxp": [2, 6, 12, 14, 15, 21], "o": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ocotp_ctrl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "offici": [31, 33, 34], "offlin": [31, 33, 34], "offset": [27, 29, 30], "onli": [1, 9, 11, 17], "opencv": [31, 33, 34], "openembed": [31, 33, 34], "oper": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "otg": [1, 3, 4, 5, 7, 8], "otp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "over": [27, 29, 30], "overlai": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "own": [31, 33, 34], "packag": [1, 9, 11, 17, 31, 33, 34], "paramet": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "partit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "partup": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "patch": [31, 33, 34], "pcie": [1, 3, 4, 9, 11, 14, 15, 16, 17], "pd22": [2, 6, 12], "pd23": [2, 6, 12], "pd24": [12, 21], "peripher": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "php": [31, 33, 34], "phyboard": [1, 3, 4, 5, 7, 8, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "phycor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "phylinux": [31, 33, 34], "phytec": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 26, 31, 33, 34], "pin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "place": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "playback": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "plu": [9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19], "plugin": [3, 14, 15], "point": [31, 33, 34], "poki": [31, 33, 34], "poli": [1, 3, 4, 5, 7, 8], "pollux": [11, 13, 14, 15, 16, 17, 18, 19], "pos4": [5, 7, 8], "pos5": [5, 7, 8], "power": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "pre": [31, 33, 34], "prebuild": [31, 33, 34], "prepar": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "previou": [31, 33, 34], "process": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "project": [31, 33, 34], "provid": [31, 33, 34], "pseudo": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "pull": [31, 33, 34], "pulseaudio": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "pwm": [22, 23, 24], "pxp": [22, 23, 24], "qt": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "qt6": [31, 33, 34], "ram": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 19, 22, 23, 24, 31, 33, 34], "rauc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 28, 29, 30, 31, 33, 34], "read": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "recip": [31, 33, 34], "refer": [27, 29, 30, 32], "regist": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "releas": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "reliabl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "remoteproc": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "repo": [31, 33, 34], "repositori": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "requir": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rescu": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "resiz": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "restor": [1, 4, 9, 11, 16, 17, 22, 23, 24], "root": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "rootf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rs232": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "rs485": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "rtc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "run": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "runtim": [31, 33, 34], "rust": [31, 33, 34], "s1": [1, 3, 4, 5, 7, 8], "s3": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "scale": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "scarthgap": [28, 32], "sd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sdk": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "secur": [27, 29, 30, 31, 33, 34], "segin": [22, 23, 24], "select": [1, 3, 4, 5, 7, 8], "selinux": [31, 33, 34], "server": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "set": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "setscen": [31, 33, 34], "setup": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "singl": [9, 11, 14, 15, 16, 17], "site": [31, 33, 34], "size": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 19], "slc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "slot": [27, 29, 30], "snv": [9, 11, 13, 14, 15, 16, 17, 18, 19], "softwar": [31, 33, 34], "som": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sourc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "space": [31, 33, 34], "spi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "src_uri": [31, 33, 34], "standalon": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "start": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "state": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "stick": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "storag": [27, 29, 30], "stream": [27, 29, 30], "structur": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "support": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "suspend": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "sustain": [31, 33, 34], "switch": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "sysf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "system": [27, 29, 30], "systemd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tabl": [2, 6, 10, 12, 21, 28, 32], "target": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "task": [31, 33, 34], "temporari": [31, 33, 34], "tftp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "thermal": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "third": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "timesi": [31, 33, 34], "toaster": [31, 33, 34], "tool": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "toolchain": [31, 33, 34], "tpm": [23, 24], "transit": 30, "tree": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tripl": 16, "troubleshoot": [31, 33, 34], "txt": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "u": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "uart1": [1, 3, 4, 5, 7, 8], "uboot": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "udev": [31, 33, 34], "ull": [31, 33, 34], "up": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "upcom": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "updat": [27, 28, 29, 30], "upgrad": [31, 33, 34], "upstream": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "us": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "usag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "usb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "user": [31, 33, 34], "userspac": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "uuu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "valu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "variabl": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30], "variant": [1, 9, 11, 17], "version": [31, 33, 34], "via": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "video": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "virtual": [31, 33, 34], "visibl": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "vocabulari": [31, 33, 34], "volum": [1, 4, 9, 11, 16, 17, 22, 23, 24], "wakealarm": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "warn": [31, 33, 34], "watchdog": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "web": [31, 33, 34], "welcom": 26, "weston": [9, 11, 13, 14, 15, 16, 17, 18, 19], "wic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "wireless": [31, 33, 34], "wlan": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "work": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "workspac": [31, 33, 34], "write": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "yocto": [1, 2, 6, 9, 11, 12, 17, 21, 31, 32, 33, 34], "your": [1, 3, 4, 7, 14, 15, 16, 31, 33, 34]}}) \ No newline at end of file diff --git a/previews/271/sitemap.xml b/previews/271/sitemap.xml new file mode 100644 index 000000000..adac5b8ea --- /dev/null +++ b/previews/271/sitemap.xml @@ -0,0 +1,2 @@ + +https://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mm/head.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mm/imx8mm.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mm/pd22.1.1.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mm/pd23.1.0.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mn/head.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mn/imx8mn.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mn/pd22.1.1.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mn/pd23.1.0.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp-libra-fpsc/head.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/head.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/imx8mp.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/mainline-head.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/pd22.1.1.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/pd22.1.2.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/pd23.1.0.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/pd24.1.0_nxp.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx9/imx93/imx93.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/pd24.1.1.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx9/imx93/pd24.1.0.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/pd24.1.2.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx9/imx9.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx9/imx93/pd24.1.1.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx9/imx93/pd24.2.0.htmlhttps://phytec.github.io/doc-bsp-yocto/contributing_links.htmlhttps://phytec.github.io/doc-bsp-yocto/index.htmlhttps://phytec.github.io/doc-bsp-yocto/rauc/kirkstone.htmlhttps://phytec.github.io/doc-bsp-yocto/rauc/manual-index.htmlhttps://phytec.github.io/doc-bsp-yocto/yocto/kirkstone.htmlhttps://phytec.github.io/doc-bsp-yocto/yocto/manual-index.htmlhttps://phytec.github.io/doc-bsp-yocto/rauc/mickledore.htmlhttps://phytec.github.io/doc-bsp-yocto/rauc/scarthgap.htmlhttps://phytec.github.io/doc-bsp-yocto/yocto/mickledore.htmlhttps://phytec.github.io/doc-bsp-yocto/yocto/scarthgap.htmlhttps://phytec.github.io/doc-bsp-yocto/genindex.htmlhttps://phytec.github.io/doc-bsp-yocto/search.html \ No newline at end of file diff --git a/previews/271/yocto/kirkstone.html b/previews/271/yocto/kirkstone.html new file mode 100644 index 000000000..4fbab943b --- /dev/null +++ b/previews/271/yocto/kirkstone.html @@ -0,0 +1,2938 @@ + + + + + + + + + 1. The Yocto Project — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + +

Yocto Reference Manual

Document Title

Yocto Reference Manual Kirkstone

Document Type

Yocto Manual

Release Date

XXXX/XX/XX

Is Branch of

Yocto Reference Manual

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-Ampliphy-i.MX6-PD22.1.0

Major

14.12.2022

released

BSP-Yocto-Ampliphy-i.MX6-PD22.1.1

Minor

20.06.2023

released

BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.0

Major

11.08.2022

released

BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1

Minor

23.05.2023

released

BSP-Yocto-Ampliphy-AM335x-PD23.1.0

Major

25.04.2023

released

BSP-Yocto-NXP-i.MX8MM-PD23.1.0

Major

12.12.2023

released

BSP-Yocto-NXP-i.MX8MP-PD23.1.0

Major

12.12.2023

released

BSP-Yocto-Ampliphy-AM62x-PD23.2.0

Major

28.09.2023

released

BSP-Yocto-Ampliphy-AM62Ax-PD23.1.0

Major

28.09.2023

released

BSP-Yocto-Ampliphy-AM64x-PD23.2.0

Major

28.09.2023

released

BSP-Yocto-NXP-i.MX7-PD23.1.0

Major

15.12.2023

released

+

This manual applies to all Kirkstone based PHYTEC releases.

+
+

1. The Yocto Project

+
+

1.1. PHYTEC Documentation

+

PHYTEC will provide a variety of hardware and software documentation for all of +our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE board along +with brief information on building a BSP, the device tree, and accessing +peripherals.

    • +

  • Hardware Manual: A detailed description of the System on Module and +accompanying carrier board.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version the phyCORE +uses. This guide contains an overview of Yocto; introducing, installing, and +customizing the PHYTEC BSP; how to work with programs like Poky and Bitbake; +and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating software, device +tree, and accessing peripherals can be found here.

    • +

  • Development Environment Guide: This guide shows how to work with the +Virtual Machine (VM) Host PHYTEC has developed and prepared to run various +Development Environments. There are detailed step-by-step instructions for +Eclipse and Qt Creator, which are included in the VM. There are instructions +for running demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a part of this +guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin table (in Excel +format). This table will show the complete default signal path, from +processor to carrier board. The default device tree muxing option will also +be included. This gives a developer all the information needed in one +location to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also provide Product +Change Notifications, Application Notes, and Technical Notes. These will be done +on a case-by-case basis. Most of the documentation can be found in the +applicable download page of our products.

+
+
+

1.2. Yocto Introduction

+

Yocto is the smallest SI metric system prefix. Like milli equates to m = +10^-3, and so is yocto y = 10^-24. Yocto is also a project working group +of the Linux Foundation and therefore +backed up by several major companies in the field. On the Yocto Project website you can read the official introduction:

+
+

The Yocto Project is an open-source collaboration project that provides +templates, tools, and methods to help you create custom Linux-based systems +for embedded products regardless of the hardware architecture. It was founded +in 2010 as a collaboration among many hardware manufacturers, open-source +operating systems vendors, and electronics companies to bring some order to +the chaos of embedded Linux development.

+
+

As said, the project wants to provide toolsets for embedded developers. It +builds on top of the long-lasting OpenEmbedded project. It is not a Linux +distribution. But it contains the tools to create a Linux distribution +specially fitted to the product requirements. The most important step in +bringing order to the set of tools is to define a common versioning scheme and +a reference system. All subprojects have then to comply with the reference +system and have to comply with the versioning scheme.

+

The release process is similar to the Linux kernel. +Yocto increases its version number every six months and gives the release a +codename. The release list can be found here: +https://wiki.yoctoproject.org/wiki/Releases

+
+
+

1.3. Core Components

+

The most important tools or subprojects of the Yocto Project are:

+
    +

  • Bitbake: build engine, a task scheduler like make, interprets metadata

    • +

  • OpenEmbedded-Core, a set of base layers, containing metadata of software, no +sources

    • +

  • Yocto kernel

    +
      +

    • Optimized for embedded devices

      • +

    • Includes many subprojects: rt-kernel, vendor patches

      • +

    • The infrastructure provided by Wind River

      • +

    • Alternative: classic kernel build → we use it to integrate our kernel into +Yocto

      • +
    +
    • +

  • Yocto Reference BSP: beagleboneblack, minnow max

    • +

  • Poky, the reference system, a collection of projects and tools, used to +bootstrap a new distribution based on Yocto

    • +
+
+
+

1.4. Vocabulary

+
+

1.4.1. Recipes

+

Recipes contain information about the software project (author, homepage, and +license). A recipe is versioned, defines dependencies, contains the URL of the +source code, and describes how to fetch, configure, and compile the sources. It +describes how to package the software, e.g. into different .deb packages, which +then contain the installation path. Recipes are basically written in Bitbake’s +own programming language, which has a simple syntax. However, a recipe can +contain Python as well as a bash code.

+
+
+

1.4.2. Classes

+

Classes combine functionality used inside recipes into reusable blocks.

+
+
+

1.4.3. Layers

+

A layer is a collection of recipes, classes, and configuration metadata. +A layer can depend on other layers and can be included or excluded one +by one. It encapsulates a specific functionality and fulfills a specific +purpose. Each layer falls into a specific category:

+
    +

  • Base

    • +

  • Machine (BSP)

    • +

  • Software

    • +

  • Distribution

    • +

  • Miscellaneous

    • +
+

Yocto’s versioning scheme is reflected in every layer as version branches. For +each Yocto version, every layer has a named branch in its Git repository. +You can add one or many layers of each category in your build.

+

A collection of OpenEmbedded layers can be found here. The search function is +very helpful to see if a software package can be retrieved and integrated +easily: https://layers.openembedded.org/layerindex/branch/kirkstone/layers/

+
+
+

1.4.4. Machine

+

Machines are configuration variables that describe the aspects of the target +hardware.

+
+
+

1.4.5. Distribution (Distro)

+

Distribution describes the software configuration and comes with a set of +software features.

+
+
+
+

1.5. Poky

+

Poky is the reference system to define Yocto Project compatibility. It +combines several subprojects into releases:

+
    +

  • Bitbake

    • +

  • Toaster

    • +

  • OpenEmbedded Core

    • +

  • Yocto Documentation

    • +

  • Yocto Reference BSP

    • +
+
+

1.5.1. Bitbake

+

Bitbake is the task scheduler. It is written in Python and interprets +recipes that contain code in Bitbake’s own programming language, Python, and +bash code. The official documentation can be found here: +https://docs.yoctoproject.org/bitbake/2.0/index.html

+
+
+

1.5.2. Toaster

+

Toaster is a web frontend for Bitbake to start and investigate builds. It +provides information about the build history and statistics on created images. +There are several use cases where the installation and maintenance of +a Toaster instance are beneficial. PHYTEC did not add or remove any features +to the upstream Toaster, provided by Poky. The best source for more +information is the official documentation: +https://docs.yoctoproject.org/4.0.6/toaster-manual/index.html

+
+
+
+

1.6. Official Documentation

+

For more general questions about Bitbake and Poky consult the mega-manual: +https://docs.yoctoproject.org/4.0.6/singleindex.html

+
+
+
+

2. Compatible Linux Distributions

+

To build Yocto you need a compatible Linux host development machine. The +list of supported distributions can be found in the reference manual: +https://docs.yoctoproject.org/4.0.6/ref-manual/system-requirements.html#supported-linux-distributions

+
+
+

3. PHYTEC BSP Introduction

+
+

3.1. BSP Structure

+

The BSP consists roughly of three parts. BSP management, BSP metadata, and BSP +content. The management consists of Repo and phyLinux while the metadata +depends on the SOC, which describes how to build the software. The content +comprises PHYTEC’s Git repositories and external sources.

+
+

3.1.1. BSP Management

+

Yocto is an umbrella project. Naturally, this will force the user to base +their work on several external repositories. They need to be managed in a +deterministic way. We use manifest files, which contain an XML data structure, +to describe all git repositories with pinned-down versions. The Repo tool and +our phyLinux wrapper script are used to manage the manifests and set up the BSP, +as described in the manifest file.

+
+

3.1.1.1. phyLinux

+

phyLinux is a wrapper for Repo to handle downloading and setting up the BSP +with an “out of the box” experience.

+
+
+

3.1.1.2. Repo

+

Repo is a wrapper around the Repo toolset. The phyLinux script will install +the wrapper in a global path. This is only a wrapper, though. Whenever you run +repo init -u <url>, you first download the Repo tools from Googles Git +server in a specific version to the .repo/repo directory. The next time you +run Repo, all the commands will be available. Be aware that the Repo version +in different build directories can differ over the years if you do not run Repo +sync. Also if you store information for your archives, you need to include the +complete .repo folder.

+

Repo expects a Git repository which will be parsed from the command line. In +the PHYTEC BSP, it is called phy²octo. In this repository, all information about +a software BSP release is stored in the form of a Repo XML manifest. This data +structure defines URLs of Git servers (called “remotes”) and Git +repositories and their states (called “projects”). The Git repositories can be +seen in different states. The revision field can be a branch, tag, or commit id +of a repository. This means the state of the software is not necessarily unique +and can change over time. That is the reason we use only tags or commit ids for +our releases. The state of the working directory is then unique and does not +change.

+

The manifests for the releases have the same name as the release itself. It is a +unique identifier for the complete BSP. The releases are sorted by the SoC +platform. The selected SoC will define the branch of the phy²octo Git +repository which will be used for the manifest selection.

+
+
+
+

3.1.2. BSP Metadata

+

We include several third-party layers in our BSP to get a complete Linux +distribution up and running without the need to integrate external projects. All +used repositories are described in the following section.

+
+

3.1.2.1. Poky

+

The PHYTEC BSP is built on top of Poky. It comes with a specific version, +defined in the Repo manifest. Poky comes with a specific version of +Bitbake. The OpenEmbedded-core layer “meta” is used as a base for our Linux +system.

+
+
+

3.1.2.2. meta-openembedded

+

OpenEmbedded is a collection of different layers containing the meta description +for many open-source software projects. We ship all OpenEmbedded layers with our +BSP, but not all of them are activated. Our example images pull several software +packages generated from OpenEmbedded recipes.

+
+
+

3.1.2.3. meta-qt6

+

This layer provides an integration of Qt6 in the Poky-based root filesystem +and is integrated into our BSP.

+
+
+

3.1.2.4. meta-nodejs

+

This is an application layer to add recent Node.js versions.

+
+
+

3.1.2.5. meta-gstreamer1.0

+

This is an application layer to add recent GStreamer versions.

+
+
+

3.1.2.6. meta-rauc

+

This layer contains the tools required to build an updated infrastructure with +RAUC. A comparison with +other update systems can be found here: Yocto update tools.

+
+
+

3.1.2.7. meta-phytec

+

This layer contains all machines and common features for all our BSPs. It is +PHYTEC’s Yocto Board Support Package for all supported +hardware (since fido) and is designed to be standalone with Poky. Only these +two parts are required if you want to integrate the PHYTEC’s hardware into your +existing Yocto workflow. The features are:

+
    +

  • Bootloaders in recipes-bsp/barebox/ and recipes-bsp/u-boot/

    • +

  • Kernels in recipes-kernel/linux/ and +dynamic-layers/fsl-bsp-release/recipes-kernel/linux/

    • +

  • Many machines in conf/machine/

    • +

  • Proprietary OpenGL ES/EGL user space libraries for AM335x and i.MX 6 +platforms

    • +

  • Proprietary OpenCL libraries for i.MX 6 platforms

    • +
+
+
+

3.1.2.8. meta-ampliphy

+

This is our example distribution and BSP layer. It extends the basic +configuration of Poky with software projects described by all the other BSP +components. It provides a base for your specific development scenarios. The +current features are:

+
    +

  • systemd init system

    • +

  • Images: phytec-headless-image for non-graphics applications

    • +

  • Camera integration with OpenCV and GStreamer examples for the i.MX 6 platform +bundled in a phytec-vision-image

    • +

  • RAUC integration: we set up basic support for an A/B system image update, +which is possible locally and over-the-air

    • +
+
+
+

3.1.2.9. meta-qt6-phytec

+

This is our layer for Qt6 board integration and examples. The features are:

+
    +

  • Qt6 with eglfs backend for +PHYTEC’s AM335x, i.MX 6 and RK3288 platforms

    • +

  • Images: phytec-qt6demo-image for Qt6 and video applications

    • +

  • A Qt6 demo application demonstrating how to create a Qt6 project using +QML widgets and a Bitbake recipe for the Yocto and systemd +integration. It can be found in +sources/meta-qt6-phytec/recipes-qt/examples/phytec-qtdemo_git.bb

    • +
+
+
+

3.1.2.10. meta-virtualization

+
    +

  • This layer provides support for building Xen, KVM, Libvirt, and associated +packages necessary for constructing OE-based virtualized solutions.

    • +
+
+
+

3.1.2.11. meta-security

+
    +

  • This layer provides security tools, hardening tools for Linux kernels, and +libraries for implementing security mechanisms.

    • +
+
+
+

3.1.2.12. meta-selinux

+
    +

  • This layer’s purpose is to enable SE Linux support. The majority of this +layer’s work is accomplished in bbappend files, used to enable SE Linux +support in existing recipes.

    • +
+
+
+

3.1.2.13. meta-browser

+
    +

  • This is an application layer to add recent web browsers (Chromium, Firefox, +etc.).

    • +
+
+
+

3.1.2.14. meta-rust

+
    +

  • Includes the Rust compiler and the Cargo package manager for Rust.

    • +
+
+
+

3.1.2.15. meta-timesys

+
    +

  • Timesys layer for Vigiles Yocto CVE monitoring, security notifications, and +image manifest generation.

    • +
+
+
+

3.1.2.16. meta-freescale

+
    +

  • This layer provides support for the i.MX, Layerscape, and QorIQ product +lines.

    • +
+
+
+

3.1.2.17. meta-freescale-3rdparty

+
    +

  • Provides support for boards from various vendors.

    • +
+
+
+

3.1.2.18. meta-freescale-distro

+
    +

  • This layer provides support for Freescale’s Demonstration images for use with +OpenEmbedded and/or Yocto Freescale’s BSP layer.

    • +
+
+
+

3.1.2.19. base (fsl-community-bsp-base)

+
    +

  • This layer provides BSP base files of NXP.

    • +
+
+
+

3.1.2.20. meta-fsl-bsp-release

+
    +

  • This is the i.MX Yocto Project Release Layer.

    • +
+
+
+
+

3.1.3. BSP Content

+

The BSP content gets pulled from different online sources when you first start +using Bitbake. All files will be downloaded and cloned in a local directory +configured as DL_DIR in Yocto. If you backup your BSP with the complete +content, those sources have to be backed up, too. How you can do this will be +explained in the chapter Generating Source Mirrors, working Offline.

+
+
+
+

3.2. Build Configuration

+

The BSP initializes a build folder that will contain all files you +create by running Bitbake commands. It contains a conf folder +that handles build input variables.

+
    +

  • bblayers.conf defines activated meta-layers,

    • +

  • local.conf defines build input variables specific to your build

    • +

  • site.conf defines build input variables specific to the development host

    • +
+

The two topmost build input variables are DISTRO and MACHINE. They are +preconfigured local.conf when you check out the BSP using phyLinux.

+

We use “Ampliphy” as DISTRO with our BSP. This distribution will be +preselected and give you a starting point for implementing your own +configuration.

+

A MACHINE defines a binary image that supports specific hardware +combinations of module and baseboard. Check the machine.conf file or our +webpage for a description of the hardware.

+
+
+
+

4. Pre-built Images

+

For each BSP we provide pre-built target images that can be downloaded from the +PHYTEC FTP server: https://download.phytec.de/Software/Linux/

+

These images are also used for the BSP tests, which are flashed to the boards +during production. You can use the provided .wic images to create a bootable +SD card at any time. Identify your hardware and flash the downloaded image file +to an empty SD card using dd. Please see section Images for information +about the correct usage of the command.

+
+
+

5. BSP Workspace Installation

+
+

5.1. Setting Up the Host

+

You can set up the host or use one of our build-container to run a Yocto build. +You need to have a running Linux distribution. It should be running on a +powerful machine since a lot of compiling will need to be done.

+

If you want to use a build-container, you only need to install following +packages on your host

+
host:~$ sudo apt install wget git
+
+
+

Continue with the next step Git Configuration after that. The documentation for +using build-container can be found in this manual after +Advanced Usage of phyLinux.

+

Else Yocto needs a handful of additional packages on your host. For Ubuntu +20.04 you need

+
host:~$ sudo apt install gawk wget git diffstat unzip texinfo \
+      gcc build-essential chrpath socat cpio python3 python3-pip \
+      python3-pexpect xz-utils debianutils iputils-ping python3-git \
+      python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm \
+      python3-subunit mesa-common-dev zstd liblz4-tool
+
+
+

For other distributions you can find information in the Yocto Quick Build: +https://docs.yoctoproject.org/4.0.6/brief-yoctoprojectqs/index.html

+
+
+

5.2. Git Configuration

+

The BSP heavily utilizes Git. Git needs some information from +you as a user to identify who made changes. Create a ~/.gitconfig with the +following content, if you do not have one

+
[user]
+    name = <Your Name>
+    email = <Your Mail>
+[core]
+    editor = vim
+[merge]
+    tool = vimdiff
+[alias]
+    co = checkout
+    br = branch
+    ci = commit
+    st = status
+    unstage = reset HEAD --
+    last = log -1 HEAD
+[push]
+    default = current
+[color]
+    ui = auto
+
+
+

You should set name and email in your Git configuration, otherwise, +Bitbake will complain during the first build. You can use the two commands to +set them directly without editing ~/.gitconfig manually

+
host:~$ git config --global user.email "your_email@example.com"
+host:~$ git config --global user.name "name surname"
+
+
+
+
+

5.3. site.conf Setup

+

Before starting the Yocto build, it is advisable to configure the development +setup. Two things are most important: the download directory and the cache +directory. PHYTEC strongly recommends configuring the setup as it will reduce +the compile time of consequent builds.

+

A download directory is a place where Yocto stores all sources fetched from +the internet. It can contain tar.gz, Git mirror, etc. It is very useful to set +this to a common shared location on the machine. Create this directory with 777 +access rights. To share this directory with different users, all files need to +have group write access. This will most probably be in conflict with default +umask settings. One possible solution would be to use ACLs for this +directory

+
host:~$ sudo apt-get install acl
+host:~$ sudo setfacl -R -d -m g::rwx <dl_dir>
+
+
+

If you have already created a download directory and want to fix the permissions +afterward, you can do so with

+
host:~$ sudo find /home/share/ -perm /u=r ! -perm /g=r -exec chmod g+r \{\} \;
+host:~$ sudo find /home/share/ -perm /u=w ! -perm /g=w -exec chmod g+w \{\} \;
+host:~$ sudo find /home/share/ -perm /u=x ! -perm /g=x -exec chmod g+x \{\} \;
+
+
+

The cache directory stores all stages of the build process. Poky has quite an +involved caching infrastructure. It is advisable to create a shared directory, +as all builds can access this cache directory, called the shared state cache.

+

Create the two directories on a drive where you have approximately 50 GB of +space and assign the two variables in your build/conf/local.conf

+
DL_DIR ?= "<your_directory>/yocto_downloads"
+SSTATE_DIR ?= "<your_directory>/yocto_sstate"
+
+
+

If you want to know more about configuring your build, see the documented +example settings

+
sources/poky/meta-yocto/conf/local.conf.sample
+sources/poky/meta-yocto/conf/local.conf.sample.extended
+
+
+
+
+
+

6. phyLinux Documentation

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP +structure. You can get all the BSP sources without the need of interacting with +Repo or Git.

+

The phyLinux script has only one real dependency. It requires the wget tool +installed on your host. It will also install the Repo tool in a global path +(/usr/local/bin) on your host PC. You can install it in a different location +manually. Repo will be automatically detected by phyLinux if it is found in +the PATH. The Repo tool will be used to manage the different Git +repositories of the Yocto BSP.

+
+

6.1. Get phyLinux

+

The phyLinux script can be found on the PHYTEC download server: +https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux

+
+
+

6.2. Basic Usage

+

For the basic usage of phyLinux, type

+
host:~$ ./phyLinux --help
+
+
+

which will result in

+
usage: phyLinux [-h] [-v] [--verbose] {init,info,clean} ...
+
+This Programs sets up an environment to work with The Yocto Project on Phytecs
+Development Kits. Use phyLinx <command> -h to display the help text for the
+available commands.
+
+positional arguments:
+  {init,info,clean}  commands
+    init             init the phytec bsp in the current directory
+    info             print info about the phytec bsp in the current directory
+    clean            Clean up the current working directory
+
+optional arguments:
+  -h, --help         show this help message and exit
+  -v, --version      show program's version number and exit
+  --verbose
+
+
+
+
+

6.3. Initialization

+

Create a fresh project folder

+
host:~$ mkdir ~/yocto
+
+
+

Calling phyLinux will use the default Python version. Starting with Ubuntu 20.04 +it will be Python3. If you want to initiate a BSP, which is not compatible with +Python3, you need to set Python2 as default (temporarily) before running +phyLinux

+
host:~$ ln -s \`which python2\` python && export PATH=`pwd`:$PATH
+
+
+

Now run phyLinux from the new folder

+
host:~$ ./phyLinux init
+
+
+

A clean folder is important because phyLinux will clean its working directory. +Calling phyLinux from a directory that isn’t empty will result in the following +warning:

+
This current directory is not empty. It could lead to errors in the BSP configuration
+process if you continue from here. At the very least, you have to check your build directory
+for settings in bblayers.conf and local.conf, which will not be handled correctly in
+all cases. It is advisable to start from an empty directory of call:
+$ ./phyLinux clean
+Do you really want to continue from here?
+[yes/no]:
+
+
+

On the first initialization, the phyLinux script will ask you to install the +Repo tool in your /usr/local/bin directory. During the execution of the +init command, you need to choose your processor platform (SoC), PHYTEC’s BSP +release number, and the hardware you are working on

+
***************************************************
+* Please choose one of the available SoC Platforms:
+*
+*   1: am335x
+*   2: am57x
+*   3: am62ax
+*   4: am62x
+*   5: am64x
+*   6: am68x
+*   7: imx6
+*   8: imx6ul
+*   9: imx7
+*   10: imx8
+*   11: imx8m
+*   12: imx8mm
+*   13: imx8mp
+*   14: imx8x
+*   15: imx93
+*   16: nightly
+*   17: rk3288
+*   18: stm32mp13x
+*   19: stm32mp15x
+*   20: topic
+
+# Exemplary output for chosen imx6ul
+***************************************************
+* Please choose one of the available Releases:
+*
+*   1: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc1
+*   2: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc2
+*   3: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc3
+*   4: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc4
+*   5: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc5
+*   6: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2.0
+*   7: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2.1-rc1
+*   8: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2.1
+*   9: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1-rc2
+*   10: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1-rc3
+*   11: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1-rc4
+*   12: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.0
+*   13: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1-rc1
+*   14: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1
+*   15: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.y
+*   16: BSP-Yocto-Vendor-phyBOARD-Segin-PD17.1.0
+*   17: BSP-Yocto-Vendor-phyBOARD-Segin-PD17.1.1
+*   18: BSP-Yocto-Vendor-phyBOARD-Segin-PD17.1.2
+*   19: BSP-Yocto-i.MX6UL-PD19.1-rc1
+*   20: BSP-Yocto-i.MX6UL-PD19.1-rc2
+*   21: BSP-Yocto-i.MX6UL-PD19.1-rc3
+*   22: BSP-Yocto-i.MX6UL-PD19.1.0
+*   23: BSP-Yocto-i.MX6UL-PD19.1.1-rc1
+*   24: BSP-Yocto-i.MX6UL-PD19.1.1
+*   25: BSP-Yocto-i.MX6UL-PD19.1.2-rc1
+*   26: BSP-Yocto-i.MX6UL-PD19.1.2-rc2
+*   27: BSP-Yocto-i.MX6UL-PD19.1.2
+*   28: BSP-Yocto-i.MX6UL-PD21.1.0
+*   29: BSP-Yocto-i.MX6UL-PD21.1.y
+*   30: BSP-Yocto-phyBOARD-Segin-PD17.2.0
+*   31: BSP-Yocto-phyBOARD-Segin-i.MX6UL-ALPHA1
+*   32: BSP-Yocto-phyBOARD-Segin-i.MX6UL-ALPHA2
+
+# Exemplary output for chosen BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1
+*********************************************************************
+* Please choose one of the available builds:
+*
+no:                 machine: description and article number
+                             distro: supported yocto distribution
+                             target: supported build target
+
+ 1: phyboard-segin-imx6ul-2: PHYTEC phyBOARD-Segin i.MX6 UltraLite
+                             512MB RAM, NAND
+                             PB-02013-001.A2, PB-02013-110I.A2, PCL-063-23300CI.A2
+                             distro: ampliphy
+                             target: phytec-headless-image
+                             target: phytec-qt5demo-image
+ 2: phyboard-segin-imx6ul-6: PHYTEC phyBOARD-Segin i.MX6 ULL
+                             512MB RAM, NAND
+                             PB-02013-001.A5, PB-02013-310I.A0, PCL-063-23900CI.A0
+                             distro: ampliphy
+                             target: -c populate_sdk phytec-qt5demo-image
+                             target: phytec-headless-image
+                             target: phytec-qt5demo-image
+                             target: phytec-vision-image
+ 3: phyboard-segin-imx6ul-6: PHYTEC phyBOARD-Segin i.MX6 ULL
+                             512MB RAM, NAND
+                             PB-02013-001.A5, PB-02013-310I.A0, PCL-063-23900CI.A0
+                             distro: ampliphy-rauc
+                             target: phytec-headless-bundle
+                             target: phytec-headless-image
+...
+
+10: phygate-tauri-s-imx6ul-1: PHYTEC phyGATE-Tauri-S i.MX6 ULL
+                             512MB RAM, eMMC
+                             PB-03513.A1, PCL-063-20910CI.A0
+                             distro: ampliphy
+                             target: phytec-headless-image
+11: phygate-tauri-s-imx6ul-1: PHYTEC phyGATE-Tauri-S i.MX6 ULL
+                             512MB RAM, eMMC
+                             PB-03513.A1, PCL-063-20910CI.A0
+                             distro: ampliphy-provisioning
+                             target: phytec-provisioning-image
+12: phygate-tauri-s-imx6ul-1: PHYTEC phyGATE-Tauri-S i.MX6 ULL
+                             512MB RAM, eMMC
+                             PB-03513.A1, PCL-063-20910CI.A0
+                             distro: ampliphy-secure
+                             target: phytec-security-bundle
+                             target: phytec-security-image
+
+
+

If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. After the configuration is done, +you can always run

+
host:~$ ./phyLinux info
+
+# Exemplary output
+***********************************************
+* The current BSP configuration is:
+*
+* SoC:  refs/heads/imx6ul
+* Release:  BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1
+*
+***********************************************
+
+
+

to see which SoC and Release are selected in the current workspace. If +you do not want to use the selector, phyLinux also supports command-line +arguments for several settings

+
host:~$ MACHINE=phyboard-segin-imx6ul-2 ./phyLinux init -p imx6ul -r BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1
+
+
+

or view the help command for more information

+
host:~$ ./phyLinux  init --help
+
+usage: phyLinux init [-h] [--verbose] [--no-init] [-o REPOREPO] [-b REPOREPO_BRANCH] [-x XML] [-u URL] [-p PLATFORM] [-r RELEASE]
+
+options:
+  -h, --help          show this help message and exit
+  --verbose
+  --no-init           dont execute init after fetch
+  -o REPOREPO         Use repo tool from another url
+  -b REPOREPO_BRANCH  Checkout different branch of repo tool
+  -x XML              Use a local XML manifest
+  -u URL              Manifest git url
+  -p PLATFORM         Processor platform
+  -r RELEASE          Release version
+
+
+

After the execution of the init command, phyLinux will print a few important +notes as well as information for the next steps in the build process.

+
+
+

6.4. Advanced Usage

+

phyLinux can be used to transport software states over any medium. The state of +the software is uniquely identified by manifest.xml. You can create a +manifest, send it to another place and recover the software state with

+
host:~$ ./phyLinux init -x manifest.xml
+
+
+

You can also create a Git repository containing your software states. The +Git repository needs to have branches other than master, as we reserved the +master branch for different usage. Use phyLinux to check out the states

+
host:~$ ./phyLinux -u <url-of-your-git-repo>
+
+
+
+
+
+

7. Using build-container

+
+

Warning

+

Currently, it is not possible to run the phyLinux script inside of a container. +After a complete init with the phyLinux script on your host machine, you can use a container for the build. +If you do not have phyLinux script running on your machine, please see phyLinux Documentation.

+
+

There are various possibilities to run a build-container. Commonly used is +docker and podman, though we prefer podman as it does not need root privileges +to run.

+
+

7.1. Installation

+

How to install podman: https://podman.io +How to install docker: https://docs.docker.com/engine/install/

+
+
+

7.2. Available container

+

Right now we provide 4 different container based on Ubuntu LTS versions: +https://hub.docker.com/u/phybuilder

+
    +

  • yocto-ubuntu-16.04

    • +

  • yocto-ubuntu-18.04

    • +

  • yocto-ubuntu-20.04

    • +

  • yocto-ubuntu-22.04

    • +
+

These containers can be run with podman or docker. With Yocto Project branch Kirkstone the container “yocto-ubuntu-20.04” is preferred.

+
+
+

7.3. Download/Pull container

+
host:~$ podman pull docker.io/phybuilder/yocto-ubuntu-20.04
+
+OR
+
+host:~$ docker pull docker.io/phybuilder/yocto-ubuntu-20.04
+
+
+

By adding a tag at the end separated by a colon, you can also pull or run a special tagged container.

+
+

podman pull docker.io/phybuilder/yocto-ubuntu-20.04:phy2

+
+

You can find all available tags in our duckerhub space:

+ +

If you try to run a container, which is not pulled/downloaded, it will be pulled/downloaded automatically.

+

You can have a look at all downloaded/pulled container with:

+
$USERNAME@$HOSTNAME:~$ podman images
+REPOSITORY                               TAG         IMAGE ID      CREATED       SIZE
+docker.io/phybuilder/yocto-ubuntu-22.04  latest      d626178e448d  4 months ago  935 MB
+docker.io/phybuilder/yocto-ubuntu-22.04  phy2        d626178e448d  4 months ago  935 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  phy2        e29a88b7172a  4 months ago  900 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  latest      e29a88b7172a  4 months ago  900 MB
+docker.io/phybuilder/yocto-ubuntu-18.04  phy1        14c9c3e477d4  7 months ago  567 MB
+docker.io/phybuilder/yocto-ubuntu-18.04  latest      14c9c3e477d4  7 months ago  567 MB
+docker.io/phybuilder/yocto-ubuntu-16.04  phy1        28c73e13ab4f  7 months ago  599 MB
+docker.io/phybuilder/yocto-ubuntu-16.04  latest      28c73e13ab4f  7 months ago  599 MB
+docker.io/phybuilder/yocto-ubuntu-22.04  phy1        5a0ef4b41935  8 months ago  627 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  phy1        b5a26a86c39f  8 months ago  680 MB
+
+
+
+
+

7.4. Run container

+

To run and use container for a Yocto build, first enter to your folder, where +you run phyLinux init before. Then start the container

+
host:~$ podman run --rm=true -v /home:/home --userns=keep-id --workdir=$PWD -it docker.io/phybuilder/yocto-ubuntu-20.04 bash
+
+
+
+

Note

+

To run and use a container with docker, it is not that simple like with podman. +Therefore the container-user has to be defined and configured. +Furthermore forwarding of credentials is not given per default and has to be configured as well.

+
+

Now your commandline should look something like that (where $USERNAME is the +user, who called “podman run” and the char/number code diffs every time a +container is started)

+
$USERNAME@6593e2c7b8f6:~$
+
+
+
+

Warning

+

If the given username is “root” you will not be able to run bitbake at all. +Please be sure, you run the container with your own user.

+
+

Now you are ready to go on and starting the build. +To stop/close the container, just call

+
$USERNAME@6593e2c7b8f6:~$ exit
+
+
+
+
+
+

8. Working with Poky and Bitbake

+
+

8.1. Start the Build

+

After you download all the metadata with phyLinux init, you have to set up the +shell environment variables. This needs to be done every time you open a new +shell for starting builds. We use the shell script provided by Poky in its +default configuration. From the root of your project directory type

+
host:~$ source sources/poky/oe-init-build-env
+
+
+

The abbreviation for the source command is a single dot

+
host:~$ . sources/poky/oe-init-build-env
+
+
+

The current working directory of the shell should change to build/. Before +building for the first time, you should take a look at the main configuration +file

+
host:~$ vim conf/local.conf
+
+
+

Your local modifications for the current build are stored here. Depending on +the SoC, you might need to accept license agreements. For example, to build the +image for Freescale/NXP processors you need to accept the GPU and VPU binary +license agreements. You have to uncomment the corresponding line

+
# Uncomment to accept NXP EULA # EULA can be found under
+../sources/meta-freescale/EULA ACCEPT_FSL_EULA = "1"
+
+
+

Now you are ready to build your first image. We suggest starting with our +smaller non-graphical image phytec-headless-image to see if everything is +working correctly

+
host:~$ bitbake phytec-headless-image
+
+
+

The first compile process takes about 40 minutes on a modern Intel Core i7. All +subsequent builds will use the filled caches and should take about 3 minutes.

+
+
+

8.2. Images

+

If everything worked, the images can be found under

+
host:~$ cd deploy/images/<MACHINE>
+
+
+

The easiest way to test your image is to configure your board for SD card boot +and to flash the build image to the SD card

+
host:~$ sudo dd if=phytec-headless-image-<MACHINE>.wic of=/dev/<your_device> bs=1M conv=fsync
+
+
+

Here <your_device> could be “sde”, for example, depending on your system. Be +very careful when selecting the right drive! Selecting the wrong drive can +erase your hard drive! The parameter conv=fsync forces a data buffer to write +to the device before dd returns.

+

After booting you can log in using a serial cable or over ssh. There is no +root password. That is because of the debug settings in conf/local.conf. If +you uncomment the line

+
#EXTRA_IMAGE_FEATURES = "debug-tweaks"
+
+
+

the debug settings, like setting an empty root password, will not be applied.

+
+
+

8.3. Accessing the Development States between Releases

+

Special release manifests exist to give you access to the current development +states of the Yocto BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line

+
host:~$ ./phyLinux init -p master -r kirkstone
+
+
+

This will initialize a BSP that will track the latest development state. From +now on running

+
host:~$ repo sync
+
+
+

this folder will pull all the latest changes from our Git repositories.

+
+
+

8.4. Inspect your Build Configuration

+

Poky includes several tools to inspect your build layout. You can inspect the +commands of the layer tool

+
host:~$ bitbake-layers
+
+
+

It can, for example, be used to view in which layer a specific recipe gets +modified

+
host:~$ bitbake-layers show-appends
+
+
+

Before running a build you can also launch Toaster to be able to inspect the +build details with the Toaster web GUI

+
host:~$ source toaster start
+
+
+

Maybe you need to install some requirements, first

+
host:~$ pip3 install -r
+../sources/poky/bitbake/toaster-requirements.txt
+
+
+

You can then point your browser to http://0.0.0.0:8000/ and continue working +with Bitbake. All build activity can be monitored and analyzed from this web +server. If you want to learn more about Toaster, look at +https://docs.yoctoproject.org/4.0.6/toaster-manual/index.html. +To shut down the Toaster web GUI again, execute

+
host:~$ source toaster stop
+
+
+
+
+

8.5. BSP Features of meta-phytec and meta-ampliphy

+
+

8.5.1. Buildinfo

+

The buildinfo task is a feature in our recipes that prints instructions to +fetch the source code from the public repositories. So you do not have to look +into the recipes yourself. To see the instructions, e.g. for the barebox +package, execute

+
host:~$ bitbake barebox -c buildinfo
+
+
+

in your shell. This will print something like

+
(mini) HOWTO: Use a local git repository to build barebox:
+
+To get source code for this package and version (barebox-2022.02.0-phy1), execute
+
+$ mkdir -p ~/git
+$ cd ~/git
+$ git clone git://git.phytec.de/barebox barebox
+$ cd ~/git/barebox
+$ git switch --create v2022.02.0-phy1-local-development 7fe12e65d770f7e657e683849681f339a996418b
+
+You now have two possible workflows for your changes:
+
+1. Work inside the git repository:
+Copy and paste the following snippet to your "local.conf":
+
+SRC_URI:pn-barebox = "git://${HOME}/git/barebox;branch=${BRANCH}"
+SRCREV:pn-barebox = "${AUTOREV}"
+BRANCH:pn-barebox = "v2022.02.0-phy1-local-development"
+
+After that you can recompile and deploy the package with
+
+$ bitbake barebox -c compile
+$ bitbake barebox -c deploy
+
+Note: You have to commit all your changes. Otherwise yocto doesn't pick them up!
+
+2. Work and compile from the local working directory
+To work and compile in an external source directory we provide the
+externalsrc.bbclass. To use it, copy and paste the following snippet to your
+"local.conf":
+
+INHERIT += "externalsrc"
+EXTERNALSRC:pn-barebox = "${HOME}/git/barebox"
+EXTERNALSRC_BUILD:pn-barebox = "${HOME}/git/barebox"
+
+Note: All the compiling is done in the EXTERNALSRC directory. Every time
+you build an Image, the package will be recompiled and build.
+
+NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded.
+NOTE: Writing buildhistory
+
+
+

As you can see, everything is explained in the output.

+
+

Warning

+

Using externalsrc breaks a lot of Yocto’s internal dependency +mechanisms. It is not guaranteed that any changes to the source +directory are automatically picked up by the build process and +incorporated into the root filesystem or SD card image. You have to +always use –force. E.g. to compile barebox and redeploy it to +deploy/images/<machine> execute

+
host:~$ bitbake barebox -c compile --force
+host:~$ bitbake barebox -c deploy
+
+
+
+

To update the SD card image with a new kernel or image first force the +compilation of it and then force a rebuild of the root filesystem. Use

+
host:~$ bitbake phytec-qt6demo-image -c rootfs --force
+
+
+

Note that the build system is not modifying the external source directory. If +you want to apply all patches the Yocto recipe is carrying to the external +source directory, run the line

+
SRCTREECOVEREDTASKS="" BB_ENV_PASSTHROUGH_ADDITIONS="$BB_ENV_PASSTHROUGH_ADDITIONS SRCTREECOVEREDTASKS" bitbake <recipe> -c patch
+
+
+
+
+
+

8.6. BSP Customization

+

To get you started with the BSP, we have summarized some basic tasks from the +Yocto official documentation. It describes how to add additional software to +the image, change the kernel and bootloader configuration, and integrate +patches for the kernel and bootloader.

+

Minor modifications, such as adding software, are done in the file +build/conf/local.conf. There you can overwrite global configuration variables +and make small modifications to recipes.

+

There are 2 ways to make major changes:

+
    +

  1. Either create your own layer and use bbappend files.

    2. +

  2. Add everything to PHYTEC’s Distro layer meta-ampliphy.

    3. +
+

Creating your own layer is described in the section Create your own Layer.

+
+

8.6.1. Disable Qt Demo

+

By default, the BSP image phytec-qt6demo-image starts a Qt6 Demo application +on the attached display or monitor. If you want to stop the demo and use the +Linux framebuffer console behind it, connect to the target via serial cable +or ssh and execute the shell command

+
target:~$ systemctl stop phytec-qtdemo.service
+
+
+

This command stops the demo temporarily. To start it again, reboot the +board or execute

+
target:~$ systemctl start phytec-qtdemo.service
+
+
+

You can disable the service permanently, so it does not start on boot

+
target:~$ systemctl disable phytec-qtdemo.service
+
+
+
+

Tip

+

The last command only disables the service. It does not stop immediately. +To see the current status execute

+
target:~$ systemctl status phytec-qtdemo.service
+
+
+
+

If you want to disable the service by default, edit the file +build/conf/local.conf and add the following line

+
# file build/conf/local.conf
+SYSTEMD_AUTO_ENABLE:pn-phytec-qtdemo = "disable"
+
+
+

After that, rebuild the image

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

8.6.2. Framebuffer Console

+

On boards with a display interface, the framebuffer console is enabled per +default. You can attach a USB keyboard and log in. To change the keyboard +layout from the English default to German, type

+
target:~$ loadkeys /usr/share/keymaps/i386/qwertz/de-latin1.map.gz
+
+
+

To detach the framebuffer console, run

+
target:~$ echo 0 > sys/class/vtconsole/vtcon1/bind
+
+
+

To completely deactivate the framebuffer console, disable the following kernel +configuration option

+
Device Drivers->Graphics Support->Support for framebuffer devices->Framebuffer Console Support
+
+
+

More information can be found at: +https://www.kernel.org/doc/Documentation/fb/fbcon.txt

+
+
+

8.6.3. Tools Provided in the Prebuild Image

+
+

8.6.3.1. RAM Benchmark

+

Performing RAM and cache performance tests can best be done by using pmbw +(Parallel Memory Bandwidth Benchmark/Measurement Tool). Pmbw runs several +assembly routines which all use different access patterns to the caches and RAM +of the SoC. Before running the test, make sure that you have about 2 MiB of +space left on the device for the log files. We also lower the level of the +benchmark to ask the kernel more aggressively for resources. The benchmark test +will take several hours.

+

To start the test type

+
target:~$ nice -n -2 pmbw
+
+
+

Upon completion of the test run, the log file can be converted to a gnuplot +script with

+
target:~$ stats2gnuplot stats.txt > run1.gnuplot
+
+
+

Now you can transfer the file to the host machine and install any version of +gnuplot

+
host:~$ sudo apt-get install gnuplot host:~$ gnuplot run1.gnuplot
+
+
+

The generated plots-<machine>.pdf file contains all plots. To render single +plots as png files for any web output you can use Ghostscript

+
host:~$ sudo apt-get install ghostscript
+host:~$ gs -dNOPAUSE -dBATCH -sDEVICE=png16m -r150 -sOutputFile='page-%00d.png' plots-phyboard-wega-am335x-1.pdf
+
+
+
+
+
+

8.6.4. Add Additional Software for the BSP Image

+

To add additional software to the image, look at the OpenEmbedded layer index: +https://layers.openembedded.org/layerindex/branch/kirkstone/layers/

+

First, select the Yocto version of the BSP you have from the drop-down list in +the top left corner and click Recipes. Now you can search for a software +project name and find which layer it is in. In some cases, the program is in +meta-openembedded, openembedded-core, or Poky which means that the recipe +is already in your build tree. This section describes how to add additional +software when this is the case. If the package is in another layer, see the next +section.

+

You can also search the list of available recipes

+
host:~$ bitbake -s | grep <program name> # fill in program name, like in
+host:~$ bitbake -s | grep lsof
+
+
+

When the recipe for the program is already in the Yocto build, you can simply +add it by appending a configuration option to your file build/conf/local.conf. +The general syntax to add additional software to an image is

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " <package1> <package2>"
+
+
+

For example, the line

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " ldd strace file lsof"
+
+
+

installs some helper programs on the target image.

+
+

Warning

+

The leading whitespace is essential for the append command.

+
+

All configuration options in local.conf apply to all images. Consequently, the +tools are now included in both images phytec-headless-image and +phytec-qt6demo-image.

+
+

8.6.4.1. Notes about Packages and Recipes

+

You are adding packages to the IMAGE_INSTALL variable. Those are not necessarily +equivalent to the recipes in your meta-layers. A recipe defines per default a +package with the same name. But a recipe can set the PACKAGES variable to +something different and is able to generate packages with arbitrary names. +Whenever you look for software, you have to search for the package name and, +strictly speaking, not for the recipe. In the worst case, you have to look at +all PACKAGES variables. A tool such as Toaster can be helpful in some cases.

+

If you can not find your software in the layers provided in the folder +sources, see the next section to include another layer into the Yocto +build.

+

References: Yocto 4.0.6 Documentation - Customizing Yocto builds

+
+
+
+

8.6.5. Add an Additional Layer

+

This is a step-by-step guide on how to add another layer to your Yocto build +and install additional software from it. As an example, we include the network +security scanner nmap in the layer meta-security. First, you must locate the +layer on which the software is hosted. Check out the OpenEmbedded MetaData +Index +and guess a little bit. The network scanner nmap is in the meta-security +layer. See meta-security on layers.openembedded.org. +To integrate it into the Yocto build, you have to check out the repository and +then switch to the correct stable branch. Since the BSP is based on the Yocto +‘sumo’ build, you should try to use the ‘sumo’ branch in the layer, too.

+
host:~$ cd sources
+host:~$ git clone git://git.yoctoproject.org/meta-security
+host:~$ cd meta-security
+host:~$ git branch -r
+
+
+

All available remote branches will show up. Usually there should be ‘fido’, +‘jethro’, ‘krogoth’, ‘master’, …

+
host:~$ git checkout kirkstone
+
+
+

Now we add the directory of the layer to the file build/conf/bblayers.conf by +appending the line

+
# file build/conf/bblayers.conf
+BBLAYERS += "${BSPDIR}/sources/meta-security"
+
+
+

to the end of the file. After that, you can check if the layer is available in +the build configuration by executing

+
host:~$ bitbake-layers show-layers
+
+
+

If there is an error like

+
ERROR: Layer 'security' depends on layer 'perl-layer', but this layer is not enabled in your configuration
+
+
+

the layer that you want to add (here meta-security), depends on another layer, +which you need to enable first. E.g. the dependency required here is a layer in +meta-openembedded (in the PHYTEC BSP it is in the path +sources/meta-openembedded/meta-perl/). To enable it, add the following line to +build/conf/bblayers.conf

+
# file build/conf/bblayers.conf
+BBLAYERS += "${BSPDIR}/sources/meta-openembedded/meta-perl"
+
+
+

Now the command bitbake-layers show-layers should print a list of all layers +enabled including meta-security and meta-perl. After the layer is included, +you can install additional software from it as already described above. The +easiest way is to add the following line (here is the package nmap)

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " nmap"
+
+
+

to your build/conf/local.conf. Do not forget to rebuild the image

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

8.6.6. Create your own layer

+

Creating your layer should be one of the first tasks when customizing the BSP. +You have two basic options. You can either copy and rename our meta-ampliphy, +or you can create a new layer that will contain your changes. The better option +depends on your use case. meta-ampliphy is our example of how to create a +custom Linux distribution that will be updated in the future. If you want to +benefit from those changes and are, in general, satisfied with the userspace +configuration, it could be the best solution to create your own layer on top of +Ampliphy. If you need to rework a lot of information and only need the basic +hardware support from PHYTEC, it would be better to copy meta-ampliphy, rename +it, and adapt it to your needs. You can also have a look at the OpenEmbedded +layer index to find different distribution layers. If you just need to add your +own application to the image, create your own layer.

+

In the following chapter, we have an embedded project called “racer” which we +will implement using our Ampliphy Linux distribution. First, we need to create +a new layer.

+

Yocto provides a script for that. If you set up the BSP and the shell is +ready, type

+
host:~$ bitbake-layers create-layer meta-racer
+
+
+

Default options are fine for now. Move the layer to the source directory

+
host:~$ mv meta-racer ../sources/
+
+
+

Create a Git repository in this layer to track your changes

+
host:~$ cd ../sources/meta-racer
+host:~$ git init && git add . && git commit -s
+
+
+

Now you can add the layer directly to your build/conf/bblayers.conf

+
BBLAYERS += "${BSPDIR}/sources/meta-racer"
+
+
+

or with a script provided by Yocto

+
host:~$ bitbake-layers add-layer meta-racer
+
+
+
+
+

8.6.7. Kernel and Bootloader Recipe and Version

+

First, you need to know which kernel and version are used for your target +machine. PHYTEC provides multiple kernel recipes linux-mainline, linux-ti +and linux-imx. The first one provides support for PHYTEC’s i.MX 6 and AM335x +modules and is based on the Linux kernel stable releases from kernel.org. +The Git repositories URLs are:

+
    +

  • linux-mainline: git://git.phytec.de/linux-mainline

    • +

  • linux-ti: git://git.phytec.de/linux-ti

    • +

  • linux-imx: git://git.phytec.de/linux-imx

    • +

  • barebox: git://git.phytec.de/barebox

    • +

  • u-boot-imx: git://git.phytec.de/u-boot-imx

    • +
+

To find your kernel provider, execute the following command

+
host:~$ bitbake virtual/kernel -e | grep "PREFERRED_PROVIDER_virtual/kernel"
+
+
+

The command prints the value of the variable +PREFERRED_PROVIDER_virtual/kernel. The variable is used in the internal +Yocto build process to select the kernel recipe to use. The following lines +are different outputs you might see

+
PREFERRED_PROVIDER_virtual/kernel="linux-mainline"
+PREFERRED_PROVIDER_virtual/kernel="linux-ti"
+PREFERRED_PROVIDER_virtual/kernel="linux-imx"
+
+
+

To see which version is used, execute bitbake -s. For example

+
host:~$ bitbake -s | egrep -e "linux-mainline|linux-ti|linux-imx|barebox|u-boot-imx"
+
+
+

The parameter -s prints the version of all recipes. The output contains the +recipe name on the left and the version on the right

+
barebox                      :2022.02.0-phy1-r7.0
+barebox-hosttools-native     :2022.02.0-phy1-r7.0
+barebox-targettools          :2022.02.0-phy1-r7.0
+linux-mainline               :5.15.102-phy1-r0.0
+
+
+

As you can see, the recipe linux-mainline has version 5.15.102-phy1. In +the PHYTEC’s linux-mainline Git repository, you will find a corresponding +tag v5.15.102-phy1. The version of the barebox recipe is 2022.02.0-phy1. +On i.MX8M* modules the output will contain linux-imx and u-boot-imx.

+
+
+

8.6.8. Kernel and Bootloader Configuration

+

The bootloader used by PHYTEC, barebox, uses the same build system as the +Linux kernel. Therefore, all commands in this section can be used to configure +the kernel and bootloader. To configure the kernel or bootloader, execute one of +the following commands

+
host:~$ bitbake -c menuconfig virtual/kernel  # Using the virtual provider name
+host:~$ bitbake -c menuconfig linux-ti        # Or use the recipe name directly
+host:~$ bitbake -c menuconfig linux-mainline  # Or use the recipe name directly (If you use an i.MX 6 or RK3288 Module)
+host:~$ bitbake -c menuconfig linux-imx       # Or use the recipe name directly (If you use an i.MX 8M*)
+host:~$ bitbake -c menuconfig barebox         # Or change the configuration of the bootloader
+host:~$ bitbake -c menuconfig u-boot-imx      # Or change the configuration of the bootloader (If you use an i.MX 8M*)
+
+
+

After that, you can recompile and redeploy the kernel or bootloader

+
host:~$ bitbake virtual/kernel -c compile  # Or 'barebox' for the bootloader
+host:~$ bitbake virtual/kernel -c deploy   # Or 'barebox' for the bootloader
+
+
+

Instead, you can also just rebuild the complete build output with

+
host:~$ bitbake phytec-headless-image  # To update the kernel/bootloader, modules and the images
+
+
+

In the last command, you can replace the image name with the name of an image of +your choice. The new images and binaries are in +build/deploy/images/<machine>/.

+
+

Warning

+

The build configuration is not permanent yet. Executing bitbake +virtual/kernel -c clean will remove everything.

+
+

To make your changes permanent in the build system, you have to integrate your +configuration modifications into a layer. For the configuration you have two +options:

+
    +

  • Include only a configuration fragment (a minimal diff between the +old and new configuration)

    • +

  • Complete default configuration (defconfig) after your +modifications.

    • +
+

Having a set of configuration fragments makes what was changed at which stage +more transparent. You can turn on and off the changes, you can manage +configurations for different situations and it helps when porting changes to new +kernel versions. You can also group changes together to reflect specific use +cases. A fully assembled kernel configuration will be deployed in the directory +build/deploy/images/<machine>. If you do not have any of those requirements, +it might be simpler to just manage a separate defconfig file.

+
+

8.6.8.1. Add a Configuration Fragment to a Recipe

+

The following steps can be used for both kernel and bootloader. Just replace the +recipe name linux-mainline in the commands with linux-ti, or barebox for +the bootloader. If you did not already take care of this, start with a clean +build. Otherwise, the diff of the configuration may be wrong

+
host:~$ bitbake linux-mainline -c clean
+host:~$ bitbake linux-mainline -c menuconfig
+
+
+

Make your configuration changes in the menu and generate a config +fragment

+
host:~$ bitbake linux-mainline -c diffconfig
+
+
+

which prints the path of the written file

+
Config fragment has been dumped into:
+/home/<path>/build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg
+
+
+

All config changes are in the file fragment.cfg which should consist of only +some lines. The following example shows how to create a bbappend file and how +to add the necessary lines for the config fragment. You just have to adjust the +directories and names for the specific recipe: linux-mainline, linux-ti, +linux-imx, u-boot-imx, or barebox.

+
sources/<layer>/recipes-kernel/linux/linux-mainline_%.bbappend     # For the recipe linux-mainline
+sources/<layer>/recipes-kernel/linux/linux-ti_%.bbappend           # For the recipe linux-ti
+sources/<layer>/recipes-kernel/linux/linux-imx_%.bbappend          # For the recipe linux-imx
+sources/<layer>/recipes-bsp/barebox/barebox_%.bbappend             # For the recipe barebox
+sources/<layer>/recipes-bsp/u-boot/u-boot-imx_%.bbappend           # For the recipe u-boot-imx
+
+
+

Replace the string layer with your own layer created as shown above (e.g. +meta-racer), or just use meta-ampliphy. To use meta-ampliphy, first, +create the directory for the config fragment and give it a new name (here +enable-r8169.cfg) and move the fragment to the layer.

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features
+# copy the path from the output of *diffconfig*
+host:~$ cp /home/<path>/build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg \
+    sources/meta-ampliphy/recipes-kernel/linux/features/enable-r8169.cfg
+
+
+

Then open the bbappend file (in this case +sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend ) with +your favorite editor and add the following lines

+
# contents of the file linux-mainline_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://enable-r8169.cfg \
+"
+
+
+
+

Warning

+

Do not forget to use the correct bbappend filenames: linux-ti_%.bbappend +for the linux-ti recipe and barebox_%.bbappend for the bootloader in the +folder recipes-bsp/barebox/ !

+
+

After saving the bbappend file, you have to rebuild the image. Yocto should +pick up the recipe changes automatically and generate a new image

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+
+
+

8.6.8.2. Add a Complete Default Configuration (defconfig) to a Recipe

+

This approach is similar to the one above, but instead of adding a fragment, a +defconfig is used. First, create the necessary folders in the layer you want +to use, either your own layer or meta-ampliphy

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features/ # For both linux-mainline and linux-ti
+host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features/ # Or for the bootloader
+
+
+

Then you have to create a suitable defconfig file. Make your configuration +changes using menuconfig and then save the defconfig file to the layer

+
host:~$ bitbake linux-mainline -c menuconfig # Or use recipe name linux-ti or barebox
+host:~$ bitbake linux-mainline -c savedefconfig # Create file 'defconfig.temp' in the work directory
+
+
+

This will print the path to the generated file

+
Saving defconfig to ..../defconfig.temp
+
+
+

Then, as above, copy the generated file to your layer, rename it to defconfig, +and add the following lines to the bbappend file (here +sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend)

+
# contents of the file linux-mainline_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://defconfig \
+"
+
+
+
+

Tip

+

Do not forget to use the correct bbappend filenames: linux-ti_%.bbappend +for the linux-ti recipe and barebox_%.bbappend for the bootloader in the +folder recipes-bsp/barebox/ !

+
+

After that, rebuild your image as the changes are picked up automatically

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+
+
+
+

8.6.9. Patch the Kernel or Bootloader with devtool

+

Apart from using the standard versions of kernel and bootloader which are +provided in the recipes, you can modify the source code or use our own +repositories to build your customized kernel.

+ + + + + + + + + + + + +

PRO

CON

Standard workflow of the +official Yocto documentation

Uses additional hard drive space +as the sources get duplicated

Toolchain does not have to +recompile everything

No optimal cache usage, build +overhead

+

Devtool is a set of helper scripts to enhance the user workflow of Yocto. It +was integrated with version 1.8. It is available as soon as you set up your +shell environment. Devtool can be used to:

+
    +

  • modify existing sources

    • +

  • integrate software projects into your build setup

    • +

  • build software and deploy software modifications to your target

    • +
+

Here we will use devtool to patch the kernel. We use linux-mainline as an +example for the AM335x Kernel. The first command we use is devtool modify - x +<recipe> <directory>

+
host:~$ devtool modify -x linux-mainline linux-mainline
+
+
+

Devtool will create a layer in build/workspace where you can see all +modifications done by devtool . It will extract the sources corresponding to +the recipe to the specified directory. A bbappend will be created in the +workspace directing the SRC_URI to this directory. Building an image with +Bitbake will now use the sources in this directory. Now you can modify lines +in the kernel

+
host:~$ vim linux-mainline/arch/arm/boot/dts/am335x-phycore-som.dtsi
+      -> make a change
+host:~$ bitbake phytec-qt6demo-image
+
+
+

Your changes will now be recompiled and added to the image. If you want to store +your changes permanently, it is advisable to create a patch from the changes, +then store and backup only the patch. You can go into the linux-mainline +directory and create a patch using Git. How to create a patch is described in +Patch the Kernel or Bootloader using the “Temporary Method” and is the same for all methods.

+

If you want to learn more about devtool, visit:

+

Yocto 4.0.6 - Devtool +or Devtool Quick Reference

+
+
+

8.6.10. Patch the Kernel or Bootloader using the “Temporary Method”

+ + + + + + + + + + + + +

PRO

CON

No overhead, no extra +configuration

Changes are easily overwritten +by Yocto (Everything is +lost!!).

Toolchain does not have to +recompile everything

+

It is possible to alter the source code before Bitbake configures and compiles +the recipe. Use Bitbake’ s devshell command to jump into the source +directory of the recipe. Here is the barebox recipe

+
host:~$ bitbake barebox -c devshell # or linux-mainline, linux-ti, linux-imx, u-boot-imx
+
+
+

After executing the command, a shell window opens. The current working directory +of the shell will be changed to the source directory of the recipe inside the +tmp folder. Here you can use your favorite editor, e.g. vim, emacs, or any +other graphical editor, to alter the source code. When you are finished, exit +the devshell by typing exit or hitting CTRL-D.

+

After leaving the devshell you can recompile the package

+
host:~$ bitbake barebox -c compile --force # or linux-mainline, linux-ti, linux-imx, u-boot-imx
+
+
+

The extra argument ‘–force’ is important because Yocto does not recognize +that the source code was changed.

+
+

Tip

+

You cannot execute the bitbake command in the devshell . You have +to leave it first.

+
+

If the build fails, execute the devshell command again and fix it. If the build +is successful, you can deploy the package and create a new SD card image

+
host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox.bin
+host:~$ bitbake phytec-headless-image # new WIC image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic
+
+
+
+

Warning

+

If you execute a clean e.g bitbake barebox -c clean , or if Yocto fetches +the source code again, all your changes are lost!!!

+

To avoid this, you can create a patch and add it to a bbappend file. It is +the same workflow as described in the section about changing the +configuration.

+

You have to create the patch in the devshell if you use the temporary +method and in the subdirectory created by devtool if you used devtool.

+
+
host:~$ bitbake barebox -c devshell            # Or linux-mainline, linux-ti
+host(devshell):~$ git status                   # Show changes files
+host(devshell):~$ git add <file>               # Add a special file to the staging area
+host(devshell):~$ git commit -m "important modification"   # Creates a commit with a not so useful commit message
+host(devshell):~$ git format-patch -1 -o ~/    # Creates a patch of the last commit and saves it in your home folder
+/home/<user>/0001-important-modification.patch  # Git prints the path of the written patch file
+host(devshell):~$ exit
+
+
+

After you have created the patch, you must create a bbappend file for it. The +locations for the three different recipes - linux-mainline , linux-ti , and +barebox - are

+
sources/<layer>/recipes-kernel/linux/linux-mainline_%.bbappend     # For the recipe linux-mainline
+sources/<layer>/recipes-kernel/linux/linux-ti_%.bbappend           # For the recipe linux-ti
+sources/<layer>/recipes-kernel/linux/linux-imx_%.bbappend        # For the recipe linux-imx
+sources/<layer>/recipes-bsp/barebox/barebox_%.bbappend             # For the recipe barebox
+sources/<layer>/recipes-bsp/u-boot/u-boot-imx_%.bbappend           # For the recipe u-boot-imx
+
+
+

The following example is for the recipe barebox. You have to adjust the paths. +First, create the folders and move the patch into them. Then create the +bbappend file

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features   # Or use your own layer instead of *meta-ampliphy*
+host:~$ cp ~/0001-important-modification.patch sources/meta-ampliphy/recipes-bsp/barebox/features  # copy patch
+host:~$ touch sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend
+
+
+
+

Tip

+

Pay attention to your current work directory. You have to execute the +commands in the BSP top-level directory. Not in the build directory!

+
+

After that use your favorite editor to add the following snipped into the +bbappend file (here +sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend)

+
# contents of the file barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://0001-important-modification.patch \
+"
+
+
+

Save the file and rebuild the barebox recipe with

+
host:~$ bitbake barebox -c clean # Or linux-ti, linux-mainline, linux-imx, u-boot-imx
+host:~$ bitbake barebox
+
+
+

If the build is successful, you can rebuild the final image with

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+

Further Resources:

+

The Yocto Project has some documentation for software developers. Check the +‘Kernel Development Manual’ for more information about how to configure the +kernel. Please note that not all of the information from the Yocto manual can +be applied to the PHYTEC BSP as we use the classic kernel approach of Yocto +and most of the documentation assumes the Yocto kernel approach.

+ +
+
+

8.6.11. Working with the Kernel and Bootloader using SRC_URI in local.conf

+

Here we present a third option to make kernel and bootloader changes. You have +external checkouts of the linux-mainline, linux-ti, or barebox Git +repositories. You will overwrite the URL of the source code fetcher, the +variable SRC_URI, to point to your local checkout instead of the remote +repositories.

+ + + + + + + + + + + + + + + +

PRO

CON

All changes are saved with +Git

Many working directories in +build/tmp-glibc/work/<machine>/<package>/

You have to commit every change +before recompiling

For each change, the toolchain +compiles everything from scratch +(avoidable with ccache)

+

First, you need a local clone of the Git repository barebox or +kernel. If you do not have one, use the commands

+
host:~$ mkdir ~/git
+host:~$ cd ~/git
+host:~$ git clone git://git.phytec.de/barebox
+host:~$ cd barebox
+host:~$ git switch --create v2022.02.0-phy remotes/origin/v2022.02.0-phy
+
+
+

Add the following snippet to the file build/conf/local.conf

+
# Use your own path to the git repository
+# NOTE: Branch name in variable "BRANCH_pn-barebox" should be the same as the
+# branch which is used in the repository folder. Otherwise your commits won't be recognized later.
+BRANCH:pn-barebox = "v2022.02.0-phy"
+SRC_URI:pn-barebox = "git:///${HOME}/git/barebox;branch=${BRANCH}"
+SRCREV:pn-barebox = "${AUTOREV}"
+
+
+

You also have to set the correct BRANCH name in the file. Either you create your +own branch in the Git repository, or you use the default (here +“v2015.02.0-phy”). Now you should recompile barebox from your own source

+
host:~$ bitbake barebox -c clean
+host:~$ bitbake barebox -c compile
+
+
+

The build should be successful because the source was not changed yet.

+

You can alter the source in ~/git/barebox or the default defconfig (e.g. +~/git/barebox/arch/arm/configs/imx_v7_defconfig). After you are satisfied with +your changes, you have to make a dummy commit for Yocto. If you do not, +Yocto will not notice that the source code was modified in your repository +folder (e.g. ~/git/barebox/)

+
host:~$ git status  # show modified files
+host:~$ git diff    # show changed lines
+host:~$ git commit -a -m "dummy commit for yocto"   # This command is important!
+
+
+

Try to compile your new changes. Yocto will automatically notice that the +source code was changed and fetches and configures everything from scratch.

+
host:~$ bitbake barebox -c compile
+
+
+

If the build fails, go back to the source directory, fix the problem, and +recommit your changes. If the build was successful, you can deploy barebox and +even create a new SD card image.

+
host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox-phyflex-imx6-2.bin
+host:~$ bitbake phytec-headless-image # new sd-card image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic
+
+
+

If you want to make additional changes, just make another commit in the +repository and rebuild barebox again.

+
+
+

8.6.12. Add Existing Software with “Sustainable Method”

+

Now that you have created your own layer, you have a second option to add +existing software to existing image definitions. Our standard image is defined +in meta-ampliphy

+
meta-ampliphy/recipes-images/images/phytec-headless-image.bb
+
+
+

In your layer, you can now modify the recipe with a bbappend without modifying +any BSP code

+
meta-racer/recipes-images/images/phytec-headless-image.bbappend
+
+
+

The append will be parsed together with the base recipe. As a result, you can +easily overwrite all variables set in the base recipe, which is not always what +you want. If we want to include additional software, we need to append it to the +IMAGE_INSTALL variable

+
IMAGE_INSTALL:append = " rsync"
+
+
+
+
+

8.6.13. Add Linux Firmware Files to the Root Filesystem

+

It is a common task to add an extra firmware file to your root filesystem into +/lib/firmware/. For example, WiFi adapters or PCIe Ethernet cards might need +proprietary firmware. As a solution, we use a bbappend in our layer. To create +the necessary folders, bbappend and copy the firmware file type

+
host:~$ cd meta-racer   # go into your layer
+host:~$ mkdir -p recipes-kernel/linux-firmware/linux-firmware/
+host:~$ touch recipes-kernel/linux-firmware/linux-firmware_%.bbappend
+host:~$ cp ~/example-firmware.bin recipes-kernel/linux-firmware/linux-firmware/    # adapt filename
+
+
+

Then add the following content to the bbappend file and replace every +occurrence of example-firmware.bin with your firmware file name.

+
# file recipes-kernel/linux-firmware/linux-firmware_%.bbappend
+
+FILESEXTRAPATHS:prepend := "${THISDIR}/linux-firmware:"
+SRC_URI += "file://example-firmware.bin"
+
+do_install:append () {
+        install -m 0644 ${WORKDIR}/example-firmware.bin ${D}/lib/firmware/example-firmware.bin
+}
+
+# NOTE: Use "=+" instead of "+=". Otherwise file is placed into the linux-firmware package.
+PACKAGES =+ "${PN}-example"
+FILES:${PN}-example = "/lib/firmware/example-firmware.bin"
+
+
+

Now try to build the linux-firmware recipe

+
host:~$ . sources/poky/oe-init-build-env
+host:~$ bitbake linux-firmware
+
+
+

This should generate a new package deploy/ipk/all/linux-firmware-example.

+

As the final step, you have to install the firmware package to your image. You +can do that in your local.conf or image recipe via

+
# file local.conf or image recipe
+IMAGE_INSTALL += "linux-firmware-example"
+
+
+
+

Warning

+

Ensure that you have adapted the package name linux-firmware-example with +the name you assigned in linux-firmware_%.bbappend.

+
+
+
+

8.6.14. Change the u-boot Environment via bbappend Files

+

All i.MX8M* products use the u-boot bootloader. The u-boot environment can be +modified using the Temporary Method. In the u-boot-imx sources modify the +header file corresponding to the processor located in +include/configs/phycore_imx8m*. New environment variables should be added at +the end of CONFIG_EXTRA_ENV_SETTINGS

+
#define CONFIG_EXTRA_ENV_SETTINGS \
+[...]
+PHYCORE_FITIMAGE_ENV_BOOTLOGIC \
+"newvariable=1\0"
+
+
+

Commit the changes and and create the file u-boot-imx_%.bbappend in your layer +at <layer>/recipes-bsp/u-boot/u-boot-imx_%.bbappend

+
# contents of the file u-boot-imx_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://0001-environment-addition.patch \
+"
+
+
+
+
+

8.6.15. Change the barebox Environment via bbappend Files

+

Since BSP-Yocto-AM335x-16.2.0 and BSP-Yocto-i.MX6-PD16.1.0, the barebox +environment handling in meta-phytec has changed. Now it is possible to add, +change, and remove files in the barebox environment via the Python bitbake +task do_env. There are two Python functions to change the environment. Their +signatures are:

+
    +

  • env_add(d, ***filename as string*, ***file content as string*): +to add a new file or overwrite an existing file

    • +

  • env_rm(d, ***filename as string*): to remove a file

    • +
+

The first example of a bbappend file in the custom layer meta-racer shows +how to add a new non-volatile variable linux.bootargs.fb in the barebox +environment folder /env/nv/

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_add(d, "nv/linux.bootargs.fb", "imxdrm.legacyfb_depth=32\n")
+}
+
+
+

The next example shows how to replace the network configuration file +/env/network/eth0

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_add(d, "network/eth0",
+"""#!/bin/sh
+
+# ip setting (static/dhcp)
+ip=static
+global.dhcp.vendor_id=barebox-${global.hostname}
+
+# static setup used if ip=static
+ipaddr=192.168.178.5
+netmask=255.255.255.0
+gateway=192.168.178.1
+serverip=192.168.178.1
+""")
+}
+
+
+

In the above example, the Python multiline string syntax “”” text “”” is +used to avoid adding multiple newline characters \n into the recipe Python +code. The Python function env_add can add and overwrite environment files.

+

The next example shows how to remove an already added environment file, for +example , /env/boot/mmc

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_rm(d, "boot/mmc")
+}
+
+
+
+

8.6.15.1. Debugging the Environment

+

If you want to see all environment files that are added in the build process, +you can enable a debug flag in the local.conf

+
# file local.conf
+ENV_VERBOSE = "1"
+
+
+

After that, you have to rebuild the barebox recipe to see the debugging +output

+
host:~$ bitbake barebox -c clean
+host:~$ bitbake barebox -c configure
+
+
+

The output of the last command looks like this

+
[...]
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/allow_color' content "false"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.base' content "consoleblank=0"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.fb' content "imxdrm.legacyfb_depth=32"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.rootfs' content "rootwait ro fsck.repair=yes"
+
+
+
+
+

8.6.15.2. Changing the Environment (depending on Machines)

+

If you need to apply some barebox environment modifications only to a single +or only a few machines, you can use Bitbake’ s machine overwrite syntax. For +the machine overwrite syntax, you append a machine name or SoC name (such as +mx6 , ti33x, or rk3288 ) with an underscore to a variable or task

+
DEPENDS:remove:mx6 = "virtual/libgl" or
+python do_env_append_phyboard-mira-imx6-4().
+
+
+

The next example adds the environment variables only if the MACHINE is set to +phyboard-mira-imx6-4

+
# file meta-phytec/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append:phyboard-mira-imx6-4() {
+    env_add(d, "nv/linux.bootargs.cma", "cma=64M\n")
+}
+
+
+

Bitbake’s override syntax for variables is explained in more detail at: +https://docs.yoctoproject.org/bitbake/2.0/bitbake-user-manual/bitbake-user-manual-metadata.html#conditional-metadata

+
+
+

8.6.15.3. Upgrading the barebox Environment from Previous BSP Releases

+

Prior to BSP version BSP-Yocto-AM335x-16.2.0 and BSP-Yocto-i.MX6-PD16.1.0 , +barebox environment changes via bbappend file were done differently. For +example, the directory structure in your meta layer (here meta-skeleton ) may +have looked like this

+
$ tree -a sources/meta-skeleton/recipes-bsp/barebox/
+sources/meta-skeleton/recipes-bsp/barebox
+├── barebox
+│   └── phyboard-wega-am335x-3
+│       ├── boardenv
+│       │   └── .gitignore
+│       └── machineenv
+│           └── nv
+│               └── linux.bootargs.cma
+└── barebox_%.bbappend
+
+
+

and the file barebox_%.bbappend contained

+
# file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:"
+
+
+

In this example, all environment changes from the directory boardenv in the +layer meta-phytec are ignored and the file nv/linux.bootargs.cma is added. +For the new handling of the barebox environment, you use the Python +functions env_add and env_rm in the Python task do_env. Now the above +example translates to a single Python function in the file +barebox_%.bbappend that looks like

+
# file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:"
+python do_env:append() {
+    # Removing files (previously boardenv)
+    env_rm(d, "config-expansions")
+    # Adding new files (previously machineenv)
+    env_add(d, "nv/linux.bootargs.cma", "cma=64M\n")
+}
+
+
+
+
+
+

8.6.16. Changing the Network Configuration

+

To tweak IP addresses, routes, and gateways at runtime you can use the tools +ifconfig and ip . Some examples

+
target:~$ ip addr                                         # Show all network interfaces
+target:~$ ip route                                        # Show all routes
+target:~$ ip addr add 192.168.178.11/24 dev eth0          # Add static ip and route to interface eth0
+target:~$ ip route add default via 192.168.178.1 dev eth0 # Add default gateway 192.168.178.1
+target:~$ ip addr del 192.168.178.11/24 dev eth0          # Remove static ip address from interface eth0
+
+
+

The network configuration is managed by systemd-networkd . To query the +current status use

+
target:~$ networkctl status
+target:~$ networkctl list
+
+
+

The network daemon reads its configuration from the directories +/etc/systemd/network/ , /run/systemd/network/ , and /lib/systemd/network/ +(from higher to lower priority). A sample configuration in +/lib/systemd/network/10-eth0.network looks like this

+
# file /lib/systemd/network/10-eth0.network
+[Match]
+Name=eth0
+
+[Network]
+Address=192.168.3.11/24
+Gateway=192.168.3.10
+
+
+

These files *.network replace /etc/network/interfaces from other +distributions. You can either edit the file 10-eth0.network in-place or copy +it to /etc/systemd/network/ and make your changes there. After changing a file +you must restart the daemon to apply your changes

+
target:~$ systemctl restart systemd-networkd
+
+
+

To see the syslog message of the network daemon, use

+
target:~$ journalctl --unit=systemd-networkd.service
+
+
+

To modify the network configuration at build time, look at the recipe +sources/meta-ampliphy/recipes-core/systemd/systemd-machine-units.bb +and the interface files in the folder +meta-ampliphy/recipes-core/systemd/systemd-machine-units/ where the static IP +address configuration for eth0 (and optionally eth1) is done.

+

For more information, see https://wiki.archlinux.org/title/Systemd-networkd +and https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html.

+
+
+

8.6.17. Changing the Wireless Network Configuration

+
+

8.6.17.1. Connecting to a WLAN Network

+
    +

  • First set the correct regulatory domain for your country

    • +
+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

You will see

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+
    +

  • Set up the wireless interface

    • +
+
target:~$ ip link    # list all interfaces. Search for wlan*
+target:~$ ip link set up dev wlan0
+
+
+
    +

  • Now you can scan for available networks

    • +
+
target:~$ iw wlan0 scan | grep SSID
+
+
+

You can use a cross-platform supplicant with support for WEP, WPA, and +WPA2 called wpa_supplicant for an encrypted connection.

+
    +

  • To do so, add the network credentials to the file +/etc/wpa_supplicant.conf

    • +
+
Confluence country=DE network={ ssid="<SSID>" proto=WPA2 psk="<KEY>" }
+
+
+
    +

  • Now a connection can be established

    • +
+
target:~$ wpa_supplicant -Dnl80211 -c/etc/wpa_supplicant.conf -iwlan0 -B
+
+
+

This should result in the following output

+
ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see the section Changing the Network Configuration.

+
    +

  • First, create the directory

    • +
+
target:~$ mkdir -p /etc/systemd/network/
+
+
+
    +

  • Then add the following configuration snippet in +/etc/systemd/network/10-wlan0.network

    • +
+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+
    +

  • Now, restart the network daemon so that the configuration takes effect

    • +
+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+

8.6.17.2. Creating a WLAN Access Point

+

This section provides a basic access point (AP) configuration for a +secured WPA2 network.

+

Find the name of the WLAN interface with

+
target:~$ ip link
+
+
+

Edit the configuration in /etc/hostapd.conf. It is strongly dependent on +the use case. The following shows an example

+
# file /etc/hostapd.conf
+interface=wlan0
+driver=nl80211
+ieee80211d=1
+country_code=DE
+hw_mode=g
+ieee80211n=1
+ssid=Test-Wifi
+channel=2
+wpa=2
+wpa_passphrase=12345678
+wpa_key_mgmt=WPA-PSK
+wpa_pairwise=CCMP
+
+
+

Set up and start the DHCP server for the network interface wlan0 via +systemd-networkd

+
target:~$ mkdir -p /etc/systemd/network/
+target:~$ vi /etc/systemd/network/10-wlan0.network
+
+
+

Insert the following text into the file

+
[Match]
+Name=wlan0
+
+[Network]
+Address=192.168.0.1/24
+DHCPServer=yes
+
+[DHCPServer]
+EmitDNS=yes
+target:~$ systemctl restart systemd-networkd
+target:~$ systemctl status  systemd-networkd -l   # check status and see errors
+
+
+

Start the userspace daemon hostapd

+
target:~$ systemctl start hostapd
+target:~$ systemctl status hostapd -l # check for errors
+
+
+

Now, you should see the WLAN network Test-Wifi on your terminal device +(laptop, smartphone, etc.).

+

If there are problems with the access point, you can either check the log +messages with

+
target:~$ journalctl --unit=hostapd
+
+
+

or start the daemon in debugging mode from the command line

+
target:~$ systemctl stop hostapd
+target:~$ hostapd -d /etc/hostapd.conf -P /var/run/hostapd.pid
+
+
+

You should see

+
...
+wlan0: interface state UNINITIALIZED->ENABLED
+wlan0: AP-ENABLED
+
+
+

Further information about AP settings and the userspace daemon +hostapd can be found at

+
https://wireless.wiki.kernel.org/en/users/documentation/hostapd
+https://w1.fi/hostapd/
+
+
+
+
+

8.6.17.3. phyCORE-i.MX 6UL/ULL Bluetooth

+

Special consideration must be paid when working with any Bluetooth on a +phyCORE-i.MX 6UL/ULL. For further information, please check L-844e.A5 i.MX +6UL/ULL BSP Manual - Bluetooth.

+
+
+
+

8.6.18. Add OpenCV Libraries and Examples

+

OpenCV (Opensource Computer Vision https://opencv.org/) is an open-source +library for computer vision applications.

+

To install the libraries and examples edit the file conf/local.conf in the +Yocto build system and add

+
# file conf/local.conf
+# Installing OpenCV libraries and examples
+LICENSE_FLAGS_ACCEPTED += "commercial_libav"
+LICENSE_FLAGS_ACCEPTED += "commercial_x264"
+IMAGE_INSTALL:append = " \
+    opencv \
+    opencv-samples \
+    libopencv-calib3d2.4 \
+    libopencv-contrib2.4 \
+    libopencv-core2.4 \
+    libopencv-flann2.4 \
+    libopencv-gpu2.4 \
+    libopencv-highgui2.4 \
+    libopencv-imgproc2.4 \
+    libopencv-legacy2.4 \
+    libopencv-ml2.4 \
+    libopencv-nonfree2.4 \
+    libopencv-objdetect2.4 \
+    libopencv-ocl2.4 \
+    libopencv-photo2.4 \
+    libopencv-stitching2.4 \
+    libopencv-superres2.4 \
+    libopencv-video2.4 \
+    libopencv-videostab2.4 \
+"
+
+
+

Then rebuild your image

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+

Tip

+

Most examples do not work out of the box, because they depend on the GTK +graphics library. The BSP only supports Qt6 .

+
+
+
+

8.6.19. Add Minimal PHP web runtime with lightpd

+

This is one example of how to add a small runtime for PHP applications and a web +server on your target. Lighttpd can be used together with the PHP command line +tool over cgi. This solution weights only 5.5 MiB of disk storage. It is already +preconfigured in meta-ampliphy. Just modify the build configuration to install +it on the image

+
# file conf/local.conf
+# install lighttpd with php cgi module
+IMAGE_INSTALL:append = " lighttpd"
+
+
+

After booting the image, you should find the example web content in /www/pages +. For testing php, you can delete the index.html and replace it with a +index.php file

+
<html>
+  <head>
+    <title>PHP-Test</title>
+  </head>
+  <body>
+    <?php phpinfo(); ?>
+  </body>
+</html>
+
+
+

On your host, you can point your browser to the board’s IP, (e.g. 192.168.3.11) +and the phpinfo should show up.

+
+
+
+

8.7. Common Tasks

+
+

8.7.1. Debugging a User Space Application

+

The phytec-qt6demo-image can be cross-debugged without any change. For +cross-debugging, you just have to match the host sysroot with the image in use. +So you need to create a toolchain for your image

+
host:~$ bitbake -c populate_sdk phytec-qt6demo-image
+
+
+

Additionally, if you want to have full debug and backtrace capabilities for all +programs and libraries in the image, you could add

+
DEBUG_BUILD = "1"
+
+
+

to the conf/local.conf. This is not necessary in all cases. The compiler +options will then be switched from FULL_OPTIMIZATION to DEBUG_OPTIMIZATION. Look +at the Poky source code for the default assignment of DEBUG_OPTIMIZATION.

+

To start a cross debug session, install the SDK as mentioned previously, source +the SDK environment, and run Qt Creator in the same shell. If you do not use +Qt Creator, you can directly call the arm-<..>-gdb debugger instead which +should be in your path after sourcing the environment script.

+

If you work with Qt Creator, have a look at the appropriate documentation +delivered with your product (either QuickStart or Application Guide) for +information on how to set up the toolchain.

+

When starting the debugger with your userspace application you will get a +SIGILL, an illegal instruction from the libcrypto. Openssl probes for the +system capabilities by trapping illegal instructions, which will trigger GDB. +You can ignore this and hit Continue (c command). You can permanently ignore +this stop by adding

+
handle SIGILL nostop
+
+
+

to your GDB startup script or in the Qt Creator GDB configuration panel. +Secondly, you might need to disable a security feature by adding

+
set auto-load safe-path /
+
+
+

to the same startup script, which will enable the automatic loading of libraries +from any location.

+

If you need to have native debugging, you might want to install the debug +symbols on the target. You can do this by adding the following line to your +conf/local.conf

+
EXTRA_IMAGE_FEATURES += "dbg-pkgs"
+
+
+

For cross-debugging, this is not required as the debug symbols will be loaded +from the host side and the dbg-pkgs are included in the SDK of your image +anyway.

+
+
+

8.7.2. Generating Source Mirrors, working Offline

+

Modify your site.conf (or local.conf if you do not use a site.conf ) as +follows

+
#DL_DIR ?= "" don't set it! It will default to a directory inside /build
+SOURCE_MIRROR_URL = "file:///home/share/yocto_downloads/"
+INHERIT += "own-mirrors"
+BB_GENERATE_MIRROR_TARBALLS = "1"
+
+
+

Now run

+
host:~$ bitbake --runall=fetch <image>
+
+
+

for all images and for all machines you want to provide sources for. This will +create all the necessary tar archives. We can remove all SCM subfolders, as +they are duplicated with the tarballs

+
host:~$ rm -rf build/download/git2/
+etc...
+
+
+

Please consider that we used a local source mirror for generating the dl_dir. +Because of that, some archives will be linked locally.

+

First, we need to copy all files, resolving symbolic links into the new mirror +directory

+
host:~$ rsync -vaL <dl_dir> ${TOPDIR}/../src_mirror/
+
+
+

Now we clean the /build directory by deleting everything except /build/conf/ +but including /build/conf/sanity. We change site.conf as follows

+
SOURCE_MIRROR_URL = "file://${TOPDIR}/../src_mirror"
+INHERIT += "own-mirrors"
+BB_NO_NETWORK = "1"
+SCONF_VERSION = "1"
+
+
+

The BSP directory can now be compressed with

+
host:~$ tar cfJ <filename>.tar.xz <folder>
+
+
+

where filename and folder should be the full BSP Name.

+
+
+

8.7.3. Compiling on the Target

+

To your local.conf add

+
IMAGE_FEATURES:append = " tools-sdk dev-pkgs"
+
+
+
+
+

8.7.4. Different Toolchains

+

There are several ways to create a toolchain installer in Poky. One option is +to run

+
host:~$ bitbake meta-toolchain
+
+
+

This will generate a toolchain installer in build/deploy/sdk which can be used +for cross-compiling of target applications. However, the installer does not +include libraries added to your image, so it is a bare GCC compiler only. This +is suited for bootloader and kernel development.

+

Another you can run is

+
host:~$ bitbake -c populate_sdk <your_image>
+
+
+

This will generate a toolchain installer containing all necessary development +packages of the software installed on the root filesystem of the target. This +installer can be handed over to the user space application development team and +includes all necessary parts to develop an application. If the image contains +the QT libraries, all of those will be available in the installer too.

+

The third option is to create the ADT (Application Development Toolkit) +installer. It will contain the cross-toolchain and some tools to aid the +software developers, for example, an Eclipse plugin and a QEMU target +simulator.

+
host:~$ bitbake adt-installer
+
+
+

The ADT is untested for our BSP at the moment.

+
+

8.7.4.1. Using the SDK

+

After generating the SDK with

+
host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
+
+

run the generated binary with

+
host:~$ deploy/sdk/ampliphy-glibc-x86_64-phytec-qt6demo-image-cortexa9hf-vfp-neon-toolchain-i.MX6-PD15.3-rc.sh
+Enter target directory for SDK (default: /opt/ampliphy/i.MX6-PD15.3-rc):
+You are about to install the SDK to "/opt/ampliphy/i.MX6-PD15.3-rc". Proceed[Y/n]?
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
+
+

You can activate the toolchain for your shell by sourcing the file +environment-setup in the toolchain directory

+
host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+
+
+

Then the necessary tools like the cross compiler and linker are in your PATH. To +compile a simple C program, use

+
host:~$ $CC main.c -o main
+
+
+

The environment variable $CC contains the path to the ARM cross compiler and +other compiler arguments needed like -march , -sysroot and –mfloat-abi.

+
+

Tip

+

You cannot compile programs only with the compiler name like

+
host:~$ arm-phytec-linux-gnueabi-gcc main.c -o main
+
+
+

It will fail in many cases. Always use CC, CFLAGS, LDFLAGS, and so on.

+
+

For convenience, the environment-setup exports other environment variables +like CXX, LD, SDKTARGETSYSROOT.

+

A simple makefile compiling a C and C++ program may look like this

+
# Makefile
+TARGETS=c-program cpp-program
+
+all: $(TARGETS)
+
+c-program: c-program.c
+    $(CC) $(CFLAGS) $(LDFLAGS) $< -o $@
+
+cpp-program: cpp-program.cpp
+    $(CXX) $(CXXFLAGS) $(LDFLAGS) $< -o $@
+
+.PHONY: clean
+clean:
+    rm -f $(TARGETS)
+
+
+

To compile for the target, just source the toolchain in your shell before +executing make

+
host:~$ make     # Compiling with host CC, CXX for host architecture
+host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+host:~$ make     # Compiling with target CC, CXX for target architecture
+
+
+

If you need to specify additionally included directories in the sysroot of the +toolchain, you can use an ‘=’ sign in the -I argument like

+
-I=/usr/include/SDL
+
+
+

GCC replaces it by the sysroot path (here +/opt/ampliphy/i.MX6-PD15.3-rc/sysroots/cortexa9hf-vfp-neon-phytec-linux-gnueabi/). +See the main page of GCC for more information.

+
+

Tip

+

The variables $CFLAGS and $CXXFLAGS contain the compiler debug flag ‘-g’ by +default. This includes debugging information in the binary and making it +bigger. Those should be removed from the production image. If you create a +Bitbake recipe, the default behavior is to turn on ‘-g’ too. The debugging +symbols are used in the SDK rootfs to be able to get debugging information +when invoking GDB from the host. Before installing the package to the +target rootfs, Bitbake will invoke strip on the program which removes the +debugging symbols. By default, they are not found nor required on the target +root filesystem

+
+
+
+

8.7.4.2. Using the SDK with GNU Autotools

+

Yocto SDK is a straightforward tool for a project that uses the GNU +Autotools. The traditional compile steps for the host are usually

+
host:~$ ./autogen.sh # maybe not needed
+host:~$ ./configure
+host:~$ make
+host:~$ make install DESTDIR=$PWD/build/
+
+
+

The commands to compile for the target machine with the Yocto SDK are quite +similar. The following commands assume that the SDK was unpacked to the +directory /opt/phytec-ampliphy/i.MX6-PD15.3.0/ (adapt the path as needed)

+
host:~$ source /opt/phytec-ampliphy/i.MX6-PD15.3.0/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+host:~$ ./autogen.sh  # maybe not needed
+host:~$ ./configure ${CONFIGURE_FLAGS}
+host:~$ make
+host:~$ make install DESTDIR=$PWD/build/
+
+
+

Refer to the official Yocto documentation for more information: +https://docs.yoctoproject.org/4.0.6/singleindex.html#autotools-based-projects

+
+
+
+

8.7.5. Working with Kernel Modules

+

You will come to the point where you either need to set some options for a +kernel module or you want to blacklist a module. Those things are handled by +udev and go into *.conf files in

+
/etc/modprobe.d/\*.conf.
+
+
+

If you want to specify an option at build time, there are three relevant +variables. If you just want to autoload a module that has no autoload +capabilities, add it to

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+
+
+

either in the kernel recipe or in the global variable scope. If you need to +specify options for a module, you can do so with

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+KERNEL_MODULE_PROBECONF += "your-module"
+module_conf_your-module = "options your-module parametername=parametervalue"
+
+
+

if you want to blacklist a module from autoloading, you can do it intuitively +with

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+KERNEL_MODULE_PROBECONF += "your-module"
+module_conf_your-module = "blacklist your-module"
+
+
+
+
+

8.7.6. Working with udev

+

Udev (Linux dynamic device management) is a system daemon that handles dynamic +device management in /dev. It is controlled by udev rules that are located +in /etc/udev/rules.d (sysadmin configuration space) and /lib/udev/rules.d/ +(vendor-provided). Here is an example of an udev rule file

+
# file /etc/udev/rules.d/touchscreen.rules
+# Create a symlink to any touchscreen input device
+SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="input:*-e0*,3,*a0,1,*18,*", SYMLINK+="input/touchscreen0"
+SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="ads7846", SYMLINK+="input/touchscreen0"
+
+
+

See https://www.freedesktop.org/software/systemd/man/latest/udev.html for more details +about the syntax and usage. To get the list of attributes for a specific device +that can be used in an udev rule you can use the udevadm info tool. It +prints all existing attributes of the device node and its parents. The key-value +pairs from the output can be copied and pasted into a rule file. Some examples

+
target:~$ udevadm info -a /dev/mmcblk0
+target:~$ udevadm info -a /dev/v4l-subdev25
+target:~$ udevadm info -a -p /sys/class/net/eth0
+
+
+

After changing an udev rule, you have to notify the daemon. Otherwise, your +changes are not reflected. Use the following command

+
target:~$ udevadm control --reload-rules
+
+
+

While developing udev rules you should monitor the events in order to see when +devices are attached or unattached to the system. Use

+
target:~$ udevadm monitor
+
+
+

Furthermore, it is very useful to monitor the system log in another shell, +especially if the rule executes external scripts. Execute

+
target:~$ journalctl -f
+
+
+
+

Tip

+

You cannot start daemons or heavy scripts in a RUN attribute. See +https://www.freedesktop.org/software/systemd/man/latest/udev.html .

+

This can only be used for very short-running foreground tasks. Running an +event process for a long period of time may block all further events for this +or a dependent device. Starting daemons or other long-running processes is +not appropriate for udev; the forked processes, detached or not, will be +unconditionally killed after the event handling has finished. You can use the +special attribute ENV{SYSTEMD_WANTS}=”service-name.service” and a +systemdservice instead.

+

See +https://unix.stackexchange.com/questions/63232/what-is-the-correct-way-to-write-a-udev-rule-to-stop-a-service-under-systemd.

+
+
+
+
+
+

9. Troubleshooting

+
+

9.1. Setscene Task Warning

+

This warning occurs when the Yocto cache is in a dirty state.

+
WARNING: Setscene task X ([...]) failed with exit code '1' - real task
+
+
+

You should avoid canceling the build process or if you have to, press Ctrl-C +once and wait until the build process has stopped. To remove all these warnings +just clean the sstate cache and remove the build folders.

+
host:~$ bitbake phytec-headless-image -c cleansstate && rm -rf tmp deploy/ipk
+
+
+
+
+
+

10. Yocto Documentation

+

The most important piece of documentation for a BSP user is probably the +developer manual. +https://docs.yoctoproject.org/4.0.6/dev-manual/index.html

+

The chapter about common tasks is a good starting point. +https://docs.yoctoproject.org/4.0.6/dev-manual/common-tasks.html#common-tasks

+

The complete documentation is available on one single HTML page, which is good +for searching for a feature or a variable name. +https://docs.yoctoproject.org/4.0.6/singleindex.html

+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/yocto/manual-index.html b/previews/271/yocto/manual-index.html new file mode 100644 index 000000000..faa0ec356 --- /dev/null +++ b/previews/271/yocto/manual-index.html @@ -0,0 +1,359 @@ + + + + + + + + + Yocto Reference Manuals — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

Yocto Reference Manuals

+
+

Kirkstone

+
+

Table of Contents

+ +
+
+
+

Mickledore

+
+

Table of Contents

+ +
+
+
+

Scarthgap

+
+

Table of Contents

+ +
+
+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/yocto/mickledore.html b/previews/271/yocto/mickledore.html new file mode 100644 index 000000000..c9b696722 --- /dev/null +++ b/previews/271/yocto/mickledore.html @@ -0,0 +1,2861 @@ + + + + + + + + + 1. The Yocto Project — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + +

Yocto Reference Manual

Document Title

Yocto Reference Manual Mickledore

Document Type

Yocto Manual

Release Date

XXXX/XX/XX

Is Branch of

Yocto Reference Manual

+ + + + + + + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-NXP-i.MX93-PD24.1.0

Major

05.02.2024

released

BSP-Yocto-NXP-i.MX93-PD24.1.1

Minor

08.05.2024

released

+

This manual applies to all Mickledore based PHYTEC releases.

+
+

1. The Yocto Project

+
+

1.1. PHYTEC Documentation

+

PHYTEC will provide a variety of hardware and software documentation for all of +our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE board along +with brief information on building a BSP, the device tree, and accessing +peripherals.

    • +

  • Hardware Manual: A detailed description of the System on Module and +accompanying carrier board.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version the phyCORE +uses. This guide contains an overview of Yocto; introducing, installing, and +customizing the PHYTEC BSP; how to work with programs like Poky and Bitbake; +and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating software, device +tree, and accessing peripherals can be found here.

    • +

  • Development Environment Guide: This guide shows how to work with the +Virtual Machine (VM) Host PHYTEC has developed and prepared to run various +Development Environments. There are detailed step-by-step instructions for +Eclipse and Qt Creator, which are included in the VM. There are instructions +for running demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a part of this +guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin table (in Excel +format). This table will show the complete default signal path, from +processor to carrier board. The default device tree muxing option will also +be included. This gives a developer all the information needed in one +location to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also provide Product +Change Notifications, Application Notes, and Technical Notes. These will be done +on a case-by-case basis. Most of the documentation can be found in the +applicable download page of our products.

+
+
+

1.2. Yocto Introduction

+

Yocto is the smallest SI metric system prefix. Like milli equates to m = +10^-3, and so is yocto y = 10^-24. Yocto is also a project working group +of the Linux Foundation and therefore +backed up by several major companies in the field. On the Yocto Project website you can read the official introduction:

+
+

The Yocto Project is an open-source collaboration project that provides +templates, tools, and methods to help you create custom Linux-based systems +for embedded products regardless of the hardware architecture. It was founded +in 2010 as a collaboration among many hardware manufacturers, open-source +operating systems vendors, and electronics companies to bring some order to +the chaos of embedded Linux development.

+
+

As said, the project wants to provide toolsets for embedded developers. It +builds on top of the long-lasting OpenEmbedded project. It is not a Linux distribution. But +it contains the tools to create a Linux distribution specially fitted to the +product requirements. The most important step in bringing order to the set of +tools is to define a common versioning scheme and a reference system. All +subprojects have then to comply with the reference system and have to comply +with the versioning scheme.

+

The release process is similar to the Linux kernel. +Yocto increases its version number every six months and gives the release a +codename. The release list can be found here: +https://wiki.yoctoproject.org/wiki/Releases

+
+
+

1.3. Core Components

+

The most important tools or subprojects of the Yocto Project are:

+
    +

  • Bitbake: build engine, a task scheduler like make, interprets metadata

    • +

  • OpenEmbedded-Core, a set of base layers, containing metadata of software, no +sources

    • +

  • Yocto kernel

    +
      +

    • Optimized for embedded devices

      • +

    • Includes many subprojects: rt-kernel, vendor patches

      • +

    • The infrastructure provided by Wind River

      • +

    • Alternative: classic kernel build → we use it to integrate our kernel into +Yocto

      • +
    +
    • +

  • Yocto Reference BSP: beagleboneblack, minnow max

    • +

  • Poky, the reference system, a collection of projects and tools, used to +bootstrap a new distribution based on Yocto

    • +
+
+
+

1.4. Vocabulary

+
+

1.4.1. Recipes

+

Recipes contain information about the software project (author, homepage, and +license). A recipe is versioned, defines dependencies, contains the URL of the +source code, and describes how to fetch, configure, and compile the sources. It +describes how to package the software, e.g. into different .deb packages, which +then contain the installation path. Recipes are basically written in Bitbake’s +own programming language, which has a simple syntax. However, a recipe can +contain Python as well as a bash code.

+
+
+

1.4.2. Classes

+

Classes combine functionality used inside recipes into reusable blocks.

+
+
+

1.4.3. Layers

+

A layer is a collection of recipes, classes, and configuration metadata. +A layer can depend on other layers and can be included or excluded one +by one. It encapsulates a specific functionality and fulfills a specific +purpose. Each layer falls into a specific category:

+
    +

  • Base

    • +

  • Machine (BSP)

    • +

  • Software

    • +

  • Distribution

    • +

  • Miscellaneous

    • +
+

Yocto’s versioning scheme is reflected in every layer as version branches. For +each Yocto version, every layer has a named branch in its Git repository. +You can add one or many layers of each category in your build.

+

A collection of OpenEmbedded layers can be found here. The search function is +very helpful to see if a software package can be retrieved and integrated +easily: https://layers.openembedded.org/layerindex/branch/mickledore/layers/

+
+
+

1.4.4. Machine

+

Machines are configuration variables that describe the aspects of the target +hardware.

+
+
+

1.4.5. Distribution (Distro)

+

Distribution describes the software configuration and comes with a set of +software features.

+
+
+
+

1.5. Poky

+

Poky is the reference system to define Yocto Project compatibility. It +combines several subprojects into releases:

+
    +

  • Bitbake

    • +

  • Toaster

    • +

  • OpenEmbedded Core

    • +

  • Yocto Documentation

    • +

  • Yocto Reference BSP

    • +
+
+

1.5.1. Bitbake

+

Bitbake is the task scheduler. It is written in Python and interprets +recipes that contain code in Bitbake’s own programming language, Python, and +bash code. The official documentation can be found here: +https://docs.yoctoproject.org/bitbake/2.4/index.html

+
+
+

1.5.2. Toaster

+

Toaster is a web frontend for Bitbake to start and investigate builds. It +provides information about the build history and statistics on created images. +There are several use cases where the installation and maintenance of +a Toaster instance are beneficial. PHYTEC did not add or remove any features +to the upstream Toaster, provided by Poky. The best source for more +information is the official documentation: +https://docs.yoctoproject.org/4.2.4/toaster-manual/index.html

+
+
+
+

1.6. Official Documentation

+

For more general questions about Bitbake and Poky consult the mega-manual: +https://docs.yoctoproject.org/4.2.4/singleindex.html

+
+
+
+

2. Compatible Linux Distributions

+

To build Yocto you need a compatible Linux host development machine. The +list of supported distributions can be found in the reference manual: +https://docs.yoctoproject.org/4.2.4/ref-manual/system-requirements.html#supported-linux-distributions

+
+
+

3. PHYTEC BSP Introduction

+
+

3.1. BSP Structure

+

The BSP consists roughly of three parts. BSP management, BSP metadata, and BSP +content. The management consists of Repo and phyLinux while the metadata +depends on the SOC, which describes how to build the software. The content +comprises PHYTEC’s Git repositories and external sources.

+
+

3.1.1. BSP Management

+

Yocto is an umbrella project. Naturally, this will force the user to base +their work on several external repositories. They need to be managed in a +deterministic way. We use manifest files, which contain an XML data structure, +to describe all git repositories with pinned-down versions. The Repo tool and +our phyLinux wrapper script are used to manage the manifests and set up the BSP, +as described in the manifest file.

+
+

3.1.1.1. phyLinux

+

phyLinux is a wrapper for Repo to handle downloading and setting up the BSP +with an “out of the box” experience.

+
+
+

3.1.1.2. Repo

+

Repo is a wrapper around the Repo toolset. The phyLinux script will install +the wrapper in a global path. This is only a wrapper, though. Whenever you run +repo init -u <url>, you first download the Repo tools from Googles Git +server in a specific version to the .repo/repo directory. The next time you +run Repo, all the commands will be available. Be aware that the Repo version +in different build directories can differ over the years if you do not run Repo +sync. Also if you store information for your archives, you need to include the +complete .repo folder.

+

Repo expects a Git repository which will be parsed from the command line. In +the PHYTEC BSP, it is called phy²octo. In this repository, all information about +a software BSP release is stored in the form of a Repo XML manifest. This data +structure defines URLs of Git servers (called “remotes”) and Git +repositories and their states (called “projects”). The Git repositories can be +seen in different states. The revision field can be a branch, tag, or commit id +of a repository. This means the state of the software is not necessarily unique +and can change over time. That is the reason we use only tags or commit ids for +our releases. The state of the working directory is then unique and does not +change.

+

The manifests for the releases have the same name as the release itself. It is a +unique identifier for the complete BSP. The releases are sorted by the SoC +platform. The selected SoC will define the branch of the phy²octo Git +repository which will be used for the manifest selection.

+
+
+
+

3.1.2. BSP Metadata

+

We include several third-party layers in our BSP to get a complete Linux +distribution up and running without the need to integrate external projects. All +used repositories are described in the following section.

+
+

3.1.2.1. Poky

+

The PHYTEC BSP is built on top of Poky. It comes with a specific version, +defined in the Repo manifest. Poky comes with a specific version of +Bitbake. The OpenEmbedded-core layer “meta” is used as a base for our Linux +system.

+
+
+

3.1.2.2. meta-openembedded

+

OpenEmbedded is a collection of different layers containing the meta description +for many open-source software projects. We ship all OpenEmbedded layers with our +BSP, but not all of them are activated. Our example images pull several software +packages generated from OpenEmbedded recipes.

+
+
+

3.1.2.3. meta-qt6

+

This layer provides an integration of Qt6 in the Poky-based root filesystem +and is integrated into our BSP.

+
+
+

3.1.2.4. meta-nodejs

+

This is an application layer to add recent Node.js versions.

+
+
+

3.1.2.5. meta-gstreamer1.0

+

This is an application layer to add recent GStreamer versions.

+
+
+

3.1.2.6. meta-rauc

+

This layer contains the tools required to build an updated infrastructure with +RAUC. A comparison with +other update systems can be found here: Yocto update tools.

+
+
+

3.1.2.7. meta-phytec

+

This layer contains all machines and common features for all our BSPs. It is +PHYTEC’s Yocto Board Support Package for all supported +hardware (since fido) and is designed to be standalone with Poky. Only these +two parts are required if you want to integrate the PHYTEC’s hardware into your +existing Yocto workflow. The features are:

+
    +

  • Bootloaders in recipes-bsp/barebox/ and recipes-bsp/u-boot/

    • +

  • Kernels in recipes-kernel/linux/ and +dynamic-layers/fsl-bsp-release/recipes-kernel/linux/

    • +

  • Many machines in conf/machine/

    • +

  • Proprietary OpenGL ES/EGL user space libraries for AM335x and i.MX 6 +platforms

    • +

  • Proprietary OpenCL libraries for i.MX 6 platforms

    • +
+
+
+

3.1.2.8. meta-ampliphy

+

This is our example distribution and BSP layer. It extends the basic +configuration of Poky with software projects described by all the other BSP +components. It provides a base for your specific development scenarios. The +current features are:

+
    +

  • systemd init system

    • +

  • Images: phytec-headless-image for non-graphics applications

    • +

  • Camera integration with OpenCV and GStreamer examples for the i.MX 6 platform +bundled in a phytec-vision-image

    • +

  • RAUC integration: we set up basic support for an A/B system image update, +which is possible locally and over-the-air

    • +
+
+
+

3.1.2.9. meta-qt6-phytec

+

This is our layer for Qt6 board integration and examples. The features are:

+
    +

  • Qt6 with eglfs backend for +PHYTEC’s AM335x, i.MX 6 and RK3288 platforms

    • +

  • Images: phytec-qt6demo-image for Qt6 and video applications

    • +

  • A Qt6 demo application demonstrating how to create a Qt6 project using +QML widgets and a Bitbake recipe for the Yocto and systemd +integration. It can be found in +sources/meta-qt6-phytec/recipes-qt/examples/phytec-qtdemo_git.bb

    • +
+
+
+

3.1.2.10. meta-virtualization

+
    +

  • This layer provides support for building Xen, KVM, Libvirt, and associated +packages necessary for constructing OE-based virtualized solutions.

    • +
+
+
+

3.1.2.11. meta-security

+
    +

  • This layer provides security tools, hardening tools for Linux kernels, and +libraries for implementing security mechanisms.

    • +
+
+
+

3.1.2.12. meta-selinux

+
    +

  • This layer’s purpose is to enable SE Linux support. The majority of this +layer’s work is accomplished in bbappend files, used to enable SE Linux +support in existing recipes.

    • +
+
+
+

3.1.2.13. meta-browser

+
    +

  • This is an application layer to add recent web browsers (Chromium, Firefox, +etc.).

    • +
+
+
+

3.1.2.14. meta-rust

+
    +

  • Includes the Rust compiler and the Cargo package manager for Rust.

    • +
+
+
+

3.1.2.15. meta-timesys

+
    +

  • Timesys layer for Vigiles Yocto CVE monitoring, security notifications, and +image manifest generation.

    • +
+
+
+

3.1.2.16. meta-freescale

+
    +

  • This layer provides support for the i.MX, Layerscape, and QorIQ product +lines.

    • +
+
+
+

3.1.2.17. meta-freescale-3rdparty

+
    +

  • Provides support for boards from various vendors.

    • +
+
+
+

3.1.2.18. meta-freescale-distro

+
    +

  • This layer provides support for Freescale’s Demonstration images for use with +OpenEmbedded and/or Yocto Freescale’s BSP layer.

    • +
+
+
+

3.1.2.19. base (fsl-community-bsp-base)

+
    +

  • This layer provides BSP base files of NXP.

    • +
+
+
+

3.1.2.20. meta-fsl-bsp-release

+
    +

  • This is the i.MX Yocto Project Release Layer.

    • +
+
+
+
+

3.1.3. BSP Content

+

The BSP content gets pulled from different online sources when you first start +using Bitbake. All files will be downloaded and cloned in a local directory +configured as DL_DIR in Yocto. If you backup your BSP with the complete +content, those sources have to be backed up, too. How you can do this will be +explained in the chapter Generating Source Mirrors, working Offline.

+
+
+
+

3.2. Build Configuration

+

The BSP initializes a build folder that will contain all files you +create by running Bitbake commands. It contains a conf folder +that handles build input variables.

+
    +

  • bblayers.conf defines activated meta-layers,

    • +

  • local.conf defines build input variables specific to your build

    • +

  • site.conf defines build input variables specific to the development host

    • +
+

The two topmost build input variables are DISTRO and MACHINE. They are +preconfigured local.conf when you check out the BSP using phyLinux.

+

We use “Ampliphy” as DISTRO with our BSP. This distribution will be +preselected and give you a starting point for implementing your own +configuration.

+

A MACHINE defines a binary image that supports specific hardware +combinations of module and baseboard. Check the machine.conf file or our +webpage for a description of the hardware.

+
+
+
+

4. Pre-built Images

+

For each BSP we provide pre-built target images that can be downloaded from the +PHYTEC FTP server: https://download.phytec.de/Software/Linux/

+

These images are also used for the BSP tests, which are flashed to the boards +during production. You can use the provided .wic images to create a bootable +SD card at any time. Identify your hardware and flash the downloaded image file +to an empty SD card using dd. Please see section Images for information +about the correct usage of the command.

+
+
+

5. BSP Workspace Installation

+
+

5.1. Setting Up the Host

+

You can set up the host or use one of our build-container to run a Yocto build. +You need to have a running Linux distribution. It should be running on a +powerful machine since a lot of compiling will need to be done.

+

If you want to use a build-container, you only need to install following +packages on your host

+
host:~$ sudo apt install wget git
+
+
+

Continue with the next step Git Configuration after that. The documentation for +using build-container can be found in this manual after +Advanced Usage of phyLinux.

+

Else Yocto needs a handful of additional packages on your host. For Ubuntu you need

+
host:~$ sudo apt install gawk wget git diffstat unzip texinfo \
+      gcc build-essential chrpath socat cpio python3 python3-pip \
+      python3-pexpect xz-utils debianutils iputils-ping python3-git \
+      python3-jinja2 libegl1-mesa libsdl1.2-dev \
+      python3-subunit mesa-common-dev zstd liblz4-tool file locales
+
+
+

For other distributions you can find information in the Yocto Quick Build: +https://docs.yoctoproject.org/4.2.4/brief-yoctoprojectqs/index.html

+
+
+

5.2. Git Configuration

+

The BSP heavily utilizes Git. Git needs some information from +you as a user to identify who made changes. Create a ~/.gitconfig with the +following content, if you do not have one

+
[user]
+    name = <Your Name>
+    email = <Your Mail>
+[core]
+    editor = vim
+[merge]
+    tool = vimdiff
+[alias]
+    co = checkout
+    br = branch
+    ci = commit
+    st = status
+    unstage = reset HEAD --
+    last = log -1 HEAD
+[push]
+    default = current
+[color]
+    ui = auto
+
+
+

You should set name and email in your Git configuration, otherwise, +Bitbake will complain during the first build. You can use the two commands to +set them directly without editing ~/.gitconfig manually

+
host:~$ git config --global user.email "your_email@example.com"
+host:~$ git config --global user.name "name surname"
+
+
+
+
+

5.3. site.conf Setup

+

Before starting the Yocto build, it is advisable to configure the development +setup. Two things are most important: the download directory and the cache +directory. PHYTEC strongly recommends configuring the setup as it will reduce +the compile time of consequent builds.

+

A download directory is a place where Yocto stores all sources fetched from +the internet. It can contain tar.gz, Git mirror, etc. It is very useful to set +this to a common shared location on the machine. Create this directory with 777 +access rights. To share this directory with different users, all files need to +have group write access. This will most probably be in conflict with default +umask settings. One possible solution would be to use ACLs for this +directory

+
host:~$ sudo apt-get install acl
+host:~$ sudo setfacl -R -d -m g::rwx <dl_dir>
+
+
+

If you have already created a download directory and want to fix the permissions +afterward, you can do so with

+
host:~$ sudo find /home/share/ -perm /u=r ! -perm /g=r -exec chmod g+r \{\} \;
+host:~$ sudo find /home/share/ -perm /u=w ! -perm /g=w -exec chmod g+w \{\} \;
+host:~$ sudo find /home/share/ -perm /u=x ! -perm /g=x -exec chmod g+x \{\} \;
+
+
+

The cache directory stores all stages of the build process. Poky has quite an +involved caching infrastructure. It is advisable to create a shared directory, +as all builds can access this cache directory, called the shared state cache.

+

Create the two directories on a drive where you have approximately 50 GB of +space and assign the two variables in your build/conf/local.conf:

+
DL_DIR ?= "<your_directory>/yocto_downloads"
+SSTATE_DIR ?= "<your_directory>/yocto_sstate"
+
+
+

If you want to know more about configuring your build, see the documented +example settings

+
sources/poky/meta-yocto/conf/local.conf.sample
+sources/poky/meta-yocto/conf/local.conf.sample.extended
+
+
+
+
+
+

6. phyLinux Documentation

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP +structure. You can get all the BSP sources without the need of interacting with +Repo or Git.

+

The phyLinux script has only one real dependency. It requires the wget tool +installed on your host. It will also install the Repo tool in a global path +(/usr/local/bin) on your host PC. You can install it in a different location +manually. Repo will be automatically detected by phyLinux if it is found in +the PATH. The Repo tool will be used to manage the different Git +repositories of the Yocto BSP.

+
+

6.1. Get phyLinux

+

The phyLinux script can be found on the PHYTEC download server: +https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux

+
+
+

6.2. Basic Usage

+

For the basic usage of phyLinux, type

+
host:~$ ./phyLinux --help
+
+
+

which will result in

+
usage: phyLinux [-h] [-v] [--verbose] {init,info,clean} ...
+
+This Programs sets up an environment to work with The Yocto Project on Phytecs
+Development Kits. Use phyLinx <command> -h to display the help text for the
+available commands.
+
+positional arguments:
+  {init,info,clean}  commands
+    init             init the phytec bsp in the current directory
+    info             print info about the phytec bsp in the current directory
+    clean            Clean up the current working directory
+
+optional arguments:
+  -h, --help         show this help message and exit
+  -v, --version      show program's version number and exit
+  --verbose
+
+
+
+
+

6.3. Initialization

+

Create a fresh project folder

+
host:~$ mkdir ~/yocto
+
+
+

Calling phyLinux will use the default Python version. Starting with Ubuntu 20.04 +it will be Python3. If you want to initiate a BSP, which is not compatible with +Python3, you need to set Python2 as default (temporarily) before running +phyLinux

+
host:~$ ln -s \`which python2\` python && export PATH=`pwd`:$PATH
+
+
+

Now run phyLinux from the new folder

+
host:~$ ./phyLinux init
+
+
+

A clean folder is important because phyLinux will clean its working directory. +Calling phyLinux from a directory that isn’t empty will result in the following +warning:

+
This current directory is not empty. It could lead to errors in the BSP configuration
+process if you continue from here. At the very least, you have to check your build directory
+for settings in bblayers.conf and local.conf, which will not be handled correctly in
+all cases. It is advisable to start from an empty directory of call:
+$ ./phyLinux clean
+Do you really want to continue from here?
+[yes/no]:
+
+
+

On the first initialization, the phyLinux script will ask you to install the +Repo tool in your /usr/local/bin directory. During the execution of the +init command, you need to choose your processor platform (SoC), PHYTEC’s BSP +release number, and the hardware you are working on

+
***************************************************
+* Please choose one of the available SoC Platforms:
+*
+*   1: am335x
+*   2: am57x
+*   3: am62ax
+*   4: am62x
+*   5: am64x
+*   6: am68x
+*   7: imx6
+*   8: imx6ul
+*   9: imx7
+*   10: imx8
+*   11: imx8m
+*   12: imx8mm
+*   13: imx8mp
+*   14: imx8x
+*   15: imx93
+*   16: nightly
+*   17: rk3288
+*   18: stm32mp13x
+*   19: stm32mp15x
+*   20: topic
+
+# Exemplary output for chosen imx93
+***************************************************
+* Please choose one of the available Releases:
+*
+*   1: BSP-Yocto-NXP-i.MX93-ALPHA1
+*   2: BSP-Yocto-NXP-i.MX93-PD24.1-rc1
+*   3: BSP-Yocto-NXP-i.MX93-PD24.1.0
+*   4: BSP-Yocto-NXP-i.MX93-PD24.1.1-rc1
+*   5: BSP-Yocto-NXP-i.MX93-PD24.1.1-rc2
+*   6: BSP-Yocto-NXP-i.MX93-PD24.1.1-rc3
+*   7: BSP-Yocto-NXP-i.MX93-PD24.1.1
+
+# Exemplary output for chosen BSP-Yocto-NXP-i.MX93-PD24.1.1
+*********************************************************************
+* Please choose one of the available builds:
+*
+no:                 machine: description and article number
+                             distro: supported yocto distribution
+                             target: supported build target
+
+1: phyboard-nash-imx93-1:  PHYTEC phyBOARD-Nash i.MX93
+                           2 GB RAM, eMMC
+                           PB-04729-001, PCL-077-23231211I
+                           distro: ampliphy-vendor
+                           target: phytec-headless-image
+2: phyboard-nash-imx93-1:  PHYTEC phyBOARD-Nash i.MX93
+                           2 GB RAM, eMMC
+                           PB-04729-001, PCL-077-23231211I
+                           distro: ampliphy-vendor-rauc
+                           target: phytec-headless-bundle
+3: phyboard-nash-imx93-1:  PHYTEC phyBOARD-Nash i.MX93
+                           2 GB RAM, eMMC
+                           PB-04729-001, PCL-077-23231211I
+                           distro: ampliphy-vendor-wayland
+                           target: -c populate_sdk phytec-qt6demo-image
+                           target: phytec-qt6demo-image
+4: phyboard-segin-imx93-2: PHYTEC phyBOARD-Segin i.MX93
+                           1 GB RAM, eMMC, silicon revision A1
+                           PB-02029-001, PCL-077-11231010I
+                           distro: ampliphy-vendor
+                           target: phytec-headless-image
+5: phyboard-segin-imx93-2: PHYTEC phyBOARD-Segin i.MX93
+                           1 GB RAM, eMMC, silicon revision A1
+                           PB-02029-001, PCL-077-11231010I
+                           distro: ampliphy-vendor-rauc
+                           target: phytec-headless-bundle
+6: phyboard-segin-imx93-2: PHYTEC phyBOARD-Segin i.MX93
+                           1 GB RAM, eMMC, silicon revision A1
+                           PB-02029-001, PCL-077-11231010I
+                           distro: ampliphy-vendor-wayland
+                           target: phytec-qt6demo-image
+
+
+

If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. After the configuration is done, +you can always run

+
host:~$ ./phyLinux info
+
+# Exemplary output
+**********************************************
+* The current BSP configuration is:
+*
+* SoC:  refs/heads/imx93
+* Release:  BSP-Yocto-NXP-i.MX93-PD24.1.1
+* Machine:  phyboard-segin-imx93-2
+*
+**********************************************
+
+
+

to see which SoC and Release are selected in the current workspace. If +you do not want to use the selector, phyLinux also supports command-line +arguments for several settings

+
host:~$ MACHINE=phyboard-segin-imx93-2 ./phyLinux init -p imx93 -r BSP-Yocto-NXP-i.MX93-PD24.1.1
+
+
+

or view the help command for more information

+
host:~$ ./phyLinux  init --help
+
+usage: phyLinux init [-h] [--verbose] [--no-init] [-o REPOREPO] [-b REPOREPO_BRANCH] [-x XML] [-u URL] [-p PLATFORM] [-r RELEASE]
+
+options:
+  -h, --help          show this help message and exit
+  --verbose
+  --no-init           dont execute init after fetch
+  -o REPOREPO         Use repo tool from another url
+  -b REPOREPO_BRANCH  Checkout different branch of repo tool
+  -x XML              Use a local XML manifest
+  -u URL              Manifest git url
+  -p PLATFORM         Processor platform
+  -r RELEASE          Release version
+
+
+

After the execution of the init command, phyLinux will print a few important +notes as well as information for the next steps in the build process.

+
+
+

6.4. Advanced Usage

+

phyLinux can be used to transport software states over any medium. The state of +the software is uniquely identified by manifest.xml. You can create a +manifest, send it to another place and recover the software state with

+
host:~$ ./phyLinux init -x manifest.xml
+
+
+

You can also create a Git repository containing your software states. The +Git repository needs to have branches other than master, as we reserved the +master branch for different usage. Use phyLinux to check out the states

+
host:~$ ./phyLinux -u <url-of-your-git-repo>
+
+
+
+
+
+

7. Using build-container

+
+

Warning

+

Currently, it is not possible to run the phyLinux script inside of a container. +After a complete init with the phyLinux script on your host machine, you can use a container for the build. +If you do not have phyLinux script running on your machine, please see phyLinux Documentation.

+
+

There are various possibilities to run a build-container. Commonly used is +docker and podman, though we prefer podman as it does not need root privileges +to run.

+
+

7.1. Installation

+

How to install podman: https://podman.io +How to install docker: https://docs.docker.com/engine/install/

+
+
+

7.2. Available container

+

Right now we provide 4 different container based on Ubuntu LTS versions: +https://hub.docker.com/u/phybuilder

+
    +

  • yocto-ubuntu-16.04

    • +

  • yocto-ubuntu-18.04

    • +

  • yocto-ubuntu-20.04

    • +

  • yocto-ubuntu-22.04

    • +
+

These containers can be run with podman or docker. With Yocto Project branch Mickledore the container “yocto-ubuntu-20.04” is preferred.

+
+
+

7.3. Download/Pull container

+
host:~$ podman pull docker.io/phybuilder/yocto-ubuntu-20.04
+
+OR
+
+host:~$ docker pull docker.io/phybuilder/yocto-ubuntu-20.04
+
+
+

By adding a tag at the end separated by a colon, you can also pull or run a special tagged container.

+
+

podman pull docker.io/phybuilder/yocto-ubuntu-20.04:phy2

+
+

You can find all available tags in our duckerhub space:

+ +

If you try to run a container, which is not pulled/downloaded, it will be pulled/downloaded automatically.

+

You can have a look at all downloaded/pulled container with:

+
$USERNAME@$HOSTNAME:~$ podman images
+REPOSITORY                               TAG         IMAGE ID      CREATED       SIZE
+docker.io/phybuilder/yocto-ubuntu-22.04  latest      d626178e448d  4 months ago  935 MB
+docker.io/phybuilder/yocto-ubuntu-22.04  phy2        d626178e448d  4 months ago  935 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  phy2        e29a88b7172a  4 months ago  900 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  latest      e29a88b7172a  4 months ago  900 MB
+docker.io/phybuilder/yocto-ubuntu-18.04  phy1        14c9c3e477d4  7 months ago  567 MB
+docker.io/phybuilder/yocto-ubuntu-18.04  latest      14c9c3e477d4  7 months ago  567 MB
+docker.io/phybuilder/yocto-ubuntu-16.04  phy1        28c73e13ab4f  7 months ago  599 MB
+docker.io/phybuilder/yocto-ubuntu-16.04  latest      28c73e13ab4f  7 months ago  599 MB
+docker.io/phybuilder/yocto-ubuntu-22.04  phy1        5a0ef4b41935  8 months ago  627 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  phy1        b5a26a86c39f  8 months ago  680 MB
+
+
+
+
+

7.4. Run container

+

To run and use container for a Yocto build, first enter to your folder, where +you run phyLinux init before. Then start the container

+
host:~$ podman run --rm=true -v /home:/home --userns=keep-id --workdir=$PWD -it docker.io/phybuilder/yocto-ubuntu-20.04 bash
+
+
+
+

Note

+

To run and use a container with docker, it is not that simple like with podman. +Therefore the container-user has to be defined and configured. +Furthermore forwarding of credentials is not given per default and has to be configured as well.

+
+

Now your commandline should look something like that (where $USERNAME is the +user, who called “podman run” and the char/number code diffs every time a +container is started)

+
$USERNAME@6593e2c7b8f6:~$
+
+
+
+

Warning

+

If the given username is “root” you will not be able to run bitbake at all. +Please be sure, you run the container with your own user.

+
+

Now you are ready to go on and starting the build. +To stop/close the container, just call

+
$USERNAME@6593e2c7b8f6:~$ exit
+
+
+
+
+
+

8. Working with Poky and Bitbake

+
+

8.1. Start the Build

+

After you download all the metadata with phyLinux init, you have to set up the +shell environment variables. This needs to be done every time you open a new +shell for starting builds. We use the shell script provided by Poky in its +default configuration. From the root of your project directory type

+
host:~$ source sources/poky/oe-init-build-env
+
+
+

The abbreviation for the source command is a single dot

+
host:~$ . sources/poky/oe-init-build-env
+
+
+

The current working directory of the shell should change to build/. Before +building for the first time, you should take a look at the main configuration +file

+
host:~$ vim conf/local.conf
+
+
+

Your local modifications for the current build are stored here. Depending on +the SoC, you might need to accept license agreements. For example, to build the +image for Freescale/NXP processors you need to accept the GPU and VPU binary +license agreements. You have to uncomment the corresponding line

+
# Uncomment to accept NXP EULA # EULA can be found under
+../sources/meta-freescale/EULA ACCEPT_FSL_EULA = "1"
+
+
+

Now you are ready to build your first image. We suggest starting with our +smaller non-graphical image phytec-headless-image to see if everything is +working correctly

+
host:~$ bitbake phytec-headless-image
+
+
+

The first compile process takes about 40 minutes on a modern Intel Core i7. All +subsequent builds will use the filled caches and should take about 3 minutes.

+
+
+

8.2. Images

+

If everything worked, the images can be found under

+
host:~$ cd deploy/images/<MACHINE>
+
+
+

The easiest way to test your image is to configure your board for SD card boot +and to flash the build image to the SD card

+
host:~$ sudo dd if=phytec-headless-image-<MACHINE>.wic of=/dev/<your_device> bs=1M conv=fsync
+
+
+

Here <your_device> could be “sde”, for example, depending on your system. Be +very careful when selecting the right drive! Selecting the wrong drive can +erase your hard drive! The parameter conv=fsync forces a data buffer to write +to the device before dd returns.

+

After booting you can log in using a serial cable or over ssh. There is no +root password. That is because of the debug settings in conf/local.conf. If +you uncomment the line

+
#EXTRA_IMAGE_FEATURES = "debug-tweaks"
+
+
+

the debug settings, like setting an empty root password, will not be applied.

+
+
+

8.3. Accessing the Development States between Releases

+

Special release manifests exist to give you access to the current development +states of the Yocto BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line

+
host:~$ ./phyLinux init -p master -r mickledore
+
+
+

This will initialize a BSP that will track the latest development state. From +now on running

+
host:~$ repo sync
+
+
+

this folder will pull all the latest changes from our Git repositories.

+
+
+

8.4. Inspect your Build Configuration

+

Poky includes several tools to inspect your build layout. You can inspect the +commands of the layer tool

+
host:~$ bitbake-layers
+
+
+

It can, for example, be used to view in which layer a specific recipe gets +modified

+
host:~$ bitbake-layers show-appends
+
+
+

Before running a build you can also launch Toaster to be able to inspect the +build details with the Toaster web GUI

+
host:~$ source toaster start
+
+
+

Maybe you need to install some requirements, first

+
host:~$ pip3 install -r
+../sources/poky/bitbake/toaster-requirements.txt
+
+
+

You can then point your browser to http://0.0.0.0:8000/ and continue working +with Bitbake. All build activity can be monitored and analyzed from this web +server. If you want to learn more about Toaster, look at +https://docs.yoctoproject.org/4.2.4/toaster-manual/index.html. +To shut down the Toaster web GUI again, execute

+
host:~$ source toaster stop
+
+
+
+
+

8.5. BSP Features of meta-phytec and meta-ampliphy

+
+

8.5.1. Buildinfo

+

The buildinfo task is a feature in our recipes that prints instructions to +fetch the source code from the public repositories. So you do not have to look +into the recipes yourself. To see the instructions, e.g. for the barebox +package, execute

+
host:~$ bitbake barebox -c buildinfo
+
+
+

in your shell. This will print something like

+
(mini) HOWTO: Use a local git repository to build barebox:
+
+To get source code for this package and version (barebox-2022.02.0-phy1), execute
+
+$ mkdir -p ~/git
+$ cd ~/git
+$ git clone git://git.phytec.de/barebox barebox
+$ cd ~/git/barebox
+$ git switch --create v2022.02.0-phy1-local-development 7fe12e65d770f7e657e683849681f339a996418b
+
+You now have two possible workflows for your changes:
+
+1. Work inside the git repository:
+Copy and paste the following snippet to your "local.conf":
+
+SRC_URI:pn-barebox = "git://${HOME}/git/barebox;branch=${BRANCH}"
+SRCREV:pn-barebox = "${AUTOREV}"
+BRANCH:pn-barebox = "v2022.02.0-phy1-local-development"
+
+After that you can recompile and deploy the package with
+
+$ bitbake barebox -c compile
+$ bitbake barebox -c deploy
+
+Note: You have to commit all your changes. Otherwise yocto doesn't pick them up!
+
+2. Work and compile from the local working directory
+To work and compile in an external source directory we provide the
+externalsrc.bbclass. To use it, copy and paste the following snippet to your
+"local.conf":
+
+INHERIT += "externalsrc"
+EXTERNALSRC:pn-barebox = "${HOME}/git/barebox"
+EXTERNALSRC_BUILD:pn-barebox = "${HOME}/git/barebox"
+
+Note: All the compiling is done in the EXTERNALSRC directory. Every time
+you build an Image, the package will be recompiled and build.
+
+NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded.
+NOTE: Writing buildhistory
+
+
+

As you can see, everything is explained in the output.

+
+

Warning

+

Using externalsrc breaks a lot of Yocto’s internal dependency +mechanisms. It is not guaranteed that any changes to the source +directory are automatically picked up by the build process and +incorporated into the root filesystem or SD card image. You have to +always use –force. E.g. to compile barebox and redeploy it to +deploy/images/<machine> execute

+
host:~$ bitbake barebox -c compile --force
+host:~$ bitbake barebox -c deploy
+
+
+
+

To update the SD card image with a new kernel or image first force the +compilation of it and then force a rebuild of the root filesystem. Use

+
host:~$ bitbake phytec-qt6demo-image -c rootfs --force
+
+
+

Note that the build system is not modifying the external source directory. If +you want to apply all patches the Yocto recipe is carrying to the external +source directory, run the line

+
SRCTREECOVEREDTASKS="" BB_ENV_PASSTHROUGH_ADDITIONS="$BB_ENV_PASSTHROUGH_ADDITIONS SRCTREECOVEREDTASKS" bitbake <recipe> -c patch
+
+
+
+
+
+

8.6. BSP Customization

+

To get you started with the BSP, we have summarized some basic tasks from the +Yocto official documentation. It describes how to add additional software to +the image, change the kernel and bootloader configuration, and integrate +patches for the kernel and bootloader.

+

Minor modifications, such as adding software, are done in the file +build/conf/local.conf. There you can overwrite global configuration variables +and make small modifications to recipes.

+

There are 2 ways to make major changes:

+
    +

  1. Either create your own layer and use bbappend files.

    2. +

  2. Add everything to PHYTEC’s Distro layer meta-ampliphy.

    3. +
+

Creating your own layer is described in the section Create your own Layer.

+
+

8.6.1. Disable Qt Demo

+

By default, the BSP image phytec-qt6demo-image starts a Qt6 Demo application +on the attached display or monitor. If you want to stop the demo and use the +Linux framebuffer console behind it, connect to the target via serial cable +or ssh and execute the shell command

+
target:~$ systemctl stop phytec-qtdemo.service
+
+
+

This command stops the demo temporarily. To start it again, reboot the +board or execute

+
target:~$ systemctl start phytec-qtdemo.service
+
+
+

You can disable the service permanently, so it does not start on boot

+
target:~$ systemctl disable phytec-qtdemo.service
+
+
+
+

Tip

+

The last command only disables the service. It does not stop immediately. +To see the current status execute

+
target:~$ systemctl status phytec-qtdemo.service
+
+
+
+

If you want to disable the service by default, edit the file +build/conf/local.conf and add the following line

+
# file build/conf/local.conf
+SYSTEMD_AUTO_ENABLE:pn-phytec-qtdemo = "disable"
+
+
+

After that, rebuild the image

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

8.6.2. Framebuffer Console

+

On boards with a display interface, the framebuffer console is enabled per +default. You can attach a USB keyboard and log in. To change the keyboard +layout from the English default to German, type

+
target:~$ loadkeys /usr/share/keymaps/i386/qwertz/de-latin1.map.gz
+
+
+

To detach the framebuffer console, run

+
target:~$ echo 0 > sys/class/vtconsole/vtcon1/bind
+
+
+

To completely deactivate the framebuffer console, disable the following kernel +configuration option

+
Device Drivers->Graphics Support->Support for framebuffer devices->Framebuffer Console Support
+
+
+

More information can be found at: +https://www.kernel.org/doc/Documentation/fb/fbcon.txt

+
+
+

8.6.3. Tools Provided in the Prebuild Image

+
+

8.6.3.1. RAM Benchmark

+

Performing RAM and cache performance tests can best be done by using pmbw +(Parallel Memory Bandwidth Benchmark/Measurement Tool). Pmbw runs several +assembly routines which all use different access patterns to the caches and RAM +of the SoC. Before running the test, make sure that you have about 2 MiB of +space left on the device for the log files. We also lower the level of the +benchmark to ask the kernel more aggressively for resources. The benchmark test +will take several hours.

+

To start the test type

+
target:~$ nice -n -2 pmbw
+
+
+

Upon completion of the test run, the log file can be converted to a gnuplot +script with

+
target:~$ stats2gnuplot stats.txt > run1.gnuplot
+
+
+

Now you can transfer the file to the host machine and install any version of +gnuplot

+
host:~$ sudo apt-get install gnuplot host:~$ gnuplot run1.gnuplot
+
+
+

The generated plots-<machine>.pdf file contains all plots. To render single +plots as png files for any web output you can use Ghostscript

+
host:~$ sudo apt-get install ghostscript
+host:~$ gs -dNOPAUSE -dBATCH -sDEVICE=png16m -r150 -sOutputFile='page-%00d.png' plots-phyboard-wega-am335x-1.pdf
+
+
+
+
+
+

8.6.4. Add Additional Software for the BSP Image

+

To add additional software to the image, look at the OpenEmbedded layer index: +https://layers.openembedded.org/layerindex/branch/mickledore/layers/

+

First, select the Yocto version of the BSP you have from the drop-down list in +the top left corner and click Recipes. Now you can search for a software +project name and find which layer it is in. In some cases, the program is in +meta-openembedded, openembedded-core, or Poky which means that the recipe +is already in your build tree. This section describes how to add additional +software when this is the case. If the package is in another layer, see the next +section.

+

You can also search the list of available recipes

+
host:~$ bitbake -s | grep <program name> # fill in program name, like in
+host:~$ bitbake -s | grep lsof
+
+
+

When the recipe for the program is already in the Yocto build, you can simply +add it by appending a configuration option to your file build/conf/local.conf. +The general syntax to add additional software to an image is

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " <package1> <package2>"
+
+
+

For example, the line

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " ldd strace file lsof"
+
+
+

installs some helper programs on the target image.

+
+

Warning

+

The leading whitespace is essential for the append command.

+
+

All configuration options in local.conf apply to all images. Consequently, the +tools are now included in both images phytec-headless-image and +phytec-qt6demo-image.

+
+

8.6.4.1. Notes about Packages and Recipes

+

You are adding packages to the IMAGE_INSTALL variable. Those are not necessarily +equivalent to the recipes in your meta-layers. A recipe defines per default a +package with the same name. But a recipe can set the PACKAGES variable to +something different and is able to generate packages with arbitrary names. +Whenever you look for software, you have to search for the package name and, +strictly speaking, not for the recipe. In the worst case, you have to look at +all PACKAGES variables. A tool such as Toaster can be helpful in some cases.

+

If you can not find your software in the layers provided in the folder +sources, see the next section to include another layer into the Yocto +build.

+

References: Yocto 4.2.4 Documentation - Customizing Yocto builds

+
+
+
+

8.6.5. Add an Additional Layer

+

This is a step-by-step guide on how to add another layer to your Yocto build +and install additional software from it. As an example, we include the network +security scanner nmap in the layer meta-security. First, you must locate the +layer on which the software is hosted. Check out the OpenEmbedded MetaData +Index +and guess a little bit. The network scanner nmap is in the meta-security +layer. See meta-security on layers.openembedded.org. +To integrate it into the Yocto build, you have to check out the repository and +then switch to the correct stable branch. Since the BSP is based on the Yocto +‘sumo’ build, you should try to use the ‘sumo’ branch in the layer, too.

+
host:~$ cd sources
+host:~$ git clone git://git.yoctoproject.org/meta-security
+host:~$ cd meta-security
+host:~$ git branch -r
+
+
+

All available remote branches will show up. Usually there should be ‘fido’, +‘jethro’, ‘krogoth’, ‘master’, …

+
host:~$ git checkout mickledore
+
+
+

Now we add the directory of the layer to the file build/conf/bblayers.conf by +appending the line

+
# file build/conf/bblayers.conf
+BBLAYERS += "${BSPDIR}/sources/meta-security"
+
+
+

to the end of the file. After that, you can check if the layer is available in +the build configuration by executing

+
host:~$ bitbake-layers show-layers
+
+
+

If there is an error like

+
ERROR: Layer 'security' depends on layer 'perl-layer', but this layer is not enabled in your configuration
+
+
+

the layer that you want to add (here meta-security), depends on another layer, +which you need to enable first. E.g. the dependency required here is a layer in +meta-openembedded (in the PHYTEC BSP it is in the path +sources/meta-openembedded/meta-perl/). To enable it, add the following line to +build/conf/bblayers.conf

+
# file build/conf/bblayers.conf
+BBLAYERS += "${BSPDIR}/sources/meta-openembedded/meta-perl"
+
+
+

Now the command bitbake-layers show-layers should print a list of all layers +enabled including meta-security and meta-perl. After the layer is included, +you can install additional software from it as already described above. The +easiest way is to add the following line (here is the package nmap)

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " nmap"
+
+
+

to your build/conf/local.conf. Do not forget to rebuild the image

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

8.6.6. Create your own layer

+

Creating your layer should be one of the first tasks when customizing the BSP. +You have two basic options. You can either copy and rename our meta-ampliphy, +or you can create a new layer that will contain your changes. The better option +depends on your use case. meta-ampliphy is our example of how to create a +custom Linux distribution that will be updated in the future. If you want to +benefit from those changes and are, in general, satisfied with the userspace +configuration, it could be the best solution to create your own layer on top of +Ampliphy. If you need to rework a lot of information and only need the basic +hardware support from PHYTEC, it would be better to copy meta-ampliphy, rename +it, and adapt it to your needs. You can also have a look at the OpenEmbedded +layer index to find different distribution layers. If you just need to add your +own application to the image, create your own layer.

+

In the following chapter, we have an embedded project called “racer” which we +will implement using our Ampliphy Linux distribution. First, we need to create +a new layer.

+

Yocto provides a script for that. If you set up the BSP and the shell is +ready, type

+
host:~$ bitbake-layers create-layer meta-racer
+
+
+

Default options are fine for now. Move the layer to the source directory

+
host:~$ mv meta-racer ../sources/
+
+
+

Create a Git repository in this layer to track your changes

+
host:~$ cd ../sources/meta-racer
+host:~$ git init && git add . && git commit -s
+
+
+

Now you can add the layer directly to your build/conf/bblayers.conf

+
BBLAYERS += "${BSPDIR}/sources/meta-racer"
+
+
+

or with a script provided by Yocto

+
host:~$ bitbake-layers add-layer meta-racer
+
+
+
+
+

8.6.7. Kernel and Bootloader Recipe and Version

+

First, you need to know which kernel and version are used for your target +machine. PHYTEC provides multiple kernel recipes linux-mainline, linux-ti +and linux-imx. The first one provides support for PHYTEC’s i.MX 6 and AM335x +modules and is based on the Linux kernel stable releases from kernel.org. +The Git repositories URLs are:

+
    +

  • linux-mainline: git://git.phytec.de/linux-mainline

    • +

  • linux-ti: git://git.phytec.de/linux-ti

    • +

  • linux-imx: git://git.phytec.de/linux-imx

    • +

  • barebox: git://git.phytec.de/barebox

    • +

  • u-boot-imx: git://git.phytec.de/u-boot-imx

    • +
+

To find your kernel provider, execute the following command

+
host:~$ bitbake virtual/kernel -e | grep "PREFERRED_PROVIDER_virtual/kernel"
+
+
+

The command prints the value of the variable +PREFERRED_PROVIDER_virtual/kernel. The variable is used in the internal +Yocto build process to select the kernel recipe to use. The following lines +are different outputs you might see

+
PREFERRED_PROVIDER_virtual/kernel="linux-mainline"
+PREFERRED_PROVIDER_virtual/kernel="linux-ti"
+PREFERRED_PROVIDER_virtual/kernel="linux-imx"
+
+
+

To see which version is used, execute bitbake -s. For example

+
host:~$ bitbake -s | egrep -e "linux-mainline|linux-ti|linux-imx|barebox|u-boot-imx"
+
+
+

The parameter -s prints the version of all recipes. The output contains the +recipe name on the left and the version on the right

+
barebox                      :2022.02.0-phy1-r7.0
+barebox-hosttools-native     :2022.02.0-phy1-r7.0
+barebox-targettools          :2022.02.0-phy1-r7.0
+linux-mainline               :5.15.102-phy1-r0.0
+
+
+

As you can see, the recipe linux-mainline has version 5.15.102-phy1. In +the PHYTEC’s linux-mainline Git repository, you will find a corresponding +tag v5.15.102-phy1. The version of the barebox recipe is 2022.02.0-phy1. +On i.MX8M* modules the output will contain linux-imx and u-boot-imx.

+
+
+

8.6.8. Kernel and Bootloader Configuration

+

The bootloader used by PHYTEC, barebox, uses the same build system as the +Linux kernel. Therefore, all commands in this section can be used to configure +the kernel and bootloader. To configure the kernel or bootloader, execute one of +the following commands

+
host:~$ bitbake -c menuconfig virtual/kernel  # Using the virtual provider name
+host:~$ bitbake -c menuconfig linux-ti        # Or use the recipe name directly
+host:~$ bitbake -c menuconfig linux-mainline  # Or use the recipe name directly (If you use an i.MX 6 or RK3288 Module)
+host:~$ bitbake -c menuconfig linux-imx       # Or use the recipe name directly (If you use an i.MX 8M*)
+host:~$ bitbake -c menuconfig barebox         # Or change the configuration of the bootloader
+host:~$ bitbake -c menuconfig u-boot-imx      # Or change the configuration of the bootloader (If you use an i.MX 8M*)
+
+
+

After that, you can recompile and redeploy the kernel or bootloader

+
host:~$ bitbake virtual/kernel -c compile  # Or 'barebox' for the bootloader
+host:~$ bitbake virtual/kernel -c deploy   # Or 'barebox' for the bootloader
+
+
+

Instead, you can also just rebuild the complete build output with

+
host:~$ bitbake phytec-headless-image  # To update the kernel/bootloader, modules and the images
+
+
+

In the last command, you can replace the image name with the name of an image of +your choice. The new images and binaries are in +build/deploy/images/<machine>/.

+
+

Warning

+

The build configuration is not permanent yet. Executing bitbake +virtual/kernel -c clean will remove everything.

+
+

To make your changes permanent in the build system, you have to integrate your +configuration modifications into a layer. For the configuration you have two +options:

+
    +

  • Include only a configuration fragment (a minimal diff between the +old and new configuration)

    • +

  • Complete default configuration (defconfig) after your +modifications.

    • +
+

Having a set of configuration fragments makes what was changed at which stage +more transparent. You can turn on and off the changes, you can manage +configurations for different situations and it helps when porting changes to new +kernel versions. You can also group changes together to reflect specific use +cases. A fully assembled kernel configuration will be deployed in the directory +build/deploy/images/<machine>. If you do not have any of those requirements, +it might be simpler to just manage a separate defconfig file.

+
+

8.6.8.1. Add a Configuration Fragment to a Recipe

+

The following steps can be used for both kernel and bootloader. Just replace the +recipe name linux-mainline in the commands with linux-ti, or barebox for +the bootloader. If you did not already take care of this, start with a clean +build. Otherwise, the diff of the configuration may be wrong

+
host:~$ bitbake linux-mainline -c clean
+host:~$ bitbake linux-mainline -c menuconfig
+
+
+

Make your configuration changes in the menu and generate a config +fragment

+
host:~$ bitbake linux-mainline -c diffconfig
+
+
+

which prints the path of the written file

+
Config fragment has been dumped into:
+/home/<path>/build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg
+
+
+

All config changes are in the file fragment.cfg which should consist of only +some lines. The following example shows how to create a bbappend file and how +to add the necessary lines for the config fragment. You just have to adjust the +directories and names for the specific recipe: linux-mainline, linux-ti, +linux-imx, u-boot-imx, or barebox.

+
sources/<layer>/recipes-kernel/linux/linux-mainline_%.bbappend     # For the recipe linux-mainline
+sources/<layer>/recipes-kernel/linux/linux-ti_%.bbappend           # For the recipe linux-ti
+sources/<layer>/recipes-kernel/linux/linux-imx_%.bbappend          # For the recipe linux-imx
+sources/<layer>/recipes-bsp/barebox/barebox_%.bbappend             # For the recipe barebox
+sources/<layer>/recipes-bsp/u-boot/u-boot-imx_%.bbappend           # For the recipe u-boot-imx
+
+
+

Replace the string layer with your own layer created as shown above (e.g. +meta-racer), or just use meta-ampliphy. To use meta-ampliphy, first, +create the directory for the config fragment and give it a new name (here +enable-r8169.cfg) and move the fragment to the layer.

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features
+# copy the path from the output of *diffconfig*
+host:~$ cp /home/<path>/build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg \
+    sources/meta-ampliphy/recipes-kernel/linux/features/enable-r8169.cfg
+
+
+

Then open the bbappend file (in this case +sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend ) with +your favorite editor and add the following lines

+
# contents of the file linux-mainline_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://enable-r8169.cfg \
+"
+
+
+
+

Warning

+

Do not forget to use the correct bbappend filenames: linux-ti_%.bbappend +for the linux-ti recipe and barebox_%.bbappend for the bootloader in the +folder recipes-bsp/barebox/ !

+
+

After saving the bbappend file, you have to rebuild the image. Yocto should +pick up the recipe changes automatically and generate a new image

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+
+
+

8.6.8.2. Add a Complete Default Configuration (defconfig) to a Recipe

+

This approach is similar to the one above, but instead of adding a fragment, a +defconfig is used. First, create the necessary folders in the layer you want +to use, either your own layer or meta-ampliphy

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features/ # For both linux-mainline and linux-ti
+host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features/ # Or for the bootloader
+
+
+

Then you have to create a suitable defconfig file. Make your configuration +changes using menuconfig and then save the defconfig file to the layer

+
host:~$ bitbake linux-mainline -c menuconfig # Or use recipe name linux-ti or barebox
+host:~$ bitbake linux-mainline -c savedefconfig # Create file 'defconfig.temp' in the work directory
+
+
+

This will print the path to the generated file

+
Saving defconfig to ..../defconfig.temp
+
+
+

Then, as above, copy the generated file to your layer, rename it to defconfig, +and add the following lines to the bbappend file (here +sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend)

+
# contents of the file linux-mainline_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://defconfig \
+"
+
+
+
+

Tip

+

Do not forget to use the correct bbappend filenames: linux-ti_%.bbappend +for the linux-ti recipe and barebox_%.bbappend for the bootloader in the +folder recipes-bsp/barebox/ !

+
+

After that, rebuild your image as the changes are picked up automatically

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+
+
+
+

8.6.9. Patch the Kernel or Bootloader with devtool

+

Apart from using the standard versions of kernel and bootloader which are +provided in the recipes, you can modify the source code or use our own +repositories to build your customized kernel.

+ + + + + + + + + + + + +

PRO

CON

Standard workflow of the +official Yocto documentation

Uses additional hard drive space +as the sources get duplicated

Toolchain does not have to +recompile everything

No optimal cache usage, build +overhead

+

Devtool is a set of helper scripts to enhance the user workflow of Yocto. It +was integrated with version 1.8. It is available as soon as you set up your +shell environment. Devtool can be used to:

+
    +

  • modify existing sources

    • +

  • integrate software projects into your build setup

    • +

  • build software and deploy software modifications to your target

    • +
+

Here we will use devtool to patch the kernel. We use linux-mainline as an +example for the AM335x Kernel. The first command we use is devtool modify - x +<recipe> <directory>

+
host:~$ devtool modify -x linux-mainline linux-mainline
+
+
+

Devtool will create a layer in build/workspace where you can see all +modifications done by devtool . It will extract the sources corresponding to +the recipe to the specified directory. A bbappend will be created in the +workspace directing the SRC_URI to this directory. Building an image with +Bitbake will now use the sources in this directory. Now you can modify lines +in the kernel

+
host:~$ vim linux-mainline/arch/arm/boot/dts/am335x-phycore-som.dtsi
+      -> make a change
+host:~$ bitbake phytec-qt6demo-image
+
+
+

Your changes will now be recompiled and added to the image. If you want to store +your changes permanently, it is advisable to create a patch from the changes, +then store and backup only the patch. You can go into the linux-mainline +directory and create a patch using Git. How to create a patch is described in +Patch the Kernel or Bootloader using the “Temporary Method” and is the same for all methods.

+

If you want to learn more about devtool, visit:

+

Yocto 4.2.4 - Devtool +or Devtool Quick Reference

+
+
+

8.6.10. Patch the Kernel or Bootloader using the “Temporary Method”

+ + + + + + + + + + + + +

PRO

CON

No overhead, no extra +configuration

Changes are easily overwritten +by Yocto (Everything is +lost!!).

Toolchain does not have to +recompile everything

+

It is possible to alter the source code before Bitbake configures and compiles +the recipe. Use Bitbake’ s devshell command to jump into the source +directory of the recipe. Here is the barebox recipe

+
host:~$ bitbake barebox -c devshell # or linux-mainline, linux-ti, linux-imx, u-boot-imx
+
+
+

After executing the command, a shell window opens. The current working directory +of the shell will be changed to the source directory of the recipe inside the +tmp folder. Here you can use your favorite editor, e.g. vim, emacs, or any +other graphical editor, to alter the source code. When you are finished, exit +the devshell by typing exit or hitting CTRL-D.

+

After leaving the devshell you can recompile the package

+
host:~$ bitbake barebox -c compile --force # or linux-mainline, linux-ti, linux-imx, u-boot-imx
+
+
+

The extra argument ‘–force’ is important because Yocto does not recognize +that the source code was changed.

+
+

Tip

+

You cannot execute the bitbake command in the devshell . You have +to leave it first.

+
+

If the build fails, execute the devshell command again and fix it. If the build +is successful, you can deploy the package and create a new SD card image

+
host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox.bin
+host:~$ bitbake phytec-headless-image # new WIC image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic
+
+
+
+

Warning

+

If you execute a clean e.g bitbake barebox -c clean , or if Yocto fetches +the source code again, all your changes are lost!!!

+

To avoid this, you can create a patch and add it to a bbappend file. It is +the same workflow as described in the section about changing the +configuration.

+

You have to create the patch in the devshell if you use the temporary +method and in the subdirectory created by devtool if you used devtool.

+
+
host:~$ bitbake barebox -c devshell            # Or linux-mainline, linux-ti
+host(devshell):~$ git status                   # Show changes files
+host(devshell):~$ git add <file>               # Add a special file to the staging area
+host(devshell):~$ git commit -m "important modification"   # Creates a commit with a not so useful commit message
+host(devshell):~$ git format-patch -1 -o ~/    # Creates a patch of the last commit and saves it in your home folder
+/home/<user>/0001-important-modification.patch  # Git prints the path of the written patch file
+host(devshell):~$ exit
+
+
+

After you have created the patch, you must create a bbappend file for it. The +locations for the three different recipes - linux-mainline , linux-ti , and +barebox - are

+
sources/<layer>/recipes-kernel/linux/linux-mainline_%.bbappend     # For the recipe linux-mainline
+sources/<layer>/recipes-kernel/linux/linux-ti_%.bbappend           # For the recipe linux-ti
+sources/<layer>/recipes-kernel/linux/linux-imx_%.bbappend        # For the recipe linux-imx
+sources/<layer>/recipes-bsp/barebox/barebox_%.bbappend             # For the recipe barebox
+sources/<layer>/recipes-bsp/u-boot/u-boot-imx_%.bbappend           # For the recipe u-boot-imx
+
+
+

The following example is for the recipe barebox. You have to adjust the paths. +First, create the folders and move the patch into them. Then create the +bbappend file

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features   # Or use your own layer instead of *meta-ampliphy*
+host:~$ cp ~/0001-important-modification.patch sources/meta-ampliphy/recipes-bsp/barebox/features  # copy patch
+host:~$ touch sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend
+
+
+
+

Tip

+

Pay attention to your current work directory. You have to execute the +commands in the BSP top-level directory. Not in the build directory!

+
+

After that use your favorite editor to add the following snipped into the +bbappend file (here +sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend)

+
# contents of the file barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://0001-important-modification.patch \
+"
+
+
+

Save the file and rebuild the barebox recipe with

+
host:~$ bitbake barebox -c clean # Or linux-ti, linux-mainline, linux-imx, u-boot-imx
+host:~$ bitbake barebox
+
+
+

If the build is successful, you can rebuild the final image with

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+

Further Resources:

+

The Yocto Project has some documentation for software developers. Check the +‘Kernel Development Manual’ for more information about how to configure the +kernel. Please note that not all of the information from the Yocto manual can +be applied to the PHYTEC BSP as we use the classic kernel approach of Yocto +and most of the documentation assumes the Yocto kernel approach.

+ +
+
+

8.6.11. Working with the Kernel and Bootloader using SRC_URI in local.conf

+

Here we present a third option to make kernel and bootloader changes. You have +external checkouts of the linux-mainline, linux-ti, or barebox Git +repositories. You will overwrite the URL of the source code fetcher, the +variable SRC_URI, to point to your local checkout instead of the remote +repositories.

+ + + + + + + + + + + + + + + +

PRO

CON

All changes are saved with +Git

Many working directories in +build/tmp-glibc/work/<machine>/<package>/

You have to commit every change +before recompiling

For each change, the toolchain +compiles everything from scratch +(avoidable with ccache)

+

First, you need a local clone of the Git repository barebox or +kernel. If you do not have one, use the commands

+
host:~$ mkdir ~/git
+host:~$ cd ~/git
+host:~$ git clone git://git.phytec.de/barebox
+host:~$ cd barebox
+host:~$ git switch --create v2022.02.0-phy remotes/origin/v2022.02.0-phy
+
+
+

Add the following snippet to the file build/conf/local.conf

+
# Use your own path to the git repository
+# NOTE: Branch name in variable "BRANCH_pn-barebox" should be the same as the
+# branch which is used in the repository folder. Otherwise your commits won't be recognized later.
+BRANCH:pn-barebox = "v2022.02.0-phy"
+SRC_URI:pn-barebox = "git:///${HOME}/git/barebox;branch=${BRANCH}"
+SRCREV:pn-barebox = "${AUTOREV}"
+
+
+

You also have to set the correct BRANCH name in the file. Either you create your +own branch in the Git repository, or you use the default (here +“v2015.02.0-phy”). Now you should recompile barebox from your own source

+
host:~$ bitbake barebox -c clean
+host:~$ bitbake barebox -c compile
+
+
+

The build should be successful because the source was not changed yet.

+

You can alter the source in ~/git/barebox or the default defconfig (e.g. +~/git/barebox/arch/arm/configs/imx_v7_defconfig). After you are satisfied with +your changes, you have to make a dummy commit for Yocto. If you do not, +Yocto will not notice that the source code was modified in your repository +folder (e.g. ~/git/barebox/)

+
host:~$ git status  # show modified files
+host:~$ git diff    # show changed lines
+host:~$ git commit -a -m "dummy commit for yocto"   # This command is important!
+
+
+

Try to compile your new changes. Yocto will automatically notice that the +source code was changed and fetches and configures everything from scratch.

+
host:~$ bitbake barebox -c compile
+
+
+

If the build fails, go back to the source directory, fix the problem, and +recommit your changes. If the build was successful, you can deploy barebox and +even create a new SD card image.

+
host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox-phyflex-imx6-2.bin
+host:~$ bitbake phytec-headless-image # new sd-card image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic
+
+
+

If you want to make additional changes, just make another commit in the +repository and rebuild barebox again.

+
+
+

8.6.12. Add Existing Software with “Sustainable Method”

+

Now that you have created your own layer, you have a second option to add +existing software to existing image definitions. Our standard image is defined +in meta-ampliphy

+
meta-ampliphy/recipes-images/images/phytec-headless-image.bb
+
+
+

In your layer, you can now modify the recipe with a bbappend without modifying +any BSP code

+
meta-racer/recipes-images/images/phytec-headless-image.bbappend
+
+
+

The append will be parsed together with the base recipe. As a result, you can +easily overwrite all variables set in the base recipe, which is not always what +you want. If we want to include additional software, we need to append it to the +IMAGE_INSTALL variable

+
IMAGE_INSTALL:append = " rsync"
+
+
+
+
+

8.6.13. Add Linux Firmware Files to the Root Filesystem

+

It is a common task to add an extra firmware file to your root filesystem into +/lib/firmware/. For example, WiFi adapters or PCIe Ethernet cards might need +proprietary firmware. As a solution, we use a bbappend in our layer. To create +the necessary folders, bbappend and copy the firmware file type

+
host:~$ cd meta-racer   # go into your layer
+host:~$ mkdir -p recipes-kernel/linux-firmware/linux-firmware/
+host:~$ touch recipes-kernel/linux-firmware/linux-firmware_%.bbappend
+host:~$ cp ~/example-firmware.bin recipes-kernel/linux-firmware/linux-firmware/    # adapt filename
+
+
+

Then add the following content to the bbappend file and replace every +occurrence of example-firmware.bin with your firmware file name.

+
# file recipes-kernel/linux-firmware/linux-firmware_%.bbappend
+
+FILESEXTRAPATHS:prepend := "${THISDIR}/linux-firmware:"
+SRC_URI += "file://example-firmware.bin"
+
+do_install:append () {
+        install -m 0644 ${WORKDIR}/example-firmware.bin ${D}/lib/firmware/example-firmware.bin
+}
+
+# NOTE: Use "=+" instead of "+=". Otherwise file is placed into the linux-firmware package.
+PACKAGES =+ "${PN}-example"
+FILES:${PN}-example = "/lib/firmware/example-firmware.bin"
+
+
+

Now try to build the linux-firmware recipe

+
host:~$ . sources/poky/oe-init-build-env
+host:~$ bitbake linux-firmware
+
+
+

This should generate a new package deploy/ipk/all/linux-firmware-example.

+

As the final step, you have to install the firmware package to your image. You +can do that in your local.conf or image recipe via

+
# file local.conf or image recipe
+IMAGE_INSTALL += "linux-firmware-example"
+
+
+
+

Warning

+

Ensure that you have adapted the package name linux-firmware-example with +the name you assigned in linux-firmware_%.bbappend.

+
+
+
+

8.6.14. Change the u-boot Environment via bbappend Files

+

All i.MX8M* products use the u-boot bootloader. The u-boot environment can be +modified using the Temporary Method. In the u-boot-imx sources modify the +header file corresponding to the processor located in +include/configs/phycore_imx8m*. New environment variables should be added at +the end of CONFIG_EXTRA_ENV_SETTINGS

+
#define CONFIG_EXTRA_ENV_SETTINGS \
+[...]
+PHYCORE_FITIMAGE_ENV_BOOTLOGIC \
+"newvariable=1\0"
+
+
+

Commit the changes and and create the file u-boot-imx_%.bbappend in your layer +at <layer>/recipes-bsp/u-boot/u-boot-imx_%.bbappend

+
# contents of the file u-boot-imx_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://0001-environment-addition.patch \
+"
+
+
+
+
+

8.6.15. Change the barebox Environment via bbappend Files

+

Since BSP-Yocto-AM335x-16.2.0 and BSP-Yocto-i.MX6-PD16.1.0, the barebox +environment handling in meta-phytec has changed. Now it is possible to add, +change, and remove files in the barebox environment via the Python bitbake +task do_env. There are two Python functions to change the environment. Their +signatures are:

+
    +

  • env_add(d, ***filename as string*, ***file content as string*): +to add a new file or overwrite an existing file

    • +

  • env_rm(d, ***filename as string*): to remove a file

    • +
+

The first example of a bbappend file in the custom layer meta-racer shows +how to add a new non-volatile variable linux.bootargs.fb in the barebox +environment folder /env/nv/

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_add(d, "nv/linux.bootargs.fb", "imxdrm.legacyfb_depth=32\n")
+}
+
+
+

The next example shows how to replace the network configuration file +/env/network/eth0

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_add(d, "network/eth0",
+"""#!/bin/sh
+
+# ip setting (static/dhcp)
+ip=static
+global.dhcp.vendor_id=barebox-${global.hostname}
+
+# static setup used if ip=static
+ipaddr=192.168.178.5
+netmask=255.255.255.0
+gateway=192.168.178.1
+serverip=192.168.178.1
+""")
+}
+
+
+

In the above example, the Python multiline string syntax “”” text “”” is +used to avoid adding multiple newline characters \n into the recipe Python +code. The Python function env_add can add and overwrite environment files.

+

The next example shows how to remove an already added environment file, for +example , /env/boot/mmc

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_rm(d, "boot/mmc")
+}
+
+
+
+

8.6.15.1. Debugging the Environment

+

If you want to see all environment files that are added in the build process, +you can enable a debug flag in the local.conf

+
# file local.conf
+ENV_VERBOSE = "1"
+
+
+

After that, you have to rebuild the barebox recipe to see the debugging +output

+
host:~$ bitbake barebox -c clean
+host:~$ bitbake barebox -c configure
+
+
+

The output of the last command looks like this

+
[...]
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/allow_color' content "false"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.base' content "consoleblank=0"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.fb' content "imxdrm.legacyfb_depth=32"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.rootfs' content "rootwait ro fsck.repair=yes"
+
+
+
+
+

8.6.15.2. Changing the Environment (depending on Machines)

+

If you need to apply some barebox environment modifications only to a single +or only a few machines, you can use Bitbake’ s machine overwrite syntax. For +the machine overwrite syntax, you append a machine name or SoC name (such as +mx6 , ti33x, or rk3288 ) with an underscore to a variable or task

+
DEPENDS:remove:mx6 = "virtual/libgl" or
+python do_env_append_phyboard-mira-imx6-4().
+
+
+

The next example adds the environment variables only if the MACHINE is set to +phyboard-mira-imx6-4

+
# file meta-phytec/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append:phyboard-mira-imx6-4() {
+    env_add(d, "nv/linux.bootargs.cma", "cma=64M\n")
+}
+
+
+

Bitbake’s override syntax for variables is explained in more detail at: +https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-metadata.html#conditional-metadata

+
+
+

8.6.15.3. Upgrading the barebox Environment from Previous BSP Releases

+

Prior to BSP version BSP-Yocto-AM335x-16.2.0 and BSP-Yocto-i.MX6-PD16.1.0 , +barebox environment changes via bbappend file were done differently. For +example, the directory structure in your meta layer (here meta-skeleton ) may +have looked like this

+
host:~$ tree -a sources/meta-skeleton/recipes-bsp/barebox/
+sources/meta-skeleton/recipes-bsp/barebox
+├── barebox
+│   └── phyboard-wega-am335x-3
+│       ├── boardenv
+│       │   └── .gitignore
+│       └── machineenv
+│           └── nv
+│               └── linux.bootargs.cma
+└── barebox_%.bbappend
+
+
+

and the file barebox_%.bbappend contained

+
# file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:"
+
+
+

In this example, all environment changes from the directory boardenv in the +layer meta-phytec are ignored and the file nv/linux.bootargs.cma is added. +For the new handling of the barebox environment, you use the Python +functions env_add and env_rm in the Python task do_env. Now the above +example translates to a single Python function in the file +barebox_%.bbappend that looks like

+
# file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:"
+python do_env:append() {
+    # Removing files (previously boardenv)
+    env_rm(d, "config-expansions")
+    # Adding new files (previously machineenv)
+    env_add(d, "nv/linux.bootargs.cma", "cma=64M\n")
+}
+
+
+
+
+
+

8.6.16. Changing the Network Configuration

+

To tweak IP addresses, routes, and gateways at runtime you can use the tools +ifconfig and ip . Some examples

+
target:~$ ip addr                                         # Show all network interfaces
+target:~$ ip route                                        # Show all routes
+target:~$ ip addr add 192.168.178.11/24 dev eth0          # Add static ip and route to interface eth0
+target:~$ ip route add default via 192.168.178.1 dev eth0 # Add default gateway 192.168.178.1
+target:~$ ip addr del 192.168.178.11/24 dev eth0          # Remove static ip address from interface eth0
+
+
+

The network configuration is managed by systemd-networkd . To query the +current status use

+
target:~$ networkctl status
+target:~$ networkctl list
+
+
+

The network daemon reads its configuration from the directories +/etc/systemd/network/ , /run/systemd/network/ , and /lib/systemd/network/ +(from higher to lower priority). A sample configuration in +/lib/systemd/network/10-eth0.network looks like this

+
# file /lib/systemd/network/10-eth0.network
+[Match]
+Name=eth0
+
+[Network]
+Address=192.168.3.11/24
+Gateway=192.168.3.10
+
+
+

These files *.network replace /etc/network/interfaces from other +distributions. You can either edit the file 10-eth0.network in-place or copy +it to /etc/systemd/network/ and make your changes there. After changing a file +you must restart the daemon to apply your changes

+
target:~$ systemctl restart systemd-networkd
+
+
+

To see the syslog message of the network daemon, use

+
target:~$ journalctl --unit=systemd-networkd.service
+
+
+

To modify the network configuration at build time, look at the recipe +sources/meta-ampliphy/recipes-core/systemd/systemd-machine-units.bb +and the interface files in the folder +meta-ampliphy/recipes-core/systemd/systemd-machine-units/ where the static IP +address configuration for eth0 (and optionally eth1) is done.

+

For more information, see https://wiki.archlinux.org/title/Systemd-networkd +and https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html.

+
+
+

8.6.17. Changing the Wireless Network Configuration

+
+

8.6.17.1. Connecting to a WLAN Network

+
    +

  • First set the correct regulatory domain for your country

    • +
+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

You will see

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+
    +

  • Set up the wireless interface

    • +
+
target:~$ ip link    # list all interfaces. Search for wlan*
+target:~$ ip link set up dev wlan0
+
+
+
    +

  • Now you can scan for available networks

    • +
+
target:~$ iw wlan0 scan | grep SSID
+
+
+

You can use a cross-platform supplicant with support for WEP, WPA, and +WPA2 called wpa_supplicant for an encrypted connection.

+
    +

  • To do so, add the network credentials to the file +/etc/wpa_supplicant.conf

    • +
+
Confluence country=DE network={ ssid="<SSID>" proto=WPA2 psk="<KEY>" }
+
+
+
    +

  • Now a connection can be established

    • +
+
target:~$ wpa_supplicant -Dnl80211 -c/etc/wpa_supplicant.conf -iwlan0 -B
+
+
+

This should result in the following output

+
ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see the section Changing the Network Configuration.

+
    +

  • First, create the directory

    • +
+
target:~$ mkdir -p /etc/systemd/network/
+
+
+
    +

  • Then add the following configuration snippet in +/etc/systemd/network/10-wlan0.network

    • +
+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+
    +

  • Now, restart the network daemon so that the configuration takes effect

    • +
+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+

8.6.17.2. Creating a WLAN Access Point

+

This section provides a basic access point (AP) configuration for a +secured WPA2 network.

+

Find the name of the WLAN interface with

+
target:~$ ip link
+
+
+

Edit the configuration in /etc/hostapd.conf. It is strongly dependent on +the use case. The following shows an example

+
# file /etc/hostapd.conf
+interface=wlan0
+driver=nl80211
+ieee80211d=1
+country_code=DE
+hw_mode=g
+ieee80211n=1
+ssid=Test-Wifi
+channel=2
+wpa=2
+wpa_passphrase=12345678
+wpa_key_mgmt=WPA-PSK
+wpa_pairwise=CCMP
+
+
+

Set up and start the DHCP server for the network interface wlan0 via +systemd-networkd

+
target:~$ mkdir -p /etc/systemd/network/
+target:~$ vi /etc/systemd/network/10-wlan0.network
+
+
+

Insert the following text into the file

+
[Match]
+Name=wlan0
+
+[Network]
+Address=192.168.0.1/24
+DHCPServer=yes
+
+[DHCPServer]
+EmitDNS=yes
+target:~$ systemctl restart systemd-networkd
+target:~$ systemctl status  systemd-networkd -l   # check status and see errors
+
+
+

Start the userspace daemon hostapd

+
target:~$ systemctl start hostapd
+target:~$ systemctl status hostapd -l # check for errors
+
+
+

Now, you should see the WLAN network Test-Wifi on your terminal device +(laptop, smartphone, etc.).

+

If there are problems with the access point, you can either check the log +messages with

+
target:~$ journalctl --unit=hostapd
+
+
+

or start the daemon in debugging mode from the command line

+
target:~$ systemctl stop hostapd
+target:~$ hostapd -d /etc/hostapd.conf -P /var/run/hostapd.pid
+
+
+

You should see

+
...
+wlan0: interface state UNINITIALIZED->ENABLED
+wlan0: AP-ENABLED
+
+
+

Further information about AP settings and the userspace daemon +hostapd can be found at

+
https://wireless.wiki.kernel.org/en/users/documentation/hostapd
+https://w1.fi/hostapd/
+
+
+
+
+

8.6.17.3. phyCORE-i.MX 6UL/ULL Bluetooth

+

Special consideration must be paid when working with any Bluetooth on a +phyCORE-i.MX 6UL/ULL. For further information, please check L-844e.A5 i.MX +6UL/ULL BSP Manual - Bluetooth.

+
+
+
+

8.6.18. Add OpenCV Libraries and Examples

+

OpenCV (Opensource Computer Vision https://opencv.org/) is an open-source +library for computer vision applications.

+

To install the libraries and examples edit the file conf/local.conf in the +Yocto build system and add

+
# file conf/local.conf
+# Installing OpenCV libraries and examples
+LICENSE_FLAGS_ACCEPTED += "commercial_libav"
+LICENSE_FLAGS_ACCEPTED += "commercial_x264"
+IMAGE_INSTALL:append = " \
+    opencv \
+    opencv-samples \
+    libopencv-calib3d2.4 \
+    libopencv-contrib2.4 \
+    libopencv-core2.4 \
+    libopencv-flann2.4 \
+    libopencv-gpu2.4 \
+    libopencv-highgui2.4 \
+    libopencv-imgproc2.4 \
+    libopencv-legacy2.4 \
+    libopencv-ml2.4 \
+    libopencv-nonfree2.4 \
+    libopencv-objdetect2.4 \
+    libopencv-ocl2.4 \
+    libopencv-photo2.4 \
+    libopencv-stitching2.4 \
+    libopencv-superres2.4 \
+    libopencv-video2.4 \
+    libopencv-videostab2.4 \
+"
+
+
+

Then rebuild your image

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+

Tip

+

Most examples do not work out of the box, because they depend on the GTK +graphics library. The BSP only supports Qt6 .

+
+
+
+

8.6.19. Add Minimal PHP web runtime with lightpd

+

This is one example of how to add a small runtime for PHP applications and a web +server on your target. Lighttpd can be used together with the PHP command line +tool over cgi. This solution weights only 5.5 MiB of disk storage. It is already +preconfigured in meta-ampliphy. Just modify the build configuration to install +it on the image

+
# file conf/local.conf
+# install lighttpd with php cgi module
+IMAGE_INSTALL:append = " lighttpd"
+
+
+

After booting the image, you should find the example web content in /www/pages +. For testing php, you can delete the index.html and replace it with a +index.php file

+
<html>
+  <head>
+    <title>PHP-Test</title>
+  </head>
+  <body>
+    <?php phpinfo(); ?>
+  </body>
+</html>
+
+
+

On your host, you can point your browser to the board’s IP, (e.g. 192.168.3.11) +and the phpinfo should show up.

+
+
+
+

8.7. Common Tasks

+
+

8.7.1. Debugging a User Space Application

+

The phytec-qt6demo-image can be cross-debugged without any change. For +cross-debugging, you just have to match the host sysroot with the image in use. +So you need to create a toolchain for your image

+
host:~$ bitbake -c populate_sdk phytec-qt6demo-image
+
+
+

Additionally, if you want to have full debug and backtrace capabilities for all +programs and libraries in the image, you could add

+
DEBUG_BUILD = "1"
+
+
+

to the conf/local.conf. This is not necessary in all cases. The compiler +options will then be switched from FULL_OPTIMIZATION to DEBUG_OPTIMIZATION. Look +at the Poky source code for the default assignment of DEBUG_OPTIMIZATION.

+

To start a cross debug session, install the SDK as mentioned previously, source +the SDK environment, and run Qt Creator in the same shell. If you do not use +Qt Creator, you can directly call the arm-<..>-gdb debugger instead which +should be in your path after sourcing the environment script.

+

If you work with Qt Creator, have a look at the appropriate documentation +delivered with your product (either QuickStart or Application Guide) for +information on how to set up the toolchain.

+

When starting the debugger with your userspace application you will get a +SIGILL, an illegal instruction from the libcrypto. Openssl probes for the +system capabilities by trapping illegal instructions, which will trigger GDB. +You can ignore this and hit Continue (c command). You can permanently ignore +this stop by adding

+
handle SIGILL nostop
+
+
+

to your GDB startup script or in the Qt Creator GDB configuration panel. +Secondly, you might need to disable a security feature by adding

+
set auto-load safe-path /
+
+
+

to the same startup script, which will enable the automatic loading of libraries +from any location.

+

If you need to have native debugging, you might want to install the debug +symbols on the target. You can do this by adding the following line to your +conf/local.conf

+
EXTRA_IMAGE_FEATURES += "dbg-pkgs"
+
+
+

For cross-debugging, this is not required as the debug symbols will be loaded +from the host side and the dbg-pkgs are included in the SDK of your image +anyway.

+
+
+

8.7.2. Generating Source Mirrors, working Offline

+

Modify your site.conf (or local.conf if you do not use a site.conf ) as +follows

+
#DL_DIR ?= "" don't set it! It will default to a directory inside /build
+SOURCE_MIRROR_URL = "file:///home/share/yocto_downloads/"
+INHERIT += "own-mirrors"
+BB_GENERATE_MIRROR_TARBALLS = "1"
+
+
+

Now run

+
host:~$ bitbake --runall=fetch <image>
+
+
+

for all images and for all machines you want to provide sources for. This will +create all the necessary tar archives. We can remove all SCM subfolders, as +they are duplicated with the tarballs

+
host:~$ rm -rf build/download/git2/
+etc...
+
+
+

Please consider that we used a local source mirror for generating the dl_dir. +Because of that, some archives will be linked locally.

+

First, we need to copy all files, resolving symbolic links into the new mirror +directory

+
host:~$ rsync -vaL <dl_dir> ${TOPDIR}/../src_mirror/
+
+
+

Now we clean the /build directory by deleting everything except /build/conf/ +but including /build/conf/sanity. We change site.conf as follows

+
SOURCE_MIRROR_URL = "file://${TOPDIR}/../src_mirror"
+INHERIT += "own-mirrors"
+BB_NO_NETWORK = "1"
+SCONF_VERSION = "1"
+
+
+

The BSP directory can now be compressed with

+
host:~$ tar cfJ <filename>.tar.xz <folder>
+
+
+

where filename and folder should be the full BSP Name.

+
+
+

8.7.3. Compiling on the Target

+

To your local.conf add

+
IMAGE_FEATURES:append = " tools-sdk dev-pkgs"
+
+
+
+
+

8.7.4. Different Toolchains

+

There are several ways to create a toolchain installer in Poky. One option is +to run

+
host:~$ bitbake meta-toolchain
+
+
+

This will generate a toolchain installer in build/deploy/sdk which can be used +for cross-compiling of target applications. However, the installer does not +include libraries added to your image, so it is a bare GCC compiler only. This +is suited for bootloader and kernel development.

+

Another you can run is

+
host:~$ bitbake -c populate_sdk <your_image>
+
+
+

This will generate a toolchain installer containing all necessary development +packages of the software installed on the root filesystem of the target. This +installer can be handed over to the user space application development team and +includes all necessary parts to develop an application. If the image contains +the QT libraries, all of those will be available in the installer too.

+

The third option is to create the ADT (Application Development Toolkit) +installer. It will contain the cross-toolchain and some tools to aid the +software developers, for example, an Eclipse plugin and a QEMU target +simulator.

+
host:~$ bitbake adt-installer
+
+
+

The ADT is untested for our BSP at the moment.

+
+

8.7.4.1. Using the SDK

+

After generating the SDK with

+
host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
+
+

run the generated binary with

+
host:~$ deploy/sdk/ampliphy-glibc-x86_64-phytec-qt6demo-image-cortexa9hf-vfp-neon-toolchain-i.MX6-PD15.3-rc.sh
+Enter target directory for SDK (default: /opt/ampliphy/i.MX6-PD15.3-rc):
+You are about to install the SDK to "/opt/ampliphy/i.MX6-PD15.3-rc". Proceed[Y/n]?
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
+
+

You can activate the toolchain for your shell by sourcing the file +environment-setup in the toolchain directory

+
host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+
+
+

Then the necessary tools like the cross compiler and linker are in your PATH. To +compile a simple C program, use

+
host:~$ $CC main.c -o main
+
+
+

The environment variable $CC contains the path to the ARM cross compiler and +other compiler arguments needed like -march , -sysroot and –mfloat-abi.

+
+

Tip

+

You cannot compile programs only with the compiler name like

+
host:~$ arm-phytec-linux-gnueabi-gcc main.c -o main
+
+
+

It will fail in many cases. Always use CC, CFLAGS, LDFLAGS, and so on.

+
+

For convenience, the environment-setup exports other environment variables +like CXX, LD, SDKTARGETSYSROOT.

+

A simple makefile compiling a C and C++ program may look like this

+
# Makefile
+TARGETS=c-program cpp-program
+
+all: $(TARGETS)
+
+c-program: c-program.c
+    $(CC) $(CFLAGS) $(LDFLAGS) $< -o $@
+
+cpp-program: cpp-program.cpp
+    $(CXX) $(CXXFLAGS) $(LDFLAGS) $< -o $@
+
+.PHONY: clean
+clean:
+    rm -f $(TARGETS)
+
+
+

To compile for the target, just source the toolchain in your shell before +executing make

+
host:~$ make     # Compiling with host CC, CXX for host architecture
+host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+host:~$ make     # Compiling with target CC, CXX for target architecture
+
+
+

If you need to specify additionally included directories in the sysroot of the +toolchain, you can use an ‘=’ sign in the -I argument like

+
-I=/usr/include/SDL
+
+
+

GCC replaces it by the sysroot path (here +/opt/ampliphy/i.MX6-PD15.3-rc/sysroots/cortexa9hf-vfp-neon-phytec-linux-gnueabi/). +See the main page of GCC for more information.

+
+

Tip

+

The variables $CFLAGS and $CXXFLAGS contain the compiler debug flag ‘-g’ by +default. This includes debugging information in the binary and making it +bigger. Those should be removed from the production image. If you create a +Bitbake recipe, the default behavior is to turn on ‘-g’ too. The debugging +symbols are used in the SDK rootfs to be able to get debugging information +when invoking GDB from the host. Before installing the package to the +target rootfs, Bitbake will invoke strip on the program which removes the +debugging symbols. By default, they are not found nor required on the target +root filesystem

+
+
+
+

8.7.4.2. Using the SDK with GNU Autotools

+

Yocto SDK is a straightforward tool for a project that uses the GNU +Autotools. The traditional compile steps for the host are usually

+
host:~$ ./autogen.sh # maybe not needed
+host:~$ ./configure
+host:~$ make
+host:~$ make install DESTDIR=$PWD/build/
+
+
+

The commands to compile for the target machine with the Yocto SDK are quite +similar. The following commands assume that the SDK was unpacked to the +directory /opt/phytec-ampliphy/i.MX6-PD15.3.0/ (adapt the path as needed)

+
host:~$ source /opt/phytec-ampliphy/i.MX6-PD15.3.0/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+host:~$ ./autogen.sh  # maybe not needed
+host:~$ ./configure ${CONFIGURE_FLAGS}
+host:~$ make
+host:~$ make install DESTDIR=$PWD/build/
+
+
+

Refer to the official Yocto documentation for more information: +https://docs.yoctoproject.org/4.2.4/singleindex.html#autotools-based-projects

+
+
+
+

8.7.5. Working with Kernel Modules

+

You will come to the point where you either need to set some options for a +kernel module or you want to blacklist a module. Those things are handled by +udev and go into *.conf files in

+
/etc/modprobe.d/\*.conf.
+
+
+

If you want to specify an option at build time, there are three relevant +variables. If you just want to autoload a module that has no autoload +capabilities, add it to

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+
+
+

either in the kernel recipe or in the global variable scope. If you need to +specify options for a module, you can do so with

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+KERNEL_MODULE_PROBECONF += "your-module"
+module_conf_your-module = "options your-module parametername=parametervalue"
+
+
+

if you want to blacklist a module from autoloading, you can do it intuitively +with

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+KERNEL_MODULE_PROBECONF += "your-module"
+module_conf_your-module = "blacklist your-module"
+
+
+
+
+

8.7.6. Working with udev

+

Udev (Linux dynamic device management) is a system daemon that handles dynamic +device management in /dev. It is controlled by udev rules that are located +in /etc/udev/rules.d (sysadmin configuration space) and /lib/udev/rules.d/ +(vendor-provided). Here is an example of an udev rule file

+
# file /etc/udev/rules.d/touchscreen.rules
+# Create a symlink to any touchscreen input device
+SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="input:*-e0*,3,*a0,1,*18,*", SYMLINK+="input/touchscreen0"
+SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="ads7846", SYMLINK+="input/touchscreen0"
+
+
+

See https://www.freedesktop.org/software/systemd/man/latest/udev.html for more details +about the syntax and usage. To get the list of attributes for a specific device +that can be used in an udev rule you can use the udevadm info tool. It +prints all existing attributes of the device node and its parents. The key-value +pairs from the output can be copied and pasted into a rule file. Some examples

+
target:~$ udevadm info -a /dev/mmcblk0
+target:~$ udevadm info -a /dev/v4l-subdev25
+target:~$ udevadm info -a -p /sys/class/net/eth0
+
+
+

After changing an udev rule, you have to notify the daemon. Otherwise, your +changes are not reflected. Use the following command

+
target:~$ udevadm control --reload-rules
+
+
+

While developing udev rules you should monitor the events in order to see when +devices are attached or unattached to the system. Use

+
target:~$ udevadm monitor
+
+
+

Furthermore, it is very useful to monitor the system log in another shell, +especially if the rule executes external scripts. Execute

+
target:~$ journalctl -f
+
+
+
+

Tip

+

You cannot start daemons or heavy scripts in a RUN attribute. See +https://www.freedesktop.org/software/systemd/man/latest/udev.html#RUN%7Btype%7D .

+

This can only be used for very short-running foreground tasks. Running an +event process for a long period of time may block all further events for this +or a dependent device. Starting daemons or other long-running processes is +not appropriate for udev; the forked processes, detached or not, will be +unconditionally killed after the event handling has finished. You can use the +special attribute ENV{SYSTEMD_WANTS}=”service-name.service” and a +systemdservice instead.

+

See +https://unix.stackexchange.com/questions/63232/what-is-the-correct-way-to-write-a-udev-rule-to-stop-a-service-under-systemd.

+
+
+
+
+
+

9. Troubleshooting

+
+

9.1. Setscene Task Warning

+

This warning occurs when the Yocto cache is in a dirty state.

+
WARNING: Setscene task X ([...]) failed with exit code '1' - real task
+
+
+

You should avoid canceling the build process or if you have to, press Ctrl-C +once and wait until the build process has stopped. To remove all these warnings +just clean the sstate cache and remove the build folders.

+
host:~$ bitbake phytec-headless-image -c cleansstate && rm -rf tmp deploy/ipk
+
+
+
+
+
+

10. Yocto Documentation

+

The most important piece of documentation for a BSP user is probably the +developer manual. +https://docs.yoctoproject.org/4.2.4/dev-manual/index.html

+

The chapter about common tasks is a good starting point. +https://docs.yoctoproject.org/4.2.4/dev-manual/layers.html#understanding-and-creating-layers

+

The complete documentation is available on one single HTML page, which is good +for searching for a feature or a variable name. +https://docs.yoctoproject.org/4.2.4/singleindex.html

+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/yocto/scarthgap.html b/previews/271/yocto/scarthgap.html new file mode 100644 index 000000000..d98a2fa46 --- /dev/null +++ b/previews/271/yocto/scarthgap.html @@ -0,0 +1,2935 @@ + + + + + + + + + 1. The Yocto Project — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + +

Yocto Reference Manual

Document Title

Yocto Reference Manual Scarthgap

Document Type

Yocto Manual

Release Date

XXXX/XX/XX

Is Branch of

Yocto Reference Manual

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.0

Major

2024-04-02

released

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1

Minor

2024-04-09

released

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2

Minor

2024-06-26

released

BSP-Yocto-NXP-i.MX8MP-PD24.1.0

Major

2024-11-07

released

BSP-Yocto-NXP-i.MX93-PD24.2.0

Major

2024-10-08

released

BSP-Yocto-Ampliphy-i.MX6UL-PD24.1.0

Major

2024-07-19

released

BSP-Yocto-Ampliphy-AM62Ax-PD24.1.0

Major

2024-06-27

released

BSP-Yocto-Ampliphy-AM62x-PD24.1.0

Major

2024-06-27

released

BSP-Yocto-Ampliphy-AM64x-PD24.1.0

Major

2024-06-27

released

+

This manual applies to all Scarthgap based PHYTEC releases.

+
+

1. The Yocto Project

+
+

1.1. PHYTEC Documentation

+

PHYTEC will provide a variety of hardware and software documentation for all of +our products. This includes any or all of the following:

+
    +

  • QS Guide: A short guide on how to set up and boot a phyCORE board along +with brief information on building a BSP, the device tree, and accessing +peripherals.

    • +

  • Hardware Manual: A detailed description of the System on Module and +accompanying carrier board.

    • +

  • Yocto Guide: A comprehensive guide for the Yocto version the phyCORE +uses. This guide contains an overview of Yocto; introducing, installing, and +customizing the PHYTEC BSP; how to work with programs like Poky and Bitbake; +and much more.

    • +

  • BSP Manual: A manual specific to the BSP version of the phyCORE. +Information such as how to build the BSP, booting, updating software, device +tree, and accessing peripherals can be found here.

    • +

  • Development Environment Guide: This guide shows how to work with the +Virtual Machine (VM) Host PHYTEC has developed and prepared to run various +Development Environments. There are detailed step-by-step instructions for +Eclipse and Qt Creator, which are included in the VM. There are instructions +for running demo projects for these programs on a phyCORE product as well. +Information on how to build a Linux host PC yourself is also a part of this +guide.

    • +

  • Pin Muxing Table: phyCORE SOMs have an accompanying pin table (in Excel +format). This table will show the complete default signal path, from +processor to carrier board. The default device tree muxing option will also +be included. This gives a developer all the information needed in one +location to make muxing changes and design options when developing a +specialized carrier board or adapting a PHYTEC phyCORE SOM to an application.

    • +
+

On top of these standard manuals and guides, PHYTEC will also provide Product +Change Notifications, Application Notes, and Technical Notes. These will be done +on a case-by-case basis. Most of the documentation can be found in the +applicable download page of our products.

+
+
+

1.2. Yocto Introduction

+

Yocto is the smallest SI metric system prefix. Like milli equates to m = +10^-3, and so is yocto y = 10^-24. Yocto is also a project working group +of the Linux Foundation and therefore +backed up by several major companies in the field. On the Yocto Project website you can read the official introduction:

+
+

The Yocto Project is an open-source collaboration project that provides +templates, tools, and methods to help you create custom Linux-based systems +for embedded products regardless of the hardware architecture. It was founded +in 2010 as a collaboration among many hardware manufacturers, open-source +operating systems vendors, and electronics companies to bring some order to +the chaos of embedded Linux development.

+
+

As said, the project wants to provide toolsets for embedded developers. It +builds on top of the long-lasting OpenEmbedded project. It is not a Linux distribution. But +it contains the tools to create a Linux distribution specially fitted to the +product requirements. The most important step in bringing order to the set of +tools is to define a common versioning scheme and a reference system. All +subprojects have then to comply with the reference system and have to comply +with the versioning scheme.

+

The release process is similar to the Linux kernel. +Yocto increases its version number every six months and gives the release a +codename. The release list can be found here: +https://wiki.yoctoproject.org/wiki/Releases

+
+
+

1.3. Core Components

+

The most important tools or subprojects of the Yocto Project are:

+
    +

  • Bitbake: build engine, a task scheduler like make, interprets metadata

    • +

  • OpenEmbedded-Core, a set of base layers, containing metadata of software, no +sources

    • +

  • Yocto kernel

    +
      +

    • Optimized for embedded devices

      • +

    • Includes many subprojects: rt-kernel, vendor patches

      • +

    • The infrastructure provided by Wind River

      • +

    • Alternative: classic kernel build → we use it to integrate our kernel into +Yocto

      • +
    +
    • +

  • Yocto Reference BSP: beagleboneblack, minnow max

    • +

  • Poky, the reference system, a collection of projects and tools, used to +bootstrap a new distribution based on Yocto

    • +
+
+
+

1.4. Vocabulary

+
+

1.4.1. Recipes

+

Recipes contain information about the software project (author, homepage, and +license). A recipe is versioned, defines dependencies, contains the URL of the +source code, and describes how to fetch, configure, and compile the sources. It +describes how to package the software, e.g. into different .deb packages, which +then contain the installation path. Recipes are basically written in Bitbake’s +own programming language, which has a simple syntax. However, a recipe can +contain Python as well as a bash code.

+
+
+

1.4.2. Classes

+

Classes combine functionality used inside recipes into reusable blocks.

+
+
+

1.4.3. Layers

+

A layer is a collection of recipes, classes, and configuration metadata. +A layer can depend on other layers and can be included or excluded one +by one. It encapsulates a specific functionality and fulfills a specific +purpose. Each layer falls into a specific category:

+
    +

  • Base

    • +

  • Machine (BSP)

    • +

  • Software

    • +

  • Distribution

    • +

  • Miscellaneous

    • +
+

Yocto’s versioning scheme is reflected in every layer as version branches. For +each Yocto version, every layer has a named branch in its Git repository. +You can add one or many layers of each category in your build.

+

A collection of OpenEmbedded layers can be found here. The search function is +very helpful to see if a software package can be retrieved and integrated +easily: https://layers.openembedded.org/layerindex/branch/scarthgap/layers/

+
+
+

1.4.4. Machine

+

Machines are configuration variables that describe the aspects of the target +hardware.

+
+
+

1.4.5. Distribution (Distro)

+

Distribution describes the software configuration and comes with a set of +software features.

+
+
+
+

1.5. Poky

+

Poky is the reference system to define Yocto Project compatibility. It +combines several subprojects into releases:

+
    +

  • Bitbake

    • +

  • Toaster

    • +

  • OpenEmbedded Core

    • +

  • Yocto Documentation

    • +

  • Yocto Reference BSP

    • +
+
+

1.5.1. Bitbake

+

Bitbake is the task scheduler. It is written in Python and interprets +recipes that contain code in Bitbake’s own programming language, Python, and +bash code. The official documentation can be found here: +https://docs.yoctoproject.org/bitbake/2.8/index.html

+
+
+

1.5.2. Toaster

+

Toaster is a web frontend for Bitbake to start and investigate builds. It +provides information about the build history and statistics on created images. +There are several use cases where the installation and maintenance of +a Toaster instance are beneficial. PHYTEC did not add or remove any features +to the upstream Toaster, provided by Poky. The best source for more +information is the official documentation: +https://docs.yoctoproject.org/dev/toaster-manual/index.html

+
+
+
+

1.6. Official Documentation

+

For more general questions about Bitbake and Poky consult the mega-manual: +https://docs.yoctoproject.org/dev/singleindex.html

+
+
+
+

2. Compatible Linux Distributions

+

To build Yocto you need a compatible Linux host development machine. The +list of supported distributions can be found in the reference manual: +https://docs.yoctoproject.org/dev/ref-manual/system-requirements.html#supported-linux-distributions

+
+
+

3. PHYTEC BSP Introduction

+
+

3.1. BSP Structure

+

The BSP consists roughly of three parts. BSP management, BSP metadata, and BSP +content. The management consists of Repo and phyLinux while the metadata +depends on the SOC, which describes how to build the software. The content +comprises PHYTEC’s Git repositories and external sources.

+
+

3.1.1. BSP Management

+

Yocto is an umbrella project. Naturally, this will force the user to base +their work on several external repositories. They need to be managed in a +deterministic way. We use manifest files, which contain an XML data structure, +to describe all git repositories with pinned-down versions. The Repo tool and +our phyLinux wrapper script are used to manage the manifests and set up the BSP, +as described in the manifest file.

+
+

3.1.1.1. phyLinux

+

phyLinux is a wrapper for Repo to handle downloading and setting up the BSP +with an “out of the box” experience.

+
+
+

3.1.1.2. Repo

+

Repo is a wrapper around the Repo toolset. The phyLinux script will install +the wrapper in a global path. This is only a wrapper, though. Whenever you run +repo init -u <url>, you first download the Repo tools from Googles Git +server in a specific version to the .repo/repo directory. The next time you +run Repo, all the commands will be available. Be aware that the Repo version +in different build directories can differ over the years if you do not run Repo +sync. Also if you store information for your archives, you need to include the +complete .repo folder.

+

Repo expects a Git repository which will be parsed from the command line. In +the PHYTEC BSP, it is called phy²octo. In this repository, all information about +a software BSP release is stored in the form of a Repo XML manifest. This data +structure defines URLs of Git servers (called “remotes”) and Git +repositories and their states (called “projects”). The Git repositories can be +seen in different states. The revision field can be a branch, tag, or commit id +of a repository. This means the state of the software is not necessarily unique +and can change over time. That is the reason we use only tags or commit ids for +our releases. The state of the working directory is then unique and does not +change.

+

The manifests for the releases have the same name as the release itself. It is a +unique identifier for the complete BSP. The releases are sorted by the SoC +platform. The selected SoC will define the branch of the phy²octo Git +repository which will be used for the manifest selection.

+
+
+
+

3.1.2. BSP Metadata

+

We include several third-party layers in our BSP to get a complete Linux +distribution up and running without the need to integrate external projects. All +used repositories are described in the following section.

+
+

3.1.2.1. Poky

+

The PHYTEC BSP is built on top of Poky. It comes with a specific version, +defined in the Repo manifest. Poky comes with a specific version of +Bitbake. The OpenEmbedded-core layer “meta” is used as a base for our Linux +system.

+
+
+

3.1.2.2. meta-openembedded

+

OpenEmbedded is a collection of different layers containing the meta description +for many open-source software projects. We ship all OpenEmbedded layers with our +BSP, but not all of them are activated. Our example images pull several software +packages generated from OpenEmbedded recipes.

+
+
+

3.1.2.3. meta-qt6

+

This layer provides an integration of Qt6 in the Poky-based root filesystem +and is integrated into our BSP.

+
+
+

3.1.2.4. meta-nodejs

+

This is an application layer to add recent Node.js versions.

+
+
+

3.1.2.5. meta-gstreamer1.0

+

This is an application layer to add recent GStreamer versions.

+
+
+

3.1.2.6. meta-rauc

+

This layer contains the tools required to build an updated infrastructure with +RAUC. A comparison with +other update systems can be found here: Yocto update tools.

+
+
+

3.1.2.7. meta-phytec

+

This layer contains all machines and common features for all our BSPs. It is +PHYTEC’s Yocto Board Support Package for all supported +hardware (since fido) and is designed to be standalone with Poky. Only these +two parts are required if you want to integrate the PHYTEC’s hardware into your +existing Yocto workflow. The features are:

+
    +

  • Bootloaders in recipes-bsp/barebox/ and recipes-bsp/u-boot/

    • +

  • Kernels in recipes-kernel/linux/ and +dynamic-layers/fsl-bsp-release/recipes-kernel/linux/

    • +

  • Many machines in conf/machine/

    • +

  • Proprietary OpenGL ES/EGL user space libraries for AM335x and i.MX 6 +platforms

    • +

  • Proprietary OpenCL libraries for i.MX 6 platforms

    • +
+
+
+

3.1.2.8. meta-ampliphy

+

This is our example distribution and BSP layer. It extends the basic +configuration of Poky with software projects described by all the other BSP +components. It provides a base for your specific development scenarios. The +current features are:

+
    +

  • systemd init system

    • +

  • Images: phytec-headless-image for non-graphics applications

    • +

  • Camera integration with OpenCV and GStreamer examples for the i.MX 6 platform +bundled in a phytec-vision-image

    • +

  • RAUC integration: we set up basic support for an A/B system image update, +which is possible locally and over-the-air

    • +
+
+
+

3.1.2.9. meta-qt6-phytec

+

This is our layer for Qt6 board integration and examples. The features are:

+
    +

  • Qt6 with eglfs backend for +PHYTEC’s AM335x, i.MX 6 and RK3288 platforms

    • +

  • Images: phytec-qt6demo-image for Qt6 and video applications

    • +

  • A Qt6 demo application demonstrating how to create a Qt6 project using +QML widgets and a Bitbake recipe for the Yocto and systemd +integration. It can be found in +sources/meta-qt6-phytec/recipes-qt/examples/phytec-qtdemo_git.bb

    • +
+
+
+

3.1.2.10. meta-virtualization

+
    +

  • This layer provides support for building Xen, KVM, Libvirt, and associated +packages necessary for constructing OE-based virtualized solutions.

    • +
+
+
+

3.1.2.11. meta-security

+
    +

  • This layer provides security tools, hardening tools for Linux kernels, and +libraries for implementing security mechanisms.

    • +
+
+
+

3.1.2.12. meta-selinux

+
    +

  • This layer’s purpose is to enable SE Linux support. The majority of this +layer’s work is accomplished in bbappend files, used to enable SE Linux +support in existing recipes.

    • +
+
+
+

3.1.2.13. meta-browser

+
    +

  • This is an application layer to add recent web browsers (Chromium, Firefox, +etc.).

    • +
+
+
+

3.1.2.14. meta-rust

+
    +

  • Includes the Rust compiler and the Cargo package manager for Rust.

    • +
+
+
+

3.1.2.15. meta-timesys

+
    +

  • Timesys layer for Vigiles Yocto CVE monitoring, security notifications, and +image manifest generation.

    • +
+
+
+

3.1.2.16. meta-freescale

+
    +

  • This layer provides support for the i.MX, Layerscape, and QorIQ product +lines.

    • +
+
+
+

3.1.2.17. meta-freescale-3rdparty

+
    +

  • Provides support for boards from various vendors.

    • +
+
+
+

3.1.2.18. meta-freescale-distro

+
    +

  • This layer provides support for Freescale’s Demonstration images for use with +OpenEmbedded and/or Yocto Freescale’s BSP layer.

    • +
+
+
+

3.1.2.19. base (fsl-community-bsp-base)

+
    +

  • This layer provides BSP base files of NXP.

    • +
+
+
+

3.1.2.20. meta-fsl-bsp-release

+
    +

  • This is the i.MX Yocto Project Release Layer.

    • +
+
+
+
+

3.1.3. BSP Content

+

The BSP content gets pulled from different online sources when you first start +using Bitbake. All files will be downloaded and cloned in a local directory +configured as DL_DIR in Yocto. If you backup your BSP with the complete +content, those sources have to be backed up, too. How you can do this will be +explained in the chapter Generating Source Mirrors, working Offline.

+
+
+
+

3.2. Build Configuration

+

The BSP initializes a build folder that will contain all files you +create by running Bitbake commands. It contains a conf folder +that handles build input variables.

+
    +

  • bblayers.conf defines activated meta-layers,

    • +

  • local.conf defines build input variables specific to your build

    • +

  • site.conf defines build input variables specific to the development host

    • +
+

The two topmost build input variables are DISTRO and MACHINE. They are +preconfigured local.conf when you check out the BSP using phyLinux.

+

We use “Ampliphy” as DISTRO with our BSP. This distribution will be +preselected and give you a starting point for implementing your own +configuration.

+

A MACHINE defines a binary image that supports specific hardware +combinations of module and baseboard. Check the machine.conf file or our +webpage for a description of the hardware.

+
+
+
+

4. Pre-built Images

+

For each BSP we provide pre-built target images that can be downloaded from the +PHYTEC FTP server: https://download.phytec.de/Software/Linux/

+

These images are also used for the BSP tests, which are flashed to the boards +during production. You can use the provided .wic images to create a bootable +SD card at any time. Identify your hardware and flash the downloaded image file +to an empty SD card using dd. Please see section Images for information +about the correct usage of the command.

+
+
+

5. BSP Workspace Installation

+
+

5.1. Setting Up the Host

+

You can set up the host or use one of our build-container to run a Yocto build. +You need to have a running Linux distribution. It should be running on a +powerful machine since a lot of compiling will need to be done.

+

If you want to use a build-container, you only need to install following +packages on your host

+
host:~$ sudo apt install wget git
+
+
+

Continue with the next step Git Configuration after that. The documentation for +using build-container can be found in this manual after +Advanced Usage of phyLinux.

+

Else Yocto needs a handful of additional packages on your host. For Ubuntu you need

+
host:~$ sudo apt install gawk wget git diffstat unzip texinfo \
+      gcc build-essential chrpath socat cpio python3 python3-pip \
+      python3-pexpect xz-utils debianutils iputils-ping python3-git \
+      python3-jinja2 libegl1-mesa libsdl1.2-dev \
+      python3-subunit mesa-common-dev zstd liblz4-tool file locales
+
+
+

For other distributions you can find information in the Yocto Quick Build: +https://docs.yoctoproject.org/dev/brief-yoctoprojectqs/index.html

+
+
+

5.2. Git Configuration

+

The BSP heavily utilizes Git. Git needs some information from +you as a user to identify who made changes. Create a ~/.gitconfig with the +following content, if you do not have one

+
[user]
+    name = <Your Name>
+    email = <Your Mail>
+[core]
+    editor = vim
+[merge]
+    tool = vimdiff
+[alias]
+    co = checkout
+    br = branch
+    ci = commit
+    st = status
+    unstage = reset HEAD --
+    last = log -1 HEAD
+[push]
+    default = current
+[color]
+    ui = auto
+
+
+

You should set name and email in your Git configuration, otherwise, +Bitbake will complain during the first build. You can use the two commands to +set them directly without editing ~/.gitconfig manually

+
host:~$ git config --global user.email "your_email@example.com"
+host:~$ git config --global user.name "name surname"
+
+
+
+
+

5.3. site.conf Setup

+

Before starting the Yocto build, it is advisable to configure the development +setup. Two things are most important: the download directory and the cache +directory. PHYTEC strongly recommends configuring the setup as it will reduce +the compile time of consequent builds.

+

A download directory is a place where Yocto stores all sources fetched from +the internet. It can contain tar.gz, Git mirror, etc. It is very useful to set +this to a common shared location on the machine. Create this directory with 777 +access rights. To share this directory with different users, all files need to +have group write access. This will most probably be in conflict with default +umask settings. One possible solution would be to use ACLs for this +directory

+
host:~$ sudo apt-get install acl
+host:~$ sudo setfacl -R -d -m g::rwx <dl_dir>
+
+
+

If you have already created a download directory and want to fix the permissions +afterward, you can do so with

+
host:~$ sudo find /home/share/ -perm /u=r ! -perm /g=r -exec chmod g+r \{\} \;
+host:~$ sudo find /home/share/ -perm /u=w ! -perm /g=w -exec chmod g+w \{\} \;
+host:~$ sudo find /home/share/ -perm /u=x ! -perm /g=x -exec chmod g+x \{\} \;
+
+
+

The cache directory stores all stages of the build process. Poky has quite an +involved caching infrastructure. It is advisable to create a shared directory, +as all builds can access this cache directory, called the shared state cache.

+

Create the two directories on a drive where you have approximately 50 GB of +space and assign the two variables in your build/conf/local.conf:

+
DL_DIR ?= "<your_directory>/yocto_downloads"
+SSTATE_DIR ?= "<your_directory>/yocto_sstate"
+
+
+

If you want to know more about configuring your build, see the documented +example settings

+
sources/poky/meta-yocto/conf/local.conf.sample
+sources/poky/meta-yocto/conf/local.conf.sample.extended
+
+
+
+
+
+

6. phyLinux Documentation

+

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases +written in Python. It is mainly a helper to get started with the BSP +structure. You can get all the BSP sources without the need of interacting with +Repo or Git.

+

The phyLinux script has only one real dependency. It requires the wget tool +installed on your host. It will also install the Repo tool in a global path +(/usr/local/bin) on your host PC. You can install it in a different location +manually. Repo will be automatically detected by phyLinux if it is found in +the PATH. The Repo tool will be used to manage the different Git +repositories of the Yocto BSP.

+
+

6.1. Get phyLinux

+

The phyLinux script can be found on the PHYTEC download server: +https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux

+
+
+

6.2. Basic Usage

+

For the basic usage of phyLinux, type

+
host:~$ ./phyLinux --help
+
+
+

which will result in

+
usage: phyLinux [-h] [-v] [--verbose] {init,info,clean} ...
+
+This Programs sets up an environment to work with The Yocto Project on Phytecs
+Development Kits. Use phyLinx <command> -h to display the help text for the
+available commands.
+
+positional arguments:
+  {init,info,clean}  commands
+    init             init the phytec bsp in the current directory
+    info             print info about the phytec bsp in the current directory
+    clean            Clean up the current working directory
+
+optional arguments:
+  -h, --help         show this help message and exit
+  -v, --version      show program's version number and exit
+  --verbose
+
+
+
+
+

6.3. Initialization

+

Create a fresh project folder

+
host:~$ mkdir ~/yocto
+
+
+

Calling phyLinux will use the default Python version. Starting with Ubuntu 20.04 +it will be Python3. If you want to initiate a BSP, which is not compatible with +Python3, you need to set Python2 as default (temporarily) before running +phyLinux

+
host:~$ ln -s \`which python2\` python && export PATH=`pwd`:$PATH
+
+
+

Now run phyLinux from the new folder

+
host:~$ ./phyLinux init
+
+
+

A clean folder is important because phyLinux will clean its working directory. +Calling phyLinux from a directory that isn’t empty will result in the following +warning:

+
This current directory is not empty. It could lead to errors in the BSP configuration
+process if you continue from here. At the very least, you have to check your build directory
+for settings in bblayers.conf and local.conf, which will not be handled correctly in
+all cases. It is advisable to start from an empty directory of call:
+$ ./phyLinux clean
+Do you really want to continue from here?
+[yes/no]:
+
+
+

On the first initialization, the phyLinux script will ask you to install the +Repo tool in your /usr/local/bin directory. During the execution of the +init command, you need to choose your processor platform (SoC), PHYTEC’s BSP +release number, and the hardware you are working on

+
***************************************************
+* Please choose one of the available SoC Platforms:
+*
+*   1: am335x
+*   2: am57x
+*   3: am62ax
+*   4: am62x
+*   5: am64x
+*   6: am68x
+*   7: imx6
+*   8: imx6ul
+*   9: imx7
+*   10: imx8
+*   11: imx8m
+*   12: imx8mm
+*   13: imx8mp
+*   14: imx8x
+*   15: imx93
+*   16: nightly
+*   17: rk3288
+*   18: stm32mp13x
+*   19: stm32mp15x
+*   20: topic
+
+# Exemplary output for chosen imx8mp
+***************************************************
+* Please choose one of the available Releases:
+*
+*   1: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1-rc1
+*   2: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1-rc2
+*   3: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.0
+*   4: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1
+*   5: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2-rc1
+*   6: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2
+*   7: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.y
+*   8: BSP-Yocto-Ampliphy-i.MX8MP-master
+*   9: BSP-Yocto-FSL-i.MX8MP-ALPHA1
+*   10: BSP-Yocto-FSL-i.MX8MP-ALPHA2
+*   11: BSP-Yocto-FSL-i.MX8MP-PD21.1-rc1
+*   12: BSP-Yocto-FSL-i.MX8MP-PD21.1-rc2
+*   13: BSP-Yocto-FSL-i.MX8MP-PD21.1.0
+*   14: BSP-Yocto-FSL-i.MX8MP-PD21.1.1-rc1
+*   15: BSP-Yocto-FSL-i.MX8MP-PD21.1.1-rc2
+*   16: BSP-Yocto-FSL-i.MX8MP-PD21.1.1
+*   17: BSP-Yocto-FSL-i.MX8MP-PD21.1.2-rc1
+*   18: BSP-Yocto-FSL-i.MX8MP-PD21.1.2-rc2
+*   19: BSP-Yocto-FSL-i.MX8MP-PD21.1.2
+*   20: BSP-Yocto-FSL-i.MX8MP-PD21.1.3-rc1
+*   21: BSP-Yocto-FSL-i.MX8MP-PD21.1.3
+*   22: BSP-Yocto-NXP-i.MX8MP-PD22.1-rc1
+*   23: BSP-Yocto-NXP-i.MX8MP-PD22.1-rc2
+*   24: BSP-Yocto-NXP-i.MX8MP-PD22.1-rc3
+*   25: BSP-Yocto-NXP-i.MX8MP-PD22.1-rc4
+*   26: BSP-Yocto-NXP-i.MX8MP-PD22.1.0
+*   27: BSP-Yocto-NXP-i.MX8MP-PD22.1.1-rc1
+*   28: BSP-Yocto-NXP-i.MX8MP-PD22.1.1-rc2
+*   29: BSP-Yocto-NXP-i.MX8MP-PD22.1.1-rc3
+*   30: BSP-Yocto-NXP-i.MX8MP-PD22.1.1-rc4
+*   31: BSP-Yocto-NXP-i.MX8MP-PD22.1.1
+*   32: BSP-Yocto-NXP-i.MX8MP-PD22.1.2-rc1
+*   33: BSP-Yocto-NXP-i.MX8MP-PD22.1.2-rc2
+*   34: BSP-Yocto-NXP-i.MX8MP-PD22.1.2
+*   35: BSP-Yocto-NXP-i.MX8MP-PD22.1.y
+*   36: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc1
+*   37: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc2
+*   38: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc3
+*   39: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc4
+*   40: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc5
+*   41: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc6
+*   42: BSP-Yocto-NXP-i.MX8MP-PD23.1.0
+*   43: BSP-Yocto-NXP-i.MX8MP-PD23.1.y
+*   44: BSP-Yocto-NXP-i.MX8MP-PD24.1-rc1
+*   45: BSP-Yocto-NXP-i.MX8MP-PD24.1-rc2
+*   46: BSP-Yocto-NXP-i.MX8MP-PD24.1-rc3
+*   47: BSP-Yocto-NXP-i.MX8MP-PD24.1.0
+*   48: BSP-Yocto-NXP-i.MX8MP-PD24.1.y
+
+# Exemplary output for chosen BSP-Yocto-NXP-i.MX8MP-PD24.1.0
+*********************************************************************
+* Please choose one of the available builds:
+*
+no:                 machine: description and article number
+                             distro: supported yocto distribution
+                             target: supported build target
+
+1: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM
+                             Pollux PL1552.2
+                             PB-03123-001.A3
+                             distro: ampliphy-vendor
+                             target: phytec-headless-image
+2: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM
+                             Pollux PL1552.2
+                             PB-03123-001.A3
+                             distro: ampliphy-vendor-rauc
+                             target: phytec-headless-bundle
+                             target: phytec-headless-image
+3: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM
+                             Pollux PL1552.2
+                             PB-03123-001.A3
+                             distro: ampliphy-vendor-xwayland
+                             target: -c populate_sdk phytec-qt6demo-image
+                             target: phytec-qt6demo-image
+                             target: phytec-vision-image
+4: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM
+                             Pollux PL1552.2
+                             PB-03123-001.A3
+                             distro: securiphy-vendor
+                             target: phytec-securiphy-bundle
+                             target: phytec-securiphy-image
+5: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM
+                             Pollux PL1552.2
+                             PB-03123-001.A3
+                             distro: securiphy-vendor-provisioning
+                             target: phytec-provisioning-image
+
+
+

If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. After the configuration is done, +you can always run

+
host:~$ ./phyLinux info
+
+# Exemplary output
+**********************************************
+* The current BSP configuration is:
+*
+* SoC:  refs/heads/imx8mp
+* Release:  BSP-Yocto-NXP-i.MX8MP-PD24.1.0
+*
+**********************************************
+
+
+

to see which SoC and Release are selected in the current workspace. If +you do not want to use the selector, phyLinux also supports command-line +arguments for several settings

+
host:~$ MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.0
+
+
+

or view the help command for more information

+
host:~$ ./phyLinux  init --help
+
+usage: phyLinux init [-h] [--verbose] [--no-init] [-o REPOREPO] [-b REPOREPO_BRANCH] [-x XML] [-u URL] [-p PLATFORM] [-r RELEASE]
+
+options:
+  -h, --help          show this help message and exit
+  --verbose
+  --no-init           dont execute init after fetch
+  -o REPOREPO         Use repo tool from another url
+  -b REPOREPO_BRANCH  Checkout different branch of repo tool
+  -x XML              Use a local XML manifest
+  -u URL              Manifest git url
+  -p PLATFORM         Processor platform
+  -r RELEASE          Release version
+
+
+

After the execution of the init command, phyLinux will print a few important +notes as well as information for the next steps in the build process.

+
+
+

6.4. Advanced Usage

+

phyLinux can be used to transport software states over any medium. The state of +the software is uniquely identified by manifest.xml. You can create a +manifest, send it to another place and recover the software state with

+
host:~$ ./phyLinux init -x manifest.xml
+
+
+

You can also create a Git repository containing your software states. The +Git repository needs to have branches other than master, as we reserved the +master branch for different usage. Use phyLinux to check out the states

+
host:~$ ./phyLinux -u <url-of-your-git-repo>
+
+
+
+
+
+

7. Using build-container

+
+

Warning

+

Currently, it is not possible to run the phyLinux script inside of a container. +After a complete init with the phyLinux script on your host machine, you can use a container for the build. +If you do not have phyLinux script running on your machine, please see phyLinux Documentation.

+
+

There are various possibilities to run a build-container. Commonly used is +docker and podman, though we prefer podman as it does not need root privileges +to run.

+
+

7.1. Installation

+

How to install podman: https://podman.io +How to install docker: https://docs.docker.com/engine/install/

+
+
+

7.2. Available container

+

Right now we provide 4 different container based on Ubuntu LTS versions: +https://hub.docker.com/u/phybuilder

+
    +

  • yocto-ubuntu-16.04

    • +

  • yocto-ubuntu-18.04

    • +

  • yocto-ubuntu-20.04

    • +

  • yocto-ubuntu-22.04

    • +
+

These containers can be run with podman or docker. With Yocto Project branch Scarthgap the container “yocto-ubuntu-20.04” is preferred.

+
+
+

7.3. Download/Pull container

+
host:~$ podman pull docker.io/phybuilder/yocto-ubuntu-20.04
+
+OR
+
+host:~$ docker pull docker.io/phybuilder/yocto-ubuntu-20.04
+
+
+

By adding a tag at the end separated by a colon, you can also pull or run a special tagged container.

+
+

podman pull docker.io/phybuilder/yocto-ubuntu-20.04:phy2

+
+

You can find all available tags in our duckerhub space:

+ +

If you try to run a container, which is not pulled/downloaded, it will be pulled/downloaded automatically.

+

You can have a look at all downloaded/pulled container with:

+
$USERNAME@$HOSTNAME:~$ podman images
+REPOSITORY                               TAG         IMAGE ID      CREATED       SIZE
+docker.io/phybuilder/yocto-ubuntu-22.04  latest      d626178e448d  4 months ago  935 MB
+docker.io/phybuilder/yocto-ubuntu-22.04  phy2        d626178e448d  4 months ago  935 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  phy2        e29a88b7172a  4 months ago  900 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  latest      e29a88b7172a  4 months ago  900 MB
+docker.io/phybuilder/yocto-ubuntu-18.04  phy1        14c9c3e477d4  7 months ago  567 MB
+docker.io/phybuilder/yocto-ubuntu-18.04  latest      14c9c3e477d4  7 months ago  567 MB
+docker.io/phybuilder/yocto-ubuntu-16.04  phy1        28c73e13ab4f  7 months ago  599 MB
+docker.io/phybuilder/yocto-ubuntu-16.04  latest      28c73e13ab4f  7 months ago  599 MB
+docker.io/phybuilder/yocto-ubuntu-22.04  phy1        5a0ef4b41935  8 months ago  627 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  phy1        b5a26a86c39f  8 months ago  680 MB
+
+
+
+
+

7.4. Run container

+

To run and use container for a Yocto build, first enter to your folder, where +you run phyLinux init before. Then start the container

+
host:~$ podman run --rm=true -v /home:/home --userns=keep-id --workdir=$PWD -it docker.io/phybuilder/yocto-ubuntu-20.04 bash
+
+
+
+

Note

+

To run and use a container with docker, it is not that simple like with podman. +Therefore the container-user has to be defined and configured. +Furthermore forwarding of credentials is not given per default and has to be configured as well.

+
+

Now your commandline should look something like that (where $USERNAME is the +user, who called “podman run” and the char/number code diffs every time a +container is started)

+
$USERNAME@6593e2c7b8f6:~$
+
+
+
+

Warning

+

If the given username is “root” you will not be able to run bitbake at all. +Please be sure, you run the container with your own user.

+
+

Now you are ready to go on and starting the build. +To stop/close the container, just call

+
$USERNAME@6593e2c7b8f6:~$ exit
+
+
+
+
+
+

8. Working with Poky and Bitbake

+
+

8.1. Start the Build

+

After you download all the metadata with phyLinux init, you have to set up the +shell environment variables. This needs to be done every time you open a new +shell for starting builds. We use the shell script provided by Poky in its +default configuration. From the root of your project directory type

+
host:~$ source sources/poky/oe-init-build-env
+
+
+

The abbreviation for the source command is a single dot

+
host:~$ . sources/poky/oe-init-build-env
+
+
+

The current working directory of the shell should change to build/. Before +building for the first time, you should take a look at the main configuration +file

+
host:~$ vim conf/local.conf
+
+
+

Your local modifications for the current build are stored here. Depending on +the SoC, you might need to accept license agreements. For example, to build the +image for Freescale/NXP processors you need to accept the GPU and VPU binary +license agreements. You have to uncomment the corresponding line

+
# Uncomment to accept NXP EULA # EULA can be found under
+../sources/meta-freescale/EULA ACCEPT_FSL_EULA = "1"
+
+
+

Now you are ready to build your first image. We suggest starting with our +smaller non-graphical image phytec-headless-image to see if everything is +working correctly

+
host:~$ bitbake phytec-headless-image
+
+
+

The first compile process takes about 40 minutes on a modern Intel Core i7. All +subsequent builds will use the filled caches and should take about 3 minutes.

+
+
+

8.2. Images

+

If everything worked, the images can be found under

+
host:~$ cd deploy/images/<MACHINE>
+
+
+

The easiest way to test your image is to configure your board for SD card boot +and to flash the build image to the SD card

+
host:~$ sudo dd if=phytec-headless-image-<MACHINE>.wic of=/dev/<your_device> bs=1M conv=fsync
+
+
+

Here <your_device> could be “sde”, for example, depending on your system. Be +very careful when selecting the right drive! Selecting the wrong drive can +erase your hard drive! The parameter conv=fsync forces a data buffer to write +to the device before dd returns.

+

After booting you can log in using a serial cable or over ssh. There is no +root password. That is because of the debug settings in conf/local.conf. If +you uncomment the line

+
#EXTRA_IMAGE_FEATURES = "debug-tweaks"
+
+
+

the debug settings, like setting an empty root password, will not be applied.

+
+
+

8.3. Accessing the Development States between Releases

+

Special release manifests exist to give you access to the current development +states of the Yocto BSP. They will be displayed in the phyLinux selection +menu with the ending PDXX.X.y

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.y
+
+
+

This will initialize a BSP that will track the latest development state.

+
+
+

8.4. Inspect your Build Configuration

+

Poky includes several tools to inspect your build layout. You can inspect the +commands of the layer tool

+
host:~$ bitbake-layers
+
+
+

It can, for example, be used to view in which layer a specific recipe gets +modified

+
host:~$ bitbake-layers show-appends
+
+
+

Before running a build you can also launch Toaster to be able to inspect the +build details with the Toaster web GUI

+
host:~$ source toaster start
+
+
+

Maybe you need to install some requirements, first

+
host:~$ pip3 install -r
+../sources/poky/bitbake/toaster-requirements.txt
+
+
+

You can then point your browser to http://0.0.0.0:8000/ and continue working +with Bitbake. All build activity can be monitored and analyzed from this web +server. If you want to learn more about Toaster, look at +https://docs.yoctoproject.org/dev/toaster-manual/index.html. +To shut down the Toaster web GUI again, execute

+
host:~$ source toaster stop
+
+
+
+
+

8.5. BSP Features of meta-phytec and meta-ampliphy

+
+

8.5.1. Buildinfo

+

The buildinfo task is a feature in our recipes that prints instructions to +fetch the source code from the public repositories. So you do not have to look +into the recipes yourself. To see the instructions, e.g. for the barebox +package, execute

+
host:~$ bitbake barebox -c buildinfo
+
+
+

in your shell. This will print something like

+
(mini) HOWTO: Use a local git repository to build barebox:
+
+To get source code for this package and version (barebox-2022.02.0-phy1), execute
+
+$ mkdir -p ~/git
+$ cd ~/git
+$ git clone git://git.phytec.de/barebox barebox
+$ cd ~/git/barebox
+$ git checkout -b v2022.02.0-phy1-local-development 7fe12e65d770f7e657e683849681f339a996418b
+
+You now have two possible workflows for your changes:
+
+1. Work inside the git repository:
+Copy and paste the following snippet to your "local.conf":
+
+SRC_URI:pn-barebox = "git://${HOME}/git/barebox;branch=${BRANCH}"
+SRCREV:pn-barebox = "${AUTOREV}"
+BRANCH:pn-barebox = "v2022.02.0-phy1-local-development"
+
+After that you can recompile and deploy the package with
+
+$ bitbake barebox -c compile
+$ bitbake barebox -c deploy
+
+Note: You have to commit all your changes. Otherwise yocto doesn't pick them up!
+
+2. Work and compile from the local working directory
+To work and compile in an external source directory we provide the
+externalsrc.bbclass. To use it, copy and paste the following snippet to your
+"local.conf":
+
+INHERIT += "externalsrc"
+EXTERNALSRC:pn-barebox = "${HOME}/git/barebox"
+EXTERNALSRC_BUILD:pn-barebox = "${HOME}/git/barebox"
+
+Note: All the compiling is done in the EXTERNALSRC directory. Every time
+you build an Image, the package will be recompiled and build.
+
+NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded.
+NOTE: Writing buildhistory
+
+
+

As you can see, everything is explained in the output.

+
+

Warning

+

Using externalsrc breaks a lot of Yocto’s internal dependency +mechanisms. It is not guaranteed that any changes to the source +directory are automatically picked up by the build process and +incorporated into the root filesystem or SD card image. You have to +always use –force. E.g. to compile barebox and redeploy it to +deploy/images/<machine> execute

+
host:~$ bitbake barebox -c compile --force
+host:~$ bitbake barebox -c deploy
+
+
+
+

To update the SD card image with a new kernel or image first force the +compilation of it and then force a rebuild of the root filesystem. Use

+
host:~$ bitbake phytec-qt6demo-image -c rootfs --force
+
+
+

Note that the build system is not modifying the external source directory. If +you want to apply all patches the Yocto recipe is carrying to the external +source directory, run the line

+
SRCTREECOVEREDTASKS="" BB_ENV_PASSTHROUGH_ADDITIONS="$BB_ENV_PASSTHROUGH_ADDITIONS SRCTREECOVEREDTASKS" bitbake <recipe> -c patch
+
+
+
+
+
+

8.6. BSP Customization

+

To get you started with the BSP, we have summarized some basic tasks from the +Yocto official documentation. It describes how to add additional software to +the image, change the kernel and bootloader configuration, and integrate +patches for the kernel and bootloader.

+

Minor modifications, such as adding software, are done in the file +build/conf/local.conf. There you can overwrite global configuration variables +and make small modifications to recipes.

+

There are 2 ways to make major changes:

+
    +

  1. Either create your own layer and use bbappend files.

    2. +

  2. Add everything to PHYTEC’s Distro layer meta-ampliphy.

    3. +
+

Creating your own layer is described in the section Create your own Layer.

+
+

8.6.1. Disable Qt Demo

+

By default, the BSP image phytec-qt6demo-image starts a Qt6 Demo application +on the attached display or monitor. If you want to stop the demo and use the +Linux framebuffer console behind it, connect to the target via serial cable +or ssh and execute the shell command

+
target:~$ systemctl stop phytec-qtdemo.service
+
+
+

This command stops the demo temporarily. To start it again, reboot the +board or execute

+
target:~$ systemctl start phytec-qtdemo.service
+
+
+

You can disable the service permanently, so it does not start on boot

+
target:~$ systemctl disable phytec-qtdemo.service
+
+
+
+

Tip

+

The last command only disables the service. It does not stop immediately. +To see the current status execute

+
target:~$ systemctl status phytec-qtdemo.service
+
+
+
+

If you want to disable the service by default, edit the file +build/conf/local.conf and add the following line

+
# file build/conf/local.conf
+SYSTEMD_AUTO_ENABLE:pn-phytec-qtdemo = "disable"
+
+
+

After that, rebuild the image

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

8.6.2. Framebuffer Console

+

On boards with a display interface, the framebuffer console is enabled per +default. You can attach a USB keyboard and log in. To change the keyboard +layout from the English default to German, type

+
target:~$ loadkeys /usr/share/keymaps/i386/qwertz/de-latin1.map.gz
+
+
+

To detach the framebuffer console, run

+
target:~$ echo 0 > sys/class/vtconsole/vtcon1/bind
+
+
+

To completely deactivate the framebuffer console, disable the following kernel +configuration option

+
Device Drivers->Graphics Support->Support for framebuffer devices->Framebuffer Console Support
+
+
+

More information can be found at: +https://www.kernel.org/doc/Documentation/fb/fbcon.txt

+
+
+

8.6.3. Tools Provided in the Prebuild Image

+
+

8.6.3.1. RAM Benchmark

+

Performing RAM and cache performance tests can best be done by using pmbw +(Parallel Memory Bandwidth Benchmark/Measurement Tool). Pmbw runs several +assembly routines which all use different access patterns to the caches and RAM +of the SoC. Before running the test, make sure that you have about 2 MiB of +space left on the device for the log files. We also lower the level of the +benchmark to ask the kernel more aggressively for resources. The benchmark test +will take several hours.

+

To start the test type

+
target:~$ nice -n -2 pmbw
+
+
+

Upon completion of the test run, the log file can be converted to a gnuplot +script with

+
target:~$ stats2gnuplot stats.txt > run1.gnuplot
+
+
+

Now you can transfer the file to the host machine and install any version of +gnuplot

+
host:~$ sudo apt-get install gnuplot host:~$ gnuplot run1.gnuplot
+
+
+

The generated plots-<machine>.pdf file contains all plots. To render single +plots as png files for any web output you can use Ghostscript

+
host:~$ sudo apt-get install ghostscript
+host:~$ gs -dNOPAUSE -dBATCH -sDEVICE=png16m -r150 -sOutputFile='page-%00d.png' plots-phyboard-wega-am335x-1.pdf
+
+
+
+
+
+

8.6.4. Add Additional Software for the BSP Image

+

To add additional software to the image, look at the OpenEmbedded layer index: +https://layers.openembedded.org/layerindex/branch/scarthgap/layers/

+

First, select the Yocto version of the BSP you have from the drop-down list in +the top left corner and click Recipes. Now you can search for a software +project name and find which layer it is in. In some cases, the program is in +meta-openembedded, openembedded-core, or Poky which means that the recipe +is already in your build tree. This section describes how to add additional +software when this is the case. If the package is in another layer, see the next +section.

+

You can also search the list of available recipes

+
host:~$ bitbake -s | grep <program name> # fill in program name, like in
+host:~$ bitbake -s | grep lsof
+
+
+

When the recipe for the program is already in the Yocto build, you can simply +add it by appending a configuration option to your file build/conf/local.conf. +The general syntax to add additional software to an image is

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " <package1> <package2>"
+
+
+

For example, the line

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " ldd strace file lsof"
+
+
+

installs some helper programs on the target image.

+
+

Warning

+

The leading whitespace is essential for the append command.

+
+

All configuration options in local.conf apply to all images. Consequently, the +tools are now included in both images phytec-headless-image and +phytec-qt6demo-image.

+
+

8.6.4.1. Notes about Packages and Recipes

+

You are adding packages to the IMAGE_INSTALL variable. Those are not necessarily +equivalent to the recipes in your meta-layers. A recipe defines per default a +package with the same name. But a recipe can set the PACKAGES variable to +something different and is able to generate packages with arbitrary names. +Whenever you look for software, you have to search for the package name and, +strictly speaking, not for the recipe. In the worst case, you have to look at +all PACKAGES variables. A tool such as Toaster can be helpful in some cases.

+

If you can not find your software in the layers provided in the folder +sources, see the next section to include another layer into the Yocto +build.

+

References: Yocto dev Documentation - Customizing Yocto builds

+
+
+
+

8.6.5. Add an Additional Layer

+

This is a step-by-step guide on how to add another layer to your Yocto build +and install additional software from it. As an example, we include the network +security scanner nmap in the layer meta-security. First, you must locate the +layer on which the software is hosted. Check out the OpenEmbedded MetaData +Index +and guess a little bit. The network scanner nmap is in the meta-security +layer. See meta-security on layers.openembedded.org. +To integrate it into the Yocto build, you have to check out the repository and +then switch to the correct stable branch. Since the BSP is based on the Yocto +Scarthgap build, you should try to use the Scarthgap branch in the layer, too.

+
host:~$ cd sources
+host:~$ git clone git://git.yoctoproject.org/meta-security
+host:~$ cd meta-security
+host:~$ git branch -r
+
+
+

All available remote branches will show up. Usually there should be ‘sumo’, +‘warrior’, ‘zeus’, ‘dunfell’, ‘hardnkott’, ‘kirkstone’, ‘mickledore’, ‘master’…

+
host:~$ git checkout scarthgap
+
+
+

Now we add the directory of the layer to the file build/conf/bblayers.conf by +appending the line

+
# file build/conf/bblayers.conf
+BBLAYERS += "${BSPDIR}/sources/meta-security"
+
+
+

to the end of the file. After that, you can check if the layer is available in +the build configuration by executing

+
host:~$ bitbake-layers show-layers
+
+
+

If there is an error like

+
ERROR: Layer 'security' depends on layer 'perl-layer', but this layer is not enabled in your configuration
+
+
+

the layer that you want to add (here meta-security), depends on another layer, +which you need to enable first. E.g. the dependency required here is a layer in +meta-openembedded (in the PHYTEC BSP it is in the path +sources/meta-openembedded/meta-perl/). To enable it, add the following line to +build/conf/bblayers.conf

+
# file build/conf/bblayers.conf
+BBLAYERS += "${BSPDIR}/sources/meta-openembedded/meta-perl"
+
+
+

Now the command bitbake-layers show-layers should print a list of all layers +enabled including meta-security and meta-perl. After the layer is included, +you can install additional software from it as already described above. The +easiest way is to add the following line (here is the package nmap)

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " nmap"
+
+
+

to your build/conf/local.conf. Do not forget to rebuild the image

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

8.6.6. Create your own layer

+

Creating your layer should be one of the first tasks when customizing the BSP. +You have two basic options. You can either copy and rename our meta-ampliphy, +or you can create a new layer that will contain your changes. The better option +depends on your use case. meta-ampliphy is our example of how to create a +custom Linux distribution that will be updated in the future. If you want to +benefit from those changes and are, in general, satisfied with the userspace +configuration, it could be the best solution to create your own layer on top of +Ampliphy. If you need to rework a lot of information and only need the basic +hardware support from PHYTEC, it would be better to copy meta-ampliphy, rename +it, and adapt it to your needs. You can also have a look at the OpenEmbedded +layer index to find different distribution layers. If you just need to add your +own application to the image, create your own layer.

+

In the following chapter, we have an embedded project called “racer” which we +will implement using our Ampliphy Linux distribution. First, we need to create +a new layer.

+

Yocto provides a script for that. If you set up the BSP and the shell is +ready, type

+
host:~$ bitbake-layers create-layer meta-racer
+
+
+

Default options are fine for now. Move the layer to the source directory

+
host:~$ mv meta-racer ../sources/
+
+
+

Create a Git repository in this layer to track your changes

+
host:~$ cd ../sources/meta-racer
+host:~$ git init && git add . && git commit -s
+
+
+

Now you can add the layer directly to your build/conf/bblayers.conf

+
BBLAYERS += "${BSPDIR}/sources/meta-racer"
+
+
+

or with a script provided by Yocto

+
host:~$ bitbake-layers add-layer meta-racer
+
+
+
+
+

8.6.7. Kernel and Bootloader Recipe and Version

+

First, you need to know which kernel and version are used for your target +machine. PHYTEC provides multiple kernel recipes linux-mainline, linux-ti +and linux-imx. The first one provides support for PHYTEC’s i.MX 6 and AM335x +modules and is based on the Linux kernel stable releases from kernel.org. +The Git repositories URLs are:

+
    +

  • linux-mainline: git://git.phytec.de/linux-mainline

    • +

  • linux-ti: git://git.phytec.de/linux-ti

    • +

  • linux-imx: git://git.phytec.de/linux-imx

    • +

  • barebox: git://git.phytec.de/barebox

    • +

  • u-boot-imx: git://git.phytec.de/u-boot-imx

    • +
+

To find your kernel provider, execute the following command

+
host:~$ bitbake virtual/kernel -e | grep "PREFERRED_PROVIDER_virtual/kernel"
+
+
+

The command prints the value of the variable +PREFERRED_PROVIDER_virtual/kernel. The variable is used in the internal +Yocto build process to select the kernel recipe to use. The following lines +are different outputs you might see

+
PREFERRED_PROVIDER_virtual/kernel="linux-mainline"
+PREFERRED_PROVIDER_virtual/kernel="linux-ti"
+PREFERRED_PROVIDER_virtual/kernel="linux-imx"
+
+
+

To see which version is used, execute bitbake -s. For example

+
host:~$ bitbake -s | egrep -e "linux-mainline|linux-ti|linux-imx|barebox|u-boot-imx"
+
+
+

The parameter -s prints the version of all recipes. The output contains the +recipe name on the left and the version on the right

+
barebox                      :2022.02.0-phy1-r7.0
+barebox-hosttools-native     :2022.02.0-phy1-r7.0
+barebox-targettools          :2022.02.0-phy1-r7.0
+linux-mainline               :5.15.102-phy1-r0.0
+
+
+

As you can see, the recipe linux-mainline has version 5.15.102-phy1. In +the PHYTEC’s linux-mainline Git repository, you will find a corresponding +tag v5.15.102-phy1. The version of the barebox recipe is 2022.02.0-phy1. +On i.MX8M* modules the output will contain linux-imx and u-boot-imx.

+
+
+

8.6.8. Kernel and Bootloader Configuration

+

The bootloader used by PHYTEC, barebox, uses the same build system as the +Linux kernel. Therefore, all commands in this section can be used to configure +the kernel and bootloader. To configure the kernel or bootloader, execute one of +the following commands

+
host:~$ bitbake -c menuconfig virtual/kernel  # Using the virtual provider name
+host:~$ bitbake -c menuconfig linux-ti        # Or use the recipe name directly
+host:~$ bitbake -c menuconfig linux-mainline  # Or use the recipe name directly (If you use an i.MX 6 or RK3288 Module)
+host:~$ bitbake -c menuconfig linux-imx       # Or use the recipe name directly (If you use an i.MX 8M*)
+host:~$ bitbake -c menuconfig barebox         # Or change the configuration of the bootloader
+host:~$ bitbake -c menuconfig u-boot-imx      # Or change the configuration of the bootloader (If you use an i.MX 8M*)
+
+
+

After that, you can recompile and redeploy the kernel or bootloader

+
host:~$ bitbake virtual/kernel -c compile  # Or 'barebox' for the bootloader
+host:~$ bitbake virtual/kernel -c deploy   # Or 'barebox' for the bootloader
+
+
+

Instead, you can also just rebuild the complete build output with

+
host:~$ bitbake phytec-headless-image  # To update the kernel/bootloader, modules and the images
+
+
+

In the last command, you can replace the image name with the name of an image of +your choice. The new images and binaries are in +build/deploy/images/<machine>/.

+
+

Warning

+

The build configuration is not permanent yet. Executing bitbake +virtual/kernel -c clean will remove everything.

+
+

To make your changes permanent in the build system, you have to integrate your +configuration modifications into a layer. For the configuration you have two +options:

+
    +

  • Include only a configuration fragment (a minimal diff between the +old and new configuration)

    • +

  • Complete default configuration (defconfig) after your +modifications.

    • +
+

Having a set of configuration fragments makes what was changed at which stage +more transparent. You can turn on and off the changes, you can manage +configurations for different situations and it helps when porting changes to new +kernel versions. You can also group changes together to reflect specific use +cases. A fully assembled kernel configuration will be deployed in the directory +build/deploy/images/<machine>. If you do not have any of those requirements, +it might be simpler to just manage a separate defconfig file.

+
+

8.6.8.1. Add a Configuration Fragment to a Recipe

+

The following steps can be used for both kernel and bootloader. Just replace the +recipe name linux-mainline in the commands with linux-ti, or barebox for +the bootloader. If you did not already take care of this, start with a clean +build. Otherwise, the diff of the configuration may be wrong

+
host:~$ bitbake linux-mainline -c clean
+host:~$ bitbake linux-mainline -c menuconfig
+
+
+

Make your configuration changes in the menu and generate a config +fragment

+
host:~$ bitbake linux-mainline -c diffconfig
+
+
+

which prints the path of the written file

+
Config fragment has been dumped into:
+/home/<path>/build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg
+
+
+

All config changes are in the file fragment.cfg which should consist of only +some lines. The following example shows how to create a bbappend file and how +to add the necessary lines for the config fragment. You just have to adjust the +directories and names for the specific recipe: linux-mainline, linux-ti, +linux-imx, u-boot-imx, or barebox.

+
sources/<layer>/recipes-kernel/linux/linux-mainline_%.bbappend     # For the recipe linux-mainline
+sources/<layer>/recipes-kernel/linux/linux-ti_%.bbappend           # For the recipe linux-ti
+sources/<layer>/recipes-kernel/linux/linux-imx_%.bbappend          # For the recipe linux-imx
+sources/<layer>/recipes-bsp/barebox/barebox_%.bbappend             # For the recipe barebox
+sources/<layer>/recipes-bsp/u-boot/u-boot-imx_%.bbappend           # For the recipe u-boot-imx
+
+
+

Replace the string layer with your own layer created as shown above (e.g. +meta-racer), or just use meta-ampliphy. To use meta-ampliphy, first, +create the directory for the config fragment and give it a new name (here +enable-r8169.cfg) and move the fragment to the layer.

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features
+# copy the path from the output of *diffconfig*
+host:~$ cp /home/<path>/build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg \
+    sources/meta-ampliphy/recipes-kernel/linux/features/enable-r8169.cfg
+
+
+

Then open the bbappend file (in this case +sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend ) with +your favorite editor and add the following lines

+
# contents of the file linux-mainline_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://enable-r8169.cfg \
+"
+
+
+
+

Warning

+

Do not forget to use the correct bbappend filenames: linux-ti_%.bbappend +for the linux-ti recipe and barebox_%.bbappend for the bootloader in the +folder recipes-bsp/barebox/ !

+
+

After saving the bbappend file, you have to rebuild the image. Yocto should +pick up the recipe changes automatically and generate a new image

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+
+
+

8.6.8.2. Add a Complete Default Configuration (defconfig) to a Recipe

+

This approach is similar to the one above, but instead of adding a fragment, a +defconfig is used. First, create the necessary folders in the layer you want +to use, either your own layer or meta-ampliphy

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features/ # For both linux-mainline and linux-ti
+host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features/ # Or for the bootloader
+
+
+

Then you have to create a suitable defconfig file. Make your configuration +changes using menuconfig and then save the defconfig file to the layer

+
host:~$ bitbake linux-mainline -c menuconfig # Or use recipe name linux-ti or barebox
+host:~$ bitbake linux-mainline -c savedefconfig # Create file 'defconfig.temp' in the work directory
+
+
+

This will print the path to the generated file

+
Saving defconfig to ..../defconfig.temp
+
+
+

Then, as above, copy the generated file to your layer, rename it to defconfig, +and add the following lines to the bbappend file (here +sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend)

+
# contents of the file linux-mainline_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://defconfig \
+"
+
+
+
+

Tip

+

Do not forget to use the correct bbappend filenames: linux-ti_%.bbappend +for the linux-ti recipe and barebox_%.bbappend for the bootloader in the +folder recipes-bsp/barebox/ !

+
+

After that, rebuild your image as the changes are picked up automatically

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+
+
+
+

8.6.9. Patch the Kernel or Bootloader with devtool

+

Apart from using the standard versions of kernel and bootloader which are +provided in the recipes, you can modify the source code or use our own +repositories to build your customized kernel.

+ + + + + + + + + + + + +

PRO

CON

Standard workflow of the +official Yocto documentation

Uses additional hard drive space +as the sources get duplicated

Toolchain does not have to +recompile everything

No optimal cache usage, build +overhead

+

Devtool is a set of helper scripts to enhance the user workflow of Yocto. It +was integrated with version 1.8. It is available as soon as you set up your +shell environment. Devtool can be used to:

+
    +

  • modify existing sources

    • +

  • integrate software projects into your build setup

    • +

  • build software and deploy software modifications to your target

    • +
+

Here we will use devtool to patch the kernel. We use linux-mainline as an +example for the AM335x Kernel. The first command we use is devtool modify - x +<recipe> <directory>

+
host:~$ devtool modify -x linux-mainline linux-mainline
+
+
+

Devtool will create a layer in build/workspace where you can see all +modifications done by devtool . It will extract the sources corresponding to +the recipe to the specified directory. A bbappend will be created in the +workspace directing the SRC_URI to this directory. Building an image with +Bitbake will now use the sources in this directory. Now you can modify lines +in the kernel

+
host:~$ vim linux-mainline/arch/arm/boot/dts/am335x-phycore-som.dtsi
+      -> make a change
+host:~$ bitbake phytec-qt6demo-image
+
+
+

Your changes will now be recompiled and added to the image. If you want to store +your changes permanently, it is advisable to create a patch from the changes, +then store and backup only the patch. You can go into the linux-mainline +directory and create a patch using Git. How to create a patch is described in +Patch the Kernel or Bootloader using the “Temporary Method” and is the same for all methods.

+

If you want to learn more about devtool, visit:

+

Yocto dev - Devtool +or Devtool Quick Reference

+
+
+

8.6.10. Patch the Kernel or Bootloader using the “Temporary Method”

+ + + + + + + + + + + + +

PRO

CON

No overhead, no extra +configuration

Changes are easily overwritten +by Yocto (Everything is +lost!!).

Toolchain does not have to +recompile everything

+

It is possible to alter the source code before Bitbake configures and compiles +the recipe. Use Bitbake’ s devshell command to jump into the source +directory of the recipe. Here is the barebox recipe

+
host:~$ bitbake barebox -c devshell # or linux-mainline, linux-ti, linux-imx, u-boot-imx
+
+
+

After executing the command, a shell window opens. The current working directory +of the shell will be changed to the source directory of the recipe inside the +tmp folder. Here you can use your favorite editor, e.g. vim, emacs, or any +other graphical editor, to alter the source code. When you are finished, exit +the devshell by typing exit or hitting CTRL-D.

+

After leaving the devshell you can recompile the package

+
host:~$ bitbake barebox -c compile --force # or linux-mainline, linux-ti, linux-imx, u-boot-imx
+
+
+

The extra argument ‘–force’ is important because Yocto does not recognize +that the source code was changed.

+
+

Tip

+

You cannot execute the bitbake command in the devshell . You have +to leave it first.

+
+

If the build fails, execute the devshell command again and fix it. If the build +is successful, you can deploy the package and create a new SD card image

+
host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox.bin
+host:~$ bitbake phytec-headless-image # new WIC image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic
+
+
+
+

Warning

+

If you execute a clean e.g bitbake barebox -c clean , or if Yocto fetches +the source code again, all your changes are lost!!!

+

To avoid this, you can create a patch and add it to a bbappend file. It is +the same workflow as described in the section about changing the +configuration.

+

You have to create the patch in the devshell if you use the temporary +method and in the subdirectory created by devtool if you used devtool.

+
+
host:~$ bitbake barebox -c devshell            # Or linux-mainline, linux-ti
+host(devshell):~$ git status                   # Show changes files
+host(devshell):~$ git add <file>               # Add a special file to the staging area
+host(devshell):~$ git commit -m "important modification"   # Creates a commit with a not so useful commit message
+host(devshell):~$ git format-patch -1 -o ~/    # Creates a patch of the last commit and saves it in your home folder
+/home/<user>/0001-important-modification.patch  # Git prints the path of the written patch file
+host(devshell):~$ exit
+
+
+

After you have created the patch, you must create a bbappend file for it. The +locations for the three different recipes - linux-mainline , linux-ti , and +barebox - are

+
sources/<layer>/recipes-kernel/linux/linux-mainline_%.bbappend     # For the recipe linux-mainline
+sources/<layer>/recipes-kernel/linux/linux-ti_%.bbappend           # For the recipe linux-ti
+sources/<layer>/recipes-kernel/linux/linux-imx_%.bbappend        # For the recipe linux-imx
+sources/<layer>/recipes-bsp/barebox/barebox_%.bbappend             # For the recipe barebox
+sources/<layer>/recipes-bsp/u-boot/u-boot-imx_%.bbappend           # For the recipe u-boot-imx
+
+
+

The following example is for the recipe barebox. You have to adjust the paths. +First, create the folders and move the patch into them. Then create the +bbappend file

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features   # Or use your own layer instead of *meta-ampliphy*
+host:~$ cp ~/0001-important-modification.patch sources/meta-ampliphy/recipes-bsp/barebox/features  # copy patch
+host:~$ touch sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend
+
+
+
+

Tip

+

Pay attention to your current work directory. You have to execute the +commands in the BSP top-level directory. Not in the build directory!

+
+

After that use your favorite editor to add the following snipped into the +bbappend file (here +sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend)

+
# contents of the file barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://0001-important-modification.patch \
+"
+
+
+

Save the file and rebuild the barebox recipe with

+
host:~$ bitbake barebox -c clean # Or linux-ti, linux-mainline, linux-imx, u-boot-imx
+host:~$ bitbake barebox
+
+
+

If the build is successful, you can rebuild the final image with

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+

Further Resources:

+

The Yocto Project has some documentation for software developers. Check the +‘Kernel Development Manual’ for more information about how to configure the +kernel. Please note that not all of the information from the Yocto manual can +be applied to the PHYTEC BSP as we use the classic kernel approach of Yocto +and most of the documentation assumes the Yocto kernel approach.

+ +
+
+

8.6.11. Working with the Kernel and Bootloader using SRC_URI in local.conf

+

Here we present a third option to make kernel and bootloader changes. You have +external checkouts of the linux-mainline, linux-ti, or barebox Git +repositories. You will overwrite the URL of the source code fetcher, the +variable SRC_URI, to point to your local checkout instead of the remote +repositories.

+ + + + + + + + + + + + + + + +

PRO

CON

All changes are saved with +Git

Many working directories in +build/tmp-glibc/work/<machine>/<package>/

You have to commit every change +before recompiling

For each change, the toolchain +compiles everything from scratch +(avoidable with ccache)

+

First, you need a local clone of the Git repository barebox or +kernel. If you do not have one, use the commands

+
host:~$ mkdir ~/git
+host:~$ cd ~/git
+host:~$ git clone git://git.phytec.de/barebox
+host:~$ cd barebox
+host:~$ git checkout -b v2022.02.0-phy remotes/origin/v2022.02.0-phy
+
+
+

Add the following snippet to the file build/conf/local.conf

+
# Use your own path to the git repository
+# NOTE: Branch name in variable "BRANCH_pn-barebox" should be the same as the
+# branch which is used in the repository folder. Otherwise your commits won't be recognized later.
+BRANCH:pn-barebox = "v2022.02.0-phy"
+SRC_URI:pn-barebox = "git:///${HOME}/git/barebox;branch=${BRANCH}"
+SRCREV:pn-barebox = "${AUTOREV}"
+
+
+

You also have to set the correct BRANCH name in the file. Either you create your +own branch in the Git repository, or you use the default (here +“v2015.02.0-phy”). Now you should recompile barebox from your own source

+
host:~$ bitbake barebox -c clean
+host:~$ bitbake barebox -c compile
+
+
+

The build should be successful because the source was not changed yet.

+

You can alter the source in ~/git/barebox or the default defconfig (e.g. +~/git/barebox/arch/arm/configs/imx_v7_defconfig). After you are satisfied with +your changes, you have to make a dummy commit for Yocto. If you do not, +Yocto will not notice that the source code was modified in your repository +folder (e.g. ~/git/barebox/)

+
host:~$ git status  # show modified files
+host:~$ git diff    # show changed lines
+host:~$ git commit -a -m "dummy commit for yocto"   # This command is important!
+
+
+

Try to compile your new changes. Yocto will automatically notice that the +source code was changed and fetches and configures everything from scratch.

+
host:~$ bitbake barebox -c compile
+
+
+

If the build fails, go back to the source directory, fix the problem, and +recommit your changes. If the build was successful, you can deploy barebox and +even create a new SD card image.

+
host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox-phyflex-imx6-2.bin
+host:~$ bitbake phytec-headless-image # new sd-card image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic
+
+
+

If you want to make additional changes, just make another commit in the +repository and rebuild barebox again.

+
+
+

8.6.12. Add Existing Software with “Sustainable Method”

+

Now that you have created your own layer, you have a second option to add +existing software to existing image definitions. Our standard image is defined +in meta-ampliphy

+
meta-ampliphy/recipes-images/images/phytec-headless-image.bb
+
+
+

In your layer, you can now modify the recipe with a bbappend without modifying +any BSP code

+
meta-racer/recipes-images/images/phytec-headless-image.bbappend
+
+
+

The append will be parsed together with the base recipe. As a result, you can +easily overwrite all variables set in the base recipe, which is not always what +you want. If we want to include additional software, we need to append it to the +IMAGE_INSTALL variable

+
IMAGE_INSTALL:append = " rsync"
+
+
+
+
+

8.6.13. Add Linux Firmware Files to the Root Filesystem

+

It is a common task to add an extra firmware file to your root filesystem into +/lib/firmware/. For example, WiFi adapters or PCIe Ethernet cards might need +proprietary firmware. As a solution, we use a bbappend in our layer. To create +the necessary folders, bbappend and copy the firmware file type

+
host:~$ cd meta-racer   # go into your layer
+host:~$ mkdir -p recipes-kernel/linux-firmware/linux-firmware/
+host:~$ touch recipes-kernel/linux-firmware/linux-firmware_%.bbappend
+host:~$ cp ~/example-firmware.bin recipes-kernel/linux-firmware/linux-firmware/    # adapt filename
+
+
+

Then add the following content to the bbappend file and replace every +occurrence of example-firmware.bin with your firmware file name.

+
# file recipes-kernel/linux-firmware/linux-firmware_%.bbappend
+
+FILESEXTRAPATHS:prepend := "${THISDIR}/linux-firmware:"
+SRC_URI += "file://example-firmware.bin"
+
+do_install:append () {
+        install -m 0644 ${WORKDIR}/example-firmware.bin ${D}/lib/firmware/example-firmware.bin
+}
+
+# NOTE: Use "=+" instead of "+=". Otherwise file is placed into the linux-firmware package.
+PACKAGES =+ "${PN}-example"
+FILES:${PN}-example = "/lib/firmware/example-firmware.bin"
+
+
+

Now try to build the linux-firmware recipe

+
host:~$ . sources/poky/oe-init-build-env
+host:~$ bitbake linux-firmware
+
+
+

This should generate a new package deploy/ipk/all/linux-firmware-example.

+

As the final step, you have to install the firmware package to your image. You +can do that in your local.conf or image recipe via

+
# file local.conf or image recipe
+IMAGE_INSTALL += "linux-firmware-example"
+
+
+
+

Warning

+

Ensure that you have adapted the package name linux-firmware-example with +the name you assigned in linux-firmware_%.bbappend.

+
+
+
+

8.6.14. Change the u-boot Environment via bbappend Files

+

All i.MX8M* products use the u-boot bootloader. The u-boot environment can be +modified using the Temporary Method. In the u-boot-imx sources modify the +header file corresponding to the processor located in +include/configs/phycore_imx8m*. New environment variables should be added at +the end of CONFIG_EXTRA_ENV_SETTINGS

+
#define CONFIG_EXTRA_ENV_SETTINGS \
+[...]
+PHYCORE_FITIMAGE_ENV_BOOTLOGIC \
+"newvariable=1\0"
+
+
+

Commit the changes and and create the file u-boot-imx_%.bbappend in your layer +at <layer>/recipes-bsp/u-boot/u-boot-imx_%.bbappend

+
# contents of the file u-boot-imx_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://0001-environment-addition.patch \
+"
+
+
+
+
+

8.6.15. Change the barebox Environment via bbappend Files

+

Since BSP-Yocto-AM335x-16.2.0 and BSP-Yocto-i.MX6-PD16.1.0, the barebox +environment handling in meta-phytec has changed. Now it is possible to add, +change, and remove files in the barebox environment via the Python bitbake +task do_env. There are two Python functions to change the environment. Their +signatures are:

+
    +

  • env_add(d, ***filename as string*, ***file content as string*): +to add a new file or overwrite an existing file

    • +

  • env_rm(d, ***filename as string*): to remove a file

    • +
+

The first example of a bbappend file in the custom layer meta-racer shows +how to add a new non-volatile variable linux.bootargs.fb in the barebox +environment folder /env/nv/

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_add(d, "nv/linux.bootargs.fb", "imxdrm.legacyfb_depth=32\n")
+}
+
+
+

The next example shows how to replace the network configuration file +/env/network/eth0

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_add(d, "network/eth0",
+"""#!/bin/sh
+
+# ip setting (static/dhcp)
+ip=static
+global.dhcp.vendor_id=barebox-${global.hostname}
+
+# static setup used if ip=static
+ipaddr=192.168.178.5
+netmask=255.255.255.0
+gateway=192.168.178.1
+serverip=192.168.178.1
+""")
+}
+
+
+

In the above example, the Python multiline string syntax “”” text “”” is +used to avoid adding multiple newline characters \n into the recipe Python +code. The Python function env_add can add and overwrite environment files.

+

The next example shows how to remove an already added environment file, for +example , /env/boot/mmc

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_rm(d, "boot/mmc")
+}
+
+
+
+

8.6.15.1. Debugging the Environment

+

If you want to see all environment files that are added in the build process, +you can enable a debug flag in the local.conf

+
# file local.conf
+ENV_VERBOSE = "1"
+
+
+

After that, you have to rebuild the barebox recipe to see the debugging +output

+
host:~$ bitbake barebox -c clean
+host:~$ bitbake barebox -c configure
+
+
+

The output of the last command looks like this

+
[...]
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/allow_color' content "false"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.base' content "consoleblank=0"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.fb' content "imxdrm.legacyfb_depth=32"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.rootfs' content "rootwait ro fsck.repair=yes"
+
+
+
+
+

8.6.15.2. Changing the Environment (depending on Machines)

+

If you need to apply some barebox environment modifications only to a single +or only a few machines, you can use Bitbake’ s machine overwrite syntax. For +the machine overwrite syntax, you append a machine name or SoC name (such as +mx6 , ti33x, or rk3288 ) with an underscore to a variable or task

+
DEPENDS:remove:mx6 = "virtual/libgl" or
+python do_env_append_phyboard-mira-imx6-4().
+
+
+

The next example adds the environment variables only if the MACHINE is set to +phyboard-mira-imx6-4

+
# file meta-phytec/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append:phyboard-mira-imx6-4() {
+    env_add(d, "nv/linux.bootargs.cma", "cma=64M\n")
+}
+
+
+

Bitbake’s override syntax for variables is explained in more detail at: +https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-metadata.html#conditional-metadata

+
+
+

8.6.15.3. Upgrading the barebox Environment from Previous BSP Releases

+

Prior to BSP version BSP-Yocto-AM335x-16.2.0 and BSP-Yocto-i.MX6-PD16.1.0 , +barebox environment changes via bbappend file were done differently. For +example, the directory structure in your meta layer (here meta-skeleton ) may +have looked like this

+
host:~$ tree -a sources/meta-skeleton/recipes-bsp/barebox/
+sources/meta-skeleton/recipes-bsp/barebox
+├── barebox
+│   └── phyboard-wega-am335x-3
+│       ├── boardenv
+│       │   └── .gitignore
+│       └── machineenv
+│           └── nv
+│               └── linux.bootargs.cma
+└── barebox_%.bbappend
+
+
+

and the file barebox_%.bbappend contained

+
# file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:"
+
+
+

In this example, all environment changes from the directory boardenv in the +layer meta-phytec are ignored and the file nv/linux.bootargs.cma is added. +For the new handling of the barebox environment, you use the Python +functions env_add and env_rm in the Python task do_env. Now the above +example translates to a single Python function in the file +barebox_%.bbappend that looks like

+
# file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:"
+python do_env:append() {
+    # Removing files (previously boardenv)
+    env_rm(d, "config-expansions")
+    # Adding new files (previously machineenv)
+    env_add(d, "nv/linux.bootargs.cma", "cma=64M\n")
+}
+
+
+
+
+
+

8.6.16. Changing the Network Configuration

+

To tweak IP addresses, routes, and gateways at runtime you can use the tools +ifconfig and ip . Some examples

+
target:~$ ip addr                                         # Show all network interfaces
+target:~$ ip route                                        # Show all routes
+target:~$ ip addr add 192.168.178.11/24 dev eth0          # Add static ip and route to interface eth0
+target:~$ ip route add default via 192.168.178.1 dev eth0 # Add default gateway 192.168.178.1
+target:~$ ip addr del 192.168.178.11/24 dev eth0          # Remove static ip address from interface eth0
+
+
+

The network configuration is managed by systemd-networkd . To query the +current status use

+
target:~$ networkctl status
+target:~$ networkctl list
+
+
+

The network daemon reads its configuration from the directories +/etc/systemd/network/ , /run/systemd/network/ , and /lib/systemd/network/ +(from higher to lower priority). A sample configuration in +/lib/systemd/network/10-eth0.network looks like this

+
# file /lib/systemd/network/10-eth0.network
+[Match]
+Name=eth0
+
+[Network]
+Address=192.168.3.11/24
+Gateway=192.168.3.10
+
+
+

These files *.network replace /etc/network/interfaces from other +distributions. You can either edit the file 10-eth0.network in-place or copy +it to /etc/systemd/network/ and make your changes there. After changing a file +you must restart the daemon to apply your changes

+
target:~$ systemctl restart systemd-networkd
+
+
+

To see the syslog message of the network daemon, use

+
target:~$ journalctl --unit=systemd-networkd.service
+
+
+

To modify the network configuration at build time, look at the recipe +sources/meta-ampliphy/recipes-core/systemd/systemd-machine-units.bb +and the interface files in the folder +meta-ampliphy/recipes-core/systemd/systemd-machine-units/ where the static IP +address configuration for eth0 (and optionally eth1) is done.

+

For more information, see https://wiki.archlinux.org/title/Systemd-networkd +and https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html.

+
+
+

8.6.17. Changing the Wireless Network Configuration

+
+

8.6.17.1. Connecting to a WLAN Network

+
    +

  • First set the correct regulatory domain for your country

    • +
+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

You will see

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+
    +

  • Set up the wireless interface

    • +
+
target:~$ ip link    # list all interfaces. Search for wlan*
+target:~$ ip link set up dev wlan0
+
+
+
    +

  • Now you can scan for available networks

    • +
+
target:~$ iw wlan0 scan | grep SSID
+
+
+

You can use a cross-platform supplicant with support for WEP, WPA, and +WPA2 called wpa_supplicant for an encrypted connection.

+
    +

  • To do so, add the network credentials to the file +/etc/wpa_supplicant.conf

    • +
+
Confluence country=DE network={ ssid="<SSID>" proto=WPA2 psk="<KEY>" }
+
+
+
    +

  • Now a connection can be established

    • +
+
target:~$ wpa_supplicant -Dnl80211 -c/etc/wpa_supplicant.conf -iwlan0 -B
+
+
+

This should result in the following output

+
ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see the section Changing the Network Configuration.

+
    +

  • First, create the directory

    • +
+
target:~$ mkdir -p /etc/systemd/network/
+
+
+
    +

  • Then add the following configuration snippet in +/etc/systemd/network/10-wlan0.network

    • +
+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+
    +

  • Now, restart the network daemon so that the configuration takes effect

    • +
+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+

8.6.17.2. Creating a WLAN Access Point

+

This section provides a basic access point (AP) configuration for a +secured WPA2 network.

+

Find the name of the WLAN interface with

+
target:~$ ip link
+
+
+

Edit the configuration in /etc/hostapd.conf. It is strongly dependent on +the use case. The following shows an example

+
# file /etc/hostapd.conf
+interface=wlan0
+driver=nl80211
+ieee80211d=1
+country_code=DE
+hw_mode=g
+ieee80211n=1
+ssid=Test-Wifi
+channel=2
+wpa=2
+wpa_passphrase=12345678
+wpa_key_mgmt=WPA-PSK
+wpa_pairwise=CCMP
+
+
+

Set up and start the DHCP server for the network interface wlan0 via +systemd-networkd

+
target:~$ mkdir -p /etc/systemd/network/
+target:~$ vi /etc/systemd/network/10-wlan0.network
+
+
+

Insert the following text into the file

+
[Match]
+Name=wlan0
+
+[Network]
+Address=192.168.0.1/24
+DHCPServer=yes
+
+[DHCPServer]
+EmitDNS=yes
+target:~$ systemctl restart systemd-networkd
+target:~$ systemctl status  systemd-networkd -l   # check status and see errors
+
+
+

Start the userspace daemon hostapd

+
target:~$ systemctl start hostapd
+target:~$ systemctl status hostapd -l # check for errors
+
+
+

Now, you should see the WLAN network Test-Wifi on your terminal device +(laptop, smartphone, etc.).

+

If there are problems with the access point, you can either check the log +messages with

+
target:~$ journalctl --unit=hostapd
+
+
+

or start the daemon in debugging mode from the command line

+
target:~$ systemctl stop hostapd
+target:~$ hostapd -d /etc/hostapd.conf -P /var/run/hostapd.pid
+
+
+

You should see

+
...
+wlan0: interface state UNINITIALIZED->ENABLED
+wlan0: AP-ENABLED
+
+
+

Further information about AP settings and the userspace daemon +hostapd can be found at

+
https://wireless.wiki.kernel.org/en/users/documentation/hostapd
+https://w1.fi/hostapd/
+
+
+
+
+

8.6.17.3. phyCORE-i.MX 6UL/ULL Bluetooth

+

Special consideration must be paid when working with any Bluetooth on a +phyCORE-i.MX 6UL/ULL. For further information, please check L-844e.A5 i.MX +6UL/ULL BSP Manual - Bluetooth.

+
+
+
+

8.6.18. Add OpenCV Libraries and Examples

+

OpenCV (Opensource Computer Vision https://opencv.org/) is an open-source +library for computer vision applications.

+

To install the libraries and examples edit the file conf/local.conf in the +Yocto build system and add

+
# file conf/local.conf
+# Installing OpenCV libraries and examples
+LICENSE_FLAGS_ACCEPTED += "commercial_libav"
+LICENSE_FLAGS_ACCEPTED += "commercial_x264"
+IMAGE_INSTALL:append = " \
+    opencv \
+    opencv-samples \
+    libopencv-calib3d2.4 \
+    libopencv-contrib2.4 \
+    libopencv-core2.4 \
+    libopencv-flann2.4 \
+    libopencv-gpu2.4 \
+    libopencv-highgui2.4 \
+    libopencv-imgproc2.4 \
+    libopencv-legacy2.4 \
+    libopencv-ml2.4 \
+    libopencv-nonfree2.4 \
+    libopencv-objdetect2.4 \
+    libopencv-ocl2.4 \
+    libopencv-photo2.4 \
+    libopencv-stitching2.4 \
+    libopencv-superres2.4 \
+    libopencv-video2.4 \
+    libopencv-videostab2.4 \
+"
+
+
+

Then rebuild your image

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+

Tip

+

Most examples do not work out of the box, because they depend on the GTK +graphics library. The BSP only supports Qt6 .

+
+
+
+

8.6.19. Add Minimal PHP web runtime with lightpd

+

This is one example of how to add a small runtime for PHP applications and a web +server on your target. Lighttpd can be used together with the PHP command line +tool over cgi. This solution weights only 5.5 MiB of disk storage. It is already +preconfigured in meta-ampliphy. Just modify the build configuration to install +it on the image

+
# file conf/local.conf
+# install lighttpd with php cgi module
+IMAGE_INSTALL:append = " lighttpd"
+
+
+

After booting the image, you should find the example web content in /www/pages +. For testing php, you can delete the index.html and replace it with a +index.php file

+
<html>
+  <head>
+    <title>PHP-Test</title>
+  </head>
+  <body>
+    <?php phpinfo(); ?>
+  </body>
+</html>
+
+
+

On your host, you can point your browser to the board’s IP, (e.g. 192.168.3.11) +and the phpinfo should show up.

+
+
+
+

8.7. Common Tasks

+
+

8.7.1. Debugging a User Space Application

+

The phytec-qt6demo-image can be cross-debugged without any change. For +cross-debugging, you just have to match the host sysroot with the image in use. +So you need to create a toolchain for your image

+
host:~$ bitbake -c populate_sdk phytec-qt6demo-image
+
+
+

Additionally, if you want to have full debug and backtrace capabilities for all +programs and libraries in the image, you could add

+
DEBUG_BUILD = "1"
+
+
+

to the conf/local.conf. This is not necessary in all cases. The compiler +options will then be switched from FULL_OPTIMIZATION to DEBUG_OPTIMIZATION. Look +at the Poky source code for the default assignment of DEBUG_OPTIMIZATION.

+

To start a cross debug session, install the SDK as mentioned previously, source +the SDK environment, and run Qt Creator in the same shell. If you do not use +Qt Creator, you can directly call the arm-<..>-gdb debugger instead which +should be in your path after sourcing the environment script.

+

If you work with Qt Creator, have a look at the appropriate documentation +delivered with your product (either QuickStart or Application Guide) for +information on how to set up the toolchain.

+

When starting the debugger with your userspace application you will get a +SIGILL, an illegal instruction from the libcrypto. Openssl probes for the +system capabilities by trapping illegal instructions, which will trigger GDB. +You can ignore this and hit Continue (c command). You can permanently ignore +this stop by adding

+
handle SIGILL nostop
+
+
+

to your GDB startup script or in the Qt Creator GDB configuration panel. +Secondly, you might need to disable a security feature by adding

+
set auto-load safe-path /
+
+
+

to the same startup script, which will enable the automatic loading of libraries +from any location.

+

If you need to have native debugging, you might want to install the debug +symbols on the target. You can do this by adding the following line to your +conf/local.conf

+
EXTRA_IMAGE_FEATURES += "dbg-pkgs"
+
+
+

For cross-debugging, this is not required as the debug symbols will be loaded +from the host side and the dbg-pkgs are included in the SDK of your image +anyway.

+
+
+

8.7.2. Generating Source Mirrors, working Offline

+

Modify your site.conf (or local.conf if you do not use a site.conf ) as +follows

+
#DL_DIR ?= "" don't set it! It will default to a directory inside /build
+SOURCE_MIRROR_URL = "file:///home/share/yocto_downloads/"
+INHERIT += "own-mirrors"
+BB_GENERATE_MIRROR_TARBALLS = "1"
+
+
+

Now run

+
host:~$ bitbake --runall=fetch <image>
+
+
+

for all images and for all machines you want to provide sources for. This will +create all the necessary tar archives. We can remove all SCM subfolders, as +they are duplicated with the tarballs

+
host:~$ rm -rf build/download/git2/
+etc...
+
+
+

Please consider that we used a local source mirror for generating the dl_dir. +Because of that, some archives will be linked locally.

+

First, we need to copy all files, resolving symbolic links into the new mirror +directory

+
host:~$ rsync -vaL <dl_dir> ${TOPDIR}/../src_mirror/
+
+
+

Now we clean the /build directory by deleting everything except /build/conf/ +but including /build/conf/sanity. We change site.conf as follows

+
SOURCE_MIRROR_URL = "file://${TOPDIR}/../src_mirror"
+INHERIT += "own-mirrors"
+BB_NO_NETWORK = "1"
+SCONF_VERSION = "1"
+
+
+

The BSP directory can now be compressed with

+
host:~$ tar cfJ <filename>.tar.xz <folder>
+
+
+

where filename and folder should be the full BSP Name.

+
+
+

8.7.3. Compiling on the Target

+

To your local.conf add

+
IMAGE_FEATURES:append = " tools-sdk dev-pkgs"
+
+
+
+
+

8.7.4. Different Toolchains

+

There are several ways to create a toolchain installer in Poky. One option is +to run

+
host:~$ bitbake meta-toolchain
+
+
+

This will generate a toolchain installer in build/deploy/sdk which can be used +for cross-compiling of target applications. However, the installer does not +include libraries added to your image, so it is a bare GCC compiler only. This +is suited for bootloader and kernel development.

+

Another you can run is

+
host:~$ bitbake -c populate_sdk <your_image>
+
+
+

This will generate a toolchain installer containing all necessary development +packages of the software installed on the root filesystem of the target. This +installer can be handed over to the user space application development team and +includes all necessary parts to develop an application. If the image contains +the QT libraries, all of those will be available in the installer too.

+

The third option is to create the ADT (Application Development Toolkit) +installer. It will contain the cross-toolchain and some tools to aid the +software developers, for example, an Eclipse plugin and a QEMU target +simulator.

+
host:~$ bitbake adt-installer
+
+
+

The ADT is untested for our BSP at the moment.

+
+

8.7.4.1. Using the SDK

+

After generating the SDK with

+
host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
+
+

run the generated binary with

+
host:~$ deploy/sdk/ampliphy-glibc-x86_64-phytec-qt6demo-image-cortexa9hf-vfp-neon-toolchain-i.MX6-PD15.3-rc.sh
+Enter target directory for SDK (default: /opt/ampliphy/i.MX6-PD15.3-rc):
+You are about to install the SDK to "/opt/ampliphy/i.MX6-PD15.3-rc". Proceed[Y/n]?
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
+
+

You can activate the toolchain for your shell by sourcing the file +environment-setup in the toolchain directory

+
host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+
+
+
+

Note

+

To be able to build a Qt6 application with the SDK and the Meson Build system, the following has to be done, after the SDK has been sourced:

+
host:~$ export PATH=$OECORE_NATIVE_SYSROOT/usr/libexec:$PATH
+
+
+
+

Then the necessary tools like the cross compiler and linker are in your PATH. To +compile a simple C program, use

+
host:~$ $CC main.c -o main
+
+
+

The environment variable $CC contains the path to the ARM cross compiler and +other compiler arguments needed like -march , -sysroot and –mfloat-abi.

+
+

Tip

+

You cannot compile programs only with the compiler name like

+
host:~$ arm-phytec-linux-gnueabi-gcc main.c -o main
+
+
+

It will fail in many cases. Always use CC, CFLAGS, LDFLAGS, and so on.

+
+

For convenience, the environment-setup exports other environment variables +like CXX, LD, SDKTARGETSYSROOT.

+

A simple makefile compiling a C and C++ program may look like this

+
# Makefile
+TARGETS=c-program cpp-program
+
+all: $(TARGETS)
+
+c-program: c-program.c
+    $(CC) $(CFLAGS) $(LDFLAGS) $< -o $@
+
+cpp-program: cpp-program.cpp
+    $(CXX) $(CXXFLAGS) $(LDFLAGS) $< -o $@
+
+.PHONY: clean
+clean:
+    rm -f $(TARGETS)
+
+
+

To compile for the target, just source the toolchain in your shell before +executing make

+
host:~$ make     # Compiling with host CC, CXX for host architecture
+host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+host:~$ make     # Compiling with target CC, CXX for target architecture
+
+
+

If you need to specify additionally included directories in the sysroot of the +toolchain, you can use an ‘=’ sign in the -I argument like

+
-I=/usr/include/SDL
+
+
+

GCC replaces it by the sysroot path (here +/opt/ampliphy/i.MX6-PD15.3-rc/sysroots/cortexa9hf-vfp-neon-phytec-linux-gnueabi/). +See the main page of GCC for more information.

+
+

Tip

+

The variables $CFLAGS and $CXXFLAGS contain the compiler debug flag ‘-g’ by +default. This includes debugging information in the binary and making it +bigger. Those should be removed from the production image. If you create a +Bitbake recipe, the default behavior is to turn on ‘-g’ too. The debugging +symbols are used in the SDK rootfs to be able to get debugging information +when invoking GDB from the host. Before installing the package to the +target rootfs, Bitbake will invoke strip on the program which removes the +debugging symbols. By default, they are not found nor required on the target +root filesystem

+
+
+
+

8.7.4.2. Using the SDK with GNU Autotools

+

Yocto SDK is a straightforward tool for a project that uses the GNU +Autotools. The traditional compile steps for the host are usually

+
host:~$ ./autogen.sh # maybe not needed
+host:~$ ./configure
+host:~$ make
+host:~$ make install DESTDIR=$PWD/build/
+
+
+

The commands to compile for the target machine with the Yocto SDK are quite +similar. The following commands assume that the SDK was unpacked to the +directory /opt/phytec-ampliphy/i.MX6-PD15.3.0/ (adapt the path as needed)

+
host:~$ source /opt/phytec-ampliphy/i.MX6-PD15.3.0/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+host:~$ ./autogen.sh  # maybe not needed
+host:~$ ./configure ${CONFIGURE_FLAGS}
+host:~$ make
+host:~$ make install DESTDIR=$PWD/build/
+
+
+

Refer to the official Yocto documentation for more information: +https://docs.yoctoproject.org/dev/singleindex.html#autotools-based-projects

+
+
+
+

8.7.5. Working with Kernel Modules

+

You will come to the point where you either need to set some options for a +kernel module or you want to blacklist a module. Those things are handled by +udev and go into *.conf files in

+
/etc/modprobe.d/\*.conf.
+
+
+

If you want to specify an option at build time, there are three relevant +variables. If you just want to autoload a module that has no autoload +capabilities, add it to

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+
+
+

either in the kernel recipe or in the global variable scope. If you need to +specify options for a module, you can do so with

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+KERNEL_MODULE_PROBECONF += "your-module"
+module_conf_your-module = "options your-module parametername=parametervalue"
+
+
+

if you want to blacklist a module from autoloading, you can do it intuitively +with

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+KERNEL_MODULE_PROBECONF += "your-module"
+module_conf_your-module = "blacklist your-module"
+
+
+
+
+

8.7.6. Working with udev

+

Udev (Linux dynamic device management) is a system daemon that handles dynamic +device management in /dev. It is controlled by udev rules that are located +in /etc/udev/rules.d (sysadmin configuration space) and /lib/udev/rules.d/ +(vendor-provided). Here is an example of an udev rule file

+
# file /etc/udev/rules.d/touchscreen.rules
+# Create a symlink to any touchscreen input device
+SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="input:*-e0*,3,*a0,1,*18,*", SYMLINK+="input/touchscreen0"
+SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="ads7846", SYMLINK+="input/touchscreen0"
+
+
+

See https://www.freedesktop.org/software/systemd/man/latest/udev.html for more details +about the syntax and usage. To get the list of attributes for a specific device +that can be used in an udev rule you can use the udevadm info tool. It +prints all existing attributes of the device node and its parents. The key-value +pairs from the output can be copied and pasted into a rule file. Some examples

+
target:~$ udevadm info -a /dev/mmcblk0
+target:~$ udevadm info -a /dev/v4l-subdev25
+target:~$ udevadm info -a -p /sys/class/net/eth0
+
+
+

After changing an udev rule, you have to notify the daemon. Otherwise, your +changes are not reflected. Use the following command

+
target:~$ udevadm control --reload-rules
+
+
+

While developing udev rules you should monitor the events in order to see when +devices are attached or unattached to the system. Use

+
target:~$ udevadm monitor
+
+
+

Furthermore, it is very useful to monitor the system log in another shell, +especially if the rule executes external scripts. Execute

+
target:~$ journalctl -f
+
+
+
+

Tip

+

You cannot start daemons or heavy scripts in a RUN attribute. See +https://www.freedesktop.org/software/systemd/man/latest/udev.html#RUN%7Btype%7D .

+

This can only be used for very short-running foreground tasks. Running an +event process for a long period of time may block all further events for this +or a dependent device. Starting daemons or other long-running processes is +not appropriate for udev; the forked processes, detached or not, will be +unconditionally killed after the event handling has finished. You can use the +special attribute ENV{SYSTEMD_WANTS}=”service-name.service” and a +systemdservice instead.

+

See +https://unix.stackexchange.com/questions/63232/what-is-the-correct-way-to-write-a-udev-rule-to-stop-a-service-under-systemd.

+
+
+
+
+
+

9. Troubleshooting

+
+

9.1. Setscene Task Warning

+

This warning occurs when the Yocto cache is in a dirty state.

+
WARNING: Setscene task X ([...]) failed with exit code '1' - real task
+
+
+

You should avoid canceling the build process or if you have to, press Ctrl-C +once and wait until the build process has stopped. To remove all these warnings +just clean the sstate cache and remove the build folders.

+
host:~$ bitbake phytec-headless-image -c cleansstate && rm -rf tmp deploy/ipk
+
+
+
+
+
+

10. Yocto Documentation

+

The most important piece of documentation for a BSP user is probably the +developer manual. +https://docs.yoctoproject.org/dev/dev-manual/index.html

+

The chapter about common tasks is a good starting point. +https://docs.yoctoproject.org/dev/dev-manual/layers.html#understanding-and-creating-layers

+

The complete documentation is available on one single HTML page, which is good +for searching for a feature or a variable name. +https://docs.yoctoproject.org/dev/singleindex.html

+
+ + +
+
+
+ +
+ +
+

© Copyright 2024, PHYTEC Messtechnik GmbH.

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
Languages
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/.buildinfo b/previews/271/zh_CN/.buildinfo new file mode 100644 index 000000000..78e0ec411 --- /dev/null +++ b/previews/271/zh_CN/.buildinfo @@ -0,0 +1,4 @@ +# Sphinx build info version 1 +# This file records the configuration used when building these files. When it is not found, a full rebuild will be done. +config: fdc44998c329910305b7635681c02437 +tags: 645f666f9bcd5a90fca523b33c5a78b7 diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8.doctree new file mode 100644 index 000000000..dd7dd05d1 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mm/head.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mm/head.doctree new file mode 100644 index 000000000..82eb555e7 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mm/head.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mm/imx8mm.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mm/imx8mm.doctree new file mode 100644 index 000000000..b6501104b Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mm/imx8mm.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mm/pd22.1.1.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mm/pd22.1.1.doctree new file mode 100644 index 000000000..8bf2e07e9 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mm/pd22.1.1.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mm/pd23.1.0.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mm/pd23.1.0.doctree new file mode 100644 index 000000000..0f5328935 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mm/pd23.1.0.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mn/head.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mn/head.doctree new file mode 100644 index 000000000..3dba5dd64 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mn/head.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mn/imx8mn.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mn/imx8mn.doctree new file mode 100644 index 000000000..cf12cb4ae Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mn/imx8mn.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mn/pd22.1.1.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mn/pd22.1.1.doctree new file mode 100644 index 000000000..9f157d6f7 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mn/pd22.1.1.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mn/pd23.1.0.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mn/pd23.1.0.doctree new file mode 100644 index 000000000..666d79232 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mn/pd23.1.0.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp-libra-fpsc/head.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp-libra-fpsc/head.doctree new file mode 100644 index 000000000..78c87ad2e Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp-libra-fpsc/head.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.doctree new file mode 100644 index 000000000..13d03c2e1 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/head.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/head.doctree new file mode 100644 index 000000000..866c261b9 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/head.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/imx8mp.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/imx8mp.doctree new file mode 100644 index 000000000..73d66489f Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/imx8mp.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/mainline-head.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/mainline-head.doctree new file mode 100644 index 000000000..d0741d8e0 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/mainline-head.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd22.1.1.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd22.1.1.doctree new file mode 100644 index 000000000..d7d6f1e8c Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd22.1.1.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd22.1.2.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd22.1.2.doctree new file mode 100644 index 000000000..2bd0a1489 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd22.1.2.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd23.1.0.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd23.1.0.doctree new file mode 100644 index 000000000..4500e3da2 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd23.1.0.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd24.1.0_nxp.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd24.1.0_nxp.doctree new file mode 100644 index 000000000..13ae81f6c Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd24.1.0_nxp.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd24.1.1.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd24.1.1.doctree new file mode 100644 index 000000000..c5f356694 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd24.1.1.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd24.1.2.doctree b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd24.1.2.doctree new file mode 100644 index 000000000..b8f6f340e Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx8/imx8mp/pd24.1.2.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx9/imx9.doctree b/previews/271/zh_CN/.doctrees/bsp/imx9/imx9.doctree new file mode 100644 index 000000000..6b8e460f8 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx9/imx9.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx9/imx93/imx93.doctree b/previews/271/zh_CN/.doctrees/bsp/imx9/imx93/imx93.doctree new file mode 100644 index 000000000..5fcaf5dd0 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx9/imx93/imx93.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx9/imx93/pd24.1.0.doctree b/previews/271/zh_CN/.doctrees/bsp/imx9/imx93/pd24.1.0.doctree new file mode 100644 index 000000000..ab202b427 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx9/imx93/pd24.1.0.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx9/imx93/pd24.1.1.doctree b/previews/271/zh_CN/.doctrees/bsp/imx9/imx93/pd24.1.1.doctree new file mode 100644 index 000000000..7b27bb044 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx9/imx93/pd24.1.1.doctree differ diff --git a/previews/271/zh_CN/.doctrees/bsp/imx9/imx93/pd24.2.0.doctree b/previews/271/zh_CN/.doctrees/bsp/imx9/imx93/pd24.2.0.doctree new file mode 100644 index 000000000..7656deb68 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/bsp/imx9/imx93/pd24.2.0.doctree differ diff --git a/previews/271/zh_CN/.doctrees/contributing_links.doctree b/previews/271/zh_CN/.doctrees/contributing_links.doctree new file mode 100644 index 000000000..8b26dcca7 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/contributing_links.doctree differ diff --git a/previews/271/zh_CN/.doctrees/environment.pickle b/previews/271/zh_CN/.doctrees/environment.pickle new file mode 100644 index 000000000..1aacbacc3 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/environment.pickle differ diff --git a/previews/271/zh_CN/.doctrees/index.doctree b/previews/271/zh_CN/.doctrees/index.doctree new file mode 100644 index 000000000..fca6baec0 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/index.doctree differ diff --git a/previews/271/zh_CN/.doctrees/rauc/kirkstone.doctree b/previews/271/zh_CN/.doctrees/rauc/kirkstone.doctree new file mode 100644 index 000000000..c3d2a9e10 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/rauc/kirkstone.doctree differ diff --git a/previews/271/zh_CN/.doctrees/rauc/manual-index.doctree b/previews/271/zh_CN/.doctrees/rauc/manual-index.doctree new file mode 100644 index 000000000..d6b6e3d95 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/rauc/manual-index.doctree differ diff --git a/previews/271/zh_CN/.doctrees/rauc/mickledore.doctree b/previews/271/zh_CN/.doctrees/rauc/mickledore.doctree new file mode 100644 index 000000000..100967188 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/rauc/mickledore.doctree differ diff --git a/previews/271/zh_CN/.doctrees/rauc/scarthgap.doctree b/previews/271/zh_CN/.doctrees/rauc/scarthgap.doctree new file mode 100644 index 000000000..4af1d145c Binary files /dev/null and b/previews/271/zh_CN/.doctrees/rauc/scarthgap.doctree differ diff --git a/previews/271/zh_CN/.doctrees/yocto/kirkstone.doctree b/previews/271/zh_CN/.doctrees/yocto/kirkstone.doctree new file mode 100644 index 000000000..11079fecc Binary files /dev/null and b/previews/271/zh_CN/.doctrees/yocto/kirkstone.doctree differ diff --git a/previews/271/zh_CN/.doctrees/yocto/manual-index.doctree b/previews/271/zh_CN/.doctrees/yocto/manual-index.doctree new file mode 100644 index 000000000..fccd61bea Binary files /dev/null and b/previews/271/zh_CN/.doctrees/yocto/manual-index.doctree differ diff --git a/previews/271/zh_CN/.doctrees/yocto/mickledore.doctree b/previews/271/zh_CN/.doctrees/yocto/mickledore.doctree new file mode 100644 index 000000000..7d7a5972b Binary files /dev/null and b/previews/271/zh_CN/.doctrees/yocto/mickledore.doctree differ diff --git a/previews/271/zh_CN/.doctrees/yocto/scarthgap.doctree b/previews/271/zh_CN/.doctrees/yocto/scarthgap.doctree new file mode 100644 index 000000000..a023729e8 Binary files /dev/null and b/previews/271/zh_CN/.doctrees/yocto/scarthgap.doctree differ diff --git a/previews/271/zh_CN/_images/Internal_Fuses.png b/previews/271/zh_CN/_images/Internal_Fuses.png new file mode 100644 index 000000000..0a280afbb Binary files /dev/null and b/previews/271/zh_CN/_images/Internal_Fuses.png differ diff --git a/previews/271/zh_CN/_images/Internal_Fuses1.png b/previews/271/zh_CN/_images/Internal_Fuses1.png new file mode 100644 index 000000000..32ca2d2fa Binary files /dev/null and b/previews/271/zh_CN/_images/Internal_Fuses1.png differ diff --git a/previews/271/zh_CN/_images/Internal_Fuses2.png b/previews/271/zh_CN/_images/Internal_Fuses2.png new file mode 100644 index 000000000..32ca2d2fa Binary files /dev/null and b/previews/271/zh_CN/_images/Internal_Fuses2.png differ diff --git a/previews/271/zh_CN/_images/JTAG_Mode.png b/previews/271/zh_CN/_images/JTAG_Mode.png new file mode 100644 index 000000000..287da4792 Binary files /dev/null and b/previews/271/zh_CN/_images/JTAG_Mode.png differ diff --git a/previews/271/zh_CN/_images/Libra-back-components.jpg b/previews/271/zh_CN/_images/Libra-back-components.jpg new file mode 100644 index 000000000..534205954 Binary files /dev/null and b/previews/271/zh_CN/_images/Libra-back-components.jpg differ diff --git a/previews/271/zh_CN/_images/Libra-front-components.jpg b/previews/271/zh_CN/_images/Libra-front-components.jpg new file mode 100644 index 000000000..6365565db Binary files /dev/null and b/previews/271/zh_CN/_images/Libra-front-components.jpg differ diff --git a/previews/271/zh_CN/_images/Nano_Fuse_BOOT.png b/previews/271/zh_CN/_images/Nano_Fuse_BOOT.png new file mode 100644 index 000000000..ce4d135f2 Binary files /dev/null and b/previews/271/zh_CN/_images/Nano_Fuse_BOOT.png differ diff --git a/previews/271/zh_CN/_images/Nano_QSPI_BOOT.png b/previews/271/zh_CN/_images/Nano_QSPI_BOOT.png new file mode 100644 index 000000000..b6560ec84 Binary files /dev/null and b/previews/271/zh_CN/_images/Nano_QSPI_BOOT.png differ diff --git a/previews/271/zh_CN/_images/Nano_SD_BOOT.jpg b/previews/271/zh_CN/_images/Nano_SD_BOOT.jpg new file mode 100644 index 000000000..8d9b9042c Binary files /dev/null and b/previews/271/zh_CN/_images/Nano_SD_BOOT.jpg differ diff --git a/previews/271/zh_CN/_images/Nano_Serial_downloader_BOOT.png b/previews/271/zh_CN/_images/Nano_Serial_downloader_BOOT.png new file mode 100644 index 000000000..9814af8a5 Binary files /dev/null and b/previews/271/zh_CN/_images/Nano_Serial_downloader_BOOT.png differ diff --git a/previews/271/zh_CN/_images/Nano_eMMC_BOOT.png b/previews/271/zh_CN/_images/Nano_eMMC_BOOT.png new file mode 100644 index 000000000..b80e6d659 Binary files /dev/null and b/previews/271/zh_CN/_images/Nano_eMMC_BOOT.png differ diff --git a/previews/271/zh_CN/_images/RS485_fullduplex_connection.png b/previews/271/zh_CN/_images/RS485_fullduplex_connection.png new file mode 100644 index 000000000..050e123f9 Binary files /dev/null and b/previews/271/zh_CN/_images/RS485_fullduplex_connection.png differ diff --git a/previews/271/zh_CN/_images/RS485_halfduplex_connection.png b/previews/271/zh_CN/_images/RS485_halfduplex_connection.png new file mode 100644 index 000000000..9b599a9ab Binary files /dev/null and b/previews/271/zh_CN/_images/RS485_halfduplex_connection.png differ diff --git a/previews/271/zh_CN/_images/RS485_halfduplex_connection1.png b/previews/271/zh_CN/_images/RS485_halfduplex_connection1.png new file mode 100644 index 000000000..4db999ecd Binary files /dev/null and b/previews/271/zh_CN/_images/RS485_halfduplex_connection1.png differ diff --git a/previews/271/zh_CN/_images/RS485_halfduplex_connection2.png b/previews/271/zh_CN/_images/RS485_halfduplex_connection2.png new file mode 100644 index 000000000..4db999ecd Binary files /dev/null and b/previews/271/zh_CN/_images/RS485_halfduplex_connection2.png differ diff --git a/previews/271/zh_CN/_images/RS485_halfduplex_connection3.png b/previews/271/zh_CN/_images/RS485_halfduplex_connection3.png new file mode 100644 index 000000000..9b599a9ab Binary files /dev/null and b/previews/271/zh_CN/_images/RS485_halfduplex_connection3.png differ diff --git a/previews/271/zh_CN/_images/SD_Card_Boot.jpg b/previews/271/zh_CN/_images/SD_Card_Boot.jpg new file mode 100644 index 000000000..ec7224420 Binary files /dev/null and b/previews/271/zh_CN/_images/SD_Card_Boot.jpg differ diff --git a/previews/271/zh_CN/_images/SD_Card_Boot.png b/previews/271/zh_CN/_images/SD_Card_Boot.png new file mode 100644 index 000000000..0fee073cd Binary files /dev/null and b/previews/271/zh_CN/_images/SD_Card_Boot.png differ diff --git a/previews/271/zh_CN/_images/SD_Card_Boot1.png b/previews/271/zh_CN/_images/SD_Card_Boot1.png new file mode 100644 index 000000000..875841b6d Binary files /dev/null and b/previews/271/zh_CN/_images/SD_Card_Boot1.png differ diff --git a/previews/271/zh_CN/_images/SD_Card_Boot2.png b/previews/271/zh_CN/_images/SD_Card_Boot2.png new file mode 100644 index 000000000..875841b6d Binary files /dev/null and b/previews/271/zh_CN/_images/SD_Card_Boot2.png differ diff --git a/previews/271/zh_CN/_images/SPI_NOR.png b/previews/271/zh_CN/_images/SPI_NOR.png new file mode 100644 index 000000000..497f23e66 Binary files /dev/null and b/previews/271/zh_CN/_images/SPI_NOR.png differ diff --git a/previews/271/zh_CN/_images/SPI_NOR1.png b/previews/271/zh_CN/_images/SPI_NOR1.png new file mode 100644 index 000000000..4dbc34b4c Binary files /dev/null and b/previews/271/zh_CN/_images/SPI_NOR1.png differ diff --git a/previews/271/zh_CN/_images/SPI_NOR2.png b/previews/271/zh_CN/_images/SPI_NOR2.png new file mode 100644 index 000000000..497f23e66 Binary files /dev/null and b/previews/271/zh_CN/_images/SPI_NOR2.png differ diff --git a/previews/271/zh_CN/_images/Test_Mode.png b/previews/271/zh_CN/_images/Test_Mode.png new file mode 100644 index 000000000..287da4792 Binary files /dev/null and b/previews/271/zh_CN/_images/Test_Mode.png differ diff --git a/previews/271/zh_CN/_images/UART1_RS232.jpg b/previews/271/zh_CN/_images/UART1_RS232.jpg new file mode 100644 index 000000000..b953cf79b Binary files /dev/null and b/previews/271/zh_CN/_images/UART1_RS232.jpg differ diff --git a/previews/271/zh_CN/_images/UART1_RS2321.jpg b/previews/271/zh_CN/_images/UART1_RS2321.jpg new file mode 100644 index 000000000..b80e6d659 Binary files /dev/null and b/previews/271/zh_CN/_images/UART1_RS2321.jpg differ diff --git a/previews/271/zh_CN/_images/UART1_RS485.png b/previews/271/zh_CN/_images/UART1_RS485.png new file mode 100644 index 000000000..96a081be0 Binary files /dev/null and b/previews/271/zh_CN/_images/UART1_RS485.png differ diff --git a/previews/271/zh_CN/_images/UART1_RS4851.png b/previews/271/zh_CN/_images/UART1_RS4851.png new file mode 100644 index 000000000..ed819f644 Binary files /dev/null and b/previews/271/zh_CN/_images/UART1_RS4851.png differ diff --git a/previews/271/zh_CN/_images/USB_HOST.jpg b/previews/271/zh_CN/_images/USB_HOST.jpg new file mode 100644 index 000000000..b80e6d659 Binary files /dev/null and b/previews/271/zh_CN/_images/USB_HOST.jpg differ diff --git a/previews/271/zh_CN/_images/USB_OTG.png b/previews/271/zh_CN/_images/USB_OTG.png new file mode 100644 index 000000000..fe72b24f3 Binary files /dev/null and b/previews/271/zh_CN/_images/USB_OTG.png differ diff --git a/previews/271/zh_CN/_images/USB_Serial_Download.png b/previews/271/zh_CN/_images/USB_Serial_Download.png new file mode 100644 index 000000000..875841b6d Binary files /dev/null and b/previews/271/zh_CN/_images/USB_Serial_Download.png differ diff --git a/previews/271/zh_CN/_images/USB_Serial_Download1.png b/previews/271/zh_CN/_images/USB_Serial_Download1.png new file mode 100644 index 000000000..0fee073cd Binary files /dev/null and b/previews/271/zh_CN/_images/USB_Serial_Download1.png differ diff --git a/previews/271/zh_CN/_images/USB_Serial_Download2.png b/previews/271/zh_CN/_images/USB_Serial_Download2.png new file mode 100644 index 000000000..6453fe0ab Binary files /dev/null and b/previews/271/zh_CN/_images/USB_Serial_Download2.png differ diff --git a/previews/271/zh_CN/_images/USB_Serial_Download3.png b/previews/271/zh_CN/_images/USB_Serial_Download3.png new file mode 100644 index 000000000..0fee073cd Binary files /dev/null and b/previews/271/zh_CN/_images/USB_Serial_Download3.png differ diff --git a/previews/271/zh_CN/_images/eMMC.jpg b/previews/271/zh_CN/_images/eMMC.jpg new file mode 100644 index 000000000..d41dc9ac3 Binary files /dev/null and b/previews/271/zh_CN/_images/eMMC.jpg differ diff --git a/previews/271/zh_CN/_images/eMMC.png b/previews/271/zh_CN/_images/eMMC.png new file mode 100644 index 000000000..32ca2d2fa Binary files /dev/null and b/previews/271/zh_CN/_images/eMMC.png differ diff --git a/previews/271/zh_CN/_images/eMMC1.png b/previews/271/zh_CN/_images/eMMC1.png new file mode 100644 index 000000000..0a280afbb Binary files /dev/null and b/previews/271/zh_CN/_images/eMMC1.png differ diff --git a/previews/271/zh_CN/_images/eMMC2.png b/previews/271/zh_CN/_images/eMMC2.png new file mode 100644 index 000000000..0a280afbb Binary files /dev/null and b/previews/271/zh_CN/_images/eMMC2.png differ diff --git a/previews/271/zh_CN/_images/gparted1.png b/previews/271/zh_CN/_images/gparted1.png new file mode 100644 index 000000000..5f6f842b6 Binary files /dev/null and b/previews/271/zh_CN/_images/gparted1.png differ diff --git a/previews/271/zh_CN/_images/gparted2.png b/previews/271/zh_CN/_images/gparted2.png new file mode 100644 index 000000000..149853c35 Binary files /dev/null and b/previews/271/zh_CN/_images/gparted2.png differ diff --git a/previews/271/zh_CN/_images/gparted3.png b/previews/271/zh_CN/_images/gparted3.png new file mode 100644 index 000000000..7caee2797 Binary files /dev/null and b/previews/271/zh_CN/_images/gparted3.png differ diff --git a/previews/271/zh_CN/_images/gparted4.png b/previews/271/zh_CN/_images/gparted4.png new file mode 100644 index 000000000..857f75b38 Binary files /dev/null and b/previews/271/zh_CN/_images/gparted4.png differ diff --git a/previews/271/zh_CN/_images/gparted5.png b/previews/271/zh_CN/_images/gparted5.png new file mode 100644 index 000000000..134a259b6 Binary files /dev/null and b/previews/271/zh_CN/_images/gparted5.png differ diff --git a/previews/271/zh_CN/_images/gparted6.png b/previews/271/zh_CN/_images/gparted6.png new file mode 100644 index 000000000..5593f49e7 Binary files /dev/null and b/previews/271/zh_CN/_images/gparted6.png differ diff --git a/previews/271/zh_CN/_images/gparted7.png b/previews/271/zh_CN/_images/gparted7.png new file mode 100644 index 000000000..45d967808 Binary files /dev/null and b/previews/271/zh_CN/_images/gparted7.png differ diff --git a/previews/271/zh_CN/_images/gparted8.png b/previews/271/zh_CN/_images/gparted8.png new file mode 100644 index 000000000..644191954 Binary files /dev/null and b/previews/271/zh_CN/_images/gparted8.png differ diff --git a/previews/271/zh_CN/_images/phyBOARD-Nash-iMX93-bottom-components.jpg b/previews/271/zh_CN/_images/phyBOARD-Nash-iMX93-bottom-components.jpg new file mode 100644 index 000000000..888a1ceb3 Binary files /dev/null and b/previews/271/zh_CN/_images/phyBOARD-Nash-iMX93-bottom-components.jpg differ diff --git a/previews/271/zh_CN/_images/phyBOARD-Nash-iMX93-top-components.jpg b/previews/271/zh_CN/_images/phyBOARD-Nash-iMX93-top-components.jpg new file mode 100644 index 000000000..74c3a4ed4 Binary files /dev/null and b/previews/271/zh_CN/_images/phyBOARD-Nash-iMX93-top-components.jpg differ diff --git a/previews/271/zh_CN/_images/phyBOARD-Pollux-back-components.jpg b/previews/271/zh_CN/_images/phyBOARD-Pollux-back-components.jpg new file mode 100644 index 000000000..534205954 Binary files /dev/null and b/previews/271/zh_CN/_images/phyBOARD-Pollux-back-components.jpg differ diff --git a/previews/271/zh_CN/_images/phyBOARD-Pollux-front-components.jpg b/previews/271/zh_CN/_images/phyBOARD-Pollux-front-components.jpg new file mode 100644 index 000000000..6365565db Binary files /dev/null and b/previews/271/zh_CN/_images/phyBOARD-Pollux-front-components.jpg differ diff --git a/previews/271/zh_CN/_images/phyBOARD-Segin-iMX93-bottom-components.jpg b/previews/271/zh_CN/_images/phyBOARD-Segin-iMX93-bottom-components.jpg new file mode 100644 index 000000000..7c484f384 Binary files /dev/null and b/previews/271/zh_CN/_images/phyBOARD-Segin-iMX93-bottom-components.jpg differ diff --git a/previews/271/zh_CN/_images/phyBOARD-Segin-iMX93-top-components.jpg b/previews/271/zh_CN/_images/phyBOARD-Segin-iMX93-top-components.jpg new file mode 100644 index 000000000..d849aedca Binary files /dev/null and b/previews/271/zh_CN/_images/phyBOARD-Segin-iMX93-top-components.jpg differ diff --git a/previews/271/zh_CN/_images/polis-back.jpg b/previews/271/zh_CN/_images/polis-back.jpg new file mode 100644 index 000000000..57cefde84 Binary files /dev/null and b/previews/271/zh_CN/_images/polis-back.jpg differ diff --git a/previews/271/zh_CN/_images/polis-front.jpg b/previews/271/zh_CN/_images/polis-front.jpg new file mode 100644 index 000000000..8a36aec26 Binary files /dev/null and b/previews/271/zh_CN/_images/polis-front.jpg differ diff --git a/previews/271/zh_CN/_images/rauc-ab-system.png b/previews/271/zh_CN/_images/rauc-ab-system.png new file mode 100644 index 000000000..8ba234506 Binary files /dev/null and b/previews/271/zh_CN/_images/rauc-ab-system.png differ diff --git a/previews/271/zh_CN/_images/rauc-switching-keyrings.png b/previews/271/zh_CN/_images/rauc-switching-keyrings.png new file mode 100644 index 000000000..db8aba14c Binary files /dev/null and b/previews/271/zh_CN/_images/rauc-switching-keyrings.png differ diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8.rst.txt new file mode 100644 index 000000000..dd4ea56b7 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8.rst.txt @@ -0,0 +1,12 @@ +============== +i.MX 8 Manuals +============== + +.. toctree:: + :caption: i.MX 8 Manuals + :maxdepth: 2 + + i.MX 8M Plus Manuals + Libra i.MX 8M Plus FPSC Manuals + i.MX 8M Mini Manuals + i.MX 8M Nano Manuals diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mm/head.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mm/head.rst.txt new file mode 100644 index 000000000..9e1a8ac42 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mm/head.rst.txt @@ -0,0 +1,571 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt6demo-image-phyboard-polis-imx8mm-5.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/imx-boot-tools/ +.. |link-bsp-images| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mm +.. _`static-pdf-dl`: ../../../_static/imx8mm-head.pdf + +.. IMX8(MM) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mm/phycore-imx8mm.c?h=v2022.04_2.2.2-phy5#n120 + + +.. General Replacements +.. |doc-id| replace:: L-1002e.Ax +.. |kit| replace:: **phyCORE-i.MX8M Mini Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Polis +.. |soc| replace:: i.MX 8M Mini +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MM +.. |debug-uart| replace:: ttymxc2 +.. |serial-uart| replace:: ttymxc0 +.. |bluetooth-uart| replace:: UART2 +.. |expansion-connector| replace:: X8 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx8_phytec_defconfig +.. |kernel-recipe-path| replace:: meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb +.. |kernel-repo-name| replace:: linux-phytec-imx +.. |kernel-repo-url| replace:: https://github.com/phytec/linux-phytec-imx +.. |kernel-socname| replace:: imx8mm +.. |kernel-tag| replace:: v5.15.71_2.2.2-phy3 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-offset| replace:: 33 +.. |u-boot-offset-boot-part| replace:: 33 +.. |u-boot-mmc-flash-offset| replace:: 0x42 +.. |u-boot-defconfig| replace:: phycore-imx8mm_defconfig +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx +.. |emmcdev-uboot| replace:: mmc 2 +.. |sdcarddev-uboot| replace:: mmc 1 + + +.. IMX8(MM) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MM +.. |u-boot-tag| replace:: v2022.04_2.2.2-phy5 + + +.. RAUC +.. |rauc-manual| replace:: L-1006e.A6 RAUC Update & Device Management Manual +.. _rauc-manual: https://www.phytec.de/cdocuments/?doc=F4DiM + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mm-phyboard-polis-rdk +.. |dt-som| replace:: imx8mm-phycore-som +.. |dtbo-rpmsg| replace:: imx8mm-phycore-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mm-phyboard-polis-peb-av-10.dtbo + +.. IMX8(MM) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n59` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`scarthgap` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MM +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: scarthgap +.. |yocto-distro| replace:: ampliphy-vendor +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: rootfs.wic.xz +.. |yocto-machinename| replace:: phyboard-polis-imx8mm-5 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MM-PD24.1.0 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MM-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MM-PD24.1.y +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (scarthgap) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 5.0.x +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Refs +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S1) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X30) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X2 ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MM) specific replacements +.. |sbc-network| replace:: \ +.. |pollux-fan-note| replace:: Only GPIO fan supported. +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M4 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mm_phyboard_polis/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8MM6_M4 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++----------------------+----------------------+ +| |doc-id| |soc| BSP | +| Manual Head | ++----------------------+----------------------+ +| Document Title | |doc-id| |soc| BSP | +| | Manual Head | ++----------------------+----------------------+ +| Document Type | BSP Manual | ++----------------------+----------------------+ +| Article Number | |doc-id| | ++----------------------+----------------------+ +| Yocto Manual | | ++----------------------+----------------------+ +| Release Date | XXXX/XX/XX | ++----------------------+----------------------+ +| Is Branch of | |doc-id| |soc| BSP | +| | Manual Head | ++----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +================ ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +================ ================ ================= ========== +.. +================ ================ ================= ========== + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +The |sbc| populated with either the i.MX 8M Mini SoC or i.MX 8M Nano SoC, is +supported. + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mm-head-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mm-head-getting-started: +.. include:: /bsp/getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, |ref-bootswitch| needs to be set to the following + position: + +.. list-table:: Bootmode Selection + + * - .. figure:: images/SD_Card_Boot.jpg + + Mini + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP | +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mm-head-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mm.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **fitImage**: Linux kernel FIT image +* **fitImage-its\*.its**: FIT image configuration file +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mm-phyboard-polis-rdk*.dtb**: Kernel device tree file +* **imx8mm-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.rootfs.wic.xz**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S1) +-------------------- + +The |sbc| features a boot switch with six individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mm-head-bootswitch: +.. include:: bootmode-switch.rsti + +.. include:: ../installing-os.rsti + +.. include:: ../efi.rsti +.. include:: /bsp/installing-distro-efi.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mm-head-development: + +Development +=========== + +Starting with this release, the boot behaviour in U-Boot changes. Before, kernel +and device tree came as separate blobs. Now, both will be included in a single +FIT image blob. Further, the logic for booting the PHYTEC ampliphy distributions +is moved to a boot script which itself is part of a separate FIT image blob. +To revert to the old style of booting, you may do + +.. code-block:: console + + u-boot=> run legacyboot + +.. note:: + + This way of booting is deprecated and will be removed in the next release. + By default, booting via this command will return an error as kernel and + device tree are missing in the boot partition. + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti +.. _imx8mm-head-development-build-uboot: +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti +.. include:: /bsp/imx8/development/kernel-standalone.rsti +.. include:: /bsp/imx-common/development/uuu.rsti + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx8/development/netboot.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mm-head-format-sd: + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. include:: /bsp/imx8/development/legacy_boot_deprecated.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mm-head-device-tree: +.. include:: /bsp/device-tree.rsti + +:: + + imx8mm-phyboard-polis-peb-eval-01.dtbo + |dtbo-peb-av-10| + imx8mm-phycore-rpmsg.dtbo + imx8mm-phycore-no-eth.dtbo + imx8mm-phycore-no-spiflash.dtbo + imx8mm-vm016.dtbo + imx8mm-vm016-fpdlink.dtbo + imx8mm-vm017.dtbo + imx8mm-vm017-fpdlink.dtbo + imx8mm-dual-vm017-fpdlink.dtbo + +.. _imx8mm-head-ubootexternalenv: +.. include:: ../../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX 0x00 + MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX 0x00 + MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B 0x00 + MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B 0x00 + >; + }; + +The first part of the string MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad (in this example +SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the desired muxing option for this pad. +The pad setting value (hex value on the right) defines different modes of the pad, for example, if +internal pull resistors are activated or not. In this case, the internal resistors are disabled. + +RS232/RS485 +----------- + +The |soc| SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +|ref-bootswitch| needs to be set correctly: + +.. list-table:: Switch between UART1 RS485/RS232 + + * - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS485.png + + **UART1 RS485** + + - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS232.jpg + + **UART1 RS232** + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n291` + +.. _imx8mm-head-network: + +Network +------- + +|sbc|-|soc| provides one Gigabit Ethernet interface. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +.. include:: ../../peripherals/wireless-network.rsti + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n383` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n335` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n87` + +.. include:: ../peripherals/gpios.rsti + +Pinmuxing of some GPIO pins in the device tree |dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_leds: leds1grp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1 0x16 + MX8MM_IOMUXC_GPIO1_IO14_GPIO1_IO14 0x16 + MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x16 + >; + }; + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n36` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n119` + +General I²C4 bus configuration (e.g. |dt-carrierboard|.dts): +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n244` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues. + +.. note:: + + If you deleted reserved EEPROM spaces, please contact our support! + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file |dt-som|.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n311` + +.. include:: /bsp/peripherals/rtc.rsti + +DT representation for I²C RTCs: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n319` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +'HS'). The USB subsystem has two independent USB controller cores. Both cores +are On-The-Go (OTG) controller cores and are capable of acting as a USB +peripheral device or a USB host. Each is connected to a USB 2.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +User USB2 (host) configuration is in the kernel device tree +|dt-carrierboard|.dts: + +.. code-block:: + + &usbotg2 { + dr_mode = "host"; + picophy,pre-emp-curr-control = <3>; + picophy,dc-vol-level-adjust = <7>; + status = "okay"; + }; + +DT representation for USB Host: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n347` + +.. include:: /bsp/peripherals/usb-otg.rsti + +Both USB interfaces are configured as host in the kernel device tree +|dt-carrierboard|.dts. See: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n335` + +CAN FD +------ + +The |sbc| has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. Hint:: + + phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. + There are different interfaces involved, which limits the datarate + capabilities of CANFD. + +.. Hint:: + + On phyBOARD-Polis-i.MX8MM a terminating resistor can be enabled by setting + S5 to ON if required. + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n175` + +.. include:: /bsp/peripherals/pcie.rsti + +Device Tree PCIe configuration of |dt-carrierboard|.dts: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n257` + +Audio +----- + +The PEB-AV-10-Connector exists in two versions and the 1531.1 version is +populated with a TI TLV320AIC3007 audio codec. Audio support is done via the I2S +interface and controlled via I2C. + +There is a 3.5mm headset jack with OMTP standard and an 8-pin header to connect +audio devices with the AV-Connector. The 8-pin header contains a mono speaker, +headphones, and line-in signals. + +.. include:: /bsp/peripherals/audio.rsti + +Device Tree Audio configuration: +:imx-dt:`overlays/imx8mm-phyboard-polis-peb-av-010.dtsi?h=v5.15.71_2.2.2-phy3#n54` + +.. include:: /bsp/peripherals/video.rsti + +Display +------- + +The 10" Display is always active. If the PEB-AV-Connector is not connected, an +error message may occur at boot. + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +The device tree of PEB-AV-10 can be found here: +:imx-dt:`overlays/imx8mm-phyboard-polis-peb-av-010.dtsi?h=v5.15.71_2.2.2-phy3` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Mini M4 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti + +.. +---------------------------------------------------------------------------+ +.. BSP EXTENSIONS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/bsp-extensions.rsti diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mm/imx8mm.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mm/imx8mm.rst.txt new file mode 100644 index 000000000..466d3e555 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mm/imx8mm.rst.txt @@ -0,0 +1,33 @@ +==================== +i.MX 8M Mini Manuals +==================== + +HEAD +==== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + head + +BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +============================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd23.1.0 + +BSP-Yocto-NXP-i.MX8MM-PD22.1.1 +============================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd22.1.1 diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mm/pd22.1.1.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mm/pd22.1.1.rst.txt new file mode 100644 index 000000000..b95972496 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mm/pd22.1.1.rst.txt @@ -0,0 +1,2435 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MM-PD22.1.1 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/imx-boot-tools/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mm +.. _`static-pdf-dl`: ../../../_static/imx8mm-pd22.1.1.pdf + +.. IMX8(MM) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mm/phycore-imx8mm.c?h=v2021.04_2.2.0-phy13#n188 + + +.. General Replacements +.. |atfloadaddr| replace:: 0x920000 +.. |kit| replace:: **phyCORE-i.MX8M Mini Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Polis +.. |soc| replace:: i.MX 8M Mini +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MM +.. |debug-uart| replace:: ttymxc2 +.. |serial-uart| replace:: ttymxc0 +.. |expansion-connector| replace:: X8 +.. |bluetooth-uart| replace:: UART2 + + +.. Linux Kernel +.. |kernel-socname| replace:: imx8mm +.. |kernel-tag| replace:: v5.10.72_2.2.0-phy17 +.. |emmcdev| replace:: mmcblk2 +.. |kernel-defconfig| replace:: imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx + +.. Bootloader +.. |u-boot-offset| replace:: 33 +.. |u-boot-offset-boot-part| replace:: 33 +.. |u-boot-mmc-flash-offset| replace:: 0x42 +.. |u-boot-defconfig| replace:: phycore-imx8mm_defconfig +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX8(MM) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MM +.. |u-boot-tag| replace:: v2021.04_2.2.0-phy13 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mm-phyboard-polis-rdk +.. |dt-som| replace:: imx8mm-phycore-som +.. |dtbo-rpmsg| replace:: imx8mm-phycore-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mm-phyboard-polis-peb-av-010.dtbo + +.. IMX8(MM) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n53` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`hardknott` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MM +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: hardknott +.. |yocto-distro| replace:: ampliphy-vendor-xwayland +.. |yocto-imagename| replace:: phytec-qt5demo-image +.. |yocto-machinename| replace:: phyboard-polis-imx8mm-5 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MM-PD22.1.1 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MM-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MM-PD22.1.y +.. |yocto-ref-manual| replace:: L-813e.A13 Yocto Reference Manual (hardknott) +.. _yocto-ref-manual: https://www.phytec.de/cdocuments/?doc=UIHsG +.. _yocto-ref-manual-kernel-and-bootloader-config: https://www.phytec.de/cdocuments/?doc=UIHsG#YoctoReferenceManualHardknottL813e-A12-KernelandBootloaderConfiguration +.. |yocto-sdk-rev| replace:: BSP-Yocto-NXP-i.MX8MM-PD22.1.1 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Refs +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S1) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X30) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X2 ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` + + +.. IMX8(MM) specific replacements +.. |sbc-network| replace:: \ +.. |pollux-fan-note| replace:: Only GPIO fan supported. +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M4 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mm_phyboard_polis/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8MM6_M4 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++----------------------+----------------------+ +| |soc| BSP Manual | ++----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++----------------------+----------------------+ +| Document Type | BSP Manual | ++----------------------+----------------------+ +| Yocto Manual | | ++----------------------+----------------------+ +| Release Date | 2023/05/25 | ++----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================= ========== +|yocto-manifestname| Minor 2023/05/23 Released +==================== ================ ================= ========== + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +The |sbc| populated with either the i.MX 8M Mini SoC or i.MX 8M Nano SoC, is +supported. + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mm-pd22.1.1-components: +.. include:: components.rsti + +Getting Started +=============== + +The |kit| is shipped with a pre-flashed SD card. It contains the +|yocto-imagename| and can be used directly as a boot source. The eMMC is +programmed with only a U-boot by default. You can get all sources from the +`PHYTEC download server `_. This chapter explains how to flash a BSP +image to SD card and how to start the board. + +Get the Image +------------- + +The WIC image contains all BSP files in several, correctly pre-formatted +partitions and can be copied to an SD card easily using the single Linux +command ``dd``. It can be built by Yocto or downloaded from the PHYTEC download +server. + +Get the WIC file from the download server: + +.. code-block:: console + :substitutions: + + host:~$ wget |link-image| + +Write the Image to SD Card +-------------------------- + +.. warning:: + To create your bootable SD card with the ``dd`` command, you must have root + privileges. Be very careful when specifying the destination device with + ``dd``! All files on the selected destination device will be erased + immediately without any further query! + + Selecting the wrong device may result in **data loss** and e.g. could erase + your currently running system! + +To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. Unmount any mounted partitions before +you start copying the image to the SD card. + +#. In order to get the correct device name, remove your SD card and + execute:: + + host$ lsblk + +#. Now insert your SD card and execute the command again:: + + host$ lsblk + +#. Compare the two outputs to find the new device names listed in the second + output. These are the device names of the SD card (device and partitions if + the SD card was formatted). +#. In order to verify the device names being found, execute the command + ``sudo dmesg``. Within the last lines of its output, you should also find the + device names, e.g. ``/dev/sde`` or ``/dev/mmcblk0`` (depending on your + system). + +Alternatively, you may use a graphical program of your choice, like `GNOME Disks +`_ or `KDE Partition Manager +`_, to find the correct device. + +Now that you have the correct device name, e.g. ``/dev/sde``, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. ``/dev/sde1``) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption. + +* Unmount all partitions, e.g.:: + + host$ sudo umount /dev/sde1 + +* After having unmounted all partitions, you can create your bootable SD card:: + + host$ sudo dd if=-.wic of=/dev/sdX bs=1M conv=fsync status=progress + + Again, make sure to replace ``/dev/sdX`` with your actual device name found + previously. + + The parameter ``conv=fsync`` forces a sync operation on the device before + ``dd`` returns. This ensures that all blocks are written to the SD card and + none are left in memory. The parameter ``status=progress`` will print out + information on how much data is and still has to be copied until it is + finished. + +An alternative and much faster way to prepare an SD card can be done by using +`bmap-tools `_ from Intel. Yocto +automatically creates a block map file (``-.wic.bmap``) for +the WIC image that describes the image content and includes checksums for data +integrity. *bmaptool* is packaged by various Linux distributions. For +Debian-based systems install it by issuing:: + + host$ sudo apt install bmap-tools + +Flash a WIC image to SD card by calling:: + + host$ bmaptool copy -.wic /dev/ + +.. warning:: + *bmaptool* only overwrites the areas of an SD card where image data is + located. This means that a previously written U-Boot environment may still be + available after writing the image. + +First Start-up +-------------- + +* To boot from an SD card, |ref-bootswitch| needs to be set to the following + position: + +.. list-table:: Bootmode Selection + + * - .. figure:: images/SD_Card_Boot.jpg + + Mini + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP | +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mm-pd22.1.1-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mm.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mm-phyboard-polis-rdk*.dtb**: Kernel device tree file +* **imx8mm-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt5demo-image\*.tar.gz**: Root file system +* **phytec-qt5demo-image\*.wic**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S1) +-------------------- + +The |sbc| features a boot switch with six individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mm-pd22.1.1-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **Default SOM boot**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. However, they only +work if the size of the image file is less than 1GB. If the image file is +larger, go to the section Format SD Card. Configure the |ref-bootswitch| to boot +from SD Card and put in an SD card. Power on the board and stop in U-Boot +prompt. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +* Load your image via network to RAM: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* Write the image to the eMMC: + + .. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + A working network is necessary! Setup Network Host. + +Take a compressed or uncompressed image on the host and send it with ssh through +the network (then uncompress it, if necessary) to the eMMC of the target with a +one-line command: + +.. code-block:: console + :substitutions: + + target:~$ ssh @192.168.3.10 "dd if=/|yocto-imagename|-|yocto-machinename|.wic" | dd of=/dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +Send the image with the command dd command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2" + +Flash eMMC u-boot image via Network from running u-boot +....................................................... + +Update the standalone u-boot image imx-boot is also possible from u-boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB +................... + +Flash eMMC from USB in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in Bootloader after enabling the OPTEE. + +These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch to |ref-bootswitch| and put in an SD card. Power on the board +and stop in u-boot prompt. Insert a USB device with the copied WIC image +to the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} *.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the bootmode switch to +|ref-bootswitch|. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ cd /mnt + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2boot0; mmcblk2boot1) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + +.. warning:: + + Before this will work, you need to configure the multi-port switch + to **Default SOM Boot** to |ref-bootswitch|. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see |ref-format-sd|. + +Flash eMMC from SD card in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in Bootloader after enabling the OPTEE. If the + image file is too large use the `Updating eMMC from SD card in + Linux on Target` subsection. + +* Flash an SD card with a working image and create a third FAT partition. Copy + the WIC image (for example |yocto-imagename|.wic) to this + partition. +* Configure the bootmode switch to boot from the SD Card and insert the SD + card. +* Power on the board and stop in u-boot. +* Flash your WIC image (for example |yocto-imagename|.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> fatload mmc 1:3 ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc0(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the multi-port switch to Default SOM Boot to + boot from eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a complete image saved on +the SD card (e.g. |yocto-imagename|-|yocto-machinename|.wic). + +* Show your saved image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2\ **boot0**; mmcblk2\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + +.. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to Default + SOM Boot to boot from eMMC. + +Flash SPI NOR Flash +------------------- + +The |som| modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set |ref-bootswitch| to **QSPI boot** to boot from QSPI. The SPI Flash is +usually quite small. The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash +populated. Only the bootloader and the environment can be stored. The kernel, +device tree, and file system are taken from eMMC by default. + +The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with: + +.. code-block:: + + u-boot=> printenv mtdparts + mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none) + +Flash SPI NOR Flash from Network +................................ + +The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-|soc|. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Flash SPI NOR from Network in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI-NOR flash needs to be probed: + +.. code-block:: + + u-boot=> sf probe + SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB + +* A specially formatted u-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image over tftp, erase and write the + bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + device 0 offset 0x0, size 0x1c0b20 + 1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +.. warning:: + + Erasing the complete SPI NOR flash when it is fully written will take quite + some time. This can trigger the watchdog to reset. Due to this, erase the + full flash in Linux. + +Flash SPI NOR from Network in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the image from the host to the target: + + .. code-block:: console + :substitutions: + + host:~$ scp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root + +* Find the number of erase blocks of the U-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +Flash SPI NOR Flash from SD Card +................................ + +The bootloader on SPI NOR flash can be also flashed with SD Card. + +Flash SPI NOR from SD Card in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the FAT partition + on the SD Card. Before reading and writing are possible, the SPI-NOR flash + needs to be probed: + + .. code-block:: + + u-boot=> sf probe + SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB + +* A specially formatted U-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image from the SD Card, erase and write + the bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +.. warning:: + + Erasing the complete SPI NOR flash when it is fully written will take quite + some time. This can trigger the watchdog to reset. Due to this, erase the + full flash in Linux. + +Flash SPI NOR from SD Card in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Mount the SD Card: + + .. code-block:: console + :substitutions: + + host:~$ mount /dev/mmcblkp1 /mnt + +* Find the number of erase blocks of the u-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp /mnt/imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A3 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mm-pd22.1.1-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + +.. _imx8mm-pd22.1.1-development-build-uboot: + +U-Boot standalone build +----------------------- + +Get the source code +................... + +* Get the U-Boot sources: + + .. code-block:: console + + host:~$ git clone git://git.phytec.de/u-boot-imx + +* To get the correct *U-Boot* **tag** you need to take a look at our release + notes, which can be found here: `release notes `_ +* The **tag** needed at this release is called |u-boot-tag| +* Check out the needed *U-Boot* **tag**: + +.. code-block:: console + :substitutions: + + host:~$ cd ~/u-boot-imx/ + host:~$ git fetch --all --tags + host:~$ git checkout tags/|u-boot-tag| + +* Technically, you can now build the U-Boot, but practically there are some + further steps necessary: + + * Create your own development branch: + + .. code-block:: console + + host:~$ git switch --create + + .. note:: + + You can name your development branch as you like, this is just an example. + +* Set up a build environment: + + .. code-block:: console + :substitutions: + + host:~$ source /opt/|yocto-distro|/|yocto-manifestname|/environment-setup-cortexa53-crypto-phytec-linux + +* Set this environment variable before building the Image: + + .. code-block:: console + :substitutions: + + host:~$ export ATF_LOAD_ADDR=|atfloadaddr| + +Get the needed binaries +....................... + +To build the bootloader, you need to **copy** these **files** to your |u-boot-repo-name| +**build directory** and rename them to fit with *mkimage* script: + +* **ARM Trusted firmware binary** (*mkimage tool* compatible format + **bl31.bin**): bl31-|kernel-socname|.bin +* **OPTEE image** (optional): tee.bin +* **DDR firmware files** (*mkimage tool* compatible format + **lpddr4_[i,d]mem_\*d_\*.bin**): + lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, + lpddr4_imem_2d_*.bin + +If you already built our BSP with Yocto, you can get the +bl31-|kernel-socname|.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: |ref-bsp-images| + +Or you can download the files here: |link-boot-tools| + +.. warning:: + + Make sure you rename the files you need so that they are compatible with the + *mkimage tool*. + +Build the bootloader +.................... + +* build flash.bin (imx-boot): + + .. code-block:: console + :substitutions: + + host:~$ make phycore-|kernel-socname|_defconfig + host:~$ make flash.bin + +Flash the bootloader to a block device +...................................... + +The flash.bin can be found at u-boot-imx/ directory and now can be flashed. A +chip-specific offset is needed: + +.. _offset-table: + +===== =================== ============================= ============ +SoC Offset User Area Offset Boot Partition eMMC Device +===== =================== ============================= ============ +|soc| |u-boot-offset| kiB |u-boot-offset-boot-part| kiB /dev/mmcblk2 +===== =================== ============================= ============ + +E.g. flash SD card: + +.. code-block:: console + :substitutions: + + host:~$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=|u-boot-offset| conv=sync + +.. hint:: + The specific offset values are also declared in the Yocto variables "BOOTLOADER_SEEK" and "BOOTLOADER_SEEK_EMMC" + +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + :start-after: .. build-uboot-fixed-ram-size-marker + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mm-pd22.1.1-device-tree: + +Device Tree (DT) +================ + +Introduction +------------ + +The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html) + +*"The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn't need to hard code details of the machine."* + +The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at `devicetree.org `_. + +PHYTEC |soc| BSP Device Tree Concept +------------------------------------ + +The following sections explain some rules PHYTEC has defined on how to set up +device trees for our |soc| SoC-based boards. + +Device Tree Structure +..................... + +* *Module.dtsi* - Module includes all devices mounted on the SoM, such as PMIC + and RAM. +* *Carrierboard.dtsi* - Devices that come from the |soc| SoC but are just routed + down to the carrier board and used there are included in this dtsi. +* *Board.dts* - include the carrier board and module dtsi files. There may also + be some hardware configuration nodes enabled on the carrier board or the + module (i.e. the Board .dts shows the special characteristics of the board + configuration). For example, there are phyCORE-|soc| SOMs which may or may not + have a MIPI DSI to LVDS converter mounted. The converter is enabled (if + available) in the Board .dts and not in the Module .dtsi + +From the root directory of the Linux Kernel our devicetree files for |socfamily| +platforms can be found in ``arch/arm64/boot/dts/freescale/``. + +Device Tree Overlay +................... + +Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder ``arch/arm64/boot/dts/freescale/overlays``. + +Available overlays for |yocto-machinename|.conf are: + +.. code-block:: + + imx8mm-phyboard-polis-peb-eval-01.dtbo + imx8mm-phyboard-polis-peb-av-010.dtbo + imx8mm-phycore-rpmsg.dtbo + imx8mm-phycore-no-eth.dtbo + imx8mm-phycore-no-spiflash.dtbo + imx8mm-vm016.dtbo + imx8mm-vm016-fpdlink.dtbo + imx8mm-vm017.dtbo + imx8mm-vm017-fpdlink.dtbo + imx8mm-dual-vm017-fpdlink.dtbo + +.. _imx8mm-pd22.1.1-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +imx8mm-phyboard-polis.dtsi: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX 0x00 + MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX 0x00 + MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B 0x00 + MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B 0x00 + >; + }; + +The first part of the string MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad (in this example +SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the desired muxing option for this pad. +The pad setting value (hex value on the right) defines different modes of the pad, for example, if +internal pull resistors are activated or not. In this case, the internal resistors are disabled. + +RS232/RS485 +----------- + +The |soc| SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +|ref-bootswitch| needs to be set correctly: + +.. list-table:: Switch between UART1 RS485/RS232 + + * - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS485.png + + **UART1 RS485** + + - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS232.jpg + + **UART1 RS232** + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n188` + +.. _imx8mm-pd22.1.1-network: + +Network +------- + +|sbc|-|soc| provides one Gigabit Ethernet interface. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First set the correct regulatory domain for your country: + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see: + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +Set up the wireless interface: + +.. code-block:: console + + target:~$ ip link + target:~$ ip link set up dev wlan0 + +Now you can scan for available networks: + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection. + +To do so, add the network-credentials to the file ``/etc/wpa_supplicant.conf``: + +.. code-block:: + + country=DE + network={ + ssid="" + proto=WPA2 + psk="" + } + +Now a connection can be established: + +.. code-block:: console + + target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B + +This should result in the following output: + +.. code-block:: + + ... + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section `Changing the Network Configuration` in the |yocto-ref-manual|_. + +First, create the directory: + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +Then add the following configuration snippet in ``/etc/systemd/network/10-wlan0.network``: + +.. code-block:: + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +Now, restart the network daemon so that the configuration takes effect: + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Bluetooth +......... + +Bluetooth is connected to |bluetooth-uart| interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually: + +.. code-block:: console + + target:~$ hciconfig hci0 up + + target:~$ hciconfig -a + + hci0: Type: Primary Bus: UART + BD Address: 00:25:CA:2F:39:96 ACL MTU: 1021:8 SCO MTU: 64:1 + UP RUNNING PSCAN + RX bytes:1392 acl:0 sco:0 events:76 errors:0 + TX bytes:1198 acl:0 sco:0 commands:76 errors:0 + ... + +Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup. + +.. code-block:: console + + target:~$ hcitool scan + Scanning ... + XX:XX:XX:XX:XX:XX + +Visibility +~~~~~~~~~~ + +To activate visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 piscan + +To disable visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 noscan + +Connect +~~~~~~~ + +.. code-block:: console + + target:~$ bluetoothctl + [bluetooth]# discoverable on + Changing discoverable on succeeded + [bluetooth]# pairable on + Changing pairable on succeeded + [bluetooth]# agent on + Agent registered + [bluetooth]# default-agent + Default agent request successful + [bluetooth]# scan on + [NEW] Device XX:XX:XX:XX:XX:XX + [bluetooth]# connect XX:XX:XX:XX:XX:XX + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n266` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n315` + +eMMC Devices +------------ + +PHYTEC modules like phyCORE-|soc| is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw MLC memory cells combined with a memory +controller that handles ECC and wear leveling. They are connected via an SD/MMC +interface to the |soc| and are represented as block devices in the Linux kernel +like SD cards, flash drives, or hard disks. + +The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer's datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard. + +PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1 + +Extended CSD Register +..................... + +eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard. + +In the Linux user space, you can query the registers: + +.. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| + +You will see: + +.. code-block:: + + ============================================= + Extended CSD rev 1.7 (MMC 5.0) + ============================================= + + Card Supported Command sets [S_CMD_SET: 0x01] + [...] + +Enabling Background Operations (BKOPS) +...................................... + +In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +cells. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called **Background +Operations (BKOPS)**. + +By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency. + +The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details. + +Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0): + +* Value 0: The host does not support the manual trigger of BKOPS. Device write + performance suffers. +* Value 1: The host does support the manual trigger of BKOPS. It will issue + BKOPS from time to time when it does not need the device. + +The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details). + +The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)). + +The userspace tool mmc does not currently support enabling automatic BKOPS +features. + +* To check whether *BKOPS_EN* is set, execute: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep BKOPS_EN + + The output will be, for example: + + .. code-block:: + + Enable background operations handshake [BKOPS_EN]: 0x01 + #OR + Enable background operations handshake [BKOPS_EN]: 0x00 + + Where value 0x00 means BKOPS_EN is disabled and device write performance + suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue + background operations from time to time. + +* To set the BKOPS_EN bit, execute: + + .. code-block:: console + :substitutions: + + target:~$ mmc bkops enable /dev/|emmcdev| + +* To ensure that the new setting is taken over and the kernel triggers BKOPS by + itself, shut down the system: + + .. code-block:: console + + target:~$ poweroff + +.. tip:: + + The BKOPS_EN bit is one-time programmable only. It cannot be reversed. + +Reliable Write +.............. + +There are two different Reliable Write options: + +1. Reliable Write option for a whole eMMC device/partition. +2. Reliable Write for single write transactions. + +.. tip:: + + Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT + partition table (see the previous section). + +The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-|soc| SoMs. To check this on the running target: + +.. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep -A 5 WR_REL_SET + Write reliability setting register [WR_REL_SET]: 0x1f + user area: the device protects existing data if a power failure occurs during a write o + peration + partition 1: the device protects existing data if a power failure occurs during a write + operation + partition 2: the device protects existing data if a power failure occurs during a write + operation + partition 3: the device protects existing data if a power failure occurs during a write + operation + partition 4: the device protects existing data if a power failure occurs during a write + operation + -- + Device supports writing EXT_CSD_WR_REL_SET + Device supports the enhanced def. of reliable write + +Otherwise, it can be enabled with the mmc tool: + +.. code-block:: console + + target:~$ mmc --help + + [...] + mmc write_reliability set <-y|-n> + +The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META. + +**Conclusion**: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application. + +Resizing ext4 Root Filesystem +............................. + +When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk. + +* Get the current device size: + + .. code-block:: console + :substitutions: + + target:~$ parted /dev/|emmcdev| print + +* The output looks like this: + + .. code-block:: + :substitutions: + + Model: MMC Q2J55L (sd/mmc) + Disk /dev/|emmcdev|: 7617MB + Sect[ 1799.850385] |emmcdev|: p1 p2 + or size (logical/physical): 512B/512B + Partition Table: msdos + Disk Flags: + + Number Start End Size Type File system Flags + 1 4194kB 72.4MB 68.2MB primary fat16 boot, lba + 2 72.4MB 537MB 465MB primary ext4 + +* Use parted to resize the root partition to the max size of the device: + + .. code-block:: console + :substitutions: + + target:~$ parted /dev/|emmcdev| resizepart 2 100% + Information: You may need to update /etc/fstab. + + target:~$ parted /dev/|emmcdev| print + Model: MMC Q2J55L (sd/mmc) + Disk /dev/|emmcdev|: 7617MB + Sector size (logical/physical): 512[ 1974.191657] |emmcdev|: p1 p2 + B/512B + Partition Table: msdos + Disk Flags: + + Number Start End Size Type File system Flags + 1 4194kB 72.4MB 68.2MB primary fat16 boot, lba + 2 72.4MB 7617MB 7545MB primary ext4 + +Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted. + +* Resize the filesystem to a new partition size: + + .. code-block:: console + :substitutions: + + target:~$ resize2fs /dev/|emmcdev|p2 + resize2fs 1.46.1 (9-Feb-2021) + Filesystem at /dev/|emmcdev|p2 is mounted on /; on-line resizing required + [ 131.609512] EXT4-fs (|emmcdev|p2): resizing filesystem + from 454136 to 7367680 blocks + old_desc_blocks = 4, new_desc_blocks = 57 + [ 131.970278] EXT4-fs (|emmcdev|p2): resized filesystem to 7367680 + The filesystem on /dev/|emmcdev|p2 is now 7367680 (1k) blocks long + +Enable pseudo-SLC Mode +...................... + +eMMC devices use MLC memory cells +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC memory cells used in NAND Flash, MLC memory cells have lower +reliability and a higher error rate at lower costs. + +If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity. + +.. warning:: + + When enabling the enhanced attribute on the device, all data will be lost. + +The following sequence shows how to enable the enhanced attribute. + +* First obtain the current size of the eMMC device with: + + .. code-block:: console + :substitutions: + + target:~$ parted -m /dev/|emmcdev| unit B print + + You will receive: + + .. code-block:: + :substitutions: + + BYT; + /dev/|emmcdev|:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:; + + As you can see this device has 63652757504 Byte = 60704 MiB. + +* To get the maximum size of the device after pseudo-SLC is enabled use: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep ENH_SIZE_MULT -A 1 + + which shows, for example: + + .. code-block:: + + Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + -- + Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000 + i.e. 0 KiB + + Here the maximum size is 3719168 KiB = 3632 MiB. + +* Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by + typing: + + .. code-block:: console + :substitutions: + + target:~$ mmc enh_area set -y 0 3719168 /dev/|emmcdev| + + You will get: + + .. code-block:: + :substitutions: + + Done setting ENH_USR area on /dev/|emmcdev| + setting OTP PARTITION_SETTING_COMPLETED! + Setting OTP PARTITION_SETTING_COMPLETED on /dev/|emmcdev| SUCCESS + Device power cycle needed for settings to take effect. + Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle + +* To ensure that the new setting has taken over, shut down the system: + + .. code-block:: console + + target:~$ poweroff + + and perform a power cycle. It is recommended that you verify the settings now. + +* First, check the value of ENH_SIZE_MULT which must be 3719168 KiB: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep ENH_SIZE_MULT -A 1 + + You should receive:: + + Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + -- + Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + +* Finally, check the size of the device: + + .. code-block:: console + :substitutions: + + target:~$ parted -m /dev/|emmcdev| unit B print + BYT; + /dev/|emmcdev|:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:; + +Erasing the Device +.................. + +It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC memory +cells or mark these blocks as discard. The data on the device is lost and will +be read back as zeros. + +* After booting from SD Card execute: + + .. code-block:: console + :substitutions: + + target:~$ blkdiscard -f --secure /dev/|emmcdev| + + The option --secure ensures that the command waits until the eMMC device has + erased all blocks. The -f (force) option disables all checking before erasing + and it is needed when the eMMC device contains existing partitions with data. + +.. tip:: + .. code-block:: console + :substitutions: + + target:~$ dd if=/dev/zero of=/dev/|emmcdev| conv=fsync + + also destroys all information on the device, but this command is bad for wear + leveling and takes much longer! + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy9#n71` + +GPIOs +----- + +The |sbc| has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to |soc| pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal |soc| GPIO banks GPIO1 – GPIO5. + +The GPIOs are identified as GPIO_ (e.g. GPIO5_07). identifies the GPIO +bank and counts from 1 to 5, while stands for the GPIO within the bank. +is being counted from 0 to 31 (32 GPIOs on each bank). + +By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is: + +.. code-block:: + + Linux GPIO number: = ( - 1) * 32 + + +Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools: + +* Detecting the gpiochips on the chip: + + .. code-block:: console + + target:~$ gpiodetect + gpiochip0 [30200000.gpio] (32 lines) + gpiochip1 [30210000.gpio] (32 lines) + gpiochip2 [30220000.gpio] (32 lines) + gpiochip3 [30230000.gpio] (32 lines) + gpiochip4 [30240000.gpio] (32 lines) + +* Show detailed information about the gpiochips. Like their names, consumers, + direction, active state, and additional flags: + + .. code-block:: console + + target:~$ gpioinfo gpiochip0 + +* Read the value of a GPIO (e.g GPIO 20 from chip0): + + .. code-block:: console + + target:~$ gpioget gpiochip0 20 + +* Set the value of GPIO 20 on chip0 to 0 and exit tool: + + .. code-block:: console + + target:~$ gpioset --mode=exit gpiochip0 20=0 + +* Help text of gpioset shows possible options: + + .. code-block:: console + + target:~$ gpioset --help + Usage: gpioset [OPTIONS] = = ... + Set GPIO line values of a GPIO chip + + Options: + -h, --help: display this message and exit + -v, --version: display the version and exit + -l, --active-low: set the line active state to low + -m, --mode=[exit|wait|time|signal] (defaults to 'exit'): + tell the program what to do after setting values + -s, --sec=SEC: specify the number of seconds to wait (only valid for --mode=time) + -u, --usec=USEC: specify the number of microseconds to wait (only valid for --mode=time) + -b, --background: after setting values: detach from the controlling terminal + + Modes: + exit: set values and exit immediately + wait: set values and wait for user to press ENTER + time: set values and sleep for a specified amount of time + signal: set values and wait for SIGINT or SIGTERM + + Note: the state of a GPIO line controlled over the character device reverts to default + when the last process referencing the file descriptor representing the device file exits. + This means that it's wrong to run gpioset, have it exit and expect the line to continue + being driven high or low. It may happen if given pin is floating but it must be interpreted + as undefined behavior. + + +.. warning:: + + Some of the user IOs are used for special functions. Before using a user IO, + refer to the schematic or the hardware manual of your board to ensure that it + is not already in use. + +GPIOs via sysfs +............... + +.. warning:: + + Accessing gpios via sysfs is deprecated and we encourage to use libgpiod + instead. + +Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling ``CONFIG_GPIO_SYSFS`` in the kernel +configuration. To make ``CONFIG_GPIO_SYSFS`` visible in menuconfig the option +``CONFIG_EXPERT`` has to be enabled first. + +You can also add this option for example to the defconfig you use in +``arch/arm64/configs/`` in the linux kernel sources. For our NXP based releases, +this could be for example ``imx8_phytec_distro.config``:: + + .. + CONFIG_EXPERT=y + CONFIG_GPIO_SYSFS=y + .. + +Otherwise you can create a new config fragment. This is described in our +`Yocto Reference Manual `_. + +Pinmuxing of some GPIO pins in the device tree |dt-carrierboard|.dtsi:: + + pinctrl_leds: leds1grp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1 0x16 + MX8MM_IOMUXC_GPIO1_IO14_GPIO1_IO14 0x16 + MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x16 + >; + }; + +LEDs +---- + +If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using ``/sys/class/leds/`` instead +of ``/sys/class/gpio/``. The maximum brightness of the LEDs can be read from +the ``max_brightness`` file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings. + +Below is a simple example. + +To get all available LEDs, type: + +.. code-block:: console + + target:~$ ls /sys/class/leds + mmc1::@ mmc2::@ user-led1@ user-led2@ user-led3@ + +Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the |sbc|. + +* To toggle the LEDs ON: + + .. code-block:: console + + target:~$ echo 255 > /sys/class/leds/user-led1/brightness + +* To toggle OFF: + + .. code-block:: console + + target:~$ echo 0 > /sys/class/leds/user-led1/brightness + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n37` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy#n102` + +General I²C4 bus configuration (e.g. |dt-carrierboard|.dtsi): +:imx-dt:`imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n149` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues. + +.. include:: ../peripherals/eeprom.rsti + +Rescue EEPROM Data +.................. + +The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area. + +.. code-block:: console + + target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 + +.. note:: + + If you deleted both EEPROM spaces, please contact our support! + +DT representation, e.g. in phyCORE-|soc| file |dt-som|.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n271` + +.. include:: /bsp/peripherals/rtc.rsti + :end-before: .. rtc_parameter_start_label + +DT representation for I²C RTCs: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy9#n277` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +'HS'). The USB subsystem has two independent USB controller cores. Both cores +are On-The-Go (OTG) controller cores and are capable of acting as a USB +peripheral device or a USB host. Each is connected to a USB 2.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +User USB2 (host) configuration is in the kernel device tree +|kernel-socname|.dtsi:: + + &usbotg2 { + dr_mode = "host"; + picophy,pre-emp-curr-control = <3>; + picophy,dc-vol-level-adjust = <7>; + status = "okay"; + }; + +DT representation for USB Host: +:imx-dt:`imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy9#n240` + +.. include:: /bsp/peripherals/usb-otg.rsti + +Both USB interfaces are configured as host in the kernel device tree +imx8mm-phyboard-polis.dtsi. See: +:imx-dt:`imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n228` + +CAN FD +------ + +The |sbc| has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. Hint:: + + phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. + There are different interfaces involved, which limits the datarate + capabilities of CANFD. + +.. Hint:: + + On phyBOARD-Polis-i.MX8MM a terminating resistor can be enabled by setting + S5 to ON if required. + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of imx8mm-phyboard-polis.dtsi: +:imx-dt:`imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n106` + +PCIe +---- + +The phyCORE-|soc| has one Mini-PCIe slot. In general, PCIe autodetects new +devices on the bus. After connecting the device and booting up the system, you +can use the command lspci to see all PCIe devices recognized. + +* Type: + + .. code-block:: console + + target:~$ lspci -v + +* You will receive: + + .. code-block:: + + 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode]) + Flags: bus master, fast devsel, latency 0, IRQ 218 + Memory at 18000000 (64-bit, non-prefetchable) [size=1M] + Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0 + I/O behind bridge: None + Memory behind bridge: 18100000-181fffff [size=1M] + Prefetchable memory behind bridge: None + [virtual] Expansion ROM at 18200000 [disabled] [size=64K] + Capabilities: [40] Power Management version 3 + Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+ + Capabilities: [70] Express Root Port (Slot-), MSI 00 + Capabilities: [100] Advanced Error Reporting + Capabilities: [148] L1 PM Substates + Kernel driver in use: dwc3-haps + + 01:00.0 Network controller: Intel Corporation WiFi Link 5100 + Subsystem: Intel Corporation WiFi Link 5100 AGN + Flags: fast devsel + Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K] + Capabilities: [c8] Power Management version 3 + Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+ + Capabilities: [e0] Express Endpoint, MSI 00 + Capabilities: [100] Advanced Error Reporting + Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e + Kernel modules: iwlwifi + +In this example, the PCIe device is the *Intel Corporation WiFi Link 5100*. + +For PCIe devices, you have to enable the correct driver in the kernel +configuration. This WLAN card, for example, is manufactured by Intel. The +option for the driver, which must be enabled, is named ``CONFIG_IWLWIFI`` and can be +found under *Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimat* in +the kernel configuration. + +* In order to activate the driver, follow the instructions from our + `Yocto Reference Manual `_. + + - The linux-imx is represented by: **virtual/kernel** + +For some devices like the WLAN card, additional binary firmware blobs are +needed. These firmware blobs have to be placed in ``/lib/firmware/`` before the +device can be used. + +* Type: + + .. code-block:: console + + host:~$ scp -r root@192.168.3.11:/lib/firmware + +* For example, if you try to bring up the network interface: + + .. code-block:: console + + target:~$ ip link set up wlp1s0 + +* You will get the following output on the serial console: + + .. code-block:: console + + [ 58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0 + [ 58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0 + [ 58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready + +.. tip:: + + Some PCIe devices, e.g. the Ethernet card, may function properly even if no + firmware blob is loaded from ``/lib/firmware/`` and you received an error message + as shown in the first line of the output above. This is because some + manufacturers provide the firmware as a fallback on the card itself. In this + case, the behavior and output depend strongly on the manufacturer's firmware. + +Audio +----- + +The PEB-AV-10-Connector exists in two versions and the 1531.1 version is +populated with a TI TLV320AIC3007 audio codec. Audio support is done via the I2S +interface and controlled via I2C. + +There is a 3.5mm headset jack with OMTP standard and an 8-pin header to connect +audio devices with the AV-Connector. The 8-pin header contains a mono speaker, +headphones, and line-in signals. + +To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices: + +.. code-block:: console + + target:~$ aplay -L + +Or type for recording devices: + +.. code-block:: console + + target:~$ arecord -L + +Alsamixer +......... + +To inspect the capabilities of your soundcard, call: + +.. code-block:: console + + target:~$ alsamixer + +You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. "MM" means the feature is muted +(both output, left & right), which can be toggled by hitting **m**. You can also +toggle by hitting '**<**' for left and '**>**' for right output. With the **tab** +key, you can switch between controls for playback and recording. + +ALSA configuration +.................. + +Our BSP comes with a ALSA configuration file ``/etc/asound.conf``. + +The ALSA configuration file can be edited as desired or deleted since it is not +required for ALSA to work properly. + +.. code-block:: console + + target:~$ vi /etc/asound.conf + +To set PEB-AV-10 as output, set playback.pcm from "dummy" to "pebav10": + +.. code-block:: + + [...] + + pcm.asymed { + type asym + playback.pcm "pebav10" + capture.pcm "dsnoop" + } + + [...] + +If the sound is not audible change playback devices to the software volume control +playback devices, set *playback.pcm* to the respective softvol playback device e.g. +"softvol_pebav10". Use alsamixer controls to vary the volume levels. + +.. code-block:: + + [...] + + pcm.asymed { + type asym + playback.pcm "softvol_pebav10" + capture.pcm "dsnoop" + } + + [...] + +Pulseaudio Configuration +........................ + +For applications using Pulseaudio, check for available sinks: + +.. code-block:: console + + target:~$ pactl list short sinks + 0 alsa_output.platform-snd_dummy.0.stereo-fallback module-alsa-card.c s16le 2ch 44100Hz SUSPENDED + 1 alsa_output.platform-sound-peb-av-10.stereo-fallback module-alsa-card.c s16le 2ch 44100Hz SUSPENDED + +To select PEB-AV-10, type: + +.. code-block:: console + + target:~$ pactl set-default-sink 1 + +Playback +........ + +Run speaker-test to check playback availability: + +.. code-block:: console + + target:~$ speaker-test -c 2 -t wav + +To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds: + +.. code-block:: console + + target:~$ aplay /usr/share/sounds/alsa/* + +To playback other formats like mp3 for example, you can use Gstreamer: + +.. code-block:: console + + target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3 + +Capture +....... + +``arecord`` is a command-line tool for capturing audio streams which use Line In as +the default input source. To select a different audio source you can +use ``alsamixer``. For example, switch on *Right PGA Mixer Mic3R* and *Left PGA Mixer +Mic3R* in order to capture the audio from the microphone input of the +TLV320-Codec using the 3.5mm jack. + +.. code-block:: console + + target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on + target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on + +.. code-block:: console + + target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav + +.. hint:: + + Since playback and capture share hardware interfaces, it is not possible to + use different sampling rates and formats for simultaneous playback and + capture operations. + +Device Tree Audio configuration: +:imx-dt:`overlays/imx8mm-phyboard-polis-peb-av-010.dtso?h=v5.10.72_2.2.0-phy17#n56` + +Video +----- + +Videos with Gstreamer +..................... + +The video is installed by default in the BSP: + +.. code-block:: console + + target:~$ gst-launch-1.0 playbin uri=file:///usr/share/phytec-qtdemo/videos/caminandes.webm + +* Or: + +.. code-block:: console + + target:~$ gst-launch-1.0 -v filesrc location= \ + \! qtdemux \! h264parse \! queue \! vpudec \! waylandsink async=false enable-last-sample=false \ + qos=false sync=false + +* Or: + +.. code-block:: console + + target:~$ gplay-1.0 /usr/share/phytec-qtdemo/videos/caminandes.webm + +kmssink Plugin ID Evaluation +............................ + +The kmssink plugin needs a connector ID. To get the connector ID, you can use +the tool modetest. + +.. code-block:: console + + target:~$ modetest -c imx-drm + +The output will show something like: + +.. code-block:: + + Connectors: + id encoder status name size (mm) modes encoders + 35 34 connected LVDS-1 216x135 1 34 + modes: + index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot + #0 1280x800 59.07 1280 1380 1399 1440 800 804 808 823 70000 flags: phsync, pvsync; type: preferred, driver + props: + 1 EDID: + flags: immutable blob + blobs: + + value: + 2 DPMS: + flags: enum + enums: On=0 Standby=1 Suspend=2 Off=3 + value: 0 + 5 link-status: + flags: enum + enums: Good=0 Bad=1 + value: 0 + 6 non-desktop: + flags: immutable range + values: 0 1 + value: 0 + 4 TILE: + flags: immutable blob + blobs: + + value: + +Display +------- + +The 10" Display is always active. If the PEB-AV-Connector is not connected, an +error message may occur at boot. + +.. include:: /bsp/qt5.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +The device tree of PEB-AV-10 can be found here: +:imx-dt:`overlays/imx8mm-phyboard-polis-peb-av-010.dtso?h=v5.10.72_2.2.0-phy17` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Mini M4 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti + +.. +---------------------------------------------------------------------------+ +.. BSP EXTENSIONS +.. +---------------------------------------------------------------------------+ + +BSP Extensions +============== + +Chromium +-------- + +Our BSP for the |sbc|-|soc| supports Chromium. You can include it in the +|yocto-imagename| with only a few steps. + +Adding Chromium to Your local.conf +.................................. + +To include Chromium you have to add the following line into your local.conf. You +can find it in /build/conf/local.conf. This adds Chromium to your +next image build. :: + + IMAGE_INSTALL_append = " chromium-ozone-wayland" + +.. note:: + + Compiling Chromium takes a long time. + +Get Chromium Running on the Target +.................................. + +To run Chromium, it needs a few arguments to use the hardware graphics +acceleration:: + + target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox + +If you want to start Chromium via SSH, you must first define the display on +which Chromium will run. For example:: + + target$ DISPLAY=:0 + +After you have defined this, you can start it via virtual terminal on Weston as +shown above. diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mm/pd23.1.0.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mm/pd23.1.0.rst.txt new file mode 100644 index 000000000..18fa0f96d --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mm/pd23.1.0.rst.txt @@ -0,0 +1,1749 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt6demo-image-phyboard-polis-imx8mm-5.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/imx-boot-tools/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mm +.. _`static-pdf-dl`: ../../../_static/imx8mm-pd23.1.0.pdf + +.. IMX8(MM) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mm/phycore-imx8mm.c?h=v2022.04_2.2.2-phy5#n120 + + +.. General Replacements +.. |kit| replace:: **phyCORE-i.MX8M Mini Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Polis +.. |soc| replace:: i.MX 8M Mini +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MM +.. |debug-uart| replace:: ttymxc2 +.. |serial-uart| replace:: ttymxc0 +.. |bluetooth-uart| replace:: UART2 +.. |expansion-connector| replace:: X8 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx8mm +.. |kernel-tag| replace:: v5.15.71_2.2.2-phy3 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-offset| replace:: 33 +.. |u-boot-offset-boot-part| replace:: 33 +.. |u-boot-mmc-flash-offset| replace:: 0x42 +.. |u-boot-defconfig| replace:: phycore-imx8mm_defconfig +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX8(MM) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MM +.. |u-boot-tag| replace:: v2022.04_2.2.2-phy5 + + +.. RAUC +.. |rauc-manual| replace:: L-1006e.A5 RAUC Update & Device Management Manual +.. _rauc-manual: https://www.phytec.de/cdocuments/?doc=fgByJg + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mm-phyboard-polis-rdk +.. |dt-som| replace:: imx8mm-phycore-som +.. |dtbo-rpmsg| replace:: imx8mm-phycore-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mm-phyboard-polis-peb-av-010.dtbo + +.. IMX8(MM) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n59` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`kirkstone` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MM +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: kirkstone +.. |yocto-distro| replace:: ampliphy-vendor-xwayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: wic +.. |yocto-machinename| replace:: phyboard-polis-imx8mm-5 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MM-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MM-PD23.1.y +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (kirkstone) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 4.0.13 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + + +.. Refs +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S1) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X30) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X2 ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MM) specific replacements +.. |sbc-network| replace:: \ +.. |pollux-fan-note| replace:: Only GPIO fan supported. +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M4 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mm_phyboard_polis/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8MM6_M4 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++----------------------+----------------------+ +| |soc| BSP Manual | ++----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++----------------------+----------------------+ +| Document Type | BSP Manual | ++----------------------+----------------------+ +| Yocto Manual | Kirkstone | ++----------------------+----------------------+ +| Release Date | 2024/01/10 | ++----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================ ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================ ========== +|yocto-manifestname| Major 2023/12/12 Released +==================== ================ ================ ========== + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +The |sbc| populated with either the i.MX 8M Mini SoC or i.MX 8M Nano SoC, is +supported. + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mm-pd23.1.0-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mm-pd23.1.0-getting-started: + +Getting Started +=============== + +The |kit| is shipped with a pre-flashed SD card. It contains the +|yocto-imagename| and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +`PHYTEC download server `_. This chapter explains how to flash a BSP +image to SD card and how to start the board. + +There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool ``dd``. An +alternative way is to use PHYTEC's system initialization program called +`partup `_, which makes it especially easy to +format more complex systems. You can get `prebuilt Linux binaries of partup +`__ from its release page. Also read +`partup's README `__ for installation +instructions. + +Get the Image +------------- + +The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using ``dd``, can be downloaded from the `PHYTEC download server +`_. + +Get either the partup package or the WIC image from the download server: + +.. code-block:: console + :substitutions: + + host:~$ wget |link-partup-package| + host:~$ wget |link-image| + +.. note:: + For eMMC, more complex partitioning schemes or even just large images, we + recommend using the partup package, as it is faster in writing than ``dd`` + and allows for a more flexible configuration of the target flash device. + +Write the Image to SD Card +-------------------------- + +.. warning:: + To create your bootable SD card, you must have root privileges on your Linux + host PC. Be very careful when specifying the destination device! All files + on the selected device will be erased immediately without any further query! + + Selecting the wrong device may result in **data loss** and e.g. could erase + your currently running system on your host PC! + +Finding the Correct Device +.......................... + +To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card. + +#. In order to get the correct device name, remove your SD card and + execute: + + .. code-block:: console + + host:~$ lsblk + +#. Now insert your SD card and execute the command again: + + .. code-block:: console + + host:~$ lsblk + +#. Compare the two outputs to find the new device names listed in the second + output. These are the device names of the SD card (device and partitions if + the SD card was formatted). +#. In order to verify the device names being found, execute the command + ``sudo dmesg``. Within the last lines of its output, you should also find the + device names, e.g. ``/dev/sde`` or ``/dev/mmcblk0`` (depending on your + system). + +Alternatively, you may use a graphical program of your choice, like `GNOME Disks +`_ or `KDE Partition Manager +`_, to find the correct device. + +Now that you have the correct device name, e.g. ``/dev/sde``, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. ``/dev/sde1``) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption. + +Unmount all those partitions, e.g.: + +.. code-block:: console + + host:~$ sudo umount /dev/sde1 + host:~$ sudo umount /dev/sde2 + +Now, the SD card is ready to be flashed with an image, using either ``partup``, +``dd`` or ``bmap-tools``. + +Using partup +............ + +Writing to an SD card with partup is done in a single command: + +.. code-block:: console + :substitutions: + + host:~$ sudo partup install |yocto-imagename|-|yocto-machinename|.partup /dev/ + +Make sure to replace with your actual device name found previously. + +Further usage of partup is explained at its `official documentation website +`__. + +.. note:: + *partup* has the advantage of allowing to clear specific raw areas in the + MMC user area, which is used in our provided partup packages to erase any + existing U-Boot environments. This is a known issue *bmaptool* does not + solve, as mentioned below. + + Another key advantage of partup over other flashing tools is that it allows + configuring MMC specific parts, like writing to eMMC boot partitions, without + the need to call multiple other commands when writing. + +Using bmap-tools +................ + +An alternative and also fast way to prepare an SD card is using +`bmap-tools `_. Yocto +automatically creates a block map file (``-.wic.bmap``) for +the WIC image that describes the image content and includes checksums for data +integrity. *bmaptool* is packaged by various Linux distributions. For +Debian-based systems install it by issuing: + +.. code-block:: console + + host:~$ sudo apt install bmap-tools + +Flash a WIC image to SD card by calling: + +.. code-block:: console + :substitutions: + + host:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/ + +Replace with your actual SD card's device name found previously, +and make sure to place the file ``-.wic.bmap`` alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip. + +.. warning:: + *bmaptool* only overwrites the areas of an SD card where image data is + located. This means that a previously written U-Boot environment may still be + available after writing the image. + +Using ``dd`` +............ + +After having unmounted all SD card's partitions, you can create your bootable SD card. + +Some PHYTEC BSPs produce uncompressed images (with filename-extension \*.wic), +and some others produce compressed images (with filename-extension \*.wic.xz). + +To flash an uncompressed images (\*.wic) use command below: + +.. code-block:: console + :substitutions: + + host:~$ sudo dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/ bs=1M conv=fsync status=progress + +Or to flash a compressed images (\*.wic.xz) use that command: + +.. code-block:: console + :substitutions: + + host:~$ xzcat |yocto-imagename|-|yocto-machinename|.wic.xz | sudo dd of=/dev/ bs=1M conv=fsync status=progress + +Again, make sure to replace with your actual device name found +previously. + +The parameter ``conv=fsync`` forces a sync operation on the device before +``dd`` returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter ``status=progress`` will print out +information on how much data is and still has to be copied until it is +finished. + +First Start-up +-------------- + +* To boot from an SD card, |ref-bootswitch| needs to be set to the following + position: + +.. list-table:: Bootmode Selection + + * - .. figure:: images/SD_Card_Boot.jpg + + Mini + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP | +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mm-pd23.1.0-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mm.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mm-phyboard-polis-rdk*.dtb**: Kernel device tree file +* **imx8mm-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.wic**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S1) +-------------------- + +The |sbc| features a boot switch with six individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mm-pd23.1.0-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see |ref-setup-network-host|. + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **eMMC**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load your image via network to RAM: + +* when using dhcp + + .. code-block:: + :substitutions: + + u-boot=> dhcp |yocto-imagename|-|yocto-machinename|.wic + BOOTP broadcast 1 + DHCP client bound to address 192.168.3.1 (1 ms) + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.1 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* when using a static ip address (serverip and ipaddr must be set + additionally). + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Take a compressed or uncompressed image with accompanying block map on the host +and send it with ssh through the network to the eMMC of the target with a +one-line command: + +.. code-block:: console + :substitutions: + + target:~$ scp @192.168.3.10:/srv/tftp/|yocto-imagename|-|yocto-machinename|.wic.* /tmp && bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls /srv/tftp + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +Send the image with the ``bmaptool`` command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ scp /srv/tftp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2" + +Flash eMMC U-Boot image via Network from running U-Boot +....................................................... + +Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB stick +......................... + +Flash eMMC from USB stick in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. + +These steps will show how to update the eMMC via a USB device. Configure the +|ref-bootswitch| to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied WIC image to the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} *.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the |ref-bootswitch| to SD Card. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ ls /mnt + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy /mnt/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + + .. tip:: + + Before this will work, you need to configure the |ref-bootswitch| to + **eMMC**. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see |ref-format-sd|. + +Alternatively, flash a partup package to the SD card, as described in +|ref-getting-started|. This will ensure the full space of the SD card is used. + +Flash eMMC from SD card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. If the + image file is too large use the `Updating eMMC from SD card in + Linux on Target` subsection. + +* Flash an SD card with a working image and create a third ext4 partition. Copy + the WIC image (for example |yocto-imagename|.wic) to this + partition. +* Configure the |ref-bootswitch| to SD Card and insert the SD Card. +* Power on the board and stop in U-Boot. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> ext4load mmc 1:3 ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev to eMMC: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + +* Flash your WIC image (for example |yocto-imagename|.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. + + .. code-block:: + + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the |ref-bootswitch| to eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card. + +* Show your saved partup package or WIC image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.partup + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition) using `partup`_: + + .. code-block:: console + :substitutions: + + target:~$ partup install |yocto-imagename|-|yocto-machinename|.partup /dev/mmcblk2 + + Flashing the partup package has the advantage of using the full capacity of + the eMMC device, adjusting partitions accordingly. + + .. note:: + + Alternatively, ``bmaptool`` may be used instead: + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + + Keep in mind that the root partition does not make use of the full space when + flashing with ``bmaptool``. + +* After a complete write, your board can boot from eMMC. + + .. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to eMMC. + +Flash SPI NOR Flash +------------------- + +The |som| modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set |ref-bootswitch| to **SPI NOR**. The SPI Flash is usually quite small. +The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash populated. Only the +bootloader and the environment can be stored. The kernel, device tree, and file +system are taken from eMMC by default. + +The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with: + +.. code-block:: + + u-boot=> printenv mtdparts + mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none) + +Flash SPI NOR Flash from Network +................................ + +The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-|soc|. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Flash SPI NOR from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI NOR flash needs to be probed: + +.. code-block:: + + u-boot=> sf probe + SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB + +* A specially formatted U-Boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image over tftp, erase and write the + bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + device 0 offset 0x0, size 0x1c0b20 + 1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +Flash SPI NOR from Network in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the image from the host to the target: + + .. code-block:: console + :substitutions: + + host:~$ scp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root + +* Find the number of blocks to erase of the U-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the U-Boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +Flash SPI NOR Flash from SD Card +................................ + +The bootloader on SPI NOR flash can be also flashed with SD Card. + +Flash SPI NOR from SD Card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the first partition + on the SD Card. + +* Before reading and writing are possible, the SPI-NOR flash + needs to be probed: + + .. code-block:: + + u-boot=> sf probe + SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB + +* A specially formatted U-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image from the SD Card, erase and write + the bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +Flash SPI NOR from SD Card in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the first partition + on the SD Card. + +* Mount the SD Card: + + .. code-block:: console + :substitutions: + + target:~$ mount /dev/mmcblk1p1 /mnt + +* Find the number of blocks to erase of the U-Boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp /mnt/imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: |rauc-manual|_. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mm-pd23.1.0-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti +.. _imx8mm-pd23.1.0-development-build-uboot: +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + :end-before: .. build-uboot-marker + +.. note:: + The regulator for the SD card reset pin has been disabled to ensure + compatibility with 1532.1 revision baseboards. If you have a revision + 1532.2(a) or higher baseboard, you may enable the device tree nodes for + highest performance. In the imx8mm-phyboard-polis-rdk-u-boot.dtsi file, + remove the following lines:: + + /delete-node/ ®_usdhc2_vmmc; + /delete-property/ vmmc-supply; + +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + :start-after: .. build-uboot-marker + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mm-pd23.1.0-format-sd: + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mm-pd23.1.0-device-tree: + +Device Tree (DT) +================ + +Introduction +------------ + +The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html) + +*"The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn't need to hard code details of the machine."* + +The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at `devicetree.org `_. + +PHYTEC |soc| BSP Device Tree Concept +------------------------------------ + +The following sections explain some rules PHYTEC has defined on how to set up +device trees for our |soc| SoC-based boards. + +Device Tree Structure +..................... + +* *Module.dtsi* - Module includes all devices mounted on the SoM, such as PMIC + and RAM. +* *Board.dts* - include the module dtsi file. Devices that come from the |soc| + SoC but are just routed down to the carrier board and used there are included + in this dts. +* *Overlay.dtso* - enable/disable features depending on optional hardware that + may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10) + +From the root directory of the Linux Kernel our devicetree files for |socfamily| +platforms can be found in ``arch/arm64/boot/dts/freescale/``. + +Device Tree Overlay +................... + +Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder ``arch/arm64/boot/dts/freescale/overlays``. + +Available overlays for |yocto-machinename|.conf are: + +.. Add overlay files in leaf file + +:: + + imx8mm-phyboard-polis-peb-eval-01.dtbo + imx8mm-phyboard-polis-peb-av-010.dtbo + imx8mm-phycore-rpmsg.dtbo + imx8mm-phycore-no-eth.dtbo + imx8mm-phycore-no-spiflash.dtbo + imx8mm-vm016.dtbo + imx8mm-vm016-fpdlink.dtbo + imx8mm-vm017.dtbo + imx8mm-vm017-fpdlink.dtbo + imx8mm-dual-vm017-fpdlink.dtbo + +.. _imx8mm-pd23.1.0-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX 0x00 + MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX 0x00 + MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B 0x00 + MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B 0x00 + >; + }; + +The first part of the string MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad (in this example +SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the desired muxing option for this pad. +The pad setting value (hex value on the right) defines different modes of the pad, for example, if +internal pull resistors are activated or not. In this case, the internal resistors are disabled. + +RS232/RS485 +----------- + +The |soc| SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +|ref-bootswitch| needs to be set correctly: + +.. list-table:: Switch between UART1 RS485/RS232 + + * - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS485.png + + **UART1 RS485** + + - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS232.jpg + + **UART1 RS232** + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n291` + +.. _imx8mm-pd23.1.0-network: + +Network +------- + +|sbc|-|soc| provides one Gigabit Ethernet interface. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First set the correct regulatory domain for your country: + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see: + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +Set up the wireless interface: + +.. code-block:: console + + target:~$ ip link + target:~$ ip link set up dev wlan0 + +Now you can scan for available networks: + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection. + +To do so, add the network-credentials to the file ``/etc/wpa_supplicant.conf``: + +.. code-block:: + + country=DE + network={ + ssid="" + proto=WPA2 + psk="" + } + +Now a connection can be established: + +.. code-block:: console + + target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B + +This should result in the following output: + +.. code-block:: + + ... + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section `Changing the Network Configuration` in the |yocto-ref-manual|. + +First, create the directory: + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +Then add the following configuration snippet in ``/etc/systemd/network/10-wlan0.network``: + +.. code-block:: + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +Now, restart the network daemon so that the configuration takes effect: + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Bluetooth +......... + +Bluetooth is connected to |bluetooth-uart| interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually: + +.. code-block:: console + + target:~$ hciconfig hci0 up + + target:~$ hciconfig -a + + hci0: Type: Primary Bus: UART + BD Address: 00:25:CA:2F:39:96 ACL MTU: 1021:8 SCO MTU: 64:1 + UP RUNNING PSCAN + RX bytes:1392 acl:0 sco:0 events:76 errors:0 + TX bytes:1198 acl:0 sco:0 commands:76 errors:0 + ... + +Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup. + +.. code-block:: console + + target:~$ hcitool scan + Scanning ... + XX:XX:XX:XX:XX:XX + +Visibility +~~~~~~~~~~ + +To activate visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 piscan + +To disable visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 noscan + +Connect +~~~~~~~ + +.. code-block:: console + + target:~$ bluetoothctl + [bluetooth]# discoverable on + Changing discoverable on succeeded + [bluetooth]# pairable on + Changing pairable on succeeded + [bluetooth]# agent on + Agent registered + [bluetooth]# default-agent + Default agent request successful + [bluetooth]# scan on + [NEW] Device XX:XX:XX:XX:XX:XX + [bluetooth]# connect XX:XX:XX:XX:XX:XX +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n383` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n335` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n87` + +GPIOs +----- + +The |sbc| has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to |soc| pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal |soc| GPIO banks GPIO1 – GPIO5. + +The GPIOs are identified as GPIO_ (e.g. GPIO5_07). identifies the GPIO +bank and counts from 1 to 5, while stands for the GPIO within the bank. +is being counted from 0 to 31 (32 GPIOs on each bank). + +By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is: + +.. code-block:: + + Linux GPIO number: = ( - 1) * 32 + + +Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools: + +* Detecting the gpiochips on the chip: + + .. code-block:: console + + target:~$ gpiodetect + gpiochip0 [30200000.gpio] (32 lines) + gpiochip1 [30210000.gpio] (32 lines) + gpiochip2 [30220000.gpio] (32 lines) + gpiochip3 [30230000.gpio] (32 lines) + gpiochip4 [30240000.gpio] (32 lines) + +* Show detailed information about the gpiochips. Like their names, consumers, + direction, active state, and additional flags: + + .. code-block:: console + + target:~$ gpioinfo gpiochip0 + +* Read the value of a GPIO (e.g GPIO 20 from chip0): + + .. code-block:: console + + target:~$ gpioget gpiochip0 20 + +* Set the value of GPIO 20 on chip0 to 0 and exit tool: + + .. code-block:: console + + target:~$ gpioset --mode=exit gpiochip0 20=0 + +* Help text of gpioset shows possible options: + + .. code-block:: console + + target:~$ gpioset --help + Usage: gpioset [OPTIONS] = = ... + Set GPIO line values of a GPIO chip + + Options: + -h, --help: display this message and exit + -v, --version: display the version and exit + -l, --active-low: set the line active state to low + -m, --mode=[exit|wait|time|signal] (defaults to 'exit'): + tell the program what to do after setting values + -s, --sec=SEC: specify the number of seconds to wait (only valid for --mode=time) + -u, --usec=USEC: specify the number of microseconds to wait (only valid for --mode=time) + -b, --background: after setting values: detach from the controlling terminal + + Modes: + exit: set values and exit immediately + wait: set values and wait for user to press ENTER + time: set values and sleep for a specified amount of time + signal: set values and wait for SIGINT or SIGTERM + + Note: the state of a GPIO line controlled over the character device reverts to default + when the last process referencing the file descriptor representing the device file exits. + This means that it's wrong to run gpioset, have it exit and expect the line to continue + being driven high or low. It may happen if given pin is floating but it must be interpreted + as undefined behavior. + + +.. warning:: + + Some of the user IOs are used for special functions. Before using a user IO, + refer to the schematic or the hardware manual of your board to ensure that it + is not already in use. + +.. include:: ../peripherals/gpios.rsti + :start-after: .. gpios-via-sysfs-marker + +Pinmuxing of some GPIO pins in the device tree |dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_leds: leds1grp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1 0x16 + MX8MM_IOMUXC_GPIO1_IO14_GPIO1_IO14 0x16 + MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x16 + >; + }; + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n36` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n119` + +General I²C4 bus configuration (e.g. |dt-carrierboard|.dts): +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n244` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues. + +.. include:: ../peripherals/eeprom.rsti + +Rescue EEPROM Data +.................. + +The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area. + +.. code-block:: console + + target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 + +.. note:: + + If you deleted both EEPROM spaces, please contact our support! + +DT representation, e.g. in phyCORE-|soc| file |dt-som|.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n311` + +.. include:: /bsp/peripherals/rtc.rsti + :end-before: .. rtc_parameter_start_label + +RTC Parameters +.............. + +RTCs have a few abilities which can be read/set with the help of ``hwclock`` +tool. + +* We can check RTC supported features with: + + .. code-block:: console + + target:~$ hwclock --param-get features + The RTC parameter 0x0 is set to 0x11. + + What this value means is encoded in kernel, each set bit translates to: + + .. code-block:: + + #define RTC_FEATURE_ALARM 0 + #define RTC_FEATURE_ALARM_RES_MINUTE 1 + #define RTC_FEATURE_NEED_WEEK_DAY 2 + #define RTC_FEATURE_ALARM_RES_2S 3 + #define RTC_FEATURE_UPDATE_INTERRUPT 4 + #define RTC_FEATURE_CORRECTION 5 + #define RTC_FEATURE_BACKUP_SWITCH_MODE 6 + #define RTC_FEATURE_CNT 7 + +* We can check RTC BSM (Backup Switchover Mode) with: + + .. code-block:: console + + target:~$ hwclock --param-get bsm + The RTC parameter 0x2 is set to 0x1. + +* We can set RTC BSM with: + + .. code-block:: console + + target:~$ hwclock --param-set bsm=0x2 + The RTC parameter 0x2 will be set to 0x2. + + What BSM values mean translates to these values: + + .. code-block:: + + #define RTC_BSM_DISABLED 0 + #define RTC_BSM_DIRECT 1 + #define RTC_BSM_LEVEL 2 + #define RTC_BSM_STANDBY 3 + + .. tip:: + You should set BSM mode to DSM or LSM for RTC to switch to backup power + source when the initial power source is not available. Check **RV-3028** RTC + datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching + Mode) actually mean. + +DT representation for I²C RTCs: +:imx-dt:`imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n319` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +'HS'). The USB subsystem has two independent USB controller cores. Both cores +are On-The-Go (OTG) controller cores and are capable of acting as a USB +peripheral device or a USB host. Each is connected to a USB 2.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +User USB2 (host) configuration is in the kernel device tree +|dt-carrierboard|.dts: + +.. code-block:: + + &usbotg2 { + dr_mode = "host"; + picophy,pre-emp-curr-control = <3>; + picophy,dc-vol-level-adjust = <7>; + status = "okay"; + }; + +DT representation for USB Host: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n347` + +.. include:: /bsp/peripherals/usb-otg.rsti + +Both USB interfaces are configured as host in the kernel device tree +|dt-carrierboard|.dts. See: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n335` + +CAN FD +------ + +The |sbc| has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. Hint:: + + phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. + There are different interfaces involved, which limits the datarate + capabilities of CANFD. + +.. Hint:: + + On phyBOARD-Polis-i.MX8MM a terminating resistor can be enabled by setting + S5 to ON if required. + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:imx-dt:`imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n175` + +.. include:: /bsp/peripherals/pcie.rsti + +Audio +----- + +The PEB-AV-10-Connector exists in two versions and the 1531.1 version is +populated with a TI TLV320AIC3007 audio codec. Audio support is done via the I2S +interface and controlled via I2C. + +There is a 3.5mm headset jack with OMTP standard and an 8-pin header to connect +audio devices with the AV-Connector. The 8-pin header contains a mono speaker, +headphones, and line-in signals. + +.. include:: /bsp/peripherals/audio.rsti + +Device Tree Audio configuration: +:imx-dt:`overlays/imx8mm-phyboard-polis-peb-av-010.dtsi?h=v5.15.71_2.2.2-phy3#n54` + +.. include:: /bsp/peripherals/video.rsti + +Display +------- + +The 10" Display is always active. If the PEB-AV-Connector is not connected, an +error message may occur at boot. + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +The device tree of PEB-AV-10 can be found here: +:imx-dt:`overlays/imx8mm-phyboard-polis-peb-av-010.dtsi?h=v5.15.71_2.2.2-phy3` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Mini M4 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti + +.. +---------------------------------------------------------------------------+ +.. BSP EXTENSIONS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/bsp-extensions.rsti diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mn/head.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mn/head.rst.txt new file mode 100644 index 000000000..de505064f --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mn/head.rst.txt @@ -0,0 +1,477 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.wic +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/imx-boot-tools/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mm +.. _`static-pdf-dl`: ../../../_static/imx8mn-head.pdf + +.. IMX8(MN) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mn/phycore-imx8mn.c?h=v2022.04_2.2.2-phy5#n66 + + +.. General Replacements +.. |doc-id| replace:: L-1002e.Ax +.. |kit| replace:: **phyCORE-i.MX8M Nano Kit** +.. |kit-ram-size| replace:: 1GiB +.. |mcore| replace:: M4 Core +.. |sbc| replace:: phyBOARD-Polis +.. |soc| replace:: i.MX 8M Nano +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MN +.. |debug-uart| replace:: ttymxc2 +.. |serial-uart| replace:: ttymxc0 +.. |bluetooth-uart| replace:: UART2 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx8mn +.. |kernel-tag| replace:: v5.15.71_2.2.2-phy3 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-defconfig| replace:: phycore-imx8mn_defconfig +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX8(MN) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MN +.. |u-boot-tag| replace:: v2022.04_2.2.2-phy5 + + +.. RAUC +.. |rauc-manual| replace:: L-1006e.A6 RAUC Update & Device Management Manual +.. _rauc-manual: https://www.phytec.de/cdocuments/?doc=F4DiM + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mn-phyboard-polis +.. |dt-som| replace:: imx8mn-phycore-som +.. |dtbo-peb-av-10| replace:: imx8mn-phyboard-polis-peb-av-010.dtbo + +.. IMX8(MN) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n50` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`kirkstone` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MM +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: kirkstone +.. |yocto-distro| replace:: ampliphy-vendor +.. |yocto-imagename| replace:: phytec-headless-image +.. |yocto-imageext| replace:: rootfs.wic.xz +.. |yocto-machinename| replace:: phyboard-polis-imx8mn-2 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MM-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MM-PD23.1.y +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (kirkstone) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 4.0.13 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Refs +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S1) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X30) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X2 ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MN) specific replacements +.. |sbc-network| replace:: \ +.. |pollux-fan-note| replace:: Only GPIO fan supported. +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + +.. only:: html + + Documentation in pdf format: `Download `_ + ++----------------------+----------------------+ +| |doc-id| |soc| BSP | +| Manual Head | ++----------------------+----------------------+ +| Document Title | |doc-id| |soc| BSP | +| | Manual Head | ++----------------------+----------------------+ +| Document Type | BSP Manual | ++----------------------+----------------------+ +| Article Number | |doc-id| | ++----------------------+----------------------+ +| Yocto Manual | | ++----------------------+----------------------+ +| Release Date | XXXX/XX/XX | ++----------------------+----------------------+ +| Is Branch of | |doc-id| |soc| BSP | +| | Manual Head | ++----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +================ ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +================ ================ ================= ========== +.. +================ ================ ================= ========== + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +The |sbc| populated with the |soc| SoC is supported. + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mn-head-components: +.. include:: ../imx8mm/components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mn-head-getting-started: +.. include:: /bsp/getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, |ref-bootswitch| needs to be set to the following + position: + +.. list-table:: Bootmode Selection + :align: center + + * - .. figure:: images/Nano_SD_BOOT.jpg + :width: 250px + + SD Card Boot + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP | +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mn-head-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mn.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mn-phyboard-polis*.dtb**: Kernel device tree file +* **imx8mn-phy*.dtbo**: Kernel device tree overlay files +* **phytec-headless-image\*.tar.gz**: Root file system +* **phytec-headless-image\*.rootfs.wic.xz**: compressed SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S1) +-------------------- + +The |sbc| features a boot switch with six individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mn-head-bootswitch: +.. include:: bootmode-switch.rsti + +.. include:: ../installing-os.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mn-head-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx-common/development/netboot.rsti + +.. include:: /bsp/imx-common/development/uuu.rsti + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + :end-before: .. build-uboot-fixed-ram-size-marker + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mn-head-format-sd: + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mn-head-device-tree: +.. include:: /bsp/device-tree.rsti + +.. code-block:: + + imx8mn-phyboard-polis-peb-eval-01.dtbo + imx8mn-phyboard-polis-peb-av-010.dtbo + imx8mn-phycore-rpmsg.dtbo + imx8mn-phycore-no-eth.dtbo + imx8mn-phycore-no-spiflash.dtbo + imx8mn-vm016.dtbo + imx8mn-vm016-fpdlink.dtbo + imx8mn-vm017.dtbo + imx8mn-vm017-fpdlink.dtbo + imx8mn-dual-vm017-fpdlink.dtbo + +.. _imx8mn-head-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX 0x00 + MX8MN_IOMUXC_SAI2_RXC_UART1_DCE_RX 0x00 + MX8MN_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B 0x00 + MX8MN_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B 0x00 + >; + }; + +The first part of the string MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad +(in this example SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the right) +defines different modes of the pad, for example, if internal pull resistors are +activated or not. In this case, the internal resistors are disabled. + +RS232/RS485 +----------- + +The |soc| SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +|ref-bootswitch| needs to be set correctly: + +.. list-table:: Switch between UART1 RS485/RS232 + + * - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS485.png + + **UART1 RS485** + + - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS232.jpg + + **UART1 RS232** + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n220` + +.. _imx8mn-head-network: + +Network +------- + +|sbc|-|soc| provides one Gigabit Ethernet interface. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +.. include:: ../../peripherals/wireless-network.rsti + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n301` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n309` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n78` + +.. include:: ../peripherals/gpios.rsti + +Pinmuxing of some GPIO pins in the device tree |dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_leds: leds1grp { + fsl,pins = < + MX8MN_IOMUXC_GPIO1_IO01_GPIO1_IO1 0x16 + MX8MN_IOMUXC_GPIO1_IO14_GPIO1_IO14 0x16 + MX8MN_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x16 + >; + }; + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n45` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n106` + +General I²C3 bus configuration (e.g. |dt-carrierboard|.dts): +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n196` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues. + +.. note:: + + If you deleted reserved EEPROM spaces, please contact our support! + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file |dt-som|.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n259` + +.. include:: /bsp/peripherals/rtc.rsti + +DT representation for I²C RTCs: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n267` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +'HS'). + +The |soc| SoC has a single USB controller core that is set to OTG mode. +To use the micro USB / OTG port dip switch S1 Pos5 has to be set to on. + +.. include:: /bsp/peripherals/usb-host.rsti + +.. include:: /bsp/peripherals/usb-otg.rsti + +The USB interface is configured as host in the kernel device tree +|dt-carrierboard|.dts. See: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n264` + +CAN FD +------ + +The |sbc| has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. Hint:: + + phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. + There are different interfaces involved, which limits the datarate + capabilities of CANFD. + +.. Hint:: + + On phyBOARD-Polis-i.MX8MN a terminating resistor can be enabled by setting + S5 to ON if required. + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n125` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mn/imx8mn.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mn/imx8mn.rst.txt new file mode 100644 index 000000000..b318fc141 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mn/imx8mn.rst.txt @@ -0,0 +1,33 @@ +==================== +i.MX 8M Nano Manuals +==================== + +HEAD +==== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + head + +BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +============================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd23.1.0 + +BSP-Yocto-NXP-i.MX8MM-PD22.1.1 +============================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd22.1.1 diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mn/pd22.1.1.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mn/pd22.1.1.rst.txt new file mode 100644 index 000000000..19e3ba813 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mn/pd22.1.1.rst.txt @@ -0,0 +1,2082 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MM-PD22.1.1 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.wic +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/images/ampliphy-vendor/phyboard-polis-imx8mn-2/imx-boot-tools/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mm +.. _`static-pdf-dl`: ../../../_static/imx8mn-pd22.1.1.pdf + +.. IMX8(MN) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mn/phycore-imx8mn.c?h=v2021.04_2.2.0-phy13 + + +.. General Replacements +.. |atfloadaddr| replace:: 0x960000 +.. |kit| replace:: **phyCORE-i.MX8M Nano Kit** +.. |kit-ram-size| replace:: 1GiB +.. |mcore| replace:: M4 Core +.. |sbc| replace:: phyBOARD-Polis +.. |soc| replace:: i.MX 8M Nano +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MN +.. |debug-uart| replace:: ttymxc2 +.. |serial-uart| replace:: ttymxc0 +.. |bluetooth-uart| replace:: UART2 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx8mn +.. |kernel-tag| replace:: v5.10.72_2.2.0-phy17 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-defconfig| replace:: phycore-imx8mm_defconfig +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX8(MN) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MN +.. |u-boot-tag| replace:: v2021.04_2.2.0-phy13 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mn-phyboard-polis +.. |dt-som| replace:: imx8mn-phycore-som +.. |dtbo-peb-av-10| replace:: imx8mn-phyboard-polis-peb-av-010.dtbo + +.. IMX8(MN) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n47` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`hardknott` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MM +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: hardknott +.. |yocto-distro| replace:: ampliphy-vendor +.. |yocto-imagename| replace:: phytec-headless-image +.. |yocto-machinename| replace:: phyboard-polis-imx8mn-2 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MM-PD22.1.1 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MM-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MM-PD22.1.y +.. |yocto-ref-manual| replace:: L-813e.A12 Yocto Reference Manual (Hardknott) +.. _yocto-ref-manual: https://www.phytec.de/cdocuments/?doc=UIHsG +.. _yocto-ref-manual-kernel-and-bootloader-config: https://www.phytec.de/cdocuments/?doc=UIHsG#YoctoReferenceManualHardknottL813e-A12-KernelandBootloaderConfiguration +.. |yocto-sdk-rev| replace:: BSP-Yocto-NXP-i.MX8MP-PD22.1.1 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + + +.. Refs +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S1) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X30) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X2 ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MN) specific replacements +.. |sbc-network| replace:: \ +.. |pollux-fan-note| replace:: Only GPIO fan supported. +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + +.. only:: html + + Documentation in pdf format: `Download `_ + ++----------------------+----------------------+ +| |soc| BSP Manual | ++----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++----------------------+----------------------+ +| Document Type | BSP Manual | ++----------------------+----------------------+ +| Yocto Manual | | ++----------------------+----------------------+ +| Release Date | 2023/05/25 | ++----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================= ========== +|yocto-manifestname| Minor 2023/05/23 Released +==================== ================ ================= ========== + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +The |sbc| populated with the |soc| SoC is supported. + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mn-pd22.1.1-components: +.. include:: ../imx8mm/components.rsti + +Getting Started +=============== + +The |kit| is shipped with a pre-flashed SD card. It contains the +|yocto-imagename| and can be used directly as a boot source. The eMMC is +programmed with only a U-boot by default. You can get all sources from the +`PHYTEC download server `_. This chapter explains how to flash a BSP +image to SD card and how to start the board. + +Get the Image +------------- + +The WIC image contains all BSP files in several, correctly pre-formatted +partitions and can be copied to an SD card easily using the single Linux +command ``dd``. It can be built by Yocto or downloaded from the PHYTEC download +server. + +Get the WIC file from the download server: + +.. code-block:: console + :substitutions: + + host:~$ wget |link-image| + +Write the Image to SD Card +-------------------------- + +.. warning:: + To create your bootable SD card with the ``dd`` command, you must have root + privileges. Be very careful when specifying the destination device with + ``dd``! All files on the selected destination device will be erased + immediately without any further query! + + Selecting the wrong device may result in **data loss** and e.g. could erase + your currently running system! + +To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. Unmount any mounted partitions before +you start copying the image to the SD card. + +#. In order to get the correct device name, remove your SD card and + execute:: + + host$ lsblk + +#. Now insert your SD card and execute the command again:: + + host$ lsblk + +#. Compare the two outputs to find the new device names listed in the second + output. These are the device names of the SD card (device and partitions if + the SD card was formatted). +#. In order to verify the device names being found, execute the command + ``sudo dmesg``. Within the last lines of its output, you should also find the + device names, e.g. ``/dev/sde`` or ``/dev/mmcblk0`` (depending on your + system). + +Alternatively, you may use a graphical program of your choice, like `GNOME Disks +`_ or `KDE Partition Manager +`_, to find the correct device. + +Now that you have the correct device name, e.g. ``/dev/sde``, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. ``/dev/sde1``) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption. + +* Unmount all partitions, e.g.:: + + host$ sudo umount /dev/sde1 + +* After having unmounted all partitions, you can create your bootable SD card:: + + host$ sudo dd if=-.wic of=/dev/sdX bs=1M conv=fsync status=progress + + Again, make sure to replace ``/dev/sdX`` with your actual device name found + previously. + + The parameter ``conv=fsync`` forces a sync operation on the device before + ``dd`` returns. This ensures that all blocks are written to the SD card and + none are left in memory. The parameter ``status=progress`` will print out + information on how much data is and still has to be copied until it is + finished. + +An alternative and much faster way to prepare an SD card can be done by using +`bmap-tools `_ from Intel. Yocto +automatically creates a block map file (``-.wic.bmap``) for +the WIC image that describes the image content and includes checksums for data +integrity. *bmaptool* is packaged by various Linux distributions. For +Debian-based systems install it by issuing:: + + host$ sudo apt install bmap-tools + +Flash a WIC image to SD card by calling:: + + host$ bmaptool copy -.wic /dev/ + +.. warning:: + *bmaptool* only overwrites the areas of an SD card where image data is + located. This means that a previously written U-Boot environment may still be + available after writing the image. + +First Start-up +-------------- + +* To boot from an SD card, |ref-bootswitch| needs to be set to the following + position: + +.. list-table:: Bootmode Selection + :align: center + + * - .. figure:: images/Nano_SD_BOOT.jpg + :width: 250px + + SD Card Boot + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP | +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mn-pd22.1.1-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mm.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mn-phyboard-polis-dsi*.dtb**: Kernel device tree file +* **imx8mn-phy*.dtbo**: Kernel device tree overlay files +* **phytec-headless-image\*.tar.gz**: Root file system +* **phytec-headless-image\*.wic**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S1) +-------------------- + +The |sbc| features a boot switch with six individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mn-pd22.1.1-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **Default SOM boot**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. However, they only +work if the size of the image file is less than 1GB. If the image file is +larger, go to the section Format SD Card. Configure the |ref-bootswitch| to boot +from SD Card and put in an SD card. Power on the board and stop in U-Boot +prompt. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +* Load your image via network to RAM: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* Write the image to the eMMC: + + .. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + A working network is necessary! Setup Network Host. + +Take a compressed or uncompressed image on the host and send it with ssh through +the network (then uncompress it, if necessary) to the eMMC of the target with a +one-line command: + +.. code-block:: console + :substitutions: + + target:~$ ssh @192.168.3.10 "dd if=/|yocto-imagename|-|yocto-machinename|.wic" | dd of=/dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +Send the image with the command dd command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2" + +Flash eMMC u-boot image via Network from running u-boot +....................................................... + +Update the standalone u-boot image imx-boot is also possible from u-boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB +................... + +Flash eMMC from USB in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in Bootloader after enabling the OPTEE. + +These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch to |ref-bootswitch| and put in an SD card. Power on the board +and stop in u-boot prompt. Insert a USB device with the copied WIC image +to the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} *.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the bootmode switch to +|ref-bootswitch|. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ cd /mnt + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2boot0; mmcblk2boot1) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + +.. warning:: + + Before this will work, you need to configure the multi-port switch + to **Default SOM Boot** to |ref-bootswitch|. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see |ref-format-sd|. + +Flash eMMC from SD card in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in Bootloader after enabling the OPTEE. If the + image file is too large use the `Updating eMMC from SD card in + Linux on Target` subsection. + +* Flash an SD card with a working image and create a third FAT partition. Copy + the WIC image (for example |yocto-imagename|.wic) to this + partition. +* Configure the bootmode switch to boot from the SD Card and insert the SD + card. +* Power on the board and stop in u-boot. +* Flash your WIC image (for example |yocto-imagename|.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> fatload mmc 1:3 ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc0(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the multi-port switch to Default SOM Boot to + boot from eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a complete image saved on +the SD card (e.g. |yocto-imagename|-|yocto-machinename|.wic). + +* Show your saved image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2\ **boot0**; mmcblk2\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + +.. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to Default + SOM Boot to boot from eMMC. + +Flash SPI NOR Flash +------------------- + +The |som| modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set |ref-bootswitch| to **QSPI boot** to boot from QSPI. The SPI Flash is +usually quite small. The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash +populated. Only the bootloader and the environment can be stored. The kernel, +device tree, and file system are taken from eMMC by default. + +The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with: + +.. code-block:: + + u-boot=> printenv mtdparts + mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none) + +Flash SPI NOR Flash from Network +................................ + +The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-|soc|. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Flash SPI NOR from Network in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI-NOR flash needs to be probed: + +.. code-block:: + + u-boot=> sf probe + SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB + +* A specially formatted u-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image over tftp, erase and write the + bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + device 0 offset 0x0, size 0x1c0b20 + 1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +.. warning:: + + Erasing the complete SPI NOR flash when it is fully written will take quite + some time. This can trigger the watchdog to reset. Due to this, erase the + full flash in Linux. + +Flash SPI NOR from Network in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the image from the host to the target: + + .. code-block:: console + :substitutions: + + host:~$ scp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root + +* Find the number of erase blocks of the U-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +Flash SPI NOR Flash from SD Card +................................ + +The bootloader on SPI NOR flash can be also flashed with SD Card. + +Flash SPI NOR from SD Card in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the FAT partition + on the SD Card. Before reading and writing are possible, the SPI-NOR flash + needs to be probed: + + .. code-block:: + + u-boot=> sf probe + SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB + +* A specially formatted U-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image from the SD Card, erase and write + the bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +.. warning:: + + Erasing the complete SPI NOR flash when it is fully written will take quite + some time. This can trigger the watchdog to reset. Due to this, erase the + full flash in Linux. + +Flash SPI NOR from SD Card in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Mount the SD Card: + + .. code-block:: console + :substitutions: + + host:~$ mount /dev/mmcblkp1 /mnt + +* Find the number of erase blocks of the u-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp /mnt/imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A3 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mn-pd22.1.1-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + +U-Boot standalone build +----------------------- + +Get the source code +................... + +* Get the U-Boot sources: + + .. code-block:: console + + host:~$ git clone git://git.phytec.de/u-boot-imx + +* To get the correct *U-Boot* **tag** you need to take a look at our release + notes, which can be found here: `release notes `_ +* The **tag** needed at this release is called |u-boot-tag| +* Check out the needed *U-Boot* **tag**: + +.. code-block:: console + :substitutions: + + host:~$ cd ~/u-boot-imx/ + host:~$ git fetch --all --tags + host:~$ git checkout tags/|u-boot-tag| + +* Technically, you can now build the U-Boot, but practically there are some + further steps necessary: + + * Create your own development branch: + + .. code-block:: console + + host:~$ git switch --create + + .. note:: + + You can name your development branch as you like, this is just an example. + +* Set up a build environment: + + .. code-block:: console + :substitutions: + + host:~$ source /opt/|yocto-distro|/|yocto-manifestname|/environment-setup-cortexa53-crypto-phytec-linux + +* Set this environment variable before building the Image: + + .. code-block:: console + :substitutions: + + host:~$ export ATF_LOAD_ADDR=|atfloadaddr| + +Get the needed binaries +....................... + +To build the bootloader, you need to **copy** these **files** to your |u-boot-repo-name| +**build directory** and rename them to fit with *mkimage* script: + +* **ARM Trusted firmware binary** (*mkimage tool* compatible format + **bl31.bin**): bl31-|kernel-socname|.bin +* **OPTEE image** (optional): tee.bin +* **DDR firmware files** (*mkimage tool* compatible format + **lpddr4_[i,d]mem_\*d_\*.bin**): + lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, + lpddr4_imem_2d_*.bin + +If you already built our BSP with Yocto, you can get the +bl31-|kernel-socname|.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: |ref-bsp-images| + +Or you can download the files here: |link-boot-tools| + +.. warning:: + + Make sure you rename the files you need so that they are compatible with the + *mkimage tool*. + +Build the bootloader +.................... + +* build flash.bin (imx-boot): + + .. code-block:: console + :substitutions: + + host:~$ make phycore-|kernel-socname|_defconfig + host:~$ make flash.bin + +Flash the bootloader to a block device +...................................... + +The flash.bin can be found at u-boot-imx/ directory and now can be flashed. A +chip-specific offset is needed: + +.. _offset-table: + +===== =================== ============================= ============ +SoC Offset User Area Offset Boot Partition eMMC Device +===== =================== ============================= ============ +|soc| |u-boot-offset| kiB |u-boot-offset-boot-part| kiB /dev/mmcblk2 +===== =================== ============================= ============ + +E.g. flash SD card: + +.. code-block:: console + :substitutions: + + host:~$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=|u-boot-offset| conv=sync + +.. hint:: + The specific offset values are also declared in the Yocto variables "BOOTLOADER_SEEK" and "BOOTLOADER_SEEK_EMMC" + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mn-pd22.1.1-device-tree: + +Device Tree (DT) +================ + +Introduction +------------ + +The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html) + +*"The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn't need to hard code details of the machine."* + +The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at `devicetree.org `_. + +PHYTEC |soc| BSP Device Tree Concept +------------------------------------ + +The following sections explain some rules PHYTEC has defined on how to set up +device trees for our |soc| SoC-based boards. + +Device Tree Structure +..................... + +* *Module.dtsi* - Module includes all devices mounted on the SoM, such as PMIC + and RAM. +* *Carrierboard.dtsi* - Devices that come from the |soc| SoC but are just routed + down to the carrier board and used there are included in this dtsi. +* *Board.dts* - include the carrier board and module dtsi files. There may also + be some hardware configuration nodes enabled on the carrier board or the + module (i.e. the Board .dts shows the special characteristics of the board + configuration). For example, there are phyCORE-|soc| SOMs which may or may not + have a MIPI DSI to LVDS converter mounted. The converter is enabled (if + available) in the Board .dts and not in the Module .dtsi + +From the root directory of the Linux Kernel our devicetree files for |socfamily| +platforms can be found in ``arch/arm64/boot/dts/freescale/``. + +Device Tree Overlay +................... + +Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder ``arch/arm64/boot/dts/freescale/overlays``. + +Available overlays for |yocto-machinename|.conf are: + +.. code-block:: + + imx8mn-phyboard-polis-peb-eval-01.dtbo + imx8mn-phyboard-polis-peb-av-010.dtbo + imx8mn-phycore-rpmsg.dtbo + imx8mn-phycore-no-eth.dtbo + imx8mn-phycore-no-spiflash.dtbo + imx8mn-vm016.dtbo + imx8mn-vm016-fpdlink.dtbo + imx8mn-vm017.dtbo + imx8mn-vm017-fpdlink.dtbo + imx8mn-dual-vm017-fpdlink.dtbo + +.. _imx8mn-pd22.1.1-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +imx8mn-phyboard-polis.dtsi: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX 0x00 + MX8MN_IOMUXC_SAI2_RXC_UART1_DCE_RX 0x00 + MX8MN_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B 0x00 + MX8MN_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B 0x00 + >; + }; + +The first part of the string MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad +(in this example SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the right) +defines different modes of the pad, for example, if internal pull resistors are +activated or not. In this case, the internal resistors are disabled. + +RS232/RS485 +----------- + +The |soc| SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +|ref-bootswitch| needs to be set correctly: + +.. list-table:: Switch between UART1 RS485/RS232 + + * - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS485.png + + **UART1 RS485** + + - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS232.jpg + + **UART1 RS232** + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n166` + +.. _imx8mn-pd22.1.1-network: + +Network +------- + +|sbc|-|soc| provides one Gigabit Ethernet interface. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First set the correct regulatory domain for your country: + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see: + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +Set up the wireless interface: + +.. code-block:: console + + target:~$ ip link + target:~$ ip link set up dev wlan0 + +Now you can scan for available networks: + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection. + +To do so, add the network-credentials to the file ``/etc/wpa_supplicant.conf``: + +.. code-block:: + + country=DE + network={ + ssid="" + proto=WPA2 + psk="" + } + +Now a connection can be established: + +.. code-block:: console + + target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B + +This should result in the following output: + +.. code-block:: + + ... + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section `Changing the Network Configuration` in the |yocto-ref-manual|_. + +First, create the directory: + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +Then add the following configuration snippet in ``/etc/systemd/network/10-wlan0.network``: + +.. code-block:: + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +Now, restart the network daemon so that the configuration takes effect: + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Bluetooth +......... + +Bluetooth is connected to |bluetooth-uart| interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually: + +.. code-block:: console + + target:~$ hciconfig hci0 up + + target:~$ hciconfig -a + + hci0: Type: Primary Bus: UART + BD Address: 00:25:CA:2F:39:96 ACL MTU: 1021:8 SCO MTU: 64:1 + UP RUNNING PSCAN + RX bytes:1392 acl:0 sco:0 events:76 errors:0 + TX bytes:1198 acl:0 sco:0 commands:76 errors:0 + ... + +Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup. + +.. code-block:: console + + target:~$ hcitool scan + Scanning ... + XX:XX:XX:XX:XX:XX + +Visibility +~~~~~~~~~~ + +To activate visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 piscan + +To disable visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 noscan + +Connect +~~~~~~~ + +.. code-block:: console + + target:~$ bluetoothctl + [bluetooth]# discoverable on + Changing discoverable on succeeded + [bluetooth]# pairable on + Changing pairable on succeeded + [bluetooth]# agent on + Agent registered + [bluetooth]# default-agent + Default agent request successful + [bluetooth]# scan on + [NEW] Device XX:XX:XX:XX:XX:XX + [bluetooth]# connect XX:XX:XX:XX:XX:XX + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n238` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n293` + +eMMC Devices +------------ + +PHYTEC modules like phyCORE-|soc| is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw MLC memory cells combined with a memory +controller that handles ECC and wear leveling. They are connected via an SD/MMC +interface to the |soc| and are represented as block devices in the Linux kernel +like SD cards, flash drives, or hard disks. + +The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer's datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard. + +PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1 + +Extended CSD Register +..................... + +eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard. + +In the Linux user space, you can query the registers: + +.. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| + +You will see: + +.. code-block:: + + ============================================= + Extended CSD rev 1.7 (MMC 5.0) + ============================================= + + Card Supported Command sets [S_CMD_SET: 0x01] + [...] + +Enabling Background Operations (BKOPS) +...................................... + +In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +cells. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called **Background +Operations (BKOPS)**. + +By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency. + +The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details. + +Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0): + +* Value 0: The host does not support the manual trigger of BKOPS. Device write + performance suffers. +* Value 1: The host does support the manual trigger of BKOPS. It will issue + BKOPS from time to time when it does not need the device. + +The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details). + +The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)). + +The userspace tool mmc does not currently support enabling automatic BKOPS +features. + +* To check whether *BKOPS_EN* is set, execute: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep BKOPS_EN + + The output will be, for example: + + .. code-block:: + + Enable background operations handshake [BKOPS_EN]: 0x01 + #OR + Enable background operations handshake [BKOPS_EN]: 0x00 + + Where value 0x00 means BKOPS_EN is disabled and device write performance + suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue + background operations from time to time. + +* To set the BKOPS_EN bit, execute: + + .. code-block:: console + :substitutions: + + target:~$ mmc bkops enable /dev/|emmcdev| + +* To ensure that the new setting is taken over and the kernel triggers BKOPS by + itself, shut down the system: + + .. code-block:: console + + target:~$ poweroff + +.. tip:: + + The BKOPS_EN bit is one-time programmable only. It cannot be reversed. + +Reliable Write +.............. + +There are two different Reliable Write options: + +1. Reliable Write option for a whole eMMC device/partition. +2. Reliable Write for single write transactions. + +.. tip:: + + Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT + partition table (see the previous section). + +The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-|soc| SoMs. To check this on the running target: + +.. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep -A 5 WR_REL_SET + Write reliability setting register [WR_REL_SET]: 0x1f + user area: the device protects existing data if a power failure occurs during a write o + peration + partition 1: the device protects existing data if a power failure occurs during a write + operation + partition 2: the device protects existing data if a power failure occurs during a write + operation + partition 3: the device protects existing data if a power failure occurs during a write + operation + partition 4: the device protects existing data if a power failure occurs during a write + operation + -- + Device supports writing EXT_CSD_WR_REL_SET + Device supports the enhanced def. of reliable write + +Otherwise, it can be enabled with the mmc tool: + +.. code-block:: console + + target:~$ mmc --help + + [...] + mmc write_reliability set <-y|-n> + +The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META. + +**Conclusion**: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application. + +Resizing ext4 Root Filesystem +............................. + +When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk. + +* Get the current device size: + + .. code-block:: console + :substitutions: + + target:~$ parted /dev/|emmcdev| print + +* The output looks like this: + + .. code-block:: + :substitutions: + + Model: MMC Q2J55L (sd/mmc) + Disk /dev/|emmcdev|: 7617MB + Sect[ 1799.850385] |emmcdev|: p1 p2 + or size (logical/physical): 512B/512B + Partition Table: msdos + Disk Flags: + + Number Start End Size Type File system Flags + 1 4194kB 72.4MB 68.2MB primary fat16 boot, lba + 2 72.4MB 537MB 465MB primary ext4 + +* Use parted to resize the root partition to the max size of the device: + + .. code-block:: console + :substitutions: + + target:~$ parted /dev/|emmcdev| resizepart 2 100% + Information: You may need to update /etc/fstab. + + target:~$ parted /dev/|emmcdev| print + Model: MMC Q2J55L (sd/mmc) + Disk /dev/|emmcdev|: 7617MB + Sector size (logical/physical): 512[ 1974.191657] |emmcdev|: p1 p2 + B/512B + Partition Table: msdos + Disk Flags: + + Number Start End Size Type File system Flags + 1 4194kB 72.4MB 68.2MB primary fat16 boot, lba + 2 72.4MB 7617MB 7545MB primary ext4 + +Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted. + +* Resize the filesystem to a new partition size: + + .. code-block:: console + :substitutions: + + target:~$ resize2fs /dev/|emmcdev|p2 + resize2fs 1.46.1 (9-Feb-2021) + Filesystem at /dev/|emmcdev|p2 is mounted on /; on-line resizing required + [ 131.609512] EXT4-fs (|emmcdev|p2): resizing filesystem + from 454136 to 7367680 blocks + old_desc_blocks = 4, new_desc_blocks = 57 + [ 131.970278] EXT4-fs (|emmcdev|p2): resized filesystem to 7367680 + The filesystem on /dev/|emmcdev|p2 is now 7367680 (1k) blocks long + +Enable pseudo-SLC Mode +...................... + +eMMC devices use MLC memory cells +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC memory cells used in NAND Flash, MLC memory cells have lower +reliability and a higher error rate at lower costs. + +If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity. + +.. warning:: + + When enabling the enhanced attribute on the device, all data will be lost. + +The following sequence shows how to enable the enhanced attribute. + +* First obtain the current size of the eMMC device with: + + .. code-block:: console + :substitutions: + + target:~$ parted -m /dev/|emmcdev| unit B print + + You will receive: + + .. code-block:: + :substitutions: + + BYT; + /dev/|emmcdev|:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:; + + As you can see this device has 63652757504 Byte = 60704 MiB. + +* To get the maximum size of the device after pseudo-SLC is enabled use: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep ENH_SIZE_MULT -A 1 + + which shows, for example: + + .. code-block:: + + Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + -- + Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000 + i.e. 0 KiB + + Here the maximum size is 3719168 KiB = 3632 MiB. + +* Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by + typing: + + .. code-block:: console + :substitutions: + + target:~$ mmc enh_area set -y 0 3719168 /dev/|emmcdev| + + You will get: + + .. code-block:: + :substitutions: + + Done setting ENH_USR area on /dev/|emmcdev| + setting OTP PARTITION_SETTING_COMPLETED! + Setting OTP PARTITION_SETTING_COMPLETED on /dev/|emmcdev| SUCCESS + Device power cycle needed for settings to take effect. + Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle + +* To ensure that the new setting has taken over, shut down the system: + + .. code-block:: console + + target:~$ poweroff + + and perform a power cycle. It is recommended that you verify the settings now. + +* First, check the value of ENH_SIZE_MULT which must be 3719168 KiB: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep ENH_SIZE_MULT -A 1 + + You should receive:: + + Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + -- + Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + +* Finally, check the size of the device: + + .. code-block:: console + :substitutions: + + target:~$ parted -m /dev/|emmcdev| unit B print + BYT; + /dev/|emmcdev|:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:; + +Erasing the Device +.................. + +It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC memory +cells or mark these blocks as discard. The data on the device is lost and will +be read back as zeros. + +* After booting from SD Card execute: + + .. code-block:: console + :substitutions: + + target:~$ blkdiscard -f --secure /dev/|emmcdev| + + The option --secure ensures that the command waits until the eMMC device has + erased all blocks. The -f (force) option disables all checking before erasing + and it is needed when the eMMC device contains existing partitions with data. + +.. tip:: + .. code-block:: console + :substitutions: + + target:~$ dd if=/dev/zero of=/dev/|emmcdev| conv=fsync + + also destroys all information on the device, but this command is bad for wear + leveling and takes much longer! + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n75` + +GPIOs +----- + +The |sbc| has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to |soc| pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal |soc| GPIO banks GPIO1 – GPIO5. + +The GPIOs are identified as GPIO_ (e.g. GPIO5_07). identifies the GPIO +bank and counts from 1 to 5, while stands for the GPIO within the bank. +is being counted from 0 to 31 (32 GPIOs on each bank). + +By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is: + +.. code-block:: + + Linux GPIO number: = ( - 1) * 32 + + +Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools: + +* Detecting the gpiochips on the chip: + + .. code-block:: console + + target:~$ gpiodetect + gpiochip0 [30200000.gpio] (32 lines) + gpiochip1 [30210000.gpio] (32 lines) + gpiochip2 [30220000.gpio] (32 lines) + gpiochip3 [30230000.gpio] (32 lines) + gpiochip4 [30240000.gpio] (32 lines) + +* Show detailed information about the gpiochips. Like their names, consumers, + direction, active state, and additional flags: + + .. code-block:: console + + target:~$ gpioinfo gpiochip0 + +* Read the value of a GPIO (e.g GPIO 20 from chip0): + + .. code-block:: console + + target:~$ gpioget gpiochip0 20 + +* Set the value of GPIO 20 on chip0 to 0 and exit tool: + + .. code-block:: console + + target:~$ gpioset --mode=exit gpiochip0 20=0 + +* Help text of gpioset shows possible options: + + .. code-block:: console + + target:~$ gpioset --help + Usage: gpioset [OPTIONS] = = ... + Set GPIO line values of a GPIO chip + + Options: + -h, --help: display this message and exit + -v, --version: display the version and exit + -l, --active-low: set the line active state to low + -m, --mode=[exit|wait|time|signal] (defaults to 'exit'): + tell the program what to do after setting values + -s, --sec=SEC: specify the number of seconds to wait (only valid for --mode=time) + -u, --usec=USEC: specify the number of microseconds to wait (only valid for --mode=time) + -b, --background: after setting values: detach from the controlling terminal + + Modes: + exit: set values and exit immediately + wait: set values and wait for user to press ENTER + time: set values and sleep for a specified amount of time + signal: set values and wait for SIGINT or SIGTERM + + Note: the state of a GPIO line controlled over the character device reverts to default + when the last process referencing the file descriptor representing the device file exits. + This means that it's wrong to run gpioset, have it exit and expect the line to continue + being driven high or low. It may happen if given pin is floating but it must be interpreted + as undefined behavior. + + +.. warning:: + + Some of the user IOs are used for special functions. Before using a user IO, + refer to the schematic or the hardware manual of your board to ensure that it + is not already in use. + +GPIOs via sysfs +............... + +.. warning:: + + Accessing gpios via sysfs is deprecated and we encourage to use libgpiod + instead. + +Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling ``CONFIG_GPIO_SYSFS`` in the kernel +configuration. To make ``CONFIG_GPIO_SYSFS`` visible in menuconfig the option +``CONFIG_EXPERT`` has to be enabled first. + +You can also add this option for example to the defconfig you use in +``arch/arm64/configs/`` in the linux kernel sources. For our NXP based releases, +this could be for example ``imx8_phytec_distro.config``:: + + .. + CONFIG_EXPERT=y + CONFIG_GPIO_SYSFS=y + .. + +Otherwise you can create a new config fragment. This is described in our +`Yocto Reference Manual `_. + +Pinmuxing of some GPIO pins in the device tree |dt-carrierboard|.dtsi:: + + pinctrl_leds: leds1grp { + fsl,pins = < + MX8MN_IOMUXC_GPIO1_IO01_GPIO1_IO1 0x16 + MX8MN_IOMUXC_GPIO1_IO14_GPIO1_IO14 0x16 + MX8MN_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x16 + >; + }; + +LEDs +---- + +If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using ``/sys/class/leds/`` instead +of ``/sys/class/gpio/``. The maximum brightness of the LEDs can be read from +the ``max_brightness`` file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings. + +Below is a simple example. + +To get all available LEDs, type: + +.. code-block:: console + + target:~$ ls /sys/class/leds + mmc1::@ mmc2::@ user-led1@ user-led2@ user-led3@ + +Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the |sbc|. + +* To toggle the LEDs ON: + + .. code-block:: console + + target:~$ echo 255 > /sys/class/leds/user-led1/brightness + +* To toggle OFF: + + .. code-block:: console + + target:~$ echo 0 > /sys/class/leds/user-led1/brightness + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n35` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n98` + +General I²C3 bus configuration (e.g. |dt-carrierboard|.dtsi): +:imx-dt:`imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n147` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues. + +.. include:: ../peripherals/eeprom.rsti + +Rescue EEPROM Data +.................. + +The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area. + +.. code-block:: console + + target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 + +.. note:: + + If you deleted both EEPROM spaces, please contact our support! + +DT representation, e.g. in phyCORE-|soc| file |dt-som|.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n248` + +.. include:: /bsp/peripherals/rtc.rsti + :end-before: .. rtc_parameter_start_label + +DT representation for I²C RTCs: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy9#n254` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +'HS'). + +The |soc| SoC has a single USB controller core that is set to OTG mode. +To use the micro USB / OTG port dip switch S1 Pos5 has to be set to on. + +.. include:: /bsp/peripherals/usb-host.rsti + +.. include:: /bsp/peripherals/usb-otg.rsti + +Both USB interfaces are configured as host in the kernel device tree +|dt-carrierboard|.dtsi. See: +:imx-dt:`imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n206` + +CAN FD +------ + +The |sbc| has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. Hint:: + + phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. + There are different interfaces involved, which limits the datarate + capabilities of CANFD. + +.. Hint:: + + On phyBOARD-Polis-i.MX8MN a terminating resistor can be enabled by setting + S5 to ON if required. + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dtsi: +:imx-dt:`imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n104` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. BSP EXTENSIONS +.. +---------------------------------------------------------------------------+ + +BSP Extensions +============== + +Chromium +-------- + +Our BSP for the |sbc|-|soc| supports Chromium. You can include it in the +|yocto-imagename| with only a few steps. + +Adding Chromium to Your local.conf +.................................. + +To include Chromium you have to add the following line into your local.conf. You +can find it in /build/conf/local.conf. This adds Chromium to your +next image build. :: + + IMAGE_INSTALL_append = " chromium-ozone-wayland" + +.. note:: + + Compiling Chromium takes a long time. + +Get Chromium Running on the Target +.................................. + +To run Chromium, it needs a few arguments to use the hardware graphics +acceleration:: + + target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox + +If you want to start Chromium via SSH, you must first define the display on +which Chromium will run. For example:: + + target$ DISPLAY=:0 + +After you have defined this, you can start it via virtual terminal on Weston as +shown above. diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mn/pd23.1.0.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mn/pd23.1.0.rst.txt new file mode 100644 index 000000000..229d493ea --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mn/pd23.1.0.rst.txt @@ -0,0 +1,1670 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.wic +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/imx-boot-tools/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mm +.. _`static-pdf-dl`: ../../../_static/imx8mn-pd23.1.0.pdf + +.. IMX8(MN) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mn/phycore-imx8mn.c?h=v2022.04_2.2.2-phy5#n66 + + +.. General Replacements +.. |kit| replace:: **phyCORE-i.MX8M Nano Kit** +.. |kit-ram-size| replace:: 1GiB +.. |mcore| replace:: M4 Core +.. |sbc| replace:: phyBOARD-Polis +.. |soc| replace:: i.MX 8M Nano +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MN +.. |debug-uart| replace:: ttymxc2 +.. |serial-uart| replace:: ttymxc0 +.. |bluetooth-uart| replace:: UART2 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx8mn +.. |kernel-tag| replace:: v5.15.71_2.2.2-phy3 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-defconfig| replace:: phycore-imx8mn_defconfig +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX8(MN) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MN +.. |u-boot-tag| replace:: v2022.04_2.2.2-phy5 + + +.. RAUC +.. |rauc-manual| replace:: L-1006e.A5 RAUC Update & Device Management Manual +.. _rauc-manual: https://www.phytec.de/cdocuments/?doc=fgByJg + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mn-phyboard-polis +.. |dt-som| replace:: imx8mn-phycore-som +.. |dtbo-peb-av-10| replace:: imx8mn-phyboard-polis-peb-av-010.dtbo + +.. IMX8(MN) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n50` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`kirkstone` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MM +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: kirkstone +.. |yocto-distro| replace:: ampliphy-vendor +.. |yocto-imagename| replace:: phytec-headless-image +.. |yocto-imageext| replace:: wic +.. |yocto-machinename| replace:: phyboard-polis-imx8mn-2 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MM-PD23.1.0 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MM-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MM-PD23.1.y +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (kirkstone) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 4.0.13 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Refs +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S1) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X30) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X2 ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MN) specific replacements +.. |sbc-network| replace:: \ +.. |pollux-fan-note| replace:: Only GPIO fan supported. +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + +.. only:: html + + Documentation in pdf format: `Download `_ + ++----------------------+----------------------+ +| |soc| BSP Manual | ++----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++----------------------+----------------------+ +| Document Type | BSP Manual | ++----------------------+----------------------+ +| Yocto Manual | Kirkstone | ++----------------------+----------------------+ +| Release Date | 2024/01/10 | ++----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================ ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================ ========== +|yocto-manifestname| Major 2023/12/12 Released +==================== ================ ================ ========== + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +The |sbc| populated with the |soc| SoC is supported. + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mn-pd23.1.0-components: +.. include:: ../imx8mm/components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mn-pd23.1.0-getting-started: + +Getting Started +=============== + +The |kit| is shipped with a pre-flashed SD card. It contains the +|yocto-imagename| and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +`PHYTEC download server `_. This chapter explains how to flash a BSP +image to SD card and how to start the board. + +There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool ``dd``. An +alternative way is to use PHYTEC's system initialization program called +`partup `_, which makes it especially easy to +format more complex systems. You can get `prebuilt Linux binaries of partup +`__ from its release page. Also read +`partup's README `__ for installation +instructions. + +Get the Image +------------- + +The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using ``dd``, can be downloaded from the `PHYTEC download server +`_. + +Get either the partup package or the WIC image from the download server: + +.. code-block:: console + :substitutions: + + host:~$ wget |link-partup-package| + host:~$ wget |link-image| + +.. note:: + For eMMC, more complex partitioning schemes or even just large images, we + recommend using the partup package, as it is faster in writing than ``dd`` + and allows for a more flexible configuration of the target flash device. + +Write the Image to SD Card +-------------------------- + +.. warning:: + To create your bootable SD card, you must have root privileges on your Linux + host PC. Be very careful when specifying the destination device! All files + on the selected device will be erased immediately without any further query! + + Selecting the wrong device may result in **data loss** and e.g. could erase + your currently running system on your host PC! + +Finding the Correct Device +.......................... + +To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card. + +#. In order to get the correct device name, remove your SD card and + execute: + + .. code-block:: console + + host:~$ lsblk + +#. Now insert your SD card and execute the command again: + + .. code-block:: console + + host:~$ lsblk + +#. Compare the two outputs to find the new device names listed in the second + output. These are the device names of the SD card (device and partitions if + the SD card was formatted). +#. In order to verify the device names being found, execute the command + ``sudo dmesg``. Within the last lines of its output, you should also find the + device names, e.g. ``/dev/sde`` or ``/dev/mmcblk0`` (depending on your + system). + +Alternatively, you may use a graphical program of your choice, like `GNOME Disks +`_ or `KDE Partition Manager +`_, to find the correct device. + +Now that you have the correct device name, e.g. ``/dev/sde``, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. ``/dev/sde1``) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption. + +Unmount all those partitions, e.g.: + +.. code-block:: console + + host:~$ sudo umount /dev/sde1 + host:~$ sudo umount /dev/sde2 + +Now, the SD card is ready to be flashed with an image, using either ``partup``, +``dd`` or ``bmap-tools``. + +Using partup +............ + +Writing to an SD card with partup is done in a single command: + +.. code-block:: console + :substitutions: + + host:~$ sudo partup install |yocto-imagename|-|yocto-machinename|.partup /dev/ + +Make sure to replace with your actual device name found previously. + +Further usage of partup is explained at its `official documentation website +`__. + +.. note:: + *partup* has the advantage of allowing to clear specific raw areas in the + MMC user area, which is used in our provided partup packages to erase any + existing U-Boot environments. This is a known issue *bmaptool* does not + solve, as mentioned below. + + Another key advantage of partup over other flashing tools is that it allows + configuring MMC specific parts, like writing to eMMC boot partitions, without + the need to call multiple other commands when writing. + +Using bmap-tools +................ + +An alternative and also fast way to prepare an SD card is using +`bmap-tools `_. Yocto +automatically creates a block map file (``-.wic.bmap``) for +the WIC image that describes the image content and includes checksums for data +integrity. *bmaptool* is packaged by various Linux distributions. For +Debian-based systems install it by issuing: + +.. code-block:: console + + host:~$ sudo apt install bmap-tools + +Flash a WIC image to SD card by calling: + +.. code-block:: console + :substitutions: + + host:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/ + +Replace with your actual SD card's device name found previously, +and make sure to place the file ``-.wic.bmap`` alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip. + +.. warning:: + *bmaptool* only overwrites the areas of an SD card where image data is + located. This means that a previously written U-Boot environment may still be + available after writing the image. + +Using ``dd`` +............ + +After having unmounted all SD card's partitions, you can create your bootable SD card. + +Some PHYTEC BSPs produce uncompressed images (with filename-extension \*.wic), +and some others produce compressed images (with filename-extension \*.wic.xz). + +To flash an uncompressed images (\*.wic) use command below: + +.. code-block:: console + :substitutions: + + host:~$ sudo dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/ bs=1M conv=fsync status=progress + +Or to flash a compressed images (\*.wic.xz) use that command: + +.. code-block:: console + :substitutions: + + host:~$ xzcat |yocto-imagename|-|yocto-machinename|.wic.xz | sudo dd of=/dev/ bs=1M conv=fsync status=progress + +Again, make sure to replace with your actual device name found +previously. + +The parameter ``conv=fsync`` forces a sync operation on the device before +``dd`` returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter ``status=progress`` will print out +information on how much data is and still has to be copied until it is +finished. + +First Start-up +-------------- + +* To boot from an SD card, |ref-bootswitch| needs to be set to the following + position: + +.. list-table:: Bootmode Selection + :align: center + + * - .. figure:: images/Nano_SD_BOOT.jpg + :width: 250px + + SD Card Boot + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP | +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mn-pd23.1.0-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mn.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mn-phyboard-polis*.dtb**: Kernel device tree file +* **imx8mn-phy*.dtbo**: Kernel device tree overlay files +* **phytec-headless-image\*.tar.gz**: Root file system +* **phytec-headless-image\*.wic**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S1) +-------------------- + +The |sbc| features a boot switch with six individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mn-pd23.1.0-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see |ref-setup-network-host|. + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **eMMC**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load your image via network to RAM: + +* when using dhcp + + .. code-block:: + :substitutions: + + u-boot=> dhcp |yocto-imagename|-|yocto-machinename|.wic + BOOTP broadcast 1 + DHCP client bound to address 192.168.3.1 (1 ms) + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.1 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* when using a static ip address (serverip and ipaddr must be set + additionally). + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Take a compressed or uncompressed image with accompanying block map on the host +and send it with ssh through the network to the eMMC of the target with a +one-line command: + +.. code-block:: console + :substitutions: + + target:~$ scp @192.168.3.10:/srv/tftp/|yocto-imagename|-|yocto-machinename|.wic /tmp && bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls /srv/tftp + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +Send the image with the ``bmaptool`` command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ scp /srv/tftp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2" + +Flash eMMC U-Boot image via Network from running U-Boot +....................................................... + +Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB stick +......................... + +Flash eMMC from USB stick in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. + +These steps will show how to update the eMMC via a USB device. Configure the +|ref-bootswitch| to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied WIC image to the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} *.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the |ref-bootswitch| to SD Card. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ ls /mnt + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy /mnt/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + + .. tip:: + + Before this will work, you need to configure the |ref-bootswitch| to + **eMMC**. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see |ref-format-sd|. + +Alternatively, flash a partup package to the SD card, as described in +|ref-getting-started|. This will ensure the full space of the SD card is used. + +Flash eMMC from SD card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. If the + image file is too large use the `Updating eMMC from SD card in + Linux on Target` subsection. + +* Flash an SD card with a working image and create a third ext4 partition. Copy + the WIC image (for example |yocto-imagename|.wic) to this + partition. +* Configure the |ref-bootswitch| to SD Card and insert the SD Card. +* Power on the board and stop in U-Boot. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> ext4load mmc 1:3 ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev to eMMC: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + +* Flash your WIC image (for example |yocto-imagename|.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. + + .. code-block:: + + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the |ref-bootswitch| to eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card. + +* Show your saved partup package or WIC image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.partup + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition) using `partup`_: + + .. code-block:: console + :substitutions: + + target:~$ partup install |yocto-imagename|-|yocto-machinename|.partup /dev/mmcblk2 + + Flashing the partup package has the advantage of using the full capacity of + the eMMC device, adjusting partitions accordingly. + + .. note:: + + Alternatively, ``bmaptool`` may be used instead: + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + + Keep in mind that the root partition does not make use of the full space when + flashing with ``bmaptool``. + +* After a complete write, your board can boot from eMMC. + + .. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to eMMC. + +Flash SPI NOR Flash +------------------- + +The |som| modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set |ref-bootswitch| to **SPI NOR**. The SPI Flash is usually quite small. +The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash populated. Only the +bootloader and the environment can be stored. The kernel, device tree, and file +system are taken from eMMC by default. + +The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with: + +.. code-block:: + + u-boot=> printenv mtdparts + mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none) + +Flash SPI NOR Flash from Network +................................ + +The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-|soc|. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Flash SPI NOR from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI NOR flash needs to be probed: + +.. code-block:: + + u-boot=> sf probe + SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB + +* A specially formatted U-Boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image over tftp, erase and write the + bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + device 0 offset 0x0, size 0x1c0b20 + 1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +Flash SPI NOR from Network in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the image from the host to the target: + + .. code-block:: console + :substitutions: + + host:~$ scp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root + +* Find the number of blocks to erase of the U-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the U-Boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +Flash SPI NOR Flash from SD Card +................................ + +The bootloader on SPI NOR flash can be also flashed with SD Card. + +Flash SPI NOR from SD Card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the first partition + on the SD Card. + +* Before reading and writing are possible, the SPI-NOR flash + needs to be probed: + + .. code-block:: + + u-boot=> sf probe + SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB + +* A specially formatted U-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image from the SD Card, erase and write + the bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +Flash SPI NOR from SD Card in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the first partition + on the SD Card. + +* Mount the SD Card: + + .. code-block:: console + :substitutions: + + target:~$ mount /dev/mmcblk1p1 /mnt + +* Find the number of blocks to erase of the U-Boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp /mnt/imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: |rauc-manual|_. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mn-pd23.1.0-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + :end-before: .. build-uboot-fixed-ram-size-marker + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mn-pd23.1.0-format-sd: + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mn-pd23.1.0-device-tree: + +Device Tree (DT) +================ + +Introduction +------------ + +The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html) + +*"The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn't need to hard code details of the machine."* + +The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at `devicetree.org `_. + +PHYTEC |soc| BSP Device Tree Concept +------------------------------------ + +The following sections explain some rules PHYTEC has defined on how to set up +device trees for our |soc| SoC-based boards. + +Device Tree Structure +..................... + +* *Module.dtsi* - Module includes all devices mounted on the SoM, such as PMIC + and RAM. +* *Board.dts* - include the module dtsi file. Devices that come from the |soc| + SoC but are just routed down to the carrier board and used there are included + in this dts. +* *Overlay.dtso* - enable/disable features depending on optional hardware that + may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10) + +From the root directory of the Linux Kernel our devicetree files for |socfamily| +platforms can be found in ``arch/arm64/boot/dts/freescale/``. + +Device Tree Overlay +................... + +Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder ``arch/arm64/boot/dts/freescale/overlays``. + +Available overlays for |yocto-machinename|.conf are: + +.. Add overlay files in leaf file + +.. code-block:: + + imx8mn-phyboard-polis-peb-eval-01.dtbo + imx8mn-phyboard-polis-peb-av-010.dtbo + imx8mn-phycore-rpmsg.dtbo + imx8mn-phycore-no-eth.dtbo + imx8mn-phycore-no-spiflash.dtbo + imx8mn-vm016.dtbo + imx8mn-vm016-fpdlink.dtbo + imx8mn-vm017.dtbo + imx8mn-vm017-fpdlink.dtbo + imx8mn-dual-vm017-fpdlink.dtbo + +.. _imx8mn-pd23.1.0-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX 0x00 + MX8MN_IOMUXC_SAI2_RXC_UART1_DCE_RX 0x00 + MX8MN_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B 0x00 + MX8MN_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B 0x00 + >; + }; + +The first part of the string MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX names the pad +(in this example SAI2_RXFS). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the right) +defines different modes of the pad, for example, if internal pull resistors are +activated or not. In this case, the internal resistors are disabled. + +RS232/RS485 +----------- + +The |soc| SoC provides up to 4 UART units. PHYTEC boards support different +numbers of these UART units. UART1 can also be used as RS-485. For this, +|ref-bootswitch| needs to be set correctly: + +.. list-table:: Switch between UART1 RS485/RS232 + + * - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS485.png + + **UART1 RS485** + + - .. figure:: /bsp/imx8/imx8mm/images/UART1_RS232.jpg + + **UART1 RS232** + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n220` + +.. _imx8mn-pd23.1.0-network: + +Network +------- + +|sbc|-|soc| provides one Gigabit Ethernet interface. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First set the correct regulatory domain for your country: + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see: + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +Set up the wireless interface: + +.. code-block:: console + + target:~$ ip link + target:~$ ip link set up dev wlan0 + +Now you can scan for available networks: + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection. + +To do so, add the network-credentials to the file ``/etc/wpa_supplicant.conf``: + +.. code-block:: + + country=DE + network={ + ssid="" + proto=WPA2 + psk="" + } + +Now a connection can be established: + +.. code-block:: console + + target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B + +This should result in the following output: + +.. code-block:: + + ... + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section `Changing the Network Configuration` in the |yocto-ref-manual|. + +First, create the directory: + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +Then add the following configuration snippet in ``/etc/systemd/network/10-wlan0.network``: + +.. code-block:: + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +Now, restart the network daemon so that the configuration takes effect: + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Bluetooth +......... + +Bluetooth is connected to |bluetooth-uart| interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually: + +.. code-block:: console + + target:~$ hciconfig hci0 up + + target:~$ hciconfig -a + + hci0: Type: Primary Bus: UART + BD Address: 00:25:CA:2F:39:96 ACL MTU: 1021:8 SCO MTU: 64:1 + UP RUNNING PSCAN + RX bytes:1392 acl:0 sco:0 events:76 errors:0 + TX bytes:1198 acl:0 sco:0 commands:76 errors:0 + ... + +Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup. + +.. code-block:: console + + target:~$ hcitool scan + Scanning ... + XX:XX:XX:XX:XX:XX + +Visibility +~~~~~~~~~~ + +To activate visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 piscan + +To disable visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 noscan + +Connect +~~~~~~~ + +.. code-block:: console + + target:~$ bluetoothctl + [bluetooth]# discoverable on + Changing discoverable on succeeded + [bluetooth]# pairable on + Changing pairable on succeeded + [bluetooth]# agent on + Agent registered + [bluetooth]# default-agent + Default agent request successful + [bluetooth]# scan on + [NEW] Device XX:XX:XX:XX:XX:XX + [bluetooth]# connect XX:XX:XX:XX:XX:XX + + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n301` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n309` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n78` + +GPIOs +----- + +The |sbc| has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to |soc| pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal |soc| GPIO banks GPIO1 – GPIO5. + +The GPIOs are identified as GPIO_ (e.g. GPIO5_07). identifies the GPIO +bank and counts from 1 to 5, while stands for the GPIO within the bank. +is being counted from 0 to 31 (32 GPIOs on each bank). + +By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is: + +.. code-block:: + + Linux GPIO number: = ( - 1) * 32 + + +Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools: + +* Detecting the gpiochips on the chip: + + .. code-block:: console + + target:~$ gpiodetect + gpiochip0 [30200000.gpio] (32 lines) + gpiochip1 [30210000.gpio] (32 lines) + gpiochip2 [30220000.gpio] (32 lines) + gpiochip3 [30230000.gpio] (32 lines) + gpiochip4 [30240000.gpio] (32 lines) + +* Show detailed information about the gpiochips. Like their names, consumers, + direction, active state, and additional flags: + + .. code-block:: console + + target:~$ gpioinfo gpiochip0 + +* Read the value of a GPIO (e.g GPIO 20 from chip0): + + .. code-block:: console + + target:~$ gpioget gpiochip0 20 + +* Set the value of GPIO 20 on chip0 to 0 and exit tool: + + .. code-block:: console + + target:~$ gpioset --mode=exit gpiochip0 20=0 + +* Help text of gpioset shows possible options: + + .. code-block:: console + + target:~$ gpioset --help + Usage: gpioset [OPTIONS] = = ... + Set GPIO line values of a GPIO chip + + Options: + -h, --help: display this message and exit + -v, --version: display the version and exit + -l, --active-low: set the line active state to low + -m, --mode=[exit|wait|time|signal] (defaults to 'exit'): + tell the program what to do after setting values + -s, --sec=SEC: specify the number of seconds to wait (only valid for --mode=time) + -u, --usec=USEC: specify the number of microseconds to wait (only valid for --mode=time) + -b, --background: after setting values: detach from the controlling terminal + + Modes: + exit: set values and exit immediately + wait: set values and wait for user to press ENTER + time: set values and sleep for a specified amount of time + signal: set values and wait for SIGINT or SIGTERM + + Note: the state of a GPIO line controlled over the character device reverts to default + when the last process referencing the file descriptor representing the device file exits. + This means that it's wrong to run gpioset, have it exit and expect the line to continue + being driven high or low. It may happen if given pin is floating but it must be interpreted + as undefined behavior. + + +.. warning:: + + Some of the user IOs are used for special functions. Before using a user IO, + refer to the schematic or the hardware manual of your board to ensure that it + is not already in use. + +.. include:: ../peripherals/gpios.rsti + :start-after: .. gpios-via-sysfs-marker + +Pinmuxing of some GPIO pins in the device tree |dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_leds: leds1grp { + fsl,pins = < + MX8MN_IOMUXC_GPIO1_IO01_GPIO1_IO1 0x16 + MX8MN_IOMUXC_GPIO1_IO14_GPIO1_IO14 0x16 + MX8MN_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x16 + >; + }; + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n45` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n106` + +General I²C3 bus configuration (e.g. |dt-carrierboard|.dts): +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n196` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues. + +.. include:: ../peripherals/eeprom.rsti + +Rescue EEPROM Data +.................. + +The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area. + +.. code-block:: console + + target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 + +.. note:: + + If you deleted both EEPROM spaces, please contact our support! + +DT representation, e.g. in phyCORE-|soc| file |dt-som|.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n259` + +.. include:: /bsp/peripherals/rtc.rsti + :end-before: .. rtc_parameter_start_label + +RTC Parameters +.............. + +RTCs have a few abilities which can be read/set with the help of ``hwclock`` +tool. + +* We can check RTC supported features with: + + .. code-block:: console + + target:~$ hwclock --param-get features + The RTC parameter 0x0 is set to 0x11. + + What this value means is encoded in kernel, each set bit translates to: + + .. code-block:: + + #define RTC_FEATURE_ALARM 0 + #define RTC_FEATURE_ALARM_RES_MINUTE 1 + #define RTC_FEATURE_NEED_WEEK_DAY 2 + #define RTC_FEATURE_ALARM_RES_2S 3 + #define RTC_FEATURE_UPDATE_INTERRUPT 4 + #define RTC_FEATURE_CORRECTION 5 + #define RTC_FEATURE_BACKUP_SWITCH_MODE 6 + #define RTC_FEATURE_CNT 7 + +* We can check RTC BSM (Backup Switchover Mode) with: + + .. code-block:: console + + target:~$ hwclock --param-get bsm + The RTC parameter 0x2 is set to 0x1. + +* We can set RTC BSM with: + + .. code-block:: console + + target:~$ hwclock --param-set bsm=0x2 + The RTC parameter 0x2 will be set to 0x2. + + What BSM values mean translates to these values: + + .. code-block:: + + #define RTC_BSM_DISABLED 0 + #define RTC_BSM_DIRECT 1 + #define RTC_BSM_LEVEL 2 + #define RTC_BSM_STANDBY 3 + + .. tip:: + You should set BSM mode to DSM or LSM for RTC to switch to backup power + source when the initial power source is not available. Check **RV-3028** RTC + datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching + Mode) actually mean. + +DT representation for I²C RTCs: +:imx-dt:`imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n267` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed up to 480 Mbps (HighSpeed +'HS'). + +The |soc| SoC has a single USB controller core that is set to OTG mode. +To use the micro USB / OTG port dip switch S1 Pos5 has to be set to on. + +.. include:: /bsp/peripherals/usb-host.rsti + +.. include:: /bsp/peripherals/usb-otg.rsti + +The USB interface is configured as host in the kernel device tree +|dt-carrierboard|.dts. See: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n264` + +CAN FD +------ + +The |sbc| has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. Hint:: + + phyBOARD-Polis has an external CANFD chip MCP2518FD connected over SPI. + There are different interfaces involved, which limits the datarate + capabilities of CANFD. + +.. Hint:: + + On phyBOARD-Polis-i.MX8MN a terminating resistor can be enabled by setting + S5 to ON if required. + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:imx-dt:`imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n125` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mp-libra-fpsc/head.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp-libra-fpsc/head.rst.txt new file mode 100644 index 000000000..f02ef3f6a --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp-libra-fpsc/head.rst.txt @@ -0,0 +1,588 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MP-PD24.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/ +.. |link-bsp-images| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp +.. _`static-pdf-dl`: ../../../_static/imx8mp-libra-fpsc-head.pdf + +.. IMX8(MP) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mp/phycore-imx8mp.c?h=v2024.04-2.0.0-phy7#n177 + + +.. General Substitutions +.. |doc-id| replace:: L-XXXXX.Xx +.. |kit| replace:: **Libra i.MX 8M Plus FPSC Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: Libra +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP-FPSC +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |bluetooth-uart| replace:: UART3 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx8_phytec_defconfig +.. |kernel-recipe-path| replace:: meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb +.. |kernel-repo-name| replace:: linux-phytec-imx +.. |kernel-repo-url| replace:: https://github.com/phytec/linux-phytec-imx +.. |kernel-socname| replace:: imx8mp-fpsc +.. |kernel-tag| replace:: v6.6.23-2.0.0-phy10 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-defconfig| replace:: imx8mp-libra_defconfig +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx +.. |emmcdev-uboot| replace:: mmc 2 +.. |sdcarddev-uboot| replace:: mmc 1 + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: IMX8MP_LIBRA +.. |u-boot-tag| replace:: v2024.04_2.0.0-phy7 + + +.. RAUC +.. |rauc-manual| replace:: L-1006e.A6 RAUC Update & Device Management Manual +.. _rauc-manual: https://www.phytec.de/cdocuments/?doc=F4DiM + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-libra-rdk-fpsc +.. |dt-som| replace:: imx8mp-phycore-fpsc +.. |dtbo-rpmsg| replace:: conf-imx8mp-phycore-fpsc-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mp-libra-peb-av-10.dtbo + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: :linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L50` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`scarthgap` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP-FPSC +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: scarthgap +.. |yocto-distro| replace:: ampliphy-vendor-xwayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: rootfs.wic.xz +.. |yocto-machinename| replace:: libra-imx8mp-1 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MP-PD24.1.0 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MP-FPSC-PD25.1.y +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (scarthgap) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 5.0.x +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L179`. +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` +.. |lvds-display-adapters| replace:: PEB-AV-10 +.. |weston-hdmi-mode| replace:: preferred + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |doc-id| |soc| FPSC | | +| BSP ManualHead | | ++-----------------------+----------------------+ +| Document Title | |doc-id| |soc| FPSC | +| | BSP Manual Head | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Article Number | |doc-id| | ++-----------------------+----------------------+ +| Yocto Manual | | ++-----------------------+----------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+----------------------+ +| Is Branch of | |doc-id| |soc| FPSC | +| | BSP Manual Head | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +================ ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +================ ================ ================= ========== +.. +================ ================ ================= ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mp-libra-fpsc-head-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-libra-fpsc-head-getting-started: +.. include:: /bsp/getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-libra-fpsc-head-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **fitImage**: Linux kernel FIT image +* **fitImage-its\*.its** +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-libra-rdk-fpsc*.dtb**: Kernel device tree file +* **imx8mp-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.rootfs.wic.xz**: compressed SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-libra-fpsc-head-bootswitch: +.. include:: bootmode-switch.rsti + +.. include:: ../installing-os.rsti + +.. include:: ../efi.rsti +.. include:: /bsp/installing-distro-efi.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-libra-fpsc-head-development: + +Development +=========== + +Starting with this release, the boot behaviour in U-Boot changes. Before, kernel +and device tree came as separate blobs. Now, both will be included in a single +FIT image blob. Further, the logic for booting the PHYTEC ampliphy distributions +is moved to a boot script which itself is part of a separate FIT image blob. +To revert to the old style of booting, you may do + +.. code-block:: console + + run legacyboot + +.. note:: + + This way of booting is deprecated and will be removed in the next release. + By default, booting via this command will return an error as kernel and + device tree are missing in the boot partition. + +.. include:: ../../imx-common/development/standalone_build_preface.rsti +.. _imx8mp-libra-fpsc-head-development-build-uboot: +.. include:: ../../imx-common/development/standalone_build_u-boot_binman.rsti +.. include:: ../development/kernel-standalone.rsti +.. include:: ../../imx-common/development/uuu.rsti + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx8/development/netboot.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mp-libra-fpsc-head-format-sd: + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. include:: /bsp/imx8/development/legacy_boot_deprecated.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-libra-fpsc-head-device-tree: +.. include:: /bsp/device-tree.rsti + +.. code-block:: + :substitutions: + + imx8mp-isi-csi1.dtbo + imx8mp-isi-csi2.dtbo + imx8mp-isp-csi1.dtbo + imx8mp-isp-csi2.dtbo + |dtbo-peb-av-10| + imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + imx8mp-phycore-no-eth.dtbo + imx8mp-phycore-no-rtc.dtbo + imx8mp-phycore-no-spiflash.dtbo + imx8mp-phycore-rpmsg.dtbo + imx8mp-vm016-csi1.dtbo + imx8mp-vm016-csi1-fpdlink.dtbo + imx8mp-vm016-csi2.dtbo + imx8mp-vm016-csi2-fpdlink.dtbo + imx8mp-vm017-csi1.dtbo + imx8mp-vm017-csi1-fpdlink.dtbo + imx8mp-vm017-csi2.dtbo + imx8mp-vm017-csi2-fpdlink.dtbo + +.. _imx8mp-libra-fpsc-head-ubootexternalenv: +.. include:: ../../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x140 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x140 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +The device tree representation for UART1 pinmuxing: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L373` + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti +.. include:: /bsp/peripherals/rs485-fullduplex.rsti + +The device tree representation for RS232 and RS485: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L412` + +.. _imx8mp-libra-fpsc-head-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + +.. include:: wireless-network.rsti + +.. include:: ../../peripherals/wireless-network.rsti + :end-before: .. bluetooth_chapter_start_label + +Bluetooth is supported on |sbc| with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section. + +.. include:: ../../peripherals/wireless-network.rsti + :start-after: .. bluetooth_chapter_start_label + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L422` + +DT configuration for the eMMC interface can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L214` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L76` + +.. include:: ../peripherals/gpios.rsti + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L255` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L113` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L239` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues. + +.. note:: + + If you deleted reserved EEPROM spaces, please contact our support! + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L201` + +.. include:: ../../peripherals/rtc.rsti + +DT representation for I²C RTCs: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L208` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L380` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L203` + +.. include:: /bsp/peripherals/pcie.rsti + +Device Tree PCIe configuration of |dt-carrierboard|.dts: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L345` + +Audio +----- + +Playback devices supported for |sbc| are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals. + +.. note:: + + Using the PEB-AV-10 connector for display output along HDMI as audio output + is not supported. The audio output device must match the video output device. + +.. include:: /bsp/peripherals/audio.rsti + +Device Tree Audio configuration: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L58` + +.. include:: /bsp/peripherals/video.rsti + +.. include:: display.rsti + :end-before: .. supported-display-interfaces-marker-start + +The |sbc| supports up to 3 different display outputs. Two can be used +simultaneously. The following table shows the required extensions and devicetree +overlays for the different interfaces. + +========= ======================== ====================================== +Interface Expansion devicetree overlay +========= ======================== ====================================== +HDMI |sbc| no overlay needed (enabled by default) +LVDS0 PEB-AV-10 |dtbo-peb-av-10| + (loaded by default) +LVDS1 |sbc| disabled if PEB-AV-10 overlay is used +========= ======================== ====================================== + +.. include:: display.rsti + :start-after: .. supported-display-interfaces-marker-end + :end-before: .. no-peb-av-12-marker + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +Device tree description of LVDS-1 and HDMI can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L294` +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L218` + +The device tree of LVDS-0 on PEB-AV-10 can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L133` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +The device tree description of GPIO Fan can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L35` + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/snvs-power-key.rsti + +.. include:: ../peripherals/npu.rsti + +.. include:: ../peripherals/isp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.rst.txt new file mode 100644 index 000000000..75e3e2260 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.rst.txt @@ -0,0 +1,13 @@ +=============================== +Libra i.MX 8M Plus FPSC Manuals +=============================== + +HEAD +==== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + head diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/head.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/head.rst.txt new file mode 100644 index 000000000..1f9f59507 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/head.rst.txt @@ -0,0 +1,589 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MP-PD24.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/ +.. |link-bsp-images| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp +.. _`static-pdf-dl`: ../../../_static/imx8mp-head.pdf + +.. IMX8(MP) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mp/phycore-imx8mp.c?h=v2024.04-2.0.0-phy7#n177 + + +.. General Substitutions +.. |doc-id| replace:: L-1017e.Ax +.. |kit| replace:: **phyCORE-i.MX8M Plus Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Pollux +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |bluetooth-uart| replace:: UART3 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx8_phytec_defconfig +.. |kernel-recipe-path| replace:: meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb +.. |kernel-repo-name| replace:: linux-phytec-imx +.. |kernel-repo-url| replace:: https://github.com/phytec/linux-phytec-imx +.. |kernel-socname| replace:: imx8mp +.. |kernel-tag| replace:: v6.6.23-2.0.0-phy10 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-defconfig| replace:: phycore-imx8mp_defconfig +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx +.. |emmcdev-uboot| replace:: mmc 2 +.. |sdcarddev-uboot| replace:: mmc 1 + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MP +.. |u-boot-tag| replace:: v2024.04_2.0.0-phy7 + + +.. RAUC +.. |rauc-manual| replace:: L-1006e.A6 RAUC Update & Device Management Manual +.. _rauc-manual: https://www.phytec.de/cdocuments/?doc=F4DiM + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-phyboard-pollux-rdk +.. |dt-som| replace:: imx8mp-phycore-som +.. |dtbo-rpmsg| replace:: conf-imx8mp-phycore-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mp-phyboard-pollux-peb-av-10.dtbo + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: :linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L50` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`scarthgap` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: scarthgap +.. |yocto-distro| replace:: ampliphy-vendor-xwayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: rootfs.wic.xz +.. |yocto-machinename| replace:: phyboard-pollux-imx8mp-3 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MP-PD24.1.0 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MP-PD24.1.y +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (scarthgap) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 5.0.x +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L179`. +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` +.. |lvds-display-adapters| replace:: PEB-AV-10 +.. |weston-hdmi-mode| replace:: preferred + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |doc-id| |soc| BSP | | +| ManualHead | | ++-----------------------+----------------------+ +| Document Title | |doc-id| |soc| BSP | +| | Manual Head | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Article Number | |doc-id| | ++-----------------------+----------------------+ +| Yocto Manual | | ++-----------------------+----------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+----------------------+ +| Is Branch of | |doc-id| |soc| BSP | +| | Manual Head | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +================ ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +================ ================ ================= ========== +.. +================ ================ ================= ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mp-head-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-head-getting-started: +.. include:: /bsp/getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-head-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **fitImage**: Linux kernel FIT image +* **fitImage-its\*.its** +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-phyboard-pollux-rdk*.dtb**: Kernel device tree file +* **imx8mp-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.rootfs.wic.xz**: compressed SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-head-bootswitch: +.. include:: bootmode-switch.rsti + +.. include:: ../installing-os.rsti + +.. include:: ../efi.rsti +.. include:: /bsp/installing-distro-efi.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-head-development: + +Development +=========== + +Starting with this release, the boot behaviour in U-Boot changes. Before, kernel +and device tree came as separate blobs. Now, both will be included in a single +FIT image blob. Further, the logic for booting the PHYTEC ampliphy distributions +is moved to a boot script which itself is part of a separate FIT image blob. +To revert to the old style of booting, you may do + +.. code-block:: console + + run legacyboot + +.. note:: + + This way of booting is deprecated and will be removed in the next release. + By default, booting via this command will return an error as kernel and + device tree are missing in the boot partition. + +.. include:: ../../imx-common/development/standalone_build_preface.rsti +.. _imx8mp-head-development-build-uboot: +.. include:: ../../imx-common/development/standalone_build_u-boot_binman.rsti +.. include:: development/uboot-standalone-fixed-ram-config.rsti +.. include:: ../development/kernel-standalone.rsti +.. include:: ../../imx-common/development/uuu.rsti + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx8/development/netboot.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mp-head-format-sd: + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. include:: /bsp/imx8/development/legacy_boot_deprecated.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-head-device-tree: +.. include:: /bsp/device-tree.rsti + +.. code-block:: + :substitutions: + + imx8mp-isi-csi1.dtbo + imx8mp-isi-csi2.dtbo + imx8mp-isp-csi1.dtbo + imx8mp-isp-csi2.dtbo + |dtbo-peb-av-10| + imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + imx8mp-phycore-no-eth.dtbo + imx8mp-phycore-no-rtc.dtbo + imx8mp-phycore-no-spiflash.dtbo + imx8mp-phycore-rpmsg.dtbo + imx8mp-vm016-csi1.dtbo + imx8mp-vm016-csi1-fpdlink.dtbo + imx8mp-vm016-csi2.dtbo + imx8mp-vm016-csi2-fpdlink.dtbo + imx8mp-vm017-csi1.dtbo + imx8mp-vm017-csi1-fpdlink.dtbo + imx8mp-vm017-csi2.dtbo + imx8mp-vm017-csi2-fpdlink.dtbo + +.. _imx8mp-head-ubootexternalenv: +.. include:: ../../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x140 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x140 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +The device tree representation for UART1 pinmuxing: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L373` + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti +.. include:: /bsp/peripherals/rs485-fullduplex.rsti + +The device tree representation for RS232 and RS485: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L412` + +.. _imx8mp-head-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + +.. include:: wireless-network.rsti + +.. include:: ../../peripherals/wireless-network.rsti + :end-before: .. bluetooth_chapter_start_label + +Bluetooth is supported on |sbc| with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section. + +.. include:: ../../peripherals/wireless-network.rsti + :start-after: .. bluetooth_chapter_start_label + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L422` + +DT configuration for the eMMC interface can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L214` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L76` + +.. include:: ../peripherals/gpios.rsti + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L255` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L113` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L239` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues. + +.. note:: + + If you deleted reserved EEPROM spaces, please contact our support! + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L201` + +.. include:: ../../peripherals/rtc.rsti + +DT representation for I²C RTCs: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L208` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L380` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L203` + +.. include:: /bsp/peripherals/pcie.rsti + +Device Tree PCIe configuration of |dt-carrierboard|.dts: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L345` + +Audio +----- + +Playback devices supported for |sbc| are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals. + +.. note:: + + Using the PEB-AV-10 connector for display output along HDMI as audio output + is not supported. The audio output device must match the video output device. + +.. include:: /bsp/peripherals/audio.rsti + +Device Tree Audio configuration: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L58` + +.. include:: /bsp/peripherals/video.rsti + +.. include:: display.rsti + :end-before: .. supported-display-interfaces-marker-start + +The |sbc| supports up to 3 different display outputs. Two can be used +simultaneously. The following table shows the required extensions and devicetree +overlays for the different interfaces. + +========= ======================== ====================================== +Interface Expansion devicetree overlay +========= ======================== ====================================== +HDMI |sbc| no overlay needed (enabled by default) +LVDS0 PEB-AV-10 |dtbo-peb-av-10| + (loaded by default) +LVDS1 |sbc| disabled if PEB-AV-10 overlay is used +========= ======================== ====================================== + +.. include:: display.rsti + :start-after: .. supported-display-interfaces-marker-end + :end-before: .. no-peb-av-12-marker + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +Device tree description of LVDS-1 and HDMI can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L294` +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L218` + +The device tree of LVDS-0 on PEB-AV-10 can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L133` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +The device tree description of GPIO Fan can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L35` + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/snvs-power-key.rsti + +.. include:: ../peripherals/npu.rsti + +.. include:: ../peripherals/isp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/imx8mp.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/imx8mp.rst.txt new file mode 100644 index 000000000..8c852c8b2 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/imx8mp.rst.txt @@ -0,0 +1,84 @@ +==================== +i.MX 8M Plus Manuals +==================== + +HEAD +==== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + head + +Mainline HEAD +============= + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + mainline-head + +BSP-Yocto-NXP-i.MX8MP-PD24.1.0 +============================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd24.1.0_nxp + +BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 +=================================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd24.1.2 + +BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 +=================================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd24.1.1 + + +BSP-Yocto-NXP-i.MX8MP-PD23.1.0 +============================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd23.1.0 + +BSP-Yocto-NXP-i.MX8MP-PD22.1.2 +============================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd22.1.2 + +BSP-Yocto-NXP-i.MX8MP-PD22.1.1 +============================== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd22.1.1 diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/mainline-head.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/mainline-head.rst.txt new file mode 100644 index 000000000..9cfb4bde8 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/mainline-head.rst.txt @@ -0,0 +1,1343 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp +.. _`static-pdf-dl`: ../../../_static/imx8mp-mainline-head.pdf + + +.. General Substitutions +.. |doc-id| replace:: L-XXXXX.Xx +.. |kit| replace:: **phyCORE-i.MX8M Plus Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Pollux +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: defconfig +.. |kernel-recipe-path| replace:: recipes-kernel/linux/linux-phytec_*.bb +.. |kernel-repo-name| replace:: linux-phytec +.. |kernel-repo-url| replace:: https://github.com/phytec/linux-phytec.git +.. |kernel-socname| replace:: imx8mp +.. |kernel-tag| replace:: v6.6.21-phy1 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-defconfig| replace:: phycore-imx8mp_defconfig +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-phytec_*.bb +.. |u-boot-repo-name| replace:: u-boot-phytec +.. |u-boot-repo-url| replace:: https://github.com/phytec/u-boot-phytec.git + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MP +.. |u-boot-tag| replace:: v2024.01-phy4 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-phyboard-pollux-rdk +.. |dt-som| replace:: imx8mp-phycore-som + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L41 + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`scarthgap` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: scarthgap +.. |yocto-distro| replace:: ampliphy-xwayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: rootfs.wic.xz +.. |yocto-machinename| replace:: phyboard-pollux-imx8mp-3 +.. |yocto-manifestname| replace:: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (scarthgap) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-a-core| replace:: cortexa53-crypto +.. |yocto-sdk-rev| replace:: 5.0.1 + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L106 +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |doc-id| |soc| BSP | | +| ManualHead | | ++-----------------------+----------------------+ +| Document Title | |doc-id| |soc| BSP | +| | Mainline Manual Head | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Article Number | |doc-id| | ++-----------------------+----------------------+ +| Yocto Manual | | ++-----------------------+----------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+----------------------+ +| Is Branch of | |doc-id| |soc| BSP | +| | Mainline Manual Head | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +================ ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +================ ================ ================= ========== +.. +================ ================ ================= ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mp-mainline-head-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-mainline-head-getting-started: + +.. include:: ../../getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-mainline-head-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_1d_dmem_202006.bin, + lpddr4_pmu_train_1d_imem_202006.bin, + lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-phyboard-pollux-rdk*.dtb**: Kernel device tree file +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.wic.xz**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see |ref-setup-network-host|. + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-mainline-head-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **eMMC**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +.. tip:: + + This step only works if the size of the image file is less than 1,28GB due to + limited RAM space available in the Bootloader. + +* Uncompress your image: + +.. code-block:: console + :substitutions: + + host:~$ unxz /srv/tftp/phytec-headless-image-|yocto-machinename|.rootfs.wic.xz + +* Load your image via network to RAM: + + .. code-block:: + :substitutions: + + u-boot=> dhcp ${loadaddr} phytec-headless-image-|yocto-machinename|.rootfs.wic + BOOTP broadcast 1 + DHCP client bound to address 192.168.3.11 (101 ms) + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename 'phytec-headless-image-|yocto-machinename|.rootfs.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* Write the image to the eMMC: + + .. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Take a compressed or decompressed image with the accompanying block map file +`*.bmap` on the host and send it with `ssh` through the network to the eMMC of +the target with a one-line command: + +.. code-block:: console + :substitutions: + + target:~$ scp @192.168.3.10:/srv/tftp/|yocto-imagename|-|yocto-machinename|.rootfs.wic.* /tmp && bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls /srv/tftp + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + |yocto-imagename|-|yocto-machinename|.rootfs.wic.bmap + +Send the image with the ``bmaptool`` command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ scp /srv/tftp/|yocto-imagename|-|yocto-machinename|.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2" + +Flash eMMC U-Boot image via Network from running U-Boot +....................................................... + +Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> dhcp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB stick +......................... + +Flash eMMC from USB stick in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. note:: + + Only the lower USB-A port is configured for storage devices and only + this port will work when trying to access a storage device in U-Boot. + +.. tip:: + + This step only works if the size of the image file is less than 1,28GB due to + limited RAM space available in the Bootloader. + +These steps will show how to update the eMMC via a USB device. Configure the +|ref-bootswitch| to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied uncompressed WIC image to +the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + :substitutions: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} phytec-headless-image-|yocto-machinename|.rootfs.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.\ |yocto-imageext|). Set the |ref-bootswitch| to SD Card. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ ls /mnt + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + |yocto-imagename|-|yocto-machinename|.rootfs.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy /mnt/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + + .. tip:: + + Before this will work, you need to configure the |ref-bootswitch| to + **eMMC**. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see |ref-format-sd|. + +Alternatively, flash a partup package to the SD card, as described in +|ref-getting-started|. This will ensure the full space of the SD card is used. + +Flash eMMC from SD card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1,28GB due to + limited RAM space available in the Bootloader. + + +* Flash an SD card with a working image and create a third ext4 partition. Copy + the WIC image (for example |yocto-imagename|.rootfs.wic) to this partition. +* Configure the |ref-bootswitch| to SD Card and insert the SD Card. +* Power on the board and stop in U-Boot. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-|yocto-machinename|.rootfs.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev to eMMC: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + +* Flash your WIC image (for example |yocto-imagename|.roots.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. + + .. code-block:: + + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the |ref-bootswitch| to eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card. + +* Show your saved partup package or WIC image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.rootfs.partup + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + |yocto-imagename|-|yocto-machinename|.rootfs.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition) using `partup`_: + + .. code-block:: console + :substitutions: + + target:~$ partup install |yocto-imagename|-|yocto-machinename|.rootfs.partup /dev/mmcblk2 + + Flashing the partup package has the advantage of using the full capacity of + the eMMC device, adjusting partitions accordingly. + + .. note:: + + Alternatively, ``bmaptool`` may be used instead: + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + + Keep in mind that the root partition does not make use of the full space when + flashing with ``bmaptool``. + +* After a complete write, your board can boot from eMMC. + + .. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to eMMC. + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A6 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-mainline-head-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti + +Booting the Kernel from a Network +--------------------------------- + +Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device. + +Place Images on Host for Netboot +................................ + +* Copy the kernel image to your tftp directory: + + .. code-block:: console + + host:~$ cp Image /srv/tftp + +* Copy the devicetree to your tftp directory: + + .. code-block:: console + + host:~$ cp oftree /srv/tftp + +* Make sure other users have read access to all the files in the tftp directory, + otherwise they are not accessible from the target: + + .. code-block:: console + + host:~$ sudo chmod -R o+r /srv/tftp + +* Extract the rootfs to your nfs directory: + + .. code-block:: console + :substitutions: + + host:~$ sudo tar -xvzf |yocto-imagename|-|yocto-machinename|.rootfs.tar.gz -C /srv/nfs + +.. note:: + Make sure you extract with sudo to preserve the correct ownership. + +Booting from an Embedded Board +.............................. + +Boot the board into the U-boot prompt and press any key to hold. + +* To boot from a network, call: + + .. code-block:: console + + u-boot=> run netboot + + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy-|yocto-distro|/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.rootfs.wic + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.rootfs.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + +.. _imx8mp-mainline-head-development-build-uboot: +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + +.. include:: development/uboot-standalone-fixed-ram-config.rsti + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mp-mainline-head-format-sd: + +Format SD-Card +-------------- + +Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted. + +Gparted +....... + +* Get GParted: + + .. code-block:: console + + host:~$ sudo apt install gparted + +* Insert the SD Card into your host and get the device name: + + .. code-block:: console + + host:~$ dmesg | tail + ... + [30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB) + [30436.179846] sdb: sdb1 sdb2 + ... + +* Unmount all SD Card partitions. +* Launch GParted: + + .. code-block:: console + + host:~$ sudo gparted + +.. image:: /bsp/imx-common/images/gparted1.png + +Expand rootfs +~~~~~~~~~~~~~ + +.. warning:: + Running gparted on host systems which are using resize2fs version 1.46.6 and older + (e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto + Mickledore and newer. + This is due to a new default option in resize2fs which causes a incompatibility. + See `release notes `_. + +* Choose your SD Card device at the drop-down menu on the top right +* Choose the ext4 root partition and click on resize: + +.. image:: /bsp/imx-common/images/gparted5.png +.. image:: /bsp/imx-common/images/gparted2.png + +* Drag the slider as far as you like or enter the size manually. + +.. image:: /bsp/imx-common/images/gparted3.png + +* Confirm your entry by clicking on the "Change size" button. + +.. image:: /bsp/imx-common/images/gparted4.png + +* To apply your changes, press the green tick. +* Now you can mount the root partition and copy e.g. the + |yocto-imagename|-|yocto-machinename|.\ |yocto-imageext| image to it. Then unmount it again: + + .. code-block:: console + :substitutions: + + host:~$ sudo cp |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /mnt/ ; sync + host:~$ umount /mnt + +Create the Third Partition +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Choose your SD Card device at the drop-down menu on the top right + +.. image:: /bsp/imx-common/images/gparted1.png + +* Choose the bigger unallocated area and press "New": + +.. image:: /bsp/imx-common/images/gparted6.png + +* Click "Add" + +.. image:: /bsp/imx-common/images/gparted7.png + +* Confirm your changes by pressing the green tick. + +.. image:: /bsp/imx-common/images/gparted8.png + +* Now you can mount the new partition and copy e.g. + |yocto-imagename|-|yocto-machinename|.\ |yocto-imageext| image to it. Then unmount it again: + + .. code-block:: console + :substitutions: + + host:~$ sudo mount /dev/sde3 /mnt + host:~$ sudo cp |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /mnt/ ; sync + host:~$ umount /mnt + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-mainline-head-device-tree: +.. include:: /bsp/device-tree.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x140 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x140 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +The device tree representation for UART1 pinmuxing: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L387` + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti +.. include:: /bsp/peripherals/rs485-fullduplex.rsti + +The device tree representation for RS232 and RS485: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L251` + +.. _imx8mp-mainline-head-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + :end-before: .. u-boot-network-environment-marker + +U-boot network-environment +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* We currently use dynamic IP addresses in U-Boot. This is enabled by this variable: + + .. code-block:: + + u-boot=> printenv ip_dyn + ip_dyn=yes + +* Set up path for NFS. A modification could look like this: + + .. code-block:: + + u-boot=> setenv nfsroot /home/user/nfssrc + +Please note that these modifications will only affect the bootloader settings. + +.. include:: /bsp/imx-common/peripherals/network.rsti + :start-after: .. kernel-network-environment-marker + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:linux-phytec:`/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L261` + +DT configuration for the eMMC interface can be found here: +:linux-phytec:`/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L181` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + :end-before: .. peripherals-spi-nor-flash-marker + +The definition of the SPI master node in the device tree can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L67` + +.. include:: ../peripherals/gpios.rsti + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L160` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L81` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L145` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues. + +.. note:: + + If you deleted reserved EEPROM spaces, please contact our support! + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L169` + +RTC +--- + +RTCs can be accessed via ``/dev/rtc*``. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file. + +* To find the name of the RTC device, you can read its sysfs entry with: + + .. code-block:: console + + target:~$ cat /sys/class/rtc/rtc*/name + +* You will get, for example: + + .. code-block:: + + rtc-rv3028 0-0052 + snvs_rtc 30370000.snvs:snvs-rtc-lp + +.. tip:: + + This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device + IDs based on the device tree/aliases entries if present. + +Date and time can be manipulated with the ``hwclock`` tool and the date command. +To show the current date and time set on the target: + +.. code-block:: console + + target:~$ date + Thu Jan 1 00:01:26 UTC 1970 + +Change the date and time with the date command. The date command sets the time +with the following syntax "YYYY-MM-DD hh:mm:ss (+|-)hh:mm": + +.. code-block:: console + + target:~$ date -s "2022-03-02 11:15:00 +0100" + Wed Mar 2 10:15:00 UTC 2022 + +.. note:: + + Your timezone (in this example +0100) may vary. + +Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the ``hwclock`` command. Write the current date and time (set +with the date command) to the RTC using the ``hwclock`` tool and reboot the +target to check if the changes were applied to the RTC: + +.. code-block:: console + + target:~$ hwclock -w + target:~$ reboot + . + . + . + target:~$ date + Wed Mar 2 10:34:06 UTC 2022 + +To set the time and date from the RTC use: + +.. code-block:: console + + target:~$ date + Thu Jan 1 01:00:02 UTC 1970 + target:~$ hwclock -s + target:~$ date + Wed Mar 2 10:45:01 UTC 2022 + +.. include:: ../../peripherals/rtc.rsti + :start-after: .. rtc_parameter_start_label + +DT representation for I²C RTCs: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L175` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L220` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L130` + +Video +----- + +Videos with Gstreamer +..................... + +One example video is installed by default in the BSP at `/usr/share/qtphy/videos/`. +Start the video playback with one of these commands: + +.. code-block:: console + + target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink fullscreen=true + +* Or: + +.. code-block:: console + + target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink + +.. note:: + The mainline BSP currently only supports software rendering. + +Display +------- + +The |sbc| supports LVDS output via the LVDS1 connector on the carrier board. The +LVDS interface is enabled by default. + +Weston Configuration +.................... + +Weston will work without any additional configuration. Configuration options are +done at /etc/xdg/weston/weston.ini. + +Device tree description of LVDS can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L182` + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +.. note:: + We noticed some visible backlight flickering on brightness level 1 (probably + due to frequency problems with the hardware). + +Power Management +---------------- + +CPU Core Frequency Scaling +.......................... + +The CPU in the |soc| SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as 'Dynamic Voltage and +Frequency Scaling' (DVFS). The |soc| BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the |socfamily| +variant used, several different frequencies are supported. + +.. tip:: + + Although the DVFS framework provides frequency settings for each CPU core, a + change in the frequency settings of one CPU core always affects all other CPU + cores too. So all CPU cores always share the same DVFS setting. An individual + DVFS setting for each core is not possible. + + +* To get a complete list type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies + + In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately + 1,6 GHz, the result will be: + + .. code-block:: + + 1200000 1600000 + +* To ask for the current frequency type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq + +So-called governors are automatically selecting one of these frequencies in +accordance with their goals. + +* List all governors available with the following command: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors + + The result will be: + + .. code-block:: + + ondemand userspace performance schedutil + +* **ondemand** (default) switches between possible CPU core frequencies in + reference to the current system load. When the system load increases above a + specific limit, it increases the CPU core frequency immediately. +* **performance** always selects the highest possible CPU core frequency. +* **userspace** allows the user or userspace program running as root to set a + specific frequency (e.g. to 1600000). Type: + +* In order to ask for the current governor, type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor + + You will normally get: + + .. code-block:: + + schedutil + +* Switching over to another governor (e.g. userspace) is done with: + + .. code-block:: console + + target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor + +* Now you can set the speed: + + .. code-block:: console + + target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed + +For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +``Documentation/admin-guide/pm/cpufreq.rst``. + +CPU Core Management +................... + +The |soc| SoC can have multiple processor cores on the die. The |soc|, for +example, has 4 ARM Cores which can be turned on and off individually at runtime. + +* To see all available cores in the system, execute: + + .. code-block:: console + + target:~$ ls /sys/devices/system/cpu -1 + +* This will show, for example: + + .. code-block:: + + cpu0 cpu1 cpu2 cpu3 cpufreq + [...] + + Here the system has four processor cores. By default, all available cores in the + system are enabled to get maximum performance. + +* To switch off a single-core, execute: + + .. code-block:: console + + target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online + + As confirmation, you will see: + + .. code-block:: + + [ 110.505012] psci: CPU3 killed + + Now the core is powered down and no more processes are scheduled on this core. + +* You can use top to see a graphical overview of the cores and processes: + + .. code-block:: console + + target:~$ htop + +* To power up the core again, execute: + + .. code-block:: console + + target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online + +.. include:: ../peripherals/tm.rsti + :end-before: .. tm-gpio-fan-marker + +.. include:: /bsp/peripherals/watchdog.rsti + +snvs Power Key +-------------- + +The X_ONOFF pin connected to the ON/OFF button can be pressed long to trigger +Power OFF without SW intervention. With the *snvs_pwrkey* driver, the KEY_POWER +event is also reported to userspace when the button is pressed. On default, systemd +is configured to ignore such events. The function of Power OFF without SW +intervention are not configured. Triggering a power off with systemd when pushing +the ON/OFF button can be configured under ``/etc/systemd/logind.conf`` and set using: + +.. code-block:: + + HandlePowerKey=poweroff + +.. include:: ../peripherals/ocotp-ctrl.rsti diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd22.1.1.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd22.1.1.rst.txt new file mode 100644 index 000000000..4549e03f8 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd22.1.1.rst.txt @@ -0,0 +1,2577 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MP-PD22.1.1 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp +.. _`static-pdf-dl`: ../../../_static/imx8mp-pd22.1.1.pdf + +.. IMX8(MP) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mp/phycore-imx8mp.c?h=v2021.04_2.2.0-phy13#n239 + + +.. General Substitutions +.. |atfloadaddr| replace:: 0x970000 +.. |kit| replace:: **phyCORE-i.MX8M Plus Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Pollux +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |bluetooth-uart| replace:: UART3 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx8mp +.. |kernel-tag| replace:: v5.10.72_2.2.0-phy17 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-defconfig| replace:: phycore-imx8mp_defconfig +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MP +.. |u-boot-tag| replace:: v2021.04_2.2.0-phy13 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-phyboard-pollux-rdk +.. |dt-som| replace:: imx8mp-phycore-som +.. |dtbo-rpmsg| replace:: imx8mp-phycore-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mp-phyboard-pollux-peb-av-010.dtbo + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n41` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`hardknott` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: hardknott +.. |yocto-distro| replace:: ampliphy-vendor-xwayland +.. |yocto-imagename| replace:: phytec-qt5demo-image +.. |yocto-machinename| replace:: phyboard-pollux-imx8mp-3 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MP-PD22.1.1 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MP-PD22.1.y +.. |yocto-ref-manual| replace:: L-813e.A12 Yocto Reference Manual (Hardknott) +.. _yocto-ref-manual: https://www.phytec.de/cdocuments/?doc=UIHsG +.. _yocto-ref-manual-kernel-and-bootloader-config: https://www.phytec.de/cdocuments/?doc=UIHsG#YoctoReferenceManualHardknottL813e-A12-KernelandBootloaderConfiguration +.. |yocto-sdk-rev| replace:: BSP-Yocto-NXP-i.MX8MP-PD22.1.1 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n141`. +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Yocto Manual | | ++-----------------------+----------------------+ +| Release Date | 2023/05/25 | ++-----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================= ========== +|yocto-manifestname| Minor 2023/05/23 Released +==================== ================ ================= ========== + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mp-pd22.1.1-components: +.. include:: components.rsti + +Getting Started +=============== + +The |kit| is shipped with a pre-flashed SD card. It contains the +|yocto-imagename| and can be used directly as a boot source. The eMMC is +programmed with only a U-boot by default. You can get all sources from the +`PHYTEC download server `_. This chapter explains how to flash a BSP +image to SD card and how to start the board. + +Get the Image +------------- + +The WIC image contains all BSP files in several, correctly pre-formatted +partitions and can be copied to an SD card easily using the single Linux +command ``dd``. It can be built by Yocto or downloaded from the PHYTEC download +server. + +Get the WIC file from the download server: + +.. code-block:: console + :substitutions: + + host:~$ wget |link-image| + +Write the Image to SD Card +-------------------------- + +.. warning:: + To create your bootable SD card with the ``dd`` command, you must have root + privileges. Be very careful when specifying the destination device with + ``dd``! All files on the selected destination device will be erased + immediately without any further query! + + Selecting the wrong device may result in **data loss** and e.g. could erase + your currently running system! + +To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. Unmount any mounted partitions before +you start copying the image to the SD card. + +#. In order to get the correct device name, remove your SD card and + execute:: + + host$ lsblk + +#. Now insert your SD card and execute the command again:: + + host$ lsblk + +#. Compare the two outputs to find the new device names listed in the second + output. These are the device names of the SD card (device and partitions if + the SD card was formatted). +#. In order to verify the device names being found, execute the command + ``sudo dmesg``. Within the last lines of its output, you should also find the + device names, e.g. ``/dev/sde`` or ``/dev/mmcblk0`` (depending on your + system). + +Alternatively, you may use a graphical program of your choice, like `GNOME Disks +`_ or `KDE Partition Manager +`_, to find the correct device. + +Now that you have the correct device name, e.g. ``/dev/sde``, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. ``/dev/sde1``) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption. + +* Unmount all partitions, e.g.:: + + host$ sudo umount /dev/sde1 + +* After having unmounted all partitions, you can create your bootable SD card:: + + host$ sudo dd if=-.wic of=/dev/sdX bs=1M conv=fsync status=progress + + Again, make sure to replace ``/dev/sdX`` with your actual device name found + previously. + + The parameter ``conv=fsync`` forces a sync operation on the device before + ``dd`` returns. This ensures that all blocks are written to the SD card and + none are left in memory. The parameter ``status=progress`` will print out + information on how much data is and still has to be copied until it is + finished. + +An alternative and much faster way to prepare an SD card can be done by using +`bmap-tools `_ from Intel. Yocto +automatically creates a block map file (``-.wic.bmap``) for +the WIC image that describes the image content and includes checksums for data +integrity. *bmaptool* is packaged by various Linux distributions. For +Debian-based systems install it by issuing:: + + host$ sudo apt install bmap-tools + +Flash a WIC image to SD card by calling:: + + host$ bmaptool copy -.wic /dev/ + +.. warning:: + *bmaptool* only overwrites the areas of an SD card where image data is + located. This means that a previously written U-Boot environment may still be + available after writing the image. + +First Start-up +-------------- + +* To boot from an SD card, |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-pd22.1.1-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-phyboard-pollux-rdk*.dtb**: Kernel device tree file +* **imx8mp-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt5demo-image\*.tar.gz**: Root file system +* **phytec-qt5demo-image\*.wic**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-pd22.1.1-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **Default SOM boot**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. However, they only +work if the size of the image file is less than 1GB. If the image file is +larger, go to the section Format SD Card. Configure the |ref-bootswitch| to boot +from SD Card and put in an SD card. Power on the board and stop in U-Boot +prompt. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +* Load your image via network to RAM: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* Write the image to the eMMC: + + .. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + A working network is necessary! Setup Network Host. + +Take a compressed or uncompressed image on the host and send it with ssh through +the network (then uncompress it, if necessary) to the eMMC of the target with a +one-line command: + +.. code-block:: console + :substitutions: + + target:~$ ssh @192.168.3.10 "dd if=/|yocto-imagename|-|yocto-machinename|.wic" | dd of=/dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +Send the image with the command dd command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2" + +Flash eMMC u-boot image via Network from running u-boot +....................................................... + +Update the standalone u-boot image imx-boot is also possible from u-boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB +................... + +Flash eMMC from USB in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in Bootloader after enabling the OPTEE. + +These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch to |ref-bootswitch| and put in an SD card. Power on the board +and stop in u-boot prompt. Insert a USB device with the copied WIC image +to the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} *.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the bootmode switch to +|ref-bootswitch|. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ cd /mnt + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2boot0; mmcblk2boot1) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + +.. warning:: + + Before this will work, you need to configure the multi-port switch + to **Default SOM Boot** to |ref-bootswitch|. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to enlarge your SD card to use +its full space (if it was not enlarged before). To enlarge your SD card, see +Resizing ext4 Root Filesystem. + +Flash eMMC from SD card in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in Bootloader after enabling the OPTEE. If the + image file is too large use the `Updating eMMC from SD card in + Linux on Target` subsection. + +* Flash an SD card with a working image and create a third FAT partition. Copy + the WIC image (for example |yocto-imagename|.wic) to this + partition. +* Configure the bootmode switch to boot from the SD Card and insert the SD + card. +* Power on the board and stop in u-boot. +* Flash your WIC image (for example |yocto-imagename|.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> fatload mmc 1:3 ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc0(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the multi-port switch to Default SOM Boot to + boot from eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a complete image saved on +the SD card (e.g. |yocto-imagename|-|yocto-machinename|.wic). + +* Show your saved image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2\ **boot0**; mmcblk2\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + +.. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to Default + SOM Boot to boot from eMMC. + +Flash SPI NOR Flash +------------------- + +The |som| modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set |ref-bootswitch| to **QSPI boot** to boot from QSPI. The SPI Flash is +usually quite small. The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash +populated. Only the bootloader and the environment can be stored. The kernel, +device tree, and file system are taken from eMMC by default. + +The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with: + +.. code-block:: + + u-boot=> printenv mtdparts + mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none) + +Flash SPI NOR Flash from Network +................................ + +The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-|soc|. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Flash SPI NOR from Network in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI-NOR flash needs to be probed: + +.. code-block:: + + u-boot=> sf probe + SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB + +* A specially formatted u-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image over tftp, erase and write the + bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + device 0 offset 0x0, size 0x1c0b20 + 1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +.. warning:: + + Erasing the complete SPI NOR flash when it is fully written will take quite + some time. This can trigger the watchdog to reset. Due to this, erase the + full flash in Linux. + +Flash SPI NOR from Network in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the image from the host to the target: + + .. code-block:: console + :substitutions: + + host:~$ scp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root + +* Find the number of erase blocks of the U-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +Flash SPI NOR Flash from SD Card +................................ + +The bootloader on SPI NOR flash can be also flashed with SD Card. + +Flash SPI NOR from SD Card in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the FAT partition + on the SD Card. Before reading and writing are possible, the SPI-NOR flash + needs to be probed: + + .. code-block:: + + u-boot=> sf probe + SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB + +* A specially formatted U-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image from the SD Card, erase and write + the bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +.. warning:: + + Erasing the complete SPI NOR flash when it is fully written will take quite + some time. This can trigger the watchdog to reset. Due to this, erase the + full flash in Linux. + +Flash SPI NOR from SD Card in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Mount the SD Card: + + .. code-block:: console + :substitutions: + + host:~$ mount /dev/mmcblkp1 /mnt + +* Find the number of erase blocks of the u-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp /mnt/imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A3 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd22.1.1-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + +.. _imx8mp-pd22.1.1-development-build-uboot: + +U-Boot standalone build +----------------------- + +Get the source code +................... + +* Get the U-Boot sources: + + .. code-block:: console + + host:~$ git clone git://git.phytec.de/u-boot-imx + +* To get the correct *U-Boot* **tag** you need to take a look at our release + notes, which can be found here: `release notes `_ +* The **tag** needed at this release is called |u-boot-tag| +* Check out the needed *U-Boot* **tag**: + +.. code-block:: console + :substitutions: + + host:~$ cd ~/u-boot-imx/ + host:~$ git fetch --all --tags + host:~$ git checkout tags/|u-boot-tag| + +* Technically, you can now build the U-Boot, but practically there are some + further steps necessary: + + * Create your own development branch: + + .. code-block:: console + + host:~$ git switch --create + + .. note:: + + You can name your development branch as you like, this is just an example. + +* Set up a build environment: + + .. code-block:: console + :substitutions: + + host:~$ source /opt/|yocto-distro|/|yocto-manifestname|/environment-setup-cortexa53-crypto-phytec-linux + +* Set this environment variable before building the Image: + + .. code-block:: console + :substitutions: + + host:~$ export ATF_LOAD_ADDR=|atfloadaddr| + +Get the needed binaries +....................... + +To build the bootloader, you need to **copy** these **files** to your |u-boot-repo-name| +**build directory** and rename them to fit with *mkimage* script: + +* **ARM Trusted firmware binary** (*mkimage tool* compatible format + **bl31.bin**): bl31-|kernel-socname|.bin +* **OPTEE image** (optional): tee.bin +* **DDR firmware files** (*mkimage tool* compatible format + **lpddr4_[i,d]mem_\*d_\*.bin**): + lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, + lpddr4_imem_2d_*.bin + +If you already built our BSP with Yocto, you can get the +bl31-|kernel-socname|.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: |ref-bsp-images| + +Or you can download the files here: |link-boot-tools| + +.. warning:: + + Make sure you rename the files you need so that they are compatible with the + *mkimage tool*. + +Build the bootloader +.................... + +* build flash.bin (imx-boot): + + .. code-block:: console + :substitutions: + + host:~$ make phycore-|kernel-socname|_defconfig + host:~$ make flash.bin + +Flash the bootloader to a block device +...................................... + +The flash.bin can be found at u-boot-imx/ directory and now can be flashed. A +chip-specific offset is needed: + +.. _offset-table: + +===== =================== ============================= ============ +SoC Offset User Area Offset Boot Partition eMMC Device +===== =================== ============================= ============ +|soc| |u-boot-offset| kiB |u-boot-offset-boot-part| kiB /dev/mmcblk2 +===== =================== ============================= ============ + +E.g. flash SD card: + +.. code-block:: console + :substitutions: + + host:~$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=|u-boot-offset| conv=sync + +.. hint:: + The specific offset values are also declared in the Yocto variables "BOOTLOADER_SEEK" and "BOOTLOADER_SEEK_EMMC" + +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + :start-after: .. build-uboot-fixed-ram-size-marker + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd22.1.1-device-tree: + +Device Tree (DT) +================ + +Introduction +------------ + +The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html) + +*"The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn't need to hard code details of the machine."* + +The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at `devicetree.org `_. + +PHYTEC |soc| BSP Device Tree Concept +------------------------------------ + +The following sections explain some rules PHYTEC has defined on how to set up +device trees for our |soc| SoC-based boards. + +Device Tree Structure +..................... + +* *Module.dtsi* - Module includes all devices mounted on the SoM, such as PMIC + and RAM. +* *Carrierboard.dtsi* - Devices that come from the |soc| SoC but are just routed + down to the carrier board and used there are included in this dtsi. +* *Board.dts* - include the carrier board and module dtsi files. There may also + be some hardware configuration nodes enabled on the carrier board or the + module (i.e. the Board .dts shows the special characteristics of the board + configuration). For example, there are phyCORE-|soc| SOMs which may or may not + have a MIPI DSI to LVDS converter mounted. The converter is enabled (if + available) in the Board .dts and not in the Module .dtsi + +From the root directory of the Linux Kernel our devicetree files for |socfamily| +platforms can be found in ``arch/arm64/boot/dts/freescale/``. + +Device Tree Overlay +................... + +Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder ``arch/arm64/boot/dts/freescale/overlays``. + +Available overlays for |yocto-machinename|.conf are: + +.. code-block:: + + imx8mp-isi-csi1.dtbo + imx8mp-isi-csi2.dtbo + imx8mp-isp-csi1.dtbo + imx8mp-isp-csi2.dtbo + imx8mp-phyboard-pollux-peb-av-010.dtbo + imx8mp-phyboard-pollux-peb-av-012.dtbo + imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + imx8mp-phycore-no-eth.dtbo + imx8mp-phycore-no-rtc.dtbo + imx8mp-phycore-no-spiflash.dtbo + imx8mp-phycore-rpmsg.dtbo + imx8mp-vm016-csi1.dtbo + imx8mp-vm016-csi1-fpdlink.dtbo + imx8mp-vm016-csi2.dtbo + imx8mp-vm016-csi2-fpdlink.dtbo + imx8mp-vm017-csi1.dtbo + imx8mp-vm017-csi1-fpdlink.dtbo + imx8mp-vm017-csi2.dtbo + imx8mp-vm017-csi2-fpdlink.dtbo + +.. hint:: + There is one more overlay available for phyboard-pollux-imx8mp-2.conf: + imx8mp-phyboard-pollux-1552.1.dtbo + +.. _imx8mp-pd22.1.1-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +imx8mp-phyboard-pollux.dtsi: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x49 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x49 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n331` + +.. _imx8mp-pd22.1.1-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +WLAN and Bluetooth on the |sbc| are provided by the PEB-WLBT-05 expansion card. +The PEB-WLBT-05 for |sbc| Quickstart Guide shows you how to install the +PEB-WLBT-05. + +.. tip:: + + With the BSP Version PD22.1 and newer, the PEB-WLBT-05 overlay needs to be activated first, + otherwise the PEB-WLBT-05 won't be recognized. + + .. code-block:: console + + target:~$ vi /boot/bootenv.txt + + Afterwards the bootenv.txt file should look like this (it can also contain other devicetree + overlays!): + + .. code-block:: + + overlays=imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + + The changes will be applied after a reboot: + + .. code-block:: console + + target:~$ reboot + + For further information about devicetree overlays, read the |ref-dt| chapter. + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First set the correct regulatory domain for your country: + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see: + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +Set up the wireless interface: + +.. code-block:: console + + target:~$ ip link + target:~$ ip link set up dev wlan0 + +Now you can scan for available networks: + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection. + +To do so, add the network-credentials to the file ``/etc/wpa_supplicant.conf``: + +.. code-block:: + + country=DE + network={ + ssid="" + proto=WPA2 + psk="" + } + +Now a connection can be established: + +.. code-block:: console + + target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B + +This should result in the following output: + +.. code-block:: + + ... + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section `Changing the Network Configuration` in the |yocto-ref-manual|_. + +First, create the directory: + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +Then add the following configuration snippet in ``/etc/systemd/network/10-wlan0.network``: + +.. code-block:: + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +Now, restart the network daemon so that the configuration takes effect: + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Bluetooth +......... + +Bluetooth is supported on |sbc| with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section. + +Bluetooth is connected to |bluetooth-uart| interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually: + +.. code-block:: console + + target:~$ hciconfig hci0 up + + target:~$ hciconfig -a + + hci0: Type: Primary Bus: UART + BD Address: 00:25:CA:2F:39:96 ACL MTU: 1021:8 SCO MTU: 64:1 + UP RUNNING PSCAN + RX bytes:1392 acl:0 sco:0 events:76 errors:0 + TX bytes:1198 acl:0 sco:0 commands:76 errors:0 + ... + +Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup. + +.. code-block:: console + + target:~$ hcitool scan + Scanning ... + XX:XX:XX:XX:XX:XX + +Visibility +~~~~~~~~~~ + +To activate visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 piscan + +To disable visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 noscan + +Connect +~~~~~~~ + +.. code-block:: console + + target:~$ bluetoothctl + [bluetooth]# discoverable on + Changing discoverable on succeeded + [bluetooth]# pairable on + Changing pairable on succeeded + [bluetooth]# agent on + Agent registered + [bluetooth]# default-agent + Default agent request successful + [bluetooth]# scan on + [NEW] Device XX:XX:XX:XX:XX:XX + [bluetooth]# connect XX:XX:XX:XX:XX:XX + +.. include:: ../../peripherals/wireless-network.rsti + :start-after: .. bluetooth_chapter_start_label + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n367` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n220` + +eMMC Devices +------------ + +PHYTEC modules like phyCORE-|soc| is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw MLC memory cells combined with a memory +controller that handles ECC and wear leveling. They are connected via an SD/MMC +interface to the |soc| and are represented as block devices in the Linux kernel +like SD cards, flash drives, or hard disks. + +The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer's datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard. + +PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1 + +Extended CSD Register +..................... + +eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard. + +In the Linux user space, you can query the registers: + +.. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| + +You will see: + +.. code-block:: + + ============================================= + Extended CSD rev 1.7 (MMC 5.0) + ============================================= + + Card Supported Command sets [S_CMD_SET: 0x01] + [...] + +Enabling Background Operations (BKOPS) +...................................... + +In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +cells. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called **Background +Operations (BKOPS)**. + +By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency. + +The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details. + +Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0): + +* Value 0: The host does not support the manual trigger of BKOPS. Device write + performance suffers. +* Value 1: The host does support the manual trigger of BKOPS. It will issue + BKOPS from time to time when it does not need the device. + +The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details). + +The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)). + +The userspace tool mmc does not currently support enabling automatic BKOPS +features. + +* To check whether *BKOPS_EN* is set, execute: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep BKOPS_EN + + The output will be, for example: + + .. code-block:: + + Enable background operations handshake [BKOPS_EN]: 0x01 + #OR + Enable background operations handshake [BKOPS_EN]: 0x00 + + Where value 0x00 means BKOPS_EN is disabled and device write performance + suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue + background operations from time to time. + +* To set the BKOPS_EN bit, execute: + + .. code-block:: console + :substitutions: + + target:~$ mmc bkops enable /dev/|emmcdev| + +* To ensure that the new setting is taken over and the kernel triggers BKOPS by + itself, shut down the system: + + .. code-block:: console + + target:~$ poweroff + +.. tip:: + + The BKOPS_EN bit is one-time programmable only. It cannot be reversed. + +Reliable Write +.............. + +There are two different Reliable Write options: + +1. Reliable Write option for a whole eMMC device/partition. +2. Reliable Write for single write transactions. + +.. tip:: + + Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT + partition table (see the previous section). + +The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-|soc| SoMs. To check this on the running target: + +.. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep -A 5 WR_REL_SET + Write reliability setting register [WR_REL_SET]: 0x1f + user area: the device protects existing data if a power failure occurs during a write o + peration + partition 1: the device protects existing data if a power failure occurs during a write + operation + partition 2: the device protects existing data if a power failure occurs during a write + operation + partition 3: the device protects existing data if a power failure occurs during a write + operation + partition 4: the device protects existing data if a power failure occurs during a write + operation + -- + Device supports writing EXT_CSD_WR_REL_SET + Device supports the enhanced def. of reliable write + +Otherwise, it can be enabled with the mmc tool: + +.. code-block:: console + + target:~$ mmc --help + + [...] + mmc write_reliability set <-y|-n> + +The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META. + +**Conclusion**: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application. + +Resizing ext4 Root Filesystem +............................. + +When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk. + +* Get the current device size: + + .. code-block:: console + :substitutions: + + target:~$ parted /dev/|emmcdev| print + +* The output looks like this: + + .. code-block:: + :substitutions: + + Model: MMC Q2J55L (sd/mmc) + Disk /dev/|emmcdev|: 7617MB + Sect[ 1799.850385] |emmcdev|: p1 p2 + or size (logical/physical): 512B/512B + Partition Table: msdos + Disk Flags: + + Number Start End Size Type File system Flags + 1 4194kB 72.4MB 68.2MB primary fat16 boot, lba + 2 72.4MB 537MB 465MB primary ext4 + +* Use parted to resize the root partition to the max size of the device: + + .. code-block:: console + :substitutions: + + target:~$ parted /dev/|emmcdev| resizepart 2 100% + Information: You may need to update /etc/fstab. + + target:~$ parted /dev/|emmcdev| print + Model: MMC Q2J55L (sd/mmc) + Disk /dev/|emmcdev|: 7617MB + Sector size (logical/physical): 512[ 1974.191657] |emmcdev|: p1 p2 + B/512B + Partition Table: msdos + Disk Flags: + + Number Start End Size Type File system Flags + 1 4194kB 72.4MB 68.2MB primary fat16 boot, lba + 2 72.4MB 7617MB 7545MB primary ext4 + +Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted. + +* Resize the filesystem to a new partition size: + + .. code-block:: console + :substitutions: + + target:~$ resize2fs /dev/|emmcdev|p2 + resize2fs 1.46.1 (9-Feb-2021) + Filesystem at /dev/|emmcdev|p2 is mounted on /; on-line resizing required + [ 131.609512] EXT4-fs (|emmcdev|p2): resizing filesystem + from 454136 to 7367680 blocks + old_desc_blocks = 4, new_desc_blocks = 57 + [ 131.970278] EXT4-fs (|emmcdev|p2): resized filesystem to 7367680 + The filesystem on /dev/|emmcdev|p2 is now 7367680 (1k) blocks long + +Enable pseudo-SLC Mode +...................... + +eMMC devices use MLC memory cells +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC memory cells used in NAND Flash, MLC memory cells have lower +reliability and a higher error rate at lower costs. + +If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity. + +.. warning:: + + When enabling the enhanced attribute on the device, all data will be lost. + +The following sequence shows how to enable the enhanced attribute. + +* First obtain the current size of the eMMC device with: + + .. code-block:: console + :substitutions: + + target:~$ parted -m /dev/|emmcdev| unit B print + + You will receive: + + .. code-block:: + :substitutions: + + BYT; + /dev/|emmcdev|:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:; + + As you can see this device has 63652757504 Byte = 60704 MiB. + +* To get the maximum size of the device after pseudo-SLC is enabled use: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep ENH_SIZE_MULT -A 1 + + which shows, for example: + + .. code-block:: + + Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + -- + Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000 + i.e. 0 KiB + + Here the maximum size is 3719168 KiB = 3632 MiB. + +* Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by + typing: + + .. code-block:: console + :substitutions: + + target:~$ mmc enh_area set -y 0 3719168 /dev/|emmcdev| + + You will get: + + .. code-block:: + :substitutions: + + Done setting ENH_USR area on /dev/|emmcdev| + setting OTP PARTITION_SETTING_COMPLETED! + Setting OTP PARTITION_SETTING_COMPLETED on /dev/|emmcdev| SUCCESS + Device power cycle needed for settings to take effect. + Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle + +* To ensure that the new setting has taken over, shut down the system: + + .. code-block:: console + + target:~$ poweroff + + and perform a power cycle. It is recommended that you verify the settings now. + +* First, check the value of ENH_SIZE_MULT which must be 3719168 KiB: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep ENH_SIZE_MULT -A 1 + + You should receive:: + + Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + -- + Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + +* Finally, check the size of the device: + + .. code-block:: console + :substitutions: + + target:~$ parted -m /dev/|emmcdev| unit B print + BYT; + /dev/|emmcdev|:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:; + +Erasing the Device +.................. + +It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC memory +cells or mark these blocks as discard. The data on the device is lost and will +be read back as zeros. + +* After booting from SD Card execute: + + .. code-block:: console + :substitutions: + + target:~$ blkdiscard -f --secure /dev/|emmcdev| + + The option --secure ensures that the command waits until the eMMC device has + erased all blocks. The -f (force) option disables all checking before erasing + and it is needed when the eMMC device contains existing partitions with data. + +.. tip:: + .. code-block:: console + :substitutions: + + target:~$ dd if=/dev/zero of=/dev/|emmcdev| conv=fsync + + also destroys all information on the device, but this command is bad for wear + leveling and takes much longer! + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n72` + +GPIOs +----- + +The |sbc| has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to |soc| pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal |soc| GPIO banks GPIO1 – GPIO5. + +The GPIOs are identified as GPIO_ (e.g. GPIO5_07). identifies the GPIO +bank and counts from 1 to 5, while stands for the GPIO within the bank. +is being counted from 0 to 31 (32 GPIOs on each bank). + +By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is: + +.. code-block:: + + Linux GPIO number: = ( - 1) * 32 + + +Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools: + +* Detecting the gpiochips on the chip: + + .. code-block:: console + + target:~$ gpiodetect + gpiochip0 [30200000.gpio] (32 lines) + gpiochip1 [30210000.gpio] (32 lines) + gpiochip2 [30220000.gpio] (32 lines) + gpiochip3 [30230000.gpio] (32 lines) + gpiochip4 [30240000.gpio] (32 lines) + +* Show detailed information about the gpiochips. Like their names, consumers, + direction, active state, and additional flags: + + .. code-block:: console + + target:~$ gpioinfo gpiochip0 + +* Read the value of a GPIO (e.g GPIO 20 from chip0): + + .. code-block:: console + + target:~$ gpioget gpiochip0 20 + +* Set the value of GPIO 20 on chip0 to 0 and exit tool: + + .. code-block:: console + + target:~$ gpioset --mode=exit gpiochip0 20=0 + +* Help text of gpioset shows possible options: + + .. code-block:: console + + target:~$ gpioset --help + Usage: gpioset [OPTIONS] = = ... + Set GPIO line values of a GPIO chip + + Options: + -h, --help: display this message and exit + -v, --version: display the version and exit + -l, --active-low: set the line active state to low + -m, --mode=[exit|wait|time|signal] (defaults to 'exit'): + tell the program what to do after setting values + -s, --sec=SEC: specify the number of seconds to wait (only valid for --mode=time) + -u, --usec=USEC: specify the number of microseconds to wait (only valid for --mode=time) + -b, --background: after setting values: detach from the controlling terminal + + Modes: + exit: set values and exit immediately + wait: set values and wait for user to press ENTER + time: set values and sleep for a specified amount of time + signal: set values and wait for SIGINT or SIGTERM + + Note: the state of a GPIO line controlled over the character device reverts to default + when the last process referencing the file descriptor representing the device file exits. + This means that it's wrong to run gpioset, have it exit and expect the line to continue + being driven high or low. It may happen if given pin is floating but it must be interpreted + as undefined behavior. + + +.. warning:: + + Some of the user IOs are used for special functions. Before using a user IO, + refer to the schematic or the hardware manual of your board to ensure that it + is not already in use. + +GPIOs via sysfs +............... + +.. warning:: + + Accessing gpios via sysfs is deprecated and we encourage to use libgpiod + instead. + +Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling ``CONFIG_GPIO_SYSFS`` in the kernel +configuration. To make ``CONFIG_GPIO_SYSFS`` visible in menuconfig the option +``CONFIG_EXPERT`` has to be enabled first. + +You can also add this option for example to the defconfig you use in +``arch/arm64/configs/`` in the linux kernel sources. For our NXP based releases, +this could be for example ``imx8_phytec_distro.config``:: + + .. + CONFIG_EXPERT=y + CONFIG_GPIO_SYSFS=y + .. + +Otherwise you can create a new config fragment. This is described in our +`Yocto Reference Manual `_. + +LEDs +---- + +If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using ``/sys/class/leds/`` instead +of ``/sys/class/gpio/``. The maximum brightness of the LEDs can be read from +the ``max_brightness`` file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings. + +Below is a simple example. + +To get all available LEDs, type: + +.. code-block:: console + + target:~$ ls /sys/class/leds + mmc1::@ mmc2::@ user-led1@ user-led2@ user-led3@ + +Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the |sbc|. + +* To toggle the LEDs ON: + + .. code-block:: console + + target:~$ echo 255 > /sys/class/leds/user-led1/brightness + +* To toggle OFF: + + .. code-block:: console + + target:~$ echo 0 > /sys/class/leds/user-led1/brightness + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n216` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n105` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n201` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues. + +.. include:: ../peripherals/eeprom.rsti + +Rescue EEPROM Data +.................. + +The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area. + +.. code-block:: console + + target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 + +.. note:: + + If you deleted both EEPROM spaces, please contact our support! + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n201` + +.. include:: ../../peripherals/rtc.rsti + :end-before: .. rtc_parameter_start_label + +DT representation for I²C RTCs: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n207` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n341` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of imx8mp-phyboard-pollux.dtsi: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n165` + +PCIe +---- + +The phyCORE-|soc| has one Mini-PCIe slot. In general, PCIe autodetects new +devices on the bus. After connecting the device and booting up the system, you +can use the command lspci to see all PCIe devices recognized. + +* Type: + + .. code-block:: console + + target:~$ lspci -v + +* You will receive: + + .. code-block:: + + 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode]) + Flags: bus master, fast devsel, latency 0, IRQ 218 + Memory at 18000000 (64-bit, non-prefetchable) [size=1M] + Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0 + I/O behind bridge: None + Memory behind bridge: 18100000-181fffff [size=1M] + Prefetchable memory behind bridge: None + [virtual] Expansion ROM at 18200000 [disabled] [size=64K] + Capabilities: [40] Power Management version 3 + Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+ + Capabilities: [70] Express Root Port (Slot-), MSI 00 + Capabilities: [100] Advanced Error Reporting + Capabilities: [148] L1 PM Substates + Kernel driver in use: dwc3-haps + + 01:00.0 Network controller: Intel Corporation WiFi Link 5100 + Subsystem: Intel Corporation WiFi Link 5100 AGN + Flags: fast devsel + Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K] + Capabilities: [c8] Power Management version 3 + Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+ + Capabilities: [e0] Express Endpoint, MSI 00 + Capabilities: [100] Advanced Error Reporting + Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e + Kernel modules: iwlwifi + +In this example, the PCIe device is the *Intel Corporation WiFi Link 5100*. + +For PCIe devices, you have to enable the correct driver in the kernel +configuration. This WLAN card, for example, is manufactured by Intel. The +option for the driver, which must be enabled, is named ``CONFIG_IWLWIFI`` and can be +found under *Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimat* in +the kernel configuration. + +* In order to activate the driver, follow the instructions from our + `Yocto Reference Manual `_. + + - The linux-imx is represented by: **virtual/kernel** + +For some devices like the WLAN card, additional binary firmware blobs are +needed. These firmware blobs have to be placed in ``/lib/firmware/`` before the +device can be used. + +* Type: + + .. code-block:: console + + host:~$ scp -r root@192.168.3.11:/lib/firmware + +* For example, if you try to bring up the network interface: + + .. code-block:: console + + target:~$ ip link set up wlp1s0 + +* You will get the following output on the serial console: + + .. code-block:: console + + [ 58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0 + [ 58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0 + [ 58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready + +.. tip:: + + Some PCIe devices, e.g. the Ethernet card, may function properly even if no + firmware blob is loaded from ``/lib/firmware/`` and you received an error message + as shown in the first line of the output above. This is because some + manufacturers provide the firmware as a fallback on the card itself. In this + case, the behavior and output depend strongly on the manufacturer's firmware. + +Device Tree PCIe configuration of imx8mm-phyboard-polis.dtsi: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n277` + +Audio +----- + +Playback devices supported for |sbc| are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals. + +.. note:: + + Using the PEB-AV-10 connector for display output along HDMI as audio output + is not supported. The audio output device must match the video output device. + +To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices: + +.. code-block:: console + + target:~$ aplay -L + +Or type for recording devices: + +.. code-block:: console + + target:~$ arecord -L + +Alsamixer +......... + +To inspect the capabilities of your soundcard, call: + +.. code-block:: console + + target:~$ alsamixer + +You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. "MM" means the feature is muted +(both output, left & right), which can be toggled by hitting **m**. You can also +toggle by hitting '**<**' for left and '**>**' for right output. With the **tab** +key, you can switch between controls for playback and recording. + +ALSA configuration +.................. + +Our BSP comes with a ALSA configuration file ``/etc/asound.conf``. + +The ALSA configuration file can be edited as desired or deleted since it is not +required for ALSA to work properly. + +.. code-block:: console + + target:~$ vi /etc/asound.conf + +To set PEB-AV-10 as output, set *playback.pcm* from "dummy" to "pebav10": + +.. code-block:: + + [...] + + pcm.asymed { + type asym + playback.pcm "pebav10" + capture.pcm "dsnoop" + } + + [...] + +If the sound is not audible change playback devices to the software volume control +playback devices, set *playback.pcm* to the respective softvol playback device either +"softvol_hdmi" or "softvol_pebav10". Use alsamixer controls to vary the volume levels. + +.. code-block:: + + [...] + + pcm.asymed { + type asym + playback.pcm "softvol_hdmi" + capture.pcm "dsnoop" + } + + [...] + +Pulseaudio Configuration +........................ + +For applications using Pulseaudio, check for available sinks: + +.. code-block:: console + + target:~$ pactl list short sinks + 0 alsa_output.platform-snd_dummy.0.stereo-fallback module-alsa-card.c s16le 2ch 44100Hz SUSPENDED + 1 alsa_output.platform-sound-peb-av-10.stereo-fallback module-alsa-card.c s16le 2ch 44100Hz SUSPENDED + +To select PEB-AV-10, type: + +.. code-block:: console + + target:~$ pactl set-default-sink 1 + +Playback +........ + +Run speaker-test to check playback availability: + +.. code-block:: console + + target:~$ speaker-test -c 2 -t wav + +To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds: + +.. code-block:: console + + target:~$ aplay /usr/share/sounds/alsa/* + +To playback other formats like mp3 for example, you can use Gstreamer: + +.. code-block:: console + + target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3 + +Capture +....... + +``arecord`` is a command-line tool for capturing audio streams which use Line In as +the default input source. To select a different audio source you can +use ``alsamixer``. For example, switch on *Right PGA Mixer Mic3R* and *Left PGA Mixer +Mic3R* in order to capture the audio from the microphone input of the +TLV320-Codec using the 3.5mm jack. + +.. code-block:: console + + target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on + target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on + +.. code-block:: console + + target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav + +.. hint:: + + Since playback and capture share hardware interfaces, it is not possible to + use different sampling rates and formats for simultaneous playback and + capture operations. + +Device Tree Audio configuration: +:imx-dt:`overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.10.72_2.2.0-phy17#n57` + +Video +----- + +Videos with Gstreamer +..................... + +The video is installed by default in the BSP: + +.. code-block:: console + + target:~$ gst-launch-1.0 playbin uri=file:///usr/share/phytec-qtdemo/videos/caminandes.webm + +* Or: + +.. code-block:: console + + target:~$ gst-launch-1.0 -v filesrc location= \ + \! qtdemux \! h264parse \! queue \! vpudec \! waylandsink async=false enable-last-sample=false \ + qos=false sync=false + +* Or: + +.. code-block:: console + + target:~$ gplay-1.0 /usr/share/phytec-qtdemo/videos/caminandes.webm + +kmssink Plugin ID Evaluation +............................ + +The kmssink plugin needs a connector ID. To get the connector ID, you can use +the tool modetest. + +.. code-block:: console + + target:~$ modetest -c imx-drm + +The output will show something like: + +.. code-block:: + + Connectors: + id encoder status name size (mm) modes encoders + 35 34 connected LVDS-1 216x135 1 34 + modes: + index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot + #0 1280x800 59.07 1280 1380 1399 1440 800 804 808 823 70000 flags: phsync, pvsync; type: preferred, driver + props: + 1 EDID: + flags: immutable blob + blobs: + + value: + 2 DPMS: + flags: enum + enums: On=0 Standby=1 Suspend=2 Off=3 + value: 0 + 5 link-status: + flags: enum + enums: Good=0 Bad=1 + value: 0 + 6 non-desktop: + flags: immutable range + values: 0 1 + value: 0 + 4 TILE: + flags: immutable blob + blobs: + + value: + +Display +------- + +The |sbc| supports up to 4 different display outputs. Three can be used +simultaneously. The following table shows the required extensions and devicetree +overlays for the different interfaces. + +========= ======================== ====================================== +Interface Expansion devicetree overlay +========= ======================== ====================================== +HDMI |sbc| no overlay needed (enabled by default) +LVDS0 PEB-AV-10 imx8mp-phyboard-pollux-peb-av-010.dtbo + (loaded by default) +LVDS1 |sbc| disabled if PEB-AV-10 overlay is used +MIPI PEB-AV-12 (MIPI to LVDS) imx8mp-phyboard-pollux-peb-av-012.dtbo +========= ======================== ====================================== + +.. note:: + + * HDMI will not work if LVDS1 (onboard) is enabled. + * When changing Weston output, make sure to match the audio output as well. + * LVDS0 (PEB-AV-10) and LVDS1 (onboard)can not be used at the same time. + +HDMI is always enabled in the devicetree. The other interfaces can be enabled +with Device Tree Overlay. + +The default-enabled Interfaces are HDMI and LVDS0 (PEB-AV-010). We support a +10'' edt,etml1010g0dka display for the PEB-AV-10 and PEB-AV-12. + +.. note:: + + The current display driver limits the pixel clock for a display connected to + LVDS to 74.25Mhz (or a divider of it). If this does not fit your display + requirements, please contact Support for further help. + +Weston Configuration +.................... + +In order to get an output from Weston on the correct display, it still needs to +be configured correctly. This will be done at /etc/xdg/weston/weston.ini. + +Single Display +~~~~~~~~~~~~~~ + +In our BSP, the default Weston output is set to HDMI. :: + + [output] + name=HDMI-A-1 + mode=current + +.. include:: /bsp/qt5.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +Device tree description of LVDS-1 and HDMI can be found here: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n255` +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n180` + +The device tree of LVDS-0 on PEB-AV-10 can be found here: +:imx-dt:`overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.10.72_2.2.0-phy17#n132` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +The device tree description of GPIO Fan can be found here: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n26` + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/snvs-power-key.rsti + +NPU +--- + +The |soc| SoC contains a Neural Processing Unit up to 2.3 TOPS as an accelerator +for artificial intelligence operations. Refer to our latest phyCORE-|soc| AI Kit +Guide on the phyCORE-|soc| download section to get information about the +NPU: `L-1015e.A0 phyCORE-i.MX 8M Plus AI Kit Guide +`_ + +NXP Examples for eIQ +.................... + +NXP provides a set of machine learning examples for eIQ using Python3. To add a +pre-configured machine learning package group, add to your local.conf and build +your BSP:: + + IMAGE_INSTALL_append = " packagegroup-imx-ml python3-pip python3-requests opencv" + +This will require about 1GB of additional space on the SD Card. Instructions +on how to install and use the NXP examples can be found at +https://community.nxp.com/t5/Blogs/PyeIQ-3-x-Release-User-Guide/ba-p/1305998. + +.. hint:: + + The installation of the eiq examples with pip3 requires an internet + connection. + +.. note:: + + On some Ubuntu 20.04 hosts, cmake uses the host's Python 3 instead of Python + 3.7 from Yocto when building python3-pybind11. (see + https://community.nxp.com/t5/i-MX-Processors/Yocto-L5-4-70-2-3-0-build-image-failed/m-p/1219619) + + As a workaround edit, the python3-pybind11 recipe by:: + + $ devtool edit-recipe python3-pybind11 + + and add to the file:: + + EXTRA_OECMAKE += "-DPYTHON_EXECUTABLE=${RECIPE_SYSROOT_NATIVE}/usr/bin/python3-native/python3.7" + +.. include:: ../peripherals/isp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +Reading the registers using ``/dev/mem`` will cause the system to hang unless the +*ocotp_root_clk* is enabled. To enable this clock permanent, add to the device +tree: + +.. code-block:: + + &clk { + init-on-array = ; + }; + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti + +.. +---------------------------------------------------------------------------+ +.. BSP EXTENSIONS +.. +---------------------------------------------------------------------------+ + +BSP Extensions +============== + +Chromium +-------- + +Our BSP for the |sbc|-|soc| supports Chromium. You can include it in the +|yocto-imagename| with only a few steps. + +Adding Chromium to Your local.conf +.................................. + +To include Chromium you have to add the following line into your local.conf. You +can find it in /build/conf/local.conf. This adds Chromium to your +next image build. :: + + IMAGE_INSTALL_append = " chromium-ozone-wayland" + +.. note:: + + Compiling Chromium takes a long time. + +Get Chromium Running on the Target +.................................. + +To run Chromium, it needs a few arguments to use the hardware graphics +acceleration:: + + target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox + +If you want to start Chromium via SSH, you must first define the display on +which Chromium will run. For example:: + + target$ DISPLAY=:0 + +After you have defined this, you can start it via virtual terminal on Weston as +shown above. diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd22.1.2.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd22.1.2.rst.txt new file mode 100644 index 000000000..96163ec69 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd22.1.2.rst.txt @@ -0,0 +1,2598 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MP-PD22.1.2 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.2/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.2/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.2/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp + +.. IMX8(MP) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mp/phycore-imx8mp.c?h=v2021.04_2.2.0-phy13#n239 + + +.. General Substitutions +.. |atfloadaddr| replace:: 0x970000 +.. |kit| replace:: **phyCORE-i.MX8M Plus Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Pollux +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |bluetooth-uart| replace:: UART3 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx8mp +.. |kernel-tag| replace:: v5.10.72_2.2.0-phy18 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MP +.. |u-boot-tag| replace:: v2021.04_2.2.0-phy17 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-phyboard-pollux-rdk +.. |dt-som| replace:: imx8mp-phycore-som +.. |dtbo-rpmsg| replace:: imx8mp-phycore-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mp-phyboard-pollux-peb-av-010.dtbo + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n41` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`hardknott` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: hardknott +.. |yocto-distro| replace:: ampliphy-vendor-xwayland +.. |yocto-imagename| replace:: phytec-qt5demo-image +.. |yocto-machinename| replace:: phyboard-pollux-imx8mp-3 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MP-PD22.1.2 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MP-PD22.1.y +.. |yocto-ref-manual| replace:: L-813e.A12 Yocto Reference Manual (Hardknott) +.. _yocto-ref-manual: https://www.phytec.de/cdocuments/?doc=UIHsG +.. _yocto-ref-manual-kernel-and-bootloader-config: https://www.phytec.de/cdocuments/?doc=UIHsG#YoctoReferenceManualHardknottL813e-A12-KernelandBootloaderConfiguration +.. |yocto-sdk-rev| replace:: BSP-Yocto-NXP-i.MX8MP-PD22.1.2 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n141`. +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + ++-----------------------+----------------------+ +| |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Yocto Manual | | ++-----------------------+----------------------+ +| Release Date | 2024/08/05 | ++-----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================= ========== +|yocto-manifestname| Minor 2024/08/05 Released +==================== ================ ================= ========== + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. note:: + When the PCM-070 does not have the X1 extension connector populated, some + Software features described here do not work. These are Wirless LAN, PCIe, + CSI (cameras), PEB-AV-12, CAN, USB-OTG. + +.. _imx8mp-pd22.1.2-components: +.. include:: components.rsti + +Getting Started +=============== + +The |kit| is shipped with a pre-flashed SD card. It contains the +|yocto-imagename| and can be used directly as a boot source. The eMMC is +programmed with only a U-boot by default. You can get all sources from the +`PHYTEC download server `_. This chapter explains how to flash a BSP +image to SD card and how to start the board. + +Get the Image +------------- + +The WIC image contains all BSP files in several, correctly pre-formatted +partitions and can be copied to an SD card easily using the single Linux +command ``dd``. It can be built by Yocto or downloaded from the PHYTEC download +server. + +Get the WIC file from the download server: + +.. code-block:: console + :substitutions: + + host:~$ wget |link-image| + +Write the Image to SD Card +-------------------------- + +.. warning:: + To create your bootable SD card with the ``dd`` command, you must have root + privileges. Be very careful when specifying the destination device with + ``dd``! All files on the selected destination device will be erased + immediately without any further query! + + Selecting the wrong device may result in **data loss** and e.g. could erase + your currently running system! + +To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. Unmount any mounted partitions before +you start copying the image to the SD card. + +#. In order to get the correct device name, remove your SD card and + execute:: + + host$ lsblk + +#. Now insert your SD card and execute the command again:: + + host$ lsblk + +#. Compare the two outputs to find the new device names listed in the second + output. These are the device names of the SD card (device and partitions if + the SD card was formatted). +#. In order to verify the device names being found, execute the command + ``sudo dmesg``. Within the last lines of its output, you should also find the + device names, e.g. ``/dev/sde`` or ``/dev/mmcblk0`` (depending on your + system). + +Alternatively, you may use a graphical program of your choice, like `GNOME Disks +`_ or `KDE Partition Manager +`_, to find the correct device. + +Now that you have the correct device name, e.g. ``/dev/sde``, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. ``/dev/sde1``) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption. + +* Unmount all partitions, e.g.:: + + host$ sudo umount /dev/sde1 + +* After having unmounted all partitions, you can create your bootable SD card:: + + host$ sudo dd if=-.wic of=/dev/sdX bs=1M conv=fsync status=progress + + Again, make sure to replace ``/dev/sdX`` with your actual device name found + previously. + + The parameter ``conv=fsync`` forces a sync operation on the device before + ``dd`` returns. This ensures that all blocks are written to the SD card and + none are left in memory. The parameter ``status=progress`` will print out + information on how much data is and still has to be copied until it is + finished. + +An alternative and much faster way to prepare an SD card can be done by using +`bmap-tools `_ from Intel. Yocto +automatically creates a block map file (``-.wic.bmap``) for +the WIC image that describes the image content and includes checksums for data +integrity. *bmaptool* is packaged by various Linux distributions. For +Debian-based systems install it by issuing:: + + host$ sudo apt install bmap-tools + +Flash a WIC image to SD card by calling:: + + host$ bmaptool copy -.wic /dev/ + +.. warning:: + *bmaptool* only overwrites the areas of an SD card where image data is + located. This means that a previously written U-Boot environment may still be + available after writing the image. + +First Start-up +-------------- + +* To boot from an SD card, |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-pd22.1.2-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-phyboard-pollux-rdk*.dtb**: Kernel device tree file +* **imx8mp-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt5demo-image\*.tar.gz**: Root file system +* **phytec-qt5demo-image\*.wic**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-pd22.1.2-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **Default SOM boot**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. However, they only +work if the size of the image file is less than 1GB. If the image file is +larger, go to the section Format SD Card. Configure the |ref-bootswitch| to boot +from SD Card and put in an SD card. Power on the board and stop in U-Boot +prompt. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +* Load your image via network to RAM: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* Write the image to the eMMC: + + .. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + A working network is necessary! Setup Network Host. + +Take a compressed or uncompressed image on the host and send it with ssh through +the network (then uncompress it, if necessary) to the eMMC of the target with a +one-line command: + +.. code-block:: console + :substitutions: + + target:~$ ssh @192.168.3.10 "dd if=/|yocto-imagename|-|yocto-machinename|.wic" | dd of=/dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +Send the image with the command dd command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2" + +Flash eMMC u-boot image via Network from running u-boot +....................................................... + +Update the standalone u-boot image imx-boot is also possible from u-boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB +................... + +Flash eMMC from USB in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in Bootloader after enabling the OPTEE. + +These steps will show how to update the eMMC via a USB device. Configure the +bootmode switch to |ref-bootswitch| and put in an SD card. Power on the board +and stop in u-boot prompt. Insert a USB device with the copied WIC image +to the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} *.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the bootmode switch to +|ref-bootswitch|. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ cd /mnt + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2boot0; mmcblk2boot1) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + +.. warning:: + + Before this will work, you need to configure the multi-port switch + to **Default SOM Boot** to |ref-bootswitch|. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to enlarge your SD card to use +its full space (if it was not enlarged before). To enlarge your SD card, see +Resizing ext4 Root Filesystem. + +Flash eMMC from SD card in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in Bootloader after enabling the OPTEE. If the + image file is too large use the `Updating eMMC from SD card in + Linux on Target` subsection. + +* Flash an SD card with a working image and create a third FAT partition. Copy + the WIC image (for example |yocto-imagename|.wic) to this + partition. +* Configure the bootmode switch to boot from the SD Card and insert the SD + card. +* Power on the board and stop in u-boot. +* Flash your WIC image (for example |yocto-imagename|.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> fatload mmc 1:3 ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc0(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the multi-port switch to Default SOM Boot to + boot from eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a complete image saved on +the SD card (e.g. |yocto-imagename|-|yocto-machinename|.wic). + +* Show your saved image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2\ **boot0**; mmcblk2\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + +.. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to Default + SOM Boot to boot from eMMC. + +Flash SPI NOR Flash +------------------- + +The |som| modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set |ref-bootswitch| to **QSPI boot** to boot from QSPI. The SPI Flash is +usually quite small. The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash +populated. Only the bootloader and the environment can be stored. The kernel, +device tree, and file system are taken from eMMC by default. + +The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with: + +.. code-block:: + + u-boot=> printenv mtdparts + mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none) + +Flash SPI NOR Flash from Network +................................ + +The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-|soc|. + +.. tip:: + + A working network is necessary! Setup Network Host. + +Flash SPI NOR from Network in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI-NOR flash needs to be probed: + +.. code-block:: + + u-boot=> sf probe + SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB + +* A specially formatted u-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image over tftp, erase and write the + bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + device 0 offset 0x0, size 0x1c0b20 + 1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +.. warning:: + + Erasing the complete SPI NOR flash when it is fully written will take quite + some time. This can trigger the watchdog to reset. Due to this, erase the + full flash in Linux. + +Flash SPI NOR from Network in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the image from the host to the target: + + .. code-block:: console + :substitutions: + + host:~$ scp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root + +* Find the number of erase blocks of the U-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +Flash SPI NOR Flash from SD Card +................................ + +The bootloader on SPI NOR flash can be also flashed with SD Card. + +Flash SPI NOR from SD Card in u-boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the FAT partition + on the SD Card. Before reading and writing are possible, the SPI-NOR flash + needs to be probed: + + .. code-block:: + + u-boot=> sf probe + SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB + +* A specially formatted U-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image from the SD Card, erase and write + the bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +.. warning:: + + Erasing the complete SPI NOR flash when it is fully written will take quite + some time. This can trigger the watchdog to reset. Due to this, erase the + full flash in Linux. + +Flash SPI NOR from SD Card in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Mount the SD Card: + + .. code-block:: console + :substitutions: + + host:~$ mount /dev/mmcblkp1 /mnt + +* Find the number of erase blocks of the u-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp /mnt/imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A3 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd22.1.2-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + +.. _imx8mp-pd22.1.2-development-build-uboot: + +U-Boot standalone build +----------------------- + +Get the source code +................... + +* Get the U-Boot sources: + + .. code-block:: console + + host:~$ git clone git://git.phytec.de/u-boot-imx + +* To get the correct *U-Boot* **tag** you need to take a look at our release + notes, which can be found here: `release notes `_ +* The **tag** needed at this release is called |u-boot-tag| +* Check out the needed *U-Boot* **tag**: + +.. code-block:: console + :substitutions: + + host:~$ cd ~/u-boot-imx/ + host:~$ git fetch --all --tags + host:~$ git checkout tags/|u-boot-tag| + +* Technically, you can now build the U-Boot, but practically there are some + further steps necessary: + + * Create your own development branch: + + .. code-block:: console + + host:~$ git switch --create + + .. note:: + + You can name your development branch as you like, this is just an example. + +* Set up a build environment: + + .. code-block:: console + :substitutions: + + host:~$ source /opt/|yocto-distro|/|yocto-manifestname|/environment-setup-cortexa53-crypto-phytec-linux + +* Set this environment variable before building the Image: + + .. code-block:: console + :substitutions: + + host:~$ export ATF_LOAD_ADDR=|atfloadaddr| + +Get the needed binaries +....................... + +To build the bootloader, you need to **copy** these **files** to your |u-boot-repo-name| +**build directory** and rename them to fit with *mkimage* script: + +* **ARM Trusted firmware binary** (*mkimage tool* compatible format + **bl31.bin**): bl31-|kernel-socname|.bin +* **OPTEE image** (optional): tee.bin +* **DDR firmware files** (*mkimage tool* compatible format + **lpddr4_[i,d]mem_\*d_\*.bin**): + lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, + lpddr4_imem_2d_*.bin + +If you already built our BSP with Yocto, you can get the +bl31-|kernel-socname|.bin, tee.bin and lpddr4_*.bin from the directory mentioned +here: |ref-bsp-images| + +Or you can download the files here: |link-boot-tools| + +.. warning:: + + Make sure you rename the files you need so that they are compatible with the + *mkimage tool*. + +Build the bootloader +.................... + +* build flash.bin (imx-boot): + + .. code-block:: console + :substitutions: + + host:~$ make phycore-|kernel-socname|_defconfig + host:~$ make flash.bin + +Flash the bootloader to a block device +...................................... + +The flash.bin can be found at u-boot-imx/ directory and now can be flashed. A +chip-specific offset is needed: + +.. _offset-table: + +===== =================== ============================= ============ +SoC Offset User Area Offset Boot Partition eMMC Device +===== =================== ============================= ============ +|soc| |u-boot-offset| kiB |u-boot-offset-boot-part| kiB /dev/mmcblk2 +===== =================== ============================= ============ + +E.g. flash SD card: + +.. code-block:: console + :substitutions: + + host:~$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=|u-boot-offset| conv=sync + +.. hint:: + The specific offset values are also declared in the Yocto variables "BOOTLOADER_SEEK" and "BOOTLOADER_SEEK_EMMC" + +Build U-Boot With a Fixed RAM Size +.................................. + +If you cannot boot your system anymore because the hardware introspection in the +EEPROM is damaged or deleted, you can create a flash.bin with a fixed ram size. +You should still contact support and flash the correct EEPROM data, as this +could lead to unexpected behavior. + +Follow the steps to get the U-boot sources and check the correct branch in the +**Build U-Boot** section. + +Edit the file configs/phycore-|kernel-socname|\_defconfig: + +.. code-block:: kconfig + :substitutions: + + CONFIG_TARGET_|u-boot-socname-config|=y + CONFIG_|u-boot-socname-config|_RAM_SIZE_FIX=y + # CONFIG_|u-boot-socname-config|_RAM_SIZE_1GB=y + # CONFIG_|u-boot-socname-config|_RAM_SIZE_2GB=y + # CONFIG_|u-boot-socname-config|_RAM_SIZE_4GB=y + # CONFIG_|u-boot-socname-config|_RAM_SIZE_4GB_2GHZ=y + +Choose the correct RAM size as populated on the board and uncomment the line for +this ram size. For Article number 0F\ **8**\ 443I, use [...]_4GB_2GHZ, for +0F\ **5**\ 443I, use [...]_4GB. +After saving the changes, follow the remaining steps from |ref-build-uboot|. + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd22.1.2-device-tree: + +Device Tree (DT) +================ + +Introduction +------------ + +The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html) + +*"The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn't need to hard code details of the machine."* + +The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at `devicetree.org `_. + +PHYTEC |soc| BSP Device Tree Concept +------------------------------------ + +The following sections explain some rules PHYTEC has defined on how to set up +device trees for our |soc| SoC-based boards. + +Device Tree Structure +..................... + +* *Module.dtsi* - Module includes all devices mounted on the SoM, such as PMIC + and RAM. +* *Carrierboard.dtsi* - Devices that come from the |soc| SoC but are just routed + down to the carrier board and used there are included in this dtsi. +* *Board.dts* - include the carrier board and module dtsi files. There may also + be some hardware configuration nodes enabled on the carrier board or the + module (i.e. the Board .dts shows the special characteristics of the board + configuration). For example, there are phyCORE-|soc| SOMs which may or may not + have a MIPI DSI to LVDS converter mounted. The converter is enabled (if + available) in the Board .dts and not in the Module .dtsi + +From the root directory of the Linux Kernel our devicetree files for |socfamily| +platforms can be found in ``arch/arm64/boot/dts/freescale/``. + +Device Tree Overlay +................... + +Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder ``arch/arm64/boot/dts/freescale/overlays``. + +Available overlays for |yocto-machinename|.conf are: + +.. code-block:: + + imx8mp-isi-csi1.dtbo + imx8mp-isi-csi2.dtbo + imx8mp-isp-csi1.dtbo + imx8mp-isp-csi2.dtbo + imx8mp-phyboard-pollux-peb-av-010.dtbo + imx8mp-phyboard-pollux-peb-av-012.dtbo + imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + imx8mp-phycore-no-eth.dtbo + imx8mp-phycore-no-rtc.dtbo + imx8mp-phycore-no-spiflash.dtbo + imx8mp-phycore-rpmsg.dtbo + imx8mp-vm016-csi1.dtbo + imx8mp-vm016-csi1-fpdlink.dtbo + imx8mp-vm016-csi2.dtbo + imx8mp-vm016-csi2-fpdlink.dtbo + imx8mp-vm017-csi1.dtbo + imx8mp-vm017-csi1-fpdlink.dtbo + imx8mp-vm017-csi2.dtbo + imx8mp-vm017-csi2-fpdlink.dtbo + +.. hint:: + There is one more overlay available for phyboard-pollux-imx8mp-2.conf: + imx8mp-phyboard-pollux-1552.1.dtbo + +.. _imx8mp-pd22.1.2-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +imx8mp-phyboard-pollux.dtsi: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x49 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x49 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n331` + +.. _imx8mp-pd22.1.2-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +WLAN and Bluetooth on the |sbc| are provided by the PEB-WLBT-05 expansion card. +The PEB-WLBT-05 for |sbc| Quickstart Guide shows you how to install the +PEB-WLBT-05. + +.. tip:: + + With the BSP Version PD22.1 and newer, the PEB-WLBT-05 overlay needs to be activated first, + otherwise the PEB-WLBT-05 won't be recognized. + + .. code-block:: console + + target:~$ vi /boot/bootenv.txt + + Afterwards the bootenv.txt file should look like this (it can also contain other devicetree + overlays!): + + .. code-block:: + + overlays=imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + + The changes will be applied after a reboot: + + .. code-block:: console + + target:~$ reboot + + For further information about devicetree overlays, read the |ref-dt| chapter. + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First set the correct regulatory domain for your country: + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see: + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +Set up the wireless interface: + +.. code-block:: console + + target:~$ ip link + target:~$ ip link set up dev wlan0 + +Now you can scan for available networks: + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection. + +To do so, add the network-credentials to the file ``/etc/wpa_supplicant.conf``: + +.. code-block:: + + country=DE + network={ + ssid="" + proto=WPA2 + psk="" + } + +Now a connection can be established: + +.. code-block:: console + + target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B + +This should result in the following output: + +.. code-block:: + + ... + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section `Changing the Network Configuration` in the |yocto-ref-manual|_. + +First, create the directory: + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +Then add the following configuration snippet in ``/etc/systemd/network/10-wlan0.network``: + +.. code-block:: + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +Now, restart the network daemon so that the configuration takes effect: + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Bluetooth +......... + +Bluetooth is supported on |sbc| with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section. + +Bluetooth is connected to |bluetooth-uart| interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually: + +.. code-block:: console + + target:~$ hciconfig hci0 up + + target:~$ hciconfig -a + + hci0: Type: Primary Bus: UART + BD Address: 00:25:CA:2F:39:96 ACL MTU: 1021:8 SCO MTU: 64:1 + UP RUNNING PSCAN + RX bytes:1392 acl:0 sco:0 events:76 errors:0 + TX bytes:1198 acl:0 sco:0 commands:76 errors:0 + ... + +Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup. + +.. code-block:: console + + target:~$ hcitool scan + Scanning ... + XX:XX:XX:XX:XX:XX + +Visibility +~~~~~~~~~~ + +To activate visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 piscan + +To disable visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 noscan + +Connect +~~~~~~~ + +.. code-block:: console + + target:~$ bluetoothctl + [bluetooth]# discoverable on + Changing discoverable on succeeded + [bluetooth]# pairable on + Changing pairable on succeeded + [bluetooth]# agent on + Agent registered + [bluetooth]# default-agent + Default agent request successful + [bluetooth]# scan on + [NEW] Device XX:XX:XX:XX:XX:XX + [bluetooth]# connect XX:XX:XX:XX:XX:XX + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n367` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n220` + +eMMC Devices +------------ + +PHYTEC modules like phyCORE-|soc| is populated with an eMMC memory chip as the +main storage. eMMC devices contain raw MLC memory cells combined with a memory +controller that handles ECC and wear leveling. They are connected via an SD/MMC +interface to the |soc| and are represented as block devices in the Linux kernel +like SD cards, flash drives, or hard disks. + +The electric and protocol specifications are provided by JEDEC +(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). +The eMMC manufacturer's datasheet is relatively short and meant to be read +together with the supported version of the JEDEC eMMC standard. + +PHYTEC currently utilizes the eMMC chips with JEDEC Version 5.0 and 5.1 + +Extended CSD Register +..................... + +eMMC devices have an extensive amount of extra information and settings that are +available via the Extended CSD registers. For a detailed list of the registers, +see manufacturer datasheets and the JEDEC standard. + +In the Linux user space, you can query the registers: + +.. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| + +You will see: + +.. code-block:: + + ============================================= + Extended CSD rev 1.7 (MMC 5.0) + ============================================= + + Card Supported Command sets [S_CMD_SET: 0x01] + [...] + +Enabling Background Operations (BKOPS) +...................................... + +In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer +(FTL) that handles the wear leveling, block management, and ECC of the raw MLC +cells. This requires some maintenance tasks (for example erasing unused blocks) +that are performed regularly. These tasks are called **Background +Operations (BKOPS)**. + +By default (depending on the chip), the background operations may or may not be +executed periodically, impacting the worst-case read and write latency. + +The JEDEC Standard has specified a method since version v4.41 that the host can +issue BKOPS manually. See the JEDEC Standard chapter Background Operations and +the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in +the eMMC datasheet for more details. + +Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0): + +* Value 0: The host does not support the manual trigger of BKOPS. Device write + performance suffers. +* Value 1: The host does support the manual trigger of BKOPS. It will issue + BKOPS from time to time when it does not need the device. + +The mechanism to issue background operations has been implemented in +the Linux kernel since v3.7. You only have to enable BKOPS_EN on the eMMC device +(see below for details). + +The JEDEC standard v5.1 introduces a new automatic BKOPS feature. It frees the +host to trigger the background operations regularly because the device starts +BKOPS itself when it is idle (see the description of bit AUTO_EN in +register BKOPS_EN (Reg: 163)). + +The userspace tool mmc does not currently support enabling automatic BKOPS +features. + +* To check whether *BKOPS_EN* is set, execute: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep BKOPS_EN + + The output will be, for example: + + .. code-block:: + + Enable background operations handshake [BKOPS_EN]: 0x01 + #OR + Enable background operations handshake [BKOPS_EN]: 0x00 + + Where value 0x00 means BKOPS_EN is disabled and device write performance + suffers. Where value 0x01 means BKOPS_EN is enabled and the host will issue + background operations from time to time. + +* To set the BKOPS_EN bit, execute: + + .. code-block:: console + :substitutions: + + target:~$ mmc bkops enable /dev/|emmcdev| + +* To ensure that the new setting is taken over and the kernel triggers BKOPS by + itself, shut down the system: + + .. code-block:: console + + target:~$ poweroff + +.. tip:: + + The BKOPS_EN bit is one-time programmable only. It cannot be reversed. + +Reliable Write +.............. + +There are two different Reliable Write options: + +1. Reliable Write option for a whole eMMC device/partition. +2. Reliable Write for single write transactions. + +.. tip:: + + Do not confuse eMMC partitions with partitions of a DOS, MBR, or GPT + partition table (see the previous section). + +The first Reliable Write option is mostly already enabled on the eMMCs mounted +on the phyCORE-|soc| SoMs. To check this on the running target: + +.. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep -A 5 WR_REL_SET + Write reliability setting register [WR_REL_SET]: 0x1f + user area: the device protects existing data if a power failure occurs during a write o + peration + partition 1: the device protects existing data if a power failure occurs during a write + operation + partition 2: the device protects existing data if a power failure occurs during a write + operation + partition 3: the device protects existing data if a power failure occurs during a write + operation + partition 4: the device protects existing data if a power failure occurs during a write + operation + -- + Device supports writing EXT_CSD_WR_REL_SET + Device supports the enhanced def. of reliable write + +Otherwise, it can be enabled with the mmc tool: + +.. code-block:: console + + target:~$ mmc --help + + [...] + mmc write_reliability set <-y|-n> + +The second Reliable Write option is the configuration bit Reliable Write Request +parameter (bit 31) in command CMD23. It has been used in the kernel +since v3.0 by file systems, e.g. ext4 for the journal and user space +applications such as fdisk for the partition table. In the Linux kernel source +code, it is handled via the flag REQ_META. + +**Conclusion**: ext4 file system with mount option data=journal should be safe +against power cuts. The file system check can recover the file system after a +power failure, but data that was written just before the power cut may be lost. +In any case, a consistent state of the file system can be recovered. To ensure +data consistency for the files of an application, the system functions fdatasync +or fsync should be used in the application. + +Resizing ext4 Root Filesystem +............................. + +When flashing the sdcard image to eMMC the ext4 root partition is not extended +to the end of the eMMC. parted can be used to expand the root partition. The +example works for any block device such as eMMC, SD card, or hard disk. + +* Get the current device size: + + .. code-block:: console + :substitutions: + + target:~$ parted /dev/|emmcdev| print + +* The output looks like this: + + .. code-block:: + :substitutions: + + Model: MMC Q2J55L (sd/mmc) + Disk /dev/|emmcdev|: 7617MB + Sect[ 1799.850385] |emmcdev|: p1 p2 + or size (logical/physical): 512B/512B + Partition Table: msdos + Disk Flags: + + Number Start End Size Type File system Flags + 1 4194kB 72.4MB 68.2MB primary fat16 boot, lba + 2 72.4MB 537MB 465MB primary ext4 + +* Use parted to resize the root partition to the max size of the device: + + .. code-block:: console + :substitutions: + + target:~$ parted /dev/|emmcdev| resizepart 2 100% + Information: You may need to update /etc/fstab. + + target:~$ parted /dev/|emmcdev| print + Model: MMC Q2J55L (sd/mmc) + Disk /dev/|emmcdev|: 7617MB + Sector size (logical/physical): 512[ 1974.191657] |emmcdev|: p1 p2 + B/512B + Partition Table: msdos + Disk Flags: + + Number Start End Size Type File system Flags + 1 4194kB 72.4MB 68.2MB primary fat16 boot, lba + 2 72.4MB 7617MB 7545MB primary ext4 + +Increasing the filesystem size can be done while it is mounted. But you can +also boot the board from an SD card and then resize the file system on the eMMC +partition while it is not mounted. + +* Resize the filesystem to a new partition size: + + .. code-block:: console + :substitutions: + + target:~$ resize2fs /dev/|emmcdev|p2 + resize2fs 1.46.1 (9-Feb-2021) + Filesystem at /dev/|emmcdev|p2 is mounted on /; on-line resizing required + [ 131.609512] EXT4-fs (|emmcdev|p2): resizing filesystem + from 454136 to 7367680 blocks + old_desc_blocks = 4, new_desc_blocks = 57 + [ 131.970278] EXT4-fs (|emmcdev|p2): resized filesystem to 7367680 + The filesystem on /dev/|emmcdev|p2 is now 7367680 (1k) blocks long + +Enable pseudo-SLC Mode +...................... + +eMMC devices use MLC memory cells +(https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared +with SLC memory cells used in NAND Flash, MLC memory cells have lower +reliability and a higher error rate at lower costs. + +If you prefer reliability over storage capacity, you can enable +the pseudo-SLC mode or SLC mode. The method used here employs the enhanced +attribute, described in the JEDEC standard, which can be set for continuous +regions of the device. The JEDEC standard does not specify the implementation +details and the guarantees of the enhanced attribute. This is left to the +chipmaker. For the Micron chips, the enhanced attribute increases the +reliability but also halves the capacity. + +.. warning:: + + When enabling the enhanced attribute on the device, all data will be lost. + +The following sequence shows how to enable the enhanced attribute. + +* First obtain the current size of the eMMC device with: + + .. code-block:: console + :substitutions: + + target:~$ parted -m /dev/|emmcdev| unit B print + + You will receive: + + .. code-block:: + :substitutions: + + BYT; + /dev/|emmcdev|:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:; + + As you can see this device has 63652757504 Byte = 60704 MiB. + +* To get the maximum size of the device after pseudo-SLC is enabled use: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep ENH_SIZE_MULT -A 1 + + which shows, for example: + + .. code-block:: + + Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + -- + Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000 + i.e. 0 KiB + + Here the maximum size is 3719168 KiB = 3632 MiB. + +* Now, you can set enhanced attribute for the whole device, e.g. 3719168 KiB, by + typing: + + .. code-block:: console + :substitutions: + + target:~$ mmc enh_area set -y 0 3719168 /dev/|emmcdev| + + You will get: + + .. code-block:: + :substitutions: + + Done setting ENH_USR area on /dev/|emmcdev| + setting OTP PARTITION_SETTING_COMPLETED! + Setting OTP PARTITION_SETTING_COMPLETED on /dev/|emmcdev| SUCCESS + Device power cycle needed for settings to take effect. + Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle + +* To ensure that the new setting has taken over, shut down the system: + + .. code-block:: console + + target:~$ poweroff + + and perform a power cycle. It is recommended that you verify the settings now. + +* First, check the value of ENH_SIZE_MULT which must be 3719168 KiB: + + .. code-block:: console + :substitutions: + + target:~$ mmc extcsd read /dev/|emmcdev| | grep ENH_SIZE_MULT -A 1 + + You should receive:: + + Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + -- + Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764 + i.e. 3719168 KiB + +* Finally, check the size of the device: + + .. code-block:: console + :substitutions: + + target:~$ parted -m /dev/|emmcdev| unit B print + BYT; + /dev/|emmcdev|:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:; + +Erasing the Device +.................. + +It is possible to erase the eMMC device directly rather than overwriting it with +zeros. The eMMC block management algorithm will erase the underlying MLC memory +cells or mark these blocks as discard. The data on the device is lost and will +be read back as zeros. + +* After booting from SD Card execute: + + .. code-block:: console + :substitutions: + + target:~$ blkdiscard -f --secure /dev/|emmcdev| + + The option --secure ensures that the command waits until the eMMC device has + erased all blocks. The -f (force) option disables all checking before erasing + and it is needed when the eMMC device contains existing partitions with data. + +.. tip:: + .. code-block:: console + :substitutions: + + target:~$ dd if=/dev/zero of=/dev/|emmcdev| conv=fsync + + also destroys all information on the device, but this command is bad for wear + leveling and takes much longer! + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n72` + +GPIOs +----- + +The |sbc| has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to |soc| pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal |soc| GPIO banks GPIO1 – GPIO5. + +The GPIOs are identified as GPIO_ (e.g. GPIO5_07). identifies the GPIO +bank and counts from 1 to 5, while stands for the GPIO within the bank. +is being counted from 0 to 31 (32 GPIOs on each bank). + +By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is: + +.. code-block:: + + Linux GPIO number: = ( - 1) * 32 + + +Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools: + +* Detecting the gpiochips on the chip: + + .. code-block:: console + + target:~$ gpiodetect + gpiochip0 [30200000.gpio] (32 lines) + gpiochip1 [30210000.gpio] (32 lines) + gpiochip2 [30220000.gpio] (32 lines) + gpiochip3 [30230000.gpio] (32 lines) + gpiochip4 [30240000.gpio] (32 lines) + +* Show detailed information about the gpiochips. Like their names, consumers, + direction, active state, and additional flags: + + .. code-block:: console + + target:~$ gpioinfo gpiochip0 + +* Read the value of a GPIO (e.g GPIO 20 from chip0): + + .. code-block:: console + + target:~$ gpioget gpiochip0 20 + +* Set the value of GPIO 20 on chip0 to 0 and exit tool: + + .. code-block:: console + + target:~$ gpioset --mode=exit gpiochip0 20=0 + +* Help text of gpioset shows possible options: + + .. code-block:: console + + target:~$ gpioset --help + Usage: gpioset [OPTIONS] = = ... + Set GPIO line values of a GPIO chip + + Options: + -h, --help: display this message and exit + -v, --version: display the version and exit + -l, --active-low: set the line active state to low + -m, --mode=[exit|wait|time|signal] (defaults to 'exit'): + tell the program what to do after setting values + -s, --sec=SEC: specify the number of seconds to wait (only valid for --mode=time) + -u, --usec=USEC: specify the number of microseconds to wait (only valid for --mode=time) + -b, --background: after setting values: detach from the controlling terminal + + Modes: + exit: set values and exit immediately + wait: set values and wait for user to press ENTER + time: set values and sleep for a specified amount of time + signal: set values and wait for SIGINT or SIGTERM + + Note: the state of a GPIO line controlled over the character device reverts to default + when the last process referencing the file descriptor representing the device file exits. + This means that it's wrong to run gpioset, have it exit and expect the line to continue + being driven high or low. It may happen if given pin is floating but it must be interpreted + as undefined behavior. + + +.. warning:: + + Some of the user IOs are used for special functions. Before using a user IO, + refer to the schematic or the hardware manual of your board to ensure that it + is not already in use. + +GPIOs via sysfs +............... + +.. warning:: + + Accessing gpios via sysfs is deprecated and we encourage to use libgpiod + instead. + +Support to access GPIOs via sysfs is not enabled by default any more. +It is only possible with manually enabling ``CONFIG_GPIO_SYSFS`` in the kernel +configuration. To make ``CONFIG_GPIO_SYSFS`` visible in menuconfig the option +``CONFIG_EXPERT`` has to be enabled first. + +You can also add this option for example to the defconfig you use in +``arch/arm64/configs/`` in the linux kernel sources. For our NXP based releases, +this could be for example ``imx8_phytec_distro.config``:: + + .. + CONFIG_EXPERT=y + CONFIG_GPIO_SYSFS=y + .. + +Otherwise you can create a new config fragment. This is described in our +`Yocto Reference Manual `_. + +LEDs +---- + +If any LEDs are connected to GPIOs, you have the possibility to access them by a +special LED driver interface instead of the general GPIO interface (section +GPIOs). You will then access them using ``/sys/class/leds/`` instead +of ``/sys/class/gpio/``. The maximum brightness of the LEDs can be read from +the ``max_brightness`` file. The brightness file will set the brightness of the LED +(taking a value from 0 up to max_brightness). Most LEDs do not have hardware +brightness support and will just be turned on by all non-zero brightness +settings. + +Below is a simple example. + +To get all available LEDs, type: + +.. code-block:: console + + target:~$ ls /sys/class/leds + mmc1::@ mmc2::@ user-led1@ user-led2@ user-led3@ + +Here the LEDs blue-mmc, green-heartbeat, and red-emmc are on the |sbc|. + +* To toggle the LEDs ON: + + .. code-block:: console + + target:~$ echo 255 > /sys/class/leds/user-led1/brightness + +* To toggle OFF: + + .. code-block:: console + + target:~$ echo 0 > /sys/class/leds/user-led1/brightness + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n216` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n105` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n201` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issues. + +.. include:: ../peripherals/eeprom.rsti + +Rescue EEPROM Data +.................. + +The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area. + +.. code-block:: console + + target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 + +.. note:: + + If you deleted both EEPROM spaces, please contact our support! + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n201` + +.. include:: ../../peripherals/rtc.rsti + :end-before: .. rtc_parameter_start_label + +DT representation for I²C RTCs: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n207` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n341` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of imx8mp-phyboard-pollux.dtsi: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n165` + +PCIe +---- + +The phyCORE-|soc| has one Mini-PCIe slot. In general, PCIe autodetects new +devices on the bus. After connecting the device and booting up the system, you +can use the command lspci to see all PCIe devices recognized. + +* Type: + + .. code-block:: console + + target:~$ lspci -v + +* You will receive: + + .. code-block:: + + 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode]) + Flags: bus master, fast devsel, latency 0, IRQ 218 + Memory at 18000000 (64-bit, non-prefetchable) [size=1M] + Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0 + I/O behind bridge: None + Memory behind bridge: 18100000-181fffff [size=1M] + Prefetchable memory behind bridge: None + [virtual] Expansion ROM at 18200000 [disabled] [size=64K] + Capabilities: [40] Power Management version 3 + Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+ + Capabilities: [70] Express Root Port (Slot-), MSI 00 + Capabilities: [100] Advanced Error Reporting + Capabilities: [148] L1 PM Substates + Kernel driver in use: dwc3-haps + + 01:00.0 Network controller: Intel Corporation WiFi Link 5100 + Subsystem: Intel Corporation WiFi Link 5100 AGN + Flags: fast devsel + Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K] + Capabilities: [c8] Power Management version 3 + Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+ + Capabilities: [e0] Express Endpoint, MSI 00 + Capabilities: [100] Advanced Error Reporting + Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e + Kernel modules: iwlwifi + +In this example, the PCIe device is the *Intel Corporation WiFi Link 5100*. + +For PCIe devices, you have to enable the correct driver in the kernel +configuration. This WLAN card, for example, is manufactured by Intel. The +option for the driver, which must be enabled, is named ``CONFIG_IWLWIFI`` and can be +found under *Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimat* in +the kernel configuration. + +* In order to activate the driver, follow the instructions from our + `Yocto Reference Manual `_. + + - The linux-imx is represented by: **virtual/kernel** + +For some devices like the WLAN card, additional binary firmware blobs are +needed. These firmware blobs have to be placed in ``/lib/firmware/`` before the +device can be used. + +* Type: + + .. code-block:: console + + host:~$ scp -r root@192.168.3.11:/lib/firmware + +* For example, if you try to bring up the network interface: + + .. code-block:: console + + target:~$ ip link set up wlp1s0 + +* You will get the following output on the serial console: + + .. code-block:: console + + [ 58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0 + [ 58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled + [ 58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0 + [ 58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready + +.. tip:: + + Some PCIe devices, e.g. the Ethernet card, may function properly even if no + firmware blob is loaded from ``/lib/firmware/`` and you received an error message + as shown in the first line of the output above. This is because some + manufacturers provide the firmware as a fallback on the card itself. In this + case, the behavior and output depend strongly on the manufacturer's firmware. + +Device Tree PCIe configuration of imx8mm-phyboard-polis.dtsi: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n277` + +Audio +----- + +Playback devices supported for |sbc| are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals. + +.. note:: + + Using the PEB-AV-10 connector for display output along HDMI as audio output + is not supported. The audio output device must match the video output device. + +To check if your soundcard driver is loaded correctly and what the device is +called, type for playback devices: + +.. code-block:: console + + target:~$ aplay -L + +Or type for recording devices: + +.. code-block:: console + + target:~$ arecord -L + +Alsamixer +......... + +To inspect the capabilities of your soundcard, call: + +.. code-block:: console + + target:~$ alsamixer + +You should see a lot of options as the audio-IC has many features you can +experiment with. It might be better to open alsamixer via ssh instead of the +serial console, as the console graphical effects are better. You have either +mono or stereo gain controls for all mix points. "MM" means the feature is muted +(both output, left & right), which can be toggled by hitting **m**. You can also +toggle by hitting '**<**' for left and '**>**' for right output. With the **tab** +key, you can switch between controls for playback and recording. + +ALSA configuration +.................. + +Our BSP comes with a ALSA configuration file ``/etc/asound.conf``. + +The ALSA configuration file can be edited as desired or deleted since it is not +required for ALSA to work properly. + +.. code-block:: console + + target:~$ vi /etc/asound.conf + +To set PEB-AV-10 as output, set *playback.pcm* from "dummy" to "pebav10": + +.. code-block:: + + [...] + + pcm.asymed { + type asym + playback.pcm "pebav10" + capture.pcm "dsnoop" + } + + [...] + +If the sound is not audible change playback devices to the software volume control +playback devices, set *playback.pcm* to the respective softvol playback device either +"softvol_hdmi" or "softvol_pebav10". Use alsamixer controls to vary the volume levels. + +.. code-block:: + + [...] + + pcm.asymed { + type asym + playback.pcm "softvol_hdmi" + capture.pcm "dsnoop" + } + + [...] + +Pulseaudio Configuration +........................ + +For applications using Pulseaudio, check for available sinks: + +.. code-block:: console + + target:~$ pactl list short sinks + 0 alsa_output.platform-snd_dummy.0.stereo-fallback module-alsa-card.c s16le 2ch 44100Hz SUSPENDED + 1 alsa_output.platform-sound-peb-av-10.stereo-fallback module-alsa-card.c s16le 2ch 44100Hz SUSPENDED + +To select PEB-AV-10, type: + +.. code-block:: console + + target:~$ pactl set-default-sink 1 + +Playback +........ + +Run speaker-test to check playback availability: + +.. code-block:: console + + target:~$ speaker-test -c 2 -t wav + +To playback simple audio streams, you can use aplay. For example to play the +ALSA test sounds: + +.. code-block:: console + + target:~$ aplay /usr/share/sounds/alsa/* + +To playback other formats like mp3 for example, you can use Gstreamer: + +.. code-block:: console + + target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3 + +Capture +....... + +``arecord`` is a command-line tool for capturing audio streams which use Line In as +the default input source. To select a different audio source you can +use ``alsamixer``. For example, switch on *Right PGA Mixer Mic3R* and *Left PGA Mixer +Mic3R* in order to capture the audio from the microphone input of the +TLV320-Codec using the 3.5mm jack. + +.. code-block:: console + + target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on + target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on + +.. code-block:: console + + target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav + +.. hint:: + + Since playback and capture share hardware interfaces, it is not possible to + use different sampling rates and formats for simultaneous playback and + capture operations. + +Device Tree Audio configuration: +:imx-dt:`overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.10.72_2.2.0-phy18#n57` + +Video +----- + +Videos with Gstreamer +..................... + +The video is installed by default in the BSP: + +.. code-block:: console + + target:~$ gst-launch-1.0 playbin uri=file:///usr/share/phytec-qtdemo/videos/caminandes.webm + +* Or: + +.. code-block:: console + + target:~$ gst-launch-1.0 -v filesrc location= \ + \! qtdemux \! h264parse \! queue \! vpudec \! waylandsink async=false enable-last-sample=false \ + qos=false sync=false + +* Or: + +.. code-block:: console + + target:~$ gplay-1.0 /usr/share/phytec-qtdemo/videos/caminandes.webm + +kmssink Plugin ID Evaluation +............................ + +The kmssink plugin needs a connector ID. To get the connector ID, you can use +the tool modetest. + +.. code-block:: console + + target:~$ modetest -c imx-drm + +The output will show something like: + +.. code-block:: + + Connectors: + id encoder status name size (mm) modes encoders + 35 34 connected LVDS-1 216x135 1 34 + modes: + index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot + #0 1280x800 59.07 1280 1380 1399 1440 800 804 808 823 70000 flags: phsync, pvsync; type: preferred, driver + props: + 1 EDID: + flags: immutable blob + blobs: + + value: + 2 DPMS: + flags: enum + enums: On=0 Standby=1 Suspend=2 Off=3 + value: 0 + 5 link-status: + flags: enum + enums: Good=0 Bad=1 + value: 0 + 6 non-desktop: + flags: immutable range + values: 0 1 + value: 0 + 4 TILE: + flags: immutable blob + blobs: + + value: + +Display +------- + +The |sbc| supports up to 4 different display outputs. Three can be used +simultaneously. The following table shows the required extensions and devicetree +overlays for the different interfaces. + +========= ======================== ====================================== +Interface Expansion devicetree overlay +========= ======================== ====================================== +HDMI |sbc| no overlay needed (enabled by default) +LVDS0 PEB-AV-10 imx8mp-phyboard-pollux-peb-av-010.dtbo + (loaded by default) +LVDS1 |sbc| disabled if PEB-AV-10 overlay is used +MIPI PEB-AV-12 (MIPI to LVDS) imx8mp-phyboard-pollux-peb-av-012.dtbo +========= ======================== ====================================== + +.. note:: + + * HDMI will not work if LVDS1 (onboard) is enabled. + * When changing Weston output, make sure to match the audio output as well. + * LVDS0 (PEB-AV-10) and LVDS1 (onboard)can not be used at the same time. + +HDMI is always enabled in the devicetree. The other interfaces can be enabled +with Device Tree Overlay. + +The default-enabled Interfaces are HDMI and LVDS0 (PEB-AV-010). We support a +10'' edt,etml1010g0dka display for the PEB-AV-10 and PEB-AV-12. + +.. note:: + + The current display driver limits the pixel clock for a display connected to + LVDS to 74.25Mhz (or a divider of it). If this does not fit your display + requirements, please contact Support for further help. + +Weston Configuration +.................... + +In order to get an output from Weston on the correct display, it still needs to +be configured correctly. This will be done at /etc/xdg/weston/weston.ini. + +Single Display +~~~~~~~~~~~~~~ + +In our BSP, the default Weston output is set to HDMI. :: + + [output] + name=HDMI-A-1 + mode=current + +.. include:: /bsp/qt5.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +Device tree description of LVDS-1 and HDMI can be found here: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n255` +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n180` + +The device tree of LVDS-0 on PEB-AV-10 can be found here: +:imx-dt:`overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.10.72_2.2.0-phy18#n132` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +The device tree description of GPIO Fan can be found here: +:imx-dt:`imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n26` + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/snvs-power-key.rsti + +NPU +--- + +The |soc| SoC contains a Neural Processing Unit up to 2.3 TOPS as an accelerator +for artificial intelligence operations. Refer to our latest phyCORE-|soc| AI Kit +Guide on the phyCORE-|soc| download section to get information about the +NPU: `L-1015e.A0 phyCORE-i.MX 8M Plus AI Kit Guide +`_ + +NXP Examples for eIQ +.................... + +NXP provides a set of machine learning examples for eIQ using Python3. To add a +pre-configured machine learning package group, add to your local.conf and build +your BSP:: + + IMAGE_INSTALL_append = " packagegroup-imx-ml python3-pip python3-requests opencv" + +This will require about 1GB of additional space on the SD Card. Instructions +on how to install and use the NXP examples can be found at +https://community.nxp.com/t5/Blogs/PyeIQ-3-x-Release-User-Guide/ba-p/1305998. + +.. hint:: + + The installation of the eiq examples with pip3 requires an internet + connection. + +.. note:: + + On some Ubuntu 20.04 hosts, cmake uses the host's Python 3 instead of Python + 3.7 from Yocto when building python3-pybind11. (see + https://community.nxp.com/t5/i-MX-Processors/Yocto-L5-4-70-2-3-0-build-image-failed/m-p/1219619) + + As a workaround edit, the python3-pybind11 recipe by:: + + $ devtool edit-recipe python3-pybind11 + + and add to the file:: + + EXTRA_OECMAKE += "-DPYTHON_EXECUTABLE=${RECIPE_SYSROOT_NATIVE}/usr/bin/python3-native/python3.7" + +.. include:: ../peripherals/isp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +Reading the registers using ``/dev/mem`` will cause the system to hang unless the +*ocotp_root_clk* is enabled. To enable this clock permanent, add to the device +tree: + +.. code-block:: + + &clk { + init-on-array = ; + }; + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti + +.. +---------------------------------------------------------------------------+ +.. BSP EXTENSIONS +.. +---------------------------------------------------------------------------+ + +BSP Extensions +============== + +Chromium +-------- + +Our BSP for the |sbc|-|soc| supports Chromium. You can include it in the +|yocto-imagename| with only a few steps. + +Adding Chromium to Your local.conf +.................................. + +To include Chromium you have to add the following line into your local.conf. You +can find it in /build/conf/local.conf. This adds Chromium to your +next image build. :: + + IMAGE_INSTALL_append = " chromium-ozone-wayland" + +.. note:: + + Compiling Chromium takes a long time. + +Get Chromium Running on the Target +.................................. + +To run Chromium, it needs a few arguments to use the hardware graphics +acceleration:: + + target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox + +If you want to start Chromium via SSH, you must first define the display on +which Chromium will run. For example:: + + target$ DISPLAY=:0 + +After you have defined this, you can start it via virtual terminal on Weston as +shown above. diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd23.1.0.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd23.1.0.rst.txt new file mode 100644 index 000000000..78a61b416 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd23.1.0.rst.txt @@ -0,0 +1,1798 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MP-PD23.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD23.1.0/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp +.. _`static-pdf-dl`: ../../../_static/imx8mp-pd23.1.0.pdf + +.. IMX8(MP) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mp/phycore-imx8mp.c?h=v2022.04_2.2.2-phy5#n149 + + +.. General Substitutions +.. |kit| replace:: **phyCORE-i.MX8M Plus Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Pollux +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |bluetooth-uart| replace:: UART3 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx8mp +.. |kernel-tag| replace:: v5.15.71_2.2.2-phy3 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-defconfig| replace:: phycore-imx8mp_defconfig +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MP +.. |u-boot-tag| replace:: v2022.04_2.2.2-phy5 + + +.. RAUC +.. |rauc-manual| replace:: L-1006e.A5 RAUC Update & Device Management Manual +.. _rauc-manual: https://www.phytec.de/cdocuments/?doc=fgByJg + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-phyboard-pollux-rdk +.. |dt-som| replace:: imx8mp-phycore-som +.. |dtbo-rpmsg| replace:: imx8mp-phycore-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mp-phyboard-pollux-peb-av-010.dtbo + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: :imx-dt:`imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n50` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`kirkstone` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: kirkstone +.. |yocto-distro| replace:: ampliphy-vendor-xwayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: wic +.. |yocto-machinename| replace:: phyboard-pollux-imx8mp-3 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MP-PD23.1.0 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MP-PD23.1.y +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (kirkstone) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 4.0.13 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n150`. +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. +.. |lvds-display-adapters| replace:: PEB-AV-10 and PEB-AV-012 +.. |weston-hdmi-mode| replace:: current + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Yocto Manual | Kirkstone | ++-----------------------+----------------------+ +| Release Date | 2024/01/10 | ++-----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================ ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================ ========== +|yocto-manifestname| Major 2023/12/12 Released +==================== ================ ================ ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mp-pd23.1.0-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd23.1.0-getting-started: + +Getting Started +=============== + +The |kit| is shipped with a pre-flashed SD card. It contains the +|yocto-imagename| and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +`PHYTEC download server `_. This chapter explains how to flash a BSP +image to SD card and how to start the board. + +There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool ``dd``. An +alternative way is to use PHYTEC's system initialization program called +`partup `_, which makes it especially easy to +format more complex systems. You can get `prebuilt Linux binaries of partup +`__ from its release page. Also read +`partup's README `__ for installation +instructions. + +Get the Image +------------- + +The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using ``dd``, can be downloaded from the `PHYTEC download server +`_. + +Get either the partup package or the WIC image from the download server: + +.. code-block:: console + :substitutions: + + host:~$ wget |link-partup-package| + host:~$ wget |link-image| + +.. note:: + For eMMC, more complex partitioning schemes or even just large images, we + recommend using the partup package, as it is faster in writing than ``dd`` + and allows for a more flexible configuration of the target flash device. + +Write the Image to SD Card +-------------------------- + +.. warning:: + To create your bootable SD card, you must have root privileges on your Linux + host PC. Be very careful when specifying the destination device! All files + on the selected device will be erased immediately without any further query! + + Selecting the wrong device may result in **data loss** and e.g. could erase + your currently running system on your host PC! + +Finding the Correct Device +.......................... + +To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card. + +#. In order to get the correct device name, remove your SD card and + execute: + + .. code-block:: console + + host:~$ lsblk + +#. Now insert your SD card and execute the command again: + + .. code-block:: console + + host:~$ lsblk + +#. Compare the two outputs to find the new device names listed in the second + output. These are the device names of the SD card (device and partitions if + the SD card was formatted). +#. In order to verify the device names being found, execute the command + ``sudo dmesg``. Within the last lines of its output, you should also find the + device names, e.g. ``/dev/sde`` or ``/dev/mmcblk0`` (depending on your + system). + +Alternatively, you may use a graphical program of your choice, like `GNOME Disks +`_ or `KDE Partition Manager +`_, to find the correct device. + +Now that you have the correct device name, e.g. ``/dev/sde``, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. ``/dev/sde1``) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption. + +Unmount all those partitions, e.g.: + +.. code-block:: console + + host:~$ sudo umount /dev/sde1 + host:~$ sudo umount /dev/sde2 + +Now, the SD card is ready to be flashed with an image, using either ``partup``, +``dd`` or ``bmap-tools``. + +Using partup +............ + +Writing to an SD card with partup is done in a single command: + +.. code-block:: console + :substitutions: + + host:~$ sudo partup install |yocto-imagename|-|yocto-machinename|.partup /dev/ + +Make sure to replace with your actual device name found previously. + +Further usage of partup is explained at its `official documentation website +`__. + +.. note:: + *partup* has the advantage of allowing to clear specific raw areas in the + MMC user area, which is used in our provided partup packages to erase any + existing U-Boot environments. This is a known issue *bmaptool* does not + solve, as mentioned below. + + Another key advantage of partup over other flashing tools is that it allows + configuring MMC specific parts, like writing to eMMC boot partitions, without + the need to call multiple other commands when writing. + +Using bmap-tools +................ + +An alternative and also fast way to prepare an SD card is using +`bmap-tools `_. Yocto +automatically creates a block map file (``-.wic.bmap``) for +the WIC image that describes the image content and includes checksums for data +integrity. *bmaptool* is packaged by various Linux distributions. For +Debian-based systems install it by issuing: + +.. code-block:: console + + host:~$ sudo apt install bmap-tools + +Flash a WIC image to SD card by calling: + +.. code-block:: console + :substitutions: + + host:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/ + +Replace with your actual SD card's device name found previously, +and make sure to place the file ``-.wic.bmap`` alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip. + +.. warning:: + *bmaptool* only overwrites the areas of an SD card where image data is + located. This means that a previously written U-Boot environment may still be + available after writing the image. + +Using ``dd`` +............ + +After having unmounted all SD card's partitions, you can create your bootable SD card. + +Some PHYTEC BSPs produce uncompressed images (with filename-extension \*.wic), +and some others produce compressed images (with filename-extension \*.wic.xz). + +To flash an uncompressed images (\*.wic) use command below: + +.. code-block:: console + :substitutions: + + host:~$ sudo dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/ bs=1M conv=fsync status=progress + +Or to flash a compressed images (\*.wic.xz) use that command: + +.. code-block:: console + :substitutions: + + host:~$ xzcat |yocto-imagename|-|yocto-machinename|.wic.xz | sudo dd of=/dev/ bs=1M conv=fsync status=progress + +Again, make sure to replace with your actual device name found +previously. + +The parameter ``conv=fsync`` forces a sync operation on the device before +``dd`` returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter ``status=progress`` will print out +information on how much data is and still has to be copied until it is +finished. + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-pd23.1.0-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-phyboard-pollux-rdk*.dtb**: Kernel device tree file +* **imx8mp-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.wic**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-pd23.1.0-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see |ref-setup-network-host|. + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **eMMC**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load your image via network to RAM: + +* when using dhcp + + .. code-block:: + :substitutions: + + u-boot=> dhcp |yocto-imagename|-|yocto-machinename|.wic + BOOTP broadcast 1 + DHCP client bound to address 192.168.3.1 (1 ms) + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.1 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* when using a static ip address (serverip and ipaddr must be set + additionally). + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename '|yocto-imagename|-|yocto-machinename|.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Take a compressed or uncompressed image with accompanying block map on the host +and send it with ssh through the network to the eMMC of the target with a +one-line command: + +.. code-block:: console + :substitutions: + + target:~$ scp @192.168.3.10:/srv/tftp/|yocto-imagename|-|yocto-machinename|.wic.* /tmp && bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls /srv/tftp + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +Send the image with the ``bmaptool`` command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ scp /srv/tftp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2" + +Flash eMMC U-Boot image via Network from running U-Boot +....................................................... + +Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB stick +......................... + +Flash eMMC from USB stick in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. + +These steps will show how to update the eMMC via a USB device. Configure the +|ref-bootswitch| to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied WIC image to the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} *.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the |ref-bootswitch| to SD Card. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ ls /mnt + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy /mnt/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + + .. tip:: + + Before this will work, you need to configure the |ref-bootswitch| to + **eMMC**. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see |ref-format-sd|. + +Alternatively, flash a partup package to the SD card, as described in +|ref-getting-started|. This will ensure the full space of the SD card is used. + +Flash eMMC from SD card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. If the + image file is too large use the `Updating eMMC from SD card in + Linux on Target` subsection. + +* Flash an SD card with a working image and create a third ext4 partition. Copy + the WIC image (for example |yocto-imagename|.wic) to this + partition. +* Configure the |ref-bootswitch| to SD Card and insert the SD Card. +* Power on the board and stop in U-Boot. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> ext4load mmc 1:3 ${loadaddr} |yocto-imagename|-|yocto-machinename|.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev to eMMC: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + +* Flash your WIC image (for example |yocto-imagename|.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. + + .. code-block:: + + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the |ref-bootswitch| to eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card. + +* Show your saved partup package or WIC image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.partup + |yocto-imagename|-|yocto-machinename|.wic + |yocto-imagename|-|yocto-machinename|.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition) using `partup`_: + + .. code-block:: console + :substitutions: + + target:~$ partup install |yocto-imagename|-|yocto-machinename|.partup /dev/mmcblk2 + + Flashing the partup package has the advantage of using the full capacity of + the eMMC device, adjusting partitions accordingly. + + .. note:: + + Alternatively, ``bmaptool`` may be used instead: + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + + Keep in mind that the root partition does not make use of the full space when + flashing with ``bmaptool``. + +* After a complete write, your board can boot from eMMC. + + .. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to eMMC. + +Flash SPI NOR Flash +------------------- + +The |som| modules are optionally equipped with SPI NOR Flash. To boot from SPI +Flash, set |ref-bootswitch| to **SPI NOR**. The SPI Flash is usually quite small. +The phyBOARD-Pollux-i.MX8MP kit only has 32MB SPI NOR flash populated. Only the +bootloader and the environment can be stored. The kernel, device tree, and file +system are taken from eMMC by default. + +The SPI NOR flash partition table is defined in the U-Boot environment. It can +be printed with: + +.. code-block:: + + u-boot=> printenv mtdparts + mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none) + +Flash SPI NOR Flash from Network +................................ + +The SPI NOR can contain the bootloader and environment to boot from. The arm64 +kernel can not decompress itself, the image size extends the SPI NOR flash +populated on the phyCORE-|soc|. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Flash SPI NOR from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Similar to updating the eMMC over a network, be sure to set up the development +host correctly. The IP needs to be set to 192.168.3.10, the netmask to +255.255.255.0, and a TFTP server needs to be available. Before reading and +writing is possible, the SPI NOR flash needs to be probed: + +.. code-block:: + + u-boot=> sf probe + SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB + +* A specially formatted U-Boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image over tftp, erase and write the + bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + device 0 offset 0x0, size 0x1c0b20 + 1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +Flash SPI NOR from Network in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the image from the host to the target: + + .. code-block:: console + :substitutions: + + host:~$ scp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root + +* Find the number of blocks to erase of the U-boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the U-Boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +Flash SPI NOR Flash from SD Card +................................ + +The bootloader on SPI NOR flash can be also flashed with SD Card. + +Flash SPI NOR from SD Card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the first partition + on the SD Card. + +* Before reading and writing are possible, the SPI-NOR flash + needs to be probed: + + .. code-block:: + + u-boot=> sf probe + SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB + +* A specially formatted U-boot image for the SPI NOR flash is used. Ensure you + use the correct image file. Load the image from the SD Card, erase and write + the bootloader to the flash: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi + u-boot=> sf update ${loadaddr} 0 ${filesize} + +* Erase the environment partition as well. This way, the environment can be + written after booting from SPI NOR flash: + + .. code-block:: + + u-boot=> sf erase 0x400000 0x100000 + +Flash SPI NOR from SD Card in kernel on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Copy the SPI NOR flash U-boot image + imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi to the first partition + on the SD Card. + +* Mount the SD Card: + + .. code-block:: console + :substitutions: + + target:~$ mount /dev/mmcblk1p1 /mnt + +* Find the number of blocks to erase of the U-Boot partition: + + .. code-block:: console + + target:~$ mtdinfo /dev/mtd0 + mtd0 + Name: u-boot + Type: nor + Eraseblock size: 65536 bytes, 64.0 KiB + Amount of eraseblocks: 60 (3932160 bytes, 3.7 MiB) + Minimum input/output unit size: 1 byte + Sub-page size: 1 byte + Character device major/minor: 90:0 + Bad blocks are allowed: false + Device is writable: true + +* Erase the u-boot partition and flash it: + + .. code-block:: console + :substitutions: + + target:~$ flash_erase /dev/mtd0 0x0 60 + target:~$ flashcp /mnt/imx-boot-|yocto-machinename|-fspi.bin-flash_evk_flexspi /dev/mtd0 + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: |rauc-manual|_. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd23.1.0-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + +.. _imx8mp-pd23.1.0-development-build-uboot: +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + +Starting with PD23.1.0 release, the phyCORE-|soc| SoMs with revision 1549.3 and +newer also support 2GHz RAM timings. These will be enabled for supported boards +automatically, but they can also be enabled or disabled manually. + +Edit the file configs/phycore-|kernel-socname|\_defconfig. +The fixed RAM size with 2GHz timings will be used: + +.. code-block:: kconfig + + CONFIG_TARGET_PHYCORE_IMX8MP=y + CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y + # CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y + # CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y + # CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y + CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y + +Choose the correct RAM size as populated on the board and uncomment the line +for this ram size. When not specifying the +``CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS`` option, the 1.5GHz timings will +be chosen by default. After saving the changes, follow the remaining steps from +|ref-build-uboot|. + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mp-pd23.1.0-format-sd: + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd23.1.0-device-tree: + +Device Tree (DT) +================ + +Introduction +------------ + +The following text briefly describes the Device Tree and can be found in +the Linux kernel Documentation +(https://docs.kernel.org/devicetree/usage-model.html) + +*"The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data +structure and language for describing hardware. More specifically, it is a +description of hardware that is readable by an operating system so that the +operating system doesn't need to hard code details of the machine."* + +The kernel documentation is a really good source for a DT introduction. An +overview of the device tree data format can be found on the device tree usage +page at `devicetree.org `_. + +PHYTEC |soc| BSP Device Tree Concept +------------------------------------ + +The following sections explain some rules PHYTEC has defined on how to set up +device trees for our |soc| SoC-based boards. + +Device Tree Structure +..................... + +* *Module.dtsi* - Module includes all devices mounted on the SoM, such as PMIC + and RAM. +* *Board.dts* - include the module dtsi file. Devices that come from the |soc| + SoC but are just routed down to the carrier board and used there are included + in this dts. +* *Overlay.dtso* - enable/disable features depending on optional hardware that + may be mounted or missing on SoM or baseboard (e.g SPI flash or PEB-AV-10) + +From the root directory of the Linux Kernel our devicetree files for |socfamily| +platforms can be found in ``arch/arm64/boot/dts/freescale/``. + +Device Tree Overlay +................... + +Device Tree overlays are device tree fragments that can be merged into a device +tree during boot time. These are for example hardware descriptions of an +expansion board. They are instead of being added to the device tree as an extra +include, now applied as an overlay. They also may only contain setting the +status of a node depending on if it is mounted or not. The device tree overlays +are placed next to the other device tree files in our Linux kernel repository in +the subfolder ``arch/arm64/boot/dts/freescale/overlays``. + +Available overlays for |yocto-machinename|.conf are: + +.. Add overlay files in leaf file + +:: + + imx8mp-isi-csi1.dtbo + imx8mp-isi-csi2.dtbo + imx8mp-isp-csi1.dtbo + imx8mp-isp-csi2.dtbo + imx8mp-phyboard-pollux-peb-av-010.dtbo + imx8mp-phyboard-pollux-peb-av-012.dtbo + imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + imx8mp-phycore-no-eth.dtbo + imx8mp-phycore-no-rtc.dtbo + imx8mp-phycore-no-spiflash.dtbo + imx8mp-phycore-rpmsg.dtbo + imx8mp-vm016-csi1.dtbo + imx8mp-vm016-csi1-fpdlink.dtbo + imx8mp-vm016-csi2.dtbo + imx8mp-vm016-csi2-fpdlink.dtbo + imx8mp-vm017-csi1.dtbo + imx8mp-vm017-csi1-fpdlink.dtbo + imx8mp-vm017-csi2.dtbo + imx8mp-vm017-csi2-fpdlink.dtbo + +.. _imx8mp-pd23.1.0-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x140 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x140 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +The device tree representation for UART1 pinmuxing: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n536` + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti +.. include:: /bsp/peripherals/rs485-fullduplex.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n341` + +.. _imx8mp-pd23.1.0-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + +WLAN +.... + +WLAN and Bluetooth on the |sbc| are provided by the PEB-WLBT-05 expansion card. +The PEB-WLBT-05 for |sbc| Quickstart Guide shows you how to install the +PEB-WLBT-05. + +.. tip:: + + With the BSP Version PD22.1 and newer, the PEB-WLBT-05 overlay needs to be activated first, + otherwise the PEB-WLBT-05 won't be recognized. + + .. code-block:: console + + target:~$ vi /boot/bootenv.txt + + Afterwards the bootenv.txt file should look like this (it can also contain other devicetree + overlays!): + + .. code-block:: + + overlays=imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + + The changes will be applied after a reboot: + + .. code-block:: console + + target:~$ reboot + + For further information about devicetree overlays, read the |ref-dt| chapter. + +For WLAN and Bluetooth support, we use the Sterling-LWB module from LSR. This +module supports 2,4 GHz bandwidth and can be run in several modes, like client +mode, Access Point (AP) mode using WEP, WPA, WPA2 encryption, and more. More +information about the module can be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First set the correct regulatory domain for your country: + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see: + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +Set up the wireless interface: + +.. code-block:: console + + target:~$ ip link + target:~$ ip link set up dev wlan0 + +Now you can scan for available networks: + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for WEP, WPA, and WPA2 called wpa_supplicant for an encrypted connection. + +To do so, add the network-credentials to the file ``/etc/wpa_supplicant.conf``: + +.. code-block:: + + country=DE + network={ + ssid="" + proto=WPA2 + psk="" + } + +Now a connection can be established: + +.. code-block:: console + + target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B + +This should result in the following output: + +.. code-block:: + + ... + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section `Changing the Network Configuration` in the |yocto-ref-manual|. + +First, create the directory: + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +Then add the following configuration snippet in ``/etc/systemd/network/10-wlan0.network``: + +.. code-block:: + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +Now, restart the network daemon so that the configuration takes effect: + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Bluetooth +......... + +Bluetooth is supported on |sbc| with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section. + +Bluetooth is connected to |bluetooth-uart| interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually: + +.. code-block:: console + + target:~$ hciconfig hci0 up + + target:~$ hciconfig -a + + hci0: Type: Primary Bus: UART + BD Address: 00:25:CA:2F:39:96 ACL MTU: 1021:8 SCO MTU: 64:1 + UP RUNNING PSCAN + RX bytes:1392 acl:0 sco:0 events:76 errors:0 + TX bytes:1198 acl:0 sco:0 commands:76 errors:0 + ... + +Now you can scan your environment for visible Bluetooth devices. Bluetooth is +not visible during a default startup. + +.. code-block:: console + + target:~$ hcitool scan + Scanning ... + XX:XX:XX:XX:XX:XX + +Visibility +~~~~~~~~~~ + +To activate visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 piscan + +To disable visibility: + +.. code-block:: console + + target:~$ hciconfig hci0 noscan + +Connect +~~~~~~~ + +.. code-block:: console + + target:~$ bluetoothctl + [bluetooth]# discoverable on + Changing discoverable on succeeded + [bluetooth]# pairable on + Changing pairable on succeeded + [bluetooth]# agent on + Agent registered + [bluetooth]# default-agent + Default agent request successful + [bluetooth]# scan on + [NEW] Device XX:XX:XX:XX:XX:XX + [bluetooth]# connect XX:XX:XX:XX:XX:XX + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n380` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n223` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n76` + +GPIOs +----- + +The |sbc| has a set of pins especially dedicated to user I/Os. Those pins are +connected directly to |soc| pins and are muxed as GPIOs. They are directly +usable in Linux userspace. The processor has organized its GPIOs into five banks +of 32 GPIOs each (GPIO1 – GPIO5) +GPIOs. gpiochip0, gpiochip32, gpiochip64, gpiochip96, and gpiochip128 are +the sysfs representation of these internal |soc| GPIO banks GPIO1 – GPIO5. + +The GPIOs are identified as GPIO_ (e.g. GPIO5_07). identifies the GPIO +bank and counts from 1 to 5, while stands for the GPIO within the bank. +is being counted from 0 to 31 (32 GPIOs on each bank). + +By contrast, the Linux kernel uses a single integer to enumerate all available +GPIOs in the system. The formula to calculate the right number is: + +.. code-block:: + + Linux GPIO number: = ( - 1) * 32 + + +Accessing GPIOs from userspace will be done using the libgpiod. It provides a +library and tools for interacting with the Linux GPIO character device. Examples +of some usages of various tools: + +* Detecting the gpiochips on the chip: + + .. code-block:: console + + target:~$ gpiodetect + gpiochip0 [30200000.gpio] (32 lines) + gpiochip1 [30210000.gpio] (32 lines) + gpiochip2 [30220000.gpio] (32 lines) + gpiochip3 [30230000.gpio] (32 lines) + gpiochip4 [30240000.gpio] (32 lines) + +* Show detailed information about the gpiochips. Like their names, consumers, + direction, active state, and additional flags: + + .. code-block:: console + + target:~$ gpioinfo gpiochip0 + +* Read the value of a GPIO (e.g GPIO 20 from chip0): + + .. code-block:: console + + target:~$ gpioget gpiochip0 20 + +* Set the value of GPIO 20 on chip0 to 0 and exit tool: + + .. code-block:: console + + target:~$ gpioset --mode=exit gpiochip0 20=0 + +* Help text of gpioset shows possible options: + + .. code-block:: console + + target:~$ gpioset --help + Usage: gpioset [OPTIONS] = = ... + Set GPIO line values of a GPIO chip + + Options: + -h, --help: display this message and exit + -v, --version: display the version and exit + -l, --active-low: set the line active state to low + -m, --mode=[exit|wait|time|signal] (defaults to 'exit'): + tell the program what to do after setting values + -s, --sec=SEC: specify the number of seconds to wait (only valid for --mode=time) + -u, --usec=USEC: specify the number of microseconds to wait (only valid for --mode=time) + -b, --background: after setting values: detach from the controlling terminal + + Modes: + exit: set values and exit immediately + wait: set values and wait for user to press ENTER + time: set values and sleep for a specified amount of time + signal: set values and wait for SIGINT or SIGTERM + + Note: the state of a GPIO line controlled over the character device reverts to default + when the last process referencing the file descriptor representing the device file exits. + This means that it's wrong to run gpioset, have it exit and expect the line to continue + being driven high or low. It may happen if given pin is floating but it must be interpreted + as undefined behavior. + + +.. warning:: + + Some of the user IOs are used for special functions. Before using a user IO, + refer to the schematic or the hardware manual of your board to ensure that it + is not already in use. + +.. include:: ../peripherals/gpios.rsti + :start-after: .. gpios-via-sysfs-marker + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n229` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n110` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n212` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) and the ID-page (bus: I2C-0 +address: 0x59) can be accessed via the sysfs interface in Linux. The first +256 bytes of the main EEPROM and the ID-page are used for board detection and +must not be overwritten. Overwriting reserved spaces will result in boot issue. + +.. include:: ../peripherals/eeprom.rsti + +Rescue EEPROM Data +.................. + +The hardware introspection data is pre-written on both EEPROM data spaces. If +you have accidentally deleted or overwritten the normal area, you can copy the +hardware introspection from the ID area to the normal area. + +.. code-block:: console + + target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 + +.. note:: + + If you deleted both EEPROM spaces, please contact our support! + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n199` + +.. include:: /bsp/peripherals/rtc.rsti + :end-before: .. rtc_parameter_start_label + +RTC Parameters +.............. + +RTCs have a few abilities which can be read/set with the help of ``hwclock`` +tool. + +* We can check RTC supported features with: + + .. code-block:: console + + target:~$ hwclock --param-get features + The RTC parameter 0x0 is set to 0x11. + + What this value means is encoded in kernel, each set bit translates to: + + .. code-block:: + + #define RTC_FEATURE_ALARM 0 + #define RTC_FEATURE_ALARM_RES_MINUTE 1 + #define RTC_FEATURE_NEED_WEEK_DAY 2 + #define RTC_FEATURE_ALARM_RES_2S 3 + #define RTC_FEATURE_UPDATE_INTERRUPT 4 + #define RTC_FEATURE_CORRECTION 5 + #define RTC_FEATURE_BACKUP_SWITCH_MODE 6 + #define RTC_FEATURE_CNT 7 + +* We can check RTC BSM (Backup Switchover Mode) with: + + .. code-block:: console + + target:~$ hwclock --param-get bsm + The RTC parameter 0x2 is set to 0x1. + +* We can set RTC BSM with: + + .. code-block:: console + + target:~$ hwclock --param-set bsm=0x2 + The RTC parameter 0x2 will be set to 0x2. + + What BSM values mean translates to these values: + + .. code-block:: + + #define RTC_BSM_DISABLED 0 + #define RTC_BSM_DIRECT 1 + #define RTC_BSM_LEVEL 2 + #define RTC_BSM_STANDBY 3 + + .. tip:: + You should set BSM mode to DSM or LSM for RTC to switch to backup power + source when the initial power source is not available. Check **RV-3028** RTC + datasheet to read what LSM (Level Switching Mode) and DSM (Direct Switching + Mode) actually mean. + +DT representation for I²C RTCs: +:imx-dt:`imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n207` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n351` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n175` + +.. include:: /bsp/peripherals/pcie.rsti + +Device Tree PCIe configuration of |dt-carrierboard|.dts: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n287` + +Audio +----- + +Playback devices supported for |sbc| are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals. + +.. note:: + + Using the PEB-AV-10 connector for display output along HDMI as audio output + is not supported. The audio output device must match the video output device. + +.. include:: /bsp/peripherals/audio.rsti + +Device Tree Audio configuration: +:imx-dt:`overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.15.71_2.2.2-phy3#n58` + +.. include:: /bsp/peripherals/video.rsti + +.. include:: display.rsti + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +Device tree description of LVDS-1 and HDMI can be found here: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n264` +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n191` + +The device tree of LVDS-0 on PEB-AV-10 can be found here: +:imx-dt:`overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.15.71_2.2.2-phy3#n133` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +The device tree description of GPIO Fan can be found here: +:imx-dt:`imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n33` + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/snvs-power-key.rsti + +.. include:: ../peripherals/npu.rsti + +.. include:: ../peripherals/isp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti + +.. +---------------------------------------------------------------------------+ +.. BSP EXTENSIONS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/bsp-extensions.rsti diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd24.1.0_nxp.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd24.1.0_nxp.rst.txt new file mode 100644 index 000000000..66d5067f9 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd24.1.0_nxp.rst.txt @@ -0,0 +1,589 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX8MP-PD24.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/sdk/ampliphy-vendor-xwayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/ +.. |link-bsp-images| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp +.. _`static-pdf-dl`: ../../../_static/imx8mp-pd24.1.0_nxp.pdf + +.. IMX8(MP) specific +.. _overlaycallback: https://git.phytec.de/u-boot-imx/tree/board/phytec/phycore_imx8mp/phycore-imx8mp.c?h=v2024.04-2.0.0-phy7#n177 + + +.. General Substitutions +.. |doc-id| replace:: PD24.1.0 NXP +.. |kit| replace:: **phyCORE-i.MX8M Plus Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Pollux +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |bluetooth-uart| replace:: UART3 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx8_phytec_defconfig +.. |kernel-recipe-path| replace:: meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb +.. |kernel-repo-name| replace:: linux-phytec-imx +.. |kernel-repo-url| replace:: https://github.com/phytec/linux-phytec-imx +.. |kernel-socname| replace:: imx8mp +.. |kernel-tag| replace:: v6.6.23-2.0.0-phy10 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-defconfig| replace:: phycore-imx8mp_defconfig +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx +.. |emmcdev-uboot| replace:: mmc 2 +.. |sdcarddev-uboot| replace:: mmc 1 + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MP +.. |u-boot-tag| replace:: v2024.04_2.0.0-phy7 + + +.. RAUC +.. |rauc-manual| replace:: L-1006e.A6 RAUC Update & Device Management Manual +.. _rauc-manual: https://www.phytec.de/cdocuments/?doc=F4DiM + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-phyboard-pollux-rdk +.. |dt-som| replace:: imx8mp-phycore-som +.. |dtbo-rpmsg| replace:: conf-imx8mp-phycore-rpmsg.dtbo +.. |dtbo-peb-av-10| replace:: imx8mp-phyboard-pollux-peb-av-10.dtbo + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: :linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L50` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`scarthgap` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: scarthgap +.. |yocto-distro| replace:: ampliphy-vendor-xwayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: rootfs.wic.xz +.. |yocto-machinename| replace:: phyboard-pollux-imx8mp-3 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX8MP-PD24.1.0 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-NXP-i.MX8MP-PD24.1.y +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (scarthgap) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 5.0.x +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L179`. +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` +.. |lvds-display-adapters| replace:: PEB-AV-10 +.. |weston-hdmi-mode| replace:: preferred + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |doc-id| |soc| BSP | | +| Manual | | ++-----------------------+----------------------+ +| Document Title | |doc-id| |soc| BSP | +| | Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Article Number | |doc-id| | ++-----------------------+----------------------+ +| Yocto Manual | Scarthgap | ++-----------------------+----------------------+ +| Release Date | 2024/11/08 | ++-----------------------+----------------------+ +| Is Branch of | |doc-id| |soc| BSP | +| | Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +============================== ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +============================== ================ ================= ========== +BSP-Yocto-NXP-i.MX8MP-PD24.1.0 Major 2024/11/06 Released +============================== ================ ================= ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mp-pd24.1.0_nxp-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.0_nxp-getting-started: +.. include:: /bsp/getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-pd24.1.0_nxp-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **fitImage**: Linux kernel FIT image +* **fitImage-its\*.its** +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-phyboard-pollux-rdk*.dtb**: Kernel device tree file +* **imx8mp-phy*.dtbo**: Kernel device tree overlay files +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.rootfs.wic.xz**: compressed SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-pd24.1.0_nxp-bootswitch: +.. include:: bootmode-switch.rsti + +.. include:: ../installing-os.rsti + +.. include:: ../efi.rsti +.. include:: /bsp/installing-distro-efi.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.0_nxp-development: + +Development +=========== + +Starting with this release, the boot behaviour in U-Boot changes. Before, kernel +and device tree came as separate blobs. Now, both will be included in a single +FIT image blob. Further, the logic for booting the PHYTEC ampliphy distributions +is moved to a boot script which itself is part of a separate FIT image blob. +To revert to the old style of booting, you may do + +.. code-block:: console + + run legacyboot + +.. note:: + + This way of booting is deprecated and will be removed in the next release. + By default, booting via this command will return an error as kernel and + device tree are missing in the boot partition. + +.. include:: ../../imx-common/development/standalone_build_preface.rsti +.. _imx8mp-pd24.1.0_nxp-development-build-uboot: +.. include:: ../../imx-common/development/standalone_build_u-boot_binman.rsti +.. include:: development/uboot-standalone-fixed-ram-config.rsti +.. include:: ../development/kernel-standalone.rsti +.. include:: ../../imx-common/development/uuu.rsti + +.. include:: /bsp/imx-common/development/host_network_setup.rsti +.. include:: /bsp/imx8/development/netboot.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti + +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mp-pd24.1.0_nxp-format-sd: + +.. include:: /bsp/imx-common/development/format_sd-card.rsti + +.. include:: /bsp/imx8/development/legacy_boot_deprecated.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.0_nxp-device-tree: +.. include:: /bsp/device-tree.rsti + +.. code-block:: + :substitutions: + + imx8mp-isi-csi1.dtbo + imx8mp-isi-csi2.dtbo + imx8mp-isp-csi1.dtbo + imx8mp-isp-csi2.dtbo + |dtbo-peb-av-10| + imx8mp-phyboard-pollux-peb-wlbt-05.dtbo + imx8mp-phycore-no-eth.dtbo + imx8mp-phycore-no-rtc.dtbo + imx8mp-phycore-no-spiflash.dtbo + imx8mp-phycore-rpmsg.dtbo + imx8mp-vm016-csi1.dtbo + imx8mp-vm016-csi1-fpdlink.dtbo + imx8mp-vm016-csi2.dtbo + imx8mp-vm016-csi2-fpdlink.dtbo + imx8mp-vm017-csi1.dtbo + imx8mp-vm017-csi1-fpdlink.dtbo + imx8mp-vm017-csi2.dtbo + imx8mp-vm017-csi2-fpdlink.dtbo + +.. _imx8mp-pd24.1.0_nxp-ubootexternalenv: +.. include:: ../../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x140 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x140 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +The device tree representation for UART1 pinmuxing: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L373` + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti +.. include:: /bsp/peripherals/rs485-fullduplex.rsti + +The device tree representation for RS232 and RS485: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L412` + +.. _imx8mp-pd24.1.0_nxp-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + +.. include:: wireless-network.rsti + +.. include:: ../../peripherals/wireless-network.rsti + :end-before: .. bluetooth_chapter_start_label + +Bluetooth is supported on |sbc| with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section. + +.. include:: ../../peripherals/wireless-network.rsti + :start-after: .. bluetooth_chapter_start_label + +.. note:: + + If the connection fails with the error message: "Failed to connect: + org.bluez.Error.Failed" try restarting PulseAudio with: + + .. code-block:: console + + target:~$ pulseaudio --start + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L422` + +DT configuration for the eMMC interface can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L214` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + +The definition of the SPI master node in the device tree can be found here: + +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L76` + +.. include:: ../peripherals/gpios.rsti + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L255` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L113` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L239` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues. + +.. note:: + + If you deleted reserved EEPROM spaces, please contact our support! + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L201` + +.. include:: ../../peripherals/rtc.rsti + +DT representation for I²C RTCs: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L208` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L380` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L203` + +.. include:: /bsp/peripherals/pcie.rsti + +Device Tree PCIe configuration of |dt-carrierboard|.dts: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L345` + +Audio +----- + +Playback devices supported for |sbc| are HDMI and the TI TLV320AIC3007 audio +codec on the PEB-AV-10 connector. On the AV-Connector there is a 3.5mm headset +jack with OMTP-standard and an 8-pin header. The 8-pin header contains a mono +speaker, headphones, and line in signals. + +.. note:: + + Using the PEB-AV-10 connector for display output along HDMI as audio output + is not supported. The audio output device must match the video output device. + +.. include:: /bsp/peripherals/audio.rsti + +Device Tree Audio configuration: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L58` + +.. include:: /bsp/peripherals/video.rsti + +.. include:: display.rsti + :end-before: .. supported-display-interfaces-marker-start + +The |sbc| supports up to 3 different display outputs. Two can be used +simultaneously. The following table shows the required extensions and devicetree +overlays for the different interfaces. + +========= ======================== ====================================== +Interface Expansion devicetree overlay +========= ======================== ====================================== +HDMI |sbc| no overlay needed (enabled by default) +LVDS0 PEB-AV-10 |dtbo-peb-av-10| + (loaded by default) +LVDS1 |sbc| disabled if PEB-AV-10 overlay is used +========= ======================== ====================================== + +.. include:: display.rsti + :start-after: .. supported-display-interfaces-marker-end + :end-before: .. no-peb-av-12-marker + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +Device tree description of LVDS-1 and HDMI can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L294` +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L218` + +The device tree of LVDS-0 on PEB-AV-10 can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L133` + +.. include:: ../peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +The device tree description of GPIO Fan can be found here: +:linux-phytec-imx:`tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L35` + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/snvs-power-key.rsti + +.. include:: ../peripherals/npu.rsti + +.. include:: ../peripherals/isp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd24.1.1.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd24.1.1.rst.txt new file mode 100644 index 000000000..ea542a479 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd24.1.1.rst.txt @@ -0,0 +1,1556 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: none +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp +.. _`static-pdf-dl`: ../../../_static/imx8mp-pd24.1.1.pdf + + +.. General Substitutions +.. |doc-id| replace:: PD24.1.1 +.. |kit| replace:: **phyCORE-i.MX8M Plus Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Pollux +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: defconfig +.. |kernel-recipe-path| replace:: recipes-kernel/linux/linux-phytec_*.bb +.. |kernel-repo-name| replace:: linux-phytec +.. |kernel-repo-url| replace:: https://github.com/phytec/linux-phytec.git +.. |kernel-socname| replace:: imx8mp +.. |kernel-tag| replace:: v6.6.21-phy1 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-defconfig| replace:: phycore-imx8mp_defconfig +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-phytec_*.bb +.. |u-boot-repo-name| replace:: u-boot-phytec +.. |u-boot-repo-url| replace:: https://github.com/phytec/u-boot-phytec.git + + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MP +.. |u-boot-tag| replace:: v2024.01-phy3 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-phyboard-pollux-rdk +.. |dt-som| replace:: imx8mp-phycore-som +.. |dtbo-rpmsg| replace:: imx8mp-phycore-rpmsg.dtbo + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L41 + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`scarthgap` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: scarthgap +.. |yocto-distro| replace:: ampliphy-xwayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: rootfs.wic +.. |yocto-machinename| replace:: phyboard-pollux-imx8mp-3 +.. |yocto-manifestname| replace:: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (scarthgap) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-rev| replace:: 4.3 +.. |yocto-sdk-a-core| replace:: cortexa53-crypto + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L106 +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |doc-id| |soc| BSP | | +| Manual | | ++-----------------------+----------------------+ +| Document Title | |doc-id| |soc| BSP | +| | Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Article Number | |doc-id| | ++-----------------------+----------------------+ +| Yocto Manual | Scarthgap | ++-----------------------+----------------------+ +| Release Date | 2024/04/08 | ++-----------------------+----------------------+ +| Is Branch of | |doc-id| |soc| BSP | +| | Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +================ ================ ================= ============== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +================ ================ ================= ============== +PD24.1.1 Major 2024/04/08 Released +================ ================ ================= ============== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mp-pd24.1.1-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.1-getting-started: + +Getting Started +=============== + +The |kit| is shipped with a pre-flashed SD card. It contains the +|yocto-imagename| and can be used directly as a boot source. The eMMC is +programmed with only a U-Boot by default. You can get all sources from the +`PHYTEC download server `_. This chapter explains how to flash a BSP +image to SD card and how to start the board. + +There are several ways to flash an image to SD card or even eMMC. Most notably +using simple, sequential writing with the Linux command line tool ``dd``. An +alternative way is to use PHYTEC's system initialization program called +`partup `_, which makes it especially easy to +format more complex systems. You can get `prebuilt Linux binaries of partup +`__ from its release page. Also read +`partup's README `__ for installation +instructions. + +Get the Image +------------- + +The image contains all necessary files and makes sure partitions and any raw +data are correctly written. Both the partup package and the WIC image, which can +be flashed using ``dd``, can be downloaded from the `PHYTEC download server +`_. + +Get either the partup package or the WIC image from the download server: + +.. code-block:: console + :substitutions: + + host:~$ wget |link-partup-package| + host:~$ wget |link-image| + +.. note:: + For eMMC, more complex partitioning schemes or even just large images, we + recommend using the partup package, as it is faster in writing than ``dd`` + and allows for a more flexible configuration of the target flash device. + +Write the Image to SD Card +-------------------------- + +.. warning:: + To create your bootable SD card, you must have root privileges on your Linux + host PC. Be very careful when specifying the destination device! All files + on the selected device will be erased immediately without any further query! + + Selecting the wrong device may result in **data loss** and e.g. could erase + your currently running system on your host PC! + +Finding the Correct Device +.......................... + +To create your bootable SD card, you must first find the correct device name +of your SD card and possible partitions. If any partitions of the SD cards are +mounted, unmount those before you start copying the image to the SD card. + +#. In order to get the correct device name, remove your SD card and + execute: + + .. code-block:: console + + host:~$ lsblk + +#. Now insert your SD card and execute the command again: + + .. code-block:: console + + host:~$ lsblk + +#. Compare the two outputs to find the new device names listed in the second + output. These are the device names of the SD card (device and partitions if + the SD card was formatted). +#. In order to verify the device names being found, execute the command + ``sudo dmesg``. Within the last lines of its output, you should also find the + device names, e.g. ``/dev/sde`` or ``/dev/mmcblk0`` (depending on your + system). + +Alternatively, you may use a graphical program of your choice, like `GNOME Disks +`_ or `KDE Partition Manager +`_, to find the correct device. + +Now that you have the correct device name, e.g. ``/dev/sde``, +you can see the partitions which must be unmounted if the SD card is formatted. +In this case, you will also find the device name with an appended number +(e.g. ``/dev/sde1``) in the output. These represent the partitions. Some Linux +distributions automatically mount partitions when the device gets plugged in. +Before writing, however, these need to be unmounted to avoid data corruption. + +Unmount all those partitions, e.g.: + +.. code-block:: console + + host:~$ sudo umount /dev/sde1 + host:~$ sudo umount /dev/sde2 + +Now, the SD card is ready to be flashed with an image, using either ``partup``, +``dd`` or ``bmap-tools``. + +Using bmap-tools +................ + +One way to prepare an SD card is using +`bmap-tools `_. Yocto +automatically creates a block map file (``-.wic.bmap``) for +the WIC image that describes the image content and includes checksums for data +integrity. *bmaptool* is packaged by various Linux distributions. For +Debian-based systems install it by issuing: + +.. code-block:: console + + host:~$ sudo apt install bmap-tools + +Flash a WIC image to SD card by calling: + +.. code-block:: console + :substitutions: + + host:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/ + +Replace with your actual SD card's device name found previously, +and make sure to place the file ``-.wic.bmap`` alongside +the regular WIC image file, so bmaptool knows which blocks to write and which +to skip. + +.. warning:: + *bmaptool* only overwrites the areas of an SD card where image data is + located. This means that a previously written U-Boot environment may still be + available after writing the image. + +Using partup +............ + +Writing to an SD card with partup is done in a single command: + +.. code-block:: console + :substitutions: + + host:~$ sudo partup install |yocto-imagename|-|yocto-machinename|.rootfs.partup /dev/ + +Make sure to replace with your actual device name found previously. + +Further usage of partup is explained at its `official documentation website +`__. + +.. warning:: + Host systems which are using resize2fs version 1.46.6 and older + (e.g. Ubuntu 22.04) are not able to write partup packages created with Yocto Mickledore + or newer to SD-Card. This is due to a new default option in resize2fs which causes an + incompatibility. See `release notes `_. + +.. note:: + *partup* has the advantage of allowing to clear specific raw areas in the + MMC user area, which is used in our provided partup packages to erase any + existing U-Boot environments. This is a known issue *bmaptool* does not + solve, as mentioned in the previous chapter. + + Another key advantage of partup over other flashing tools is that it allows + configuring MMC specific parts, like writing to eMMC boot partitions, without + the need to call multiple other commands when writing. + +Using ``dd`` +............ + +After having unmounted all SD card's partitions, you can create your bootable SD card. + +Some PHYTEC BSPs produce uncompressed images (with filename-extension \*.wic), +and some others produce compressed images (with filename-extension \*.wic.xz). + +To flash an uncompressed images (\*.wic) use command below: + +.. code-block:: console + :substitutions: + + host:~$ sudo dd if=|yocto-imagename|-|yocto-machinename|.|yocto-imageext| of=/dev/ bs=1M conv=fsync status=progress + +Or to flash a compressed images (\*.wic.xz) use that command: + +.. code-block:: console + :substitutions: + + host:~$ xzcat |yocto-imagename|-|yocto-machinename|.|yocto-imageext|.xz | sudo dd of=/dev/ bs=1M conv=fsync status=progress + +Again, make sure to replace with your actual device name found +previously. + +The parameter ``conv=fsync`` forces a sync operation on the device before +``dd`` returns. This ensures that all blocks are written to the SD card and +none are left in memory. The parameter ``status=progress`` will print out +information on how much data is and still has to be copied until it is +finished. + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-pd24.1.1-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_1d_dmem_202006.bin, + lpddr4_pmu_train_1d_imem_202006.bin, + lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-phyboard-pollux-rdk*.dtb**: Kernel device tree file +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.wic**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-pd24.1.1-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **eMMC**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +* Load your image via network to RAM: + + .. code-block:: + :substitutions: + + u-boot=> dhcp ${loadaddr} |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + BOOTP broadcast 1 + DHCP client bound to address 192.168.3.11 (101 ms) + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename '|yocto-imagename|-|yocto-machinename|.|yocto-imageext|'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* Write the image to the eMMC: + + .. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Take a compressed or uncompressed image on the host and send it with ssh through +the network (then uncompress it, if necessary) to the eMMC of the target with a +one-line command: + +.. code-block:: console + :substitutions: + + target:~$ ssh @192.168.3.10 "dd if=/|yocto-imagename|-|yocto-machinename|.|yocto-imageext|" | dd of=/dev/mmcblk2 conv=fsync + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + +Send the image with the ``dd`` command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ dd if=|yocto-imagename|-|yocto-machinename|.|yocto-imageext| status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2 conv=fsync" + +Flash eMMC U-Boot image via Network from running U-Boot +....................................................... + +Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> dhcp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB +................... + +Flash eMMC from USB in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. note:: + + Only the lower USB-A port is configured for storage devices and only + this port will work when trying to access a storage device in U-Boot. + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. + +These steps will show how to update the eMMC via a USB device. Configure the +|ref-bootswitch| to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied WIC image to the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} *.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.\ |yocto-imageext|). Set the |ref-bootswitch| to SD Card. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ cd /mnt + target:~$ ls + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2boot0; mmcblk2boot1) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.|yocto-imageext| of=/dev/mmcblk2 conv=fsync + +* After a complete write, your board can boot from eMMC. + + .. tip:: + + Before this will work, you need to configure the |ref-bootswitch| to + **eMMC**. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see |ref-format-sd|. + +Alternatively, flash a partup package to the SD card, as described in +|ref-getting-started|. This will ensure the full space of the SD card is used. + +Flash eMMC from SD card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1GB due to + limited usage of RAM size in the Bootloader after enabling OPTEE. If the + image file is too large use the `Updating eMMC from SD card in + Linux on Target` subsection. + +* Flash an SD card with a working image and create a third FAT partition. Copy + the WIC image (for example |yocto-imagename|.\ |yocto-imageext|) to this + partition. +* Configure the |ref-bootswitch| to SD Card and insert the SD Card. +* Power on the board and stop in U-Boot. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> fatload mmc 1:3 ${loadaddr} |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev to eMMC: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + +* Flash your WIC image (for example |yocto-imagename|.\ |yocto-imageext|) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. + + .. code-block:: + + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the |ref-bootswitch| to eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card. + +* Show your saved partup package or WIC image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.rootfs.partup + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + +* Show list of available MMC devices: + + .. code-block:: console + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + mmcblk2 + mmcblk2boot0 + mmcblk2boot1 + mmcblk2p1 + mmcblk2p2 + mmcblk2rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (mmcblk2\ **boot0**; mmcblk2\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition) using `partup`_: + + .. code-block:: console + :substitutions: + + target:~$ partup install |yocto-imagename|-|yocto-machinename|.rootfs.partup /dev/mmcblk2 + + Flashing the partup package has the advantage of using the full capacity of + the eMMC device, adjusting partitions accordingly. + + .. note:: + + Alternatively, ``dd`` may be used instead: + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.|yocto-imageext| of=/dev/mmcblk2 conv=fsync + + Keep in mind that the root partition does not make use of the full space when + flashing with ``dd``. + +* After a complete write, your board can boot from eMMC. + + .. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to eMMC. + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A6 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.1-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti + +Booting the Kernel from a Network +--------------------------------- + +Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device. + +Place Images on Host for Netboot +................................ + +* Copy the kernel image to your tftp directory: + + .. code-block:: console + + host:~$ cp Image /srv/tftp + +* Copy the devicetree to your tftp directory: + + .. code-block:: console + + host:~$ cp oftree /srv/tftp + +* Make sure other users have read access to all the files in the tftp directory, + otherwise they are not accessible from the target: + + .. code-block:: console + + host:~$ sudo chmod -R o+r /srv/tftp + +* Extract the rootfs to your nfs directory: + + .. code-block:: console + :substitutions: + + host:~$ sudo tar -xvzf |yocto-imagename|-|yocto-machinename|.rootfs.tar.gz -C /srv/nfs + +.. note:: + Make sure you extract with sudo to preserve the correct ownership. + +Booting from an Embedded Board +.............................. + +Boot the board into the U-boot prompt and press any key to hold. + +* To boot from a network, call: + + .. code-block:: console + + u-boot=> run netboot + + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.\ |yocto-imageext| + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + :end-before: .. get-sdk-marker + +Build the SDK +............. + +You can build the SDK yourself with Yocto: + +* Move to the Yocto build directory: + + .. code-block:: console + :substitutions: + + host:~$ source sources/poky/oe-init-build-env + host:~$ bitbake -c populate_sdk |yocto-imagename| # or another image + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + :start-after: .. install-sdk-marker + +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + :end-before: .. build-uboot-fixed-ram-size-marker +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti +.. include:: /bsp/imx8/development/upstream_manifest.rsti +Format SD-Card +-------------- + +Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted. + +Gparted +....... + +* Get GParted: + + .. code-block:: console + + host:~$ sudo apt install gparted + +* Insert the SD Card into your host and get the device name: + + .. code-block:: console + + host:~$ dmesg | tail + ... + [30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB) + [30436.179846] sdb: sdb1 sdb2 + ... + +* Unmount all SD Card partitions. +* Launch GParted: + + .. code-block:: console + + host:~$ sudo gparted + +.. image:: /bsp/imx-common/images/gparted1.png + +Expand rootfs +~~~~~~~~~~~~~ + +.. warning:: + Running gparted on host systems which are using resize2fs version 1.46.6 and older + (e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto + Mickledore and newer. + This is due to a new default option in resize2fs which causes a incompatibility. + See `release notes `_. + +* Choose your SD Card device at the drop-down menu on the top right +* Choose the ext4 root partition and click on resize: + +.. image:: /bsp/imx-common/images/gparted5.png +.. image:: /bsp/imx-common/images/gparted2.png + +* Drag the slider as far as you like or enter the size manually. + +.. image:: /bsp/imx-common/images/gparted3.png + +* Confirm your entry by clicking on the "Change size" button. + +.. image:: /bsp/imx-common/images/gparted4.png + +* To apply your changes, press the green tick. +* Now you can mount the root partition and copy e.g. the + |yocto-imagename|-|yocto-machinename|.\ |yocto-imageext| image to it. Then unmount it again: + + .. code-block:: console + :substitutions: + + host:~$ sudo cp |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /mnt/ ; sync + host:~$ umount /mnt + +Create the Third Partition +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Choose your SD Card device at the drop-down menu on the top right + +.. image:: /bsp/imx-common/images/gparted1.png + +* Choose the bigger unallocated area and press "New": + +.. image:: /bsp/imx-common/images/gparted6.png + +* Click "Add" + +.. image:: /bsp/imx-common/images/gparted7.png + +* Confirm your changes by pressing the green tick. + +.. image:: /bsp/imx-common/images/gparted8.png + +* Now you can mount the new partition and copy e.g. + |yocto-imagename|-|yocto-machinename|.\ |yocto-imageext| image to it. Then unmount it again: + + .. code-block:: console + :substitutions: + + host:~$ sudo mount /dev/sde3 /mnt + host:~$ sudo cp |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /mnt/ ; sync + host:~$ umount /mnt + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.1-device-tree: +.. include:: /bsp/device-tree.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x140 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x140 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +The device tree representation for UART1 pinmuxing: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L387` + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti + +The device tree representation for RS232 and RS485: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L251` + +.. _imx8mp-pd24.1.1-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + :end-before: .. u-boot-network-environment-marker + +U-boot network-environment +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* We currently use dynamic IP addresses in U-Boot. This is enabled by this variable: + + .. code-block:: + + u-boot=> printenv ip_dyn + ip_dyn=yes + +* Set up path for NFS. A modification could look like this: + + .. code-block:: + + u-boot=> setenv nfsroot /home/user/nfssrc + +Please note that these modifications will only affect the bootloader settings. + +.. include:: /bsp/imx-common/peripherals/network.rsti + :start-after: .. kernel-network-environment-marker + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L261` + +DT configuration for the eMMC interface can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L181` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + :end-before: .. peripherals-spi-nor-flash-marker + +The definition of the SPI master node in the device tree can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L67` + +.. include:: ../peripherals/gpios.rsti + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L160` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L81` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L145` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues. + +.. note:: + + If you deleted reserved EEPROM spaces, please contact our support! + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L169` + +RTC +--- + +RTCs can be accessed via ``/dev/rtc*``. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file. + +* To find the name of the RTC device, you can read its sysfs entry with: + + .. code-block:: console + + target:~$ cat /sys/class/rtc/rtc*/name + +* You will get, for example: + + .. code-block:: + + rtc-rv3028 0-0052 + snvs_rtc 30370000.snvs:snvs-rtc-lp + +.. tip:: + + This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device + IDs based on the device tree/aliases entries if present. + +Date and time can be manipulated with the ``hwclock`` tool and the date command. +To show the current date and time set on the target: + +.. code-block:: console + + target:~$ date + Thu Jan 1 00:01:26 UTC 1970 + +Change the date and time with the date command. The date command sets the time +with the following syntax "YYYY-MM-DD hh:mm:ss (+|-)hh:mm": + +.. code-block:: console + + target:~$ date -s "2022-03-02 11:15:00 +0100" + Wed Mar 2 10:15:00 UTC 2022 + +.. note:: + + Your timezone (in this example +0100) may vary. + +Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the ``hwclock`` command. Write the current date and time (set +with the date command) to the RTC using the ``hwclock`` tool and reboot the +target to check if the changes were applied to the RTC: + +.. code-block:: console + + target:~$ hwclock -w + target:~$ reboot + . + . + . + target:~$ date + Wed Mar 2 10:34:06 UTC 2022 + +To set the time and date from the RTC use: + +.. code-block:: console + + target:~$ date + Thu Jan 1 01:00:02 UTC 1970 + target:~$ hwclock -s + target:~$ date + Wed Mar 2 10:45:01 UTC 2022 + +.. include:: ../../peripherals/rtc.rsti + :start-after: .. rtc_parameter_start_label + +DT representation for I²C RTCs: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L175` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L220` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L130` + +Video +----- + +Videos with Gstreamer +..................... + +One example video is installed by default in the BSP at `/usr/share/qtphy/videos/`. +Start the video playback with one of these commands: + +.. code-block:: console + + target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink fullscreen=true + +* Or: + +.. code-block:: console + + target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink + +.. note:: + The mainline BSP currently only supports software rendering. + +Display +------- + +The |sbc| supports LVDS output via the LVDS1 connector on the carrier board. The +LVDS interface is enabled by default. + +Weston Configuration +.................... + +Weston will work without any additional configuration. Configuration options are +done at /etc/xdg/weston/weston.ini. + +Device tree description of LVDS can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L182` + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +.. note:: + We noticed some visible backlight flickering on brightness level 1 (probably + due to frequency problems with the hardware). + +Power Management +---------------- + +CPU Core Frequency Scaling +.......................... + +The CPU in the |soc| SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as 'Dynamic Voltage and +Frequency Scaling' (DVFS). The |soc| BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the |socfamily| +variant used, several different frequencies are supported. + +.. tip:: + + Although the DVFS framework provides frequency settings for each CPU core, a + change in the frequency settings of one CPU core always affects all other CPU + cores too. So all CPU cores always share the same DVFS setting. An individual + DVFS setting for each core is not possible. + + +* To get a complete list type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies + + In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately + 1,6 GHz, the result will be: + + .. code-block:: + + 1200000 1600000 + +* To ask for the current frequency type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq + +So-called governors are automatically selecting one of these frequencies in +accordance with their goals. + +* List all governors available with the following command: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors + + The result will be: + + .. code-block:: + + ondemand userspace performance schedutil + +* **ondemand** (default) switches between possible CPU core frequencies in + reference to the current system load. When the system load increases above a + specific limit, it increases the CPU core frequency immediately. +* **performance** always selects the highest possible CPU core frequency. +* **userspace** allows the user or userspace program running as root to set a + specific frequency (e.g. to 1600000). Type: + +* In order to ask for the current governor, type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor + + You will normally get: + + .. code-block:: + + schedutil + +* Switching over to another governor (e.g. userspace) is done with: + + .. code-block:: console + + target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor + +* Now you can set the speed: + + .. code-block:: console + + target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed + +For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +``Documentation/admin-guide/pm/cpufreq.rst``. + +CPU Core Management +................... + +The |soc| SoC can have multiple processor cores on the die. The |soc|, for +example, has 4 ARM Cores which can be turned on and off individually at runtime. + +* To see all available cores in the system, execute: + + .. code-block:: console + + target:~$ ls /sys/devices/system/cpu -1 + +* This will show, for example: + + .. code-block:: + + cpu0 cpu1 cpu2 cpu3 cpufreq + [...] + + Here the system has four processor cores. By default, all available cores in the + system are enabled to get maximum performance. + +* To switch off a single-core, execute: + + .. code-block:: console + + target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online + + As confirmation, you will see: + + .. code-block:: + + [ 110.505012] psci: CPU3 killed + + Now the core is powered down and no more processes are scheduled on this core. + +* You can use top to see a graphical overview of the cores and processes: + + .. code-block:: console + + target:~$ htop + +* To power up the core again, execute: + + .. code-block:: console + + target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online + +.. include:: ../peripherals/tm.rsti + :end-before: .. tm-gpio-fan-marker + +.. include:: /bsp/peripherals/watchdog.rsti + +snvs Power Key +-------------- + +The X_ONOFF pin connected to the ON/OFF button can be pressed long to trigger +Power OFF without SW intervention. With the *snvs_pwrkey* driver, the KEY_POWER +event is also reported to userspace when the button is pressed. On default, systemd +is configured to ignore such events. The function of Power OFF without SW +intervention are not configured. Triggering a power off with systemd when pushing +the ON/OFF button can be configured under ``/etc/systemd/logind.conf`` and set using: + +.. code-block:: + + HandlePowerKey=poweroff + +.. include:: ../peripherals/ocotp-ctrl.rsti diff --git a/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd24.1.2.rst.txt b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd24.1.2.rst.txt new file mode 100644 index 000000000..1fad85de4 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx8/imx8mp/pd24.1.2.rst.txt @@ -0,0 +1,1343 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/ +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx8mp +.. _`static-pdf-dl`: ../../../_static/imx8mp-pd24.1.2.pdf + + +.. General Substitutions +.. |doc-id| replace:: PD24.1.2 +.. |kit| replace:: **phyCORE-i.MX8M Plus Kit** +.. |kit-ram-size| replace:: 2GiB +.. |sbc| replace:: phyBOARD-Pollux +.. |soc| replace:: i.MX 8M Plus +.. |socfamily| replace:: i.MX 8 +.. |som| replace:: phyCORE-i.MX8MP +.. |debug-uart| replace:: ttymxc0 +.. |serial-uart| replace:: ttymxc1 +.. |expansion-connector| replace:: X6 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: defconfig +.. |kernel-recipe-path| replace:: recipes-kernel/linux/linux-phytec_*.bb +.. |kernel-repo-name| replace:: linux-phytec +.. |kernel-repo-url| replace:: https://github.com/phytec/linux-phytec.git +.. |kernel-socname| replace:: imx8mp +.. |kernel-tag| replace:: v6.6.21-phy1 +.. |emmcdev| replace:: mmcblk2 + +.. Bootloader +.. |u-boot-defconfig| replace:: phycore-imx8mp_defconfig +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 2 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-phytec_*.bb +.. |u-boot-repo-name| replace:: u-boot-phytec +.. |u-boot-repo-url| replace:: https://github.com/phytec/u-boot-phytec.git + +.. IMX8(MP) specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX8MP +.. |u-boot-tag| replace:: v2024.01-phy4 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx8mp-phyboard-pollux-rdk +.. |dt-som| replace:: imx8mp-phycore-som + +.. IMX8(MP) specific +.. |dt-somnetwork| replace:: https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L41 + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`scarthgap` +.. |yocto-bsp-name| replace:: BSP-Yocto-IMX8MP +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: scarthgap +.. |yocto-distro| replace:: ampliphy-xwayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: rootfs.wic.xz +.. |yocto-machinename| replace:: phyboard-pollux-imx8mp-3 +.. |yocto-manifestname| replace:: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 +.. |yocto-manifestname-master| replace:: BSP-Yocto-Ampliphy-i.MX8MP-master +.. |yocto-manifestname-y| replace:: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (scarthgap) ` +.. |yocto-ref-manual-kernel-and-bootloader-conf| replace:: :ref:`Yocto Reference Manual ` +.. |yocto-sdk-a-core| replace:: cortexa53-crypto +.. |yocto-sdk-rev| replace:: 5.0.1 + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-build-uboot| replace:: :ref:`Build U-Boot ` +.. |ref-debugusbconnector| replace:: :ref:`(X1) ` +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X5 (upper connector) ` +.. |ref-format-sd| replace:: :ref:`Resizing ext4 Root Filesystem ` + + +.. IMX8(MP) specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L106 +.. |pollux-fan-note| replace:: + Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan + to GPIO fan due to availability. The PWM fan will not be supported + anymore and will not function with the new release. + +.. |ref-serial| replace:: :ref:`X2 ` +.. |ref-jp3| replace:: :ref:`JP3 ` +.. |ref-jp4| replace:: :ref:`JP4 ` + + +.. M-Core specific +.. |mcore| replace:: M7 Core +.. |mcore-zephyr-docs| replace:: https://docs.zephyrproject.org/latest/boards/phytec/mimx8mp_phyboard_pollux/doc/index.html +.. |mcore-jtag-dev| replace:: MIMX8ML8_M7 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |doc-id| |soc| BSP | | +| Manual | | ++-----------------------+----------------------+ +| Document Title | |doc-id| |soc| BSP | +| | Mainline Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Article Number | |doc-id| | ++-----------------------+----------------------+ +| Yocto Manual | Scarthgap | ++-----------------------+----------------------+ +| Release Date | 2024/06/26 | ++-----------------------+----------------------+ +| Is Branch of | |doc-id| |soc| BSP | +| | Mainline Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +===================== ================ ================= ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +===================== ================ ================= ========== +|yocto-manifestname| Minor 2024/06/26 Released +===================== ================ ================= ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname| `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware + +.. _imx8mp-pd24.1.2-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.2-getting-started: + +.. include:: ../../getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target and the host with **mirco USB** on |ref-debugusbconnector| + debug USB +* Power up the board + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx8mp-pd24.1.2-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx8mp.bin**: ARM Trusted Firmware binary +* **lpddr4_pmu_train_1d_dmem_202006.bin, + lpddr4_pmu_train_1d_imem_202006.bin, + lpddr4_pmu_train_2d_dmem_202006.bin, + lpddr4_pmu_train_2d_imem_202006.bin**: DDR PHY firmware images +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx8mp-phyboard-pollux-rdk*.dtb**: Kernel device tree file +* **phytec-qt6demo-image\*.tar.gz**: Root file system +* **phytec-qt6demo-image\*.wic.xz**: SD card image + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +For consistency, it is assumed that a TFTP server is configured; More +importantly, all generated images, as listed above, are copied to the default +/srv/tftp directory. If you do not have this set up, you need to adjust the +paths that point to the images being used in the instructions. For instructions +on how to set up the TFTP server and directory, see |ref-setup-network-host|. + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1552.2 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx8mp-pd24.1.2-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **eMMC**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If ``mmcblk2p1`` + and ``mmcblk1p1`` have an identical UUID, the setup is affected. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +Flash eMMC from Network in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to update the eMMC via a network. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +.. tip:: + + This step only works if the size of the image file is less than 1,28GB due to + limited RAM space available in the Bootloader. + +* Uncompress your image: + +.. code-block:: console + :substitutions: + + host:~$ unxz /srv/tftp/phytec-headless-image-|yocto-machinename|.rootfs.wic.xz + +* Load your image via network to RAM: + + .. code-block:: + :substitutions: + + u-boot=> dhcp ${loadaddr} phytec-headless-image-|yocto-machinename|.rootfs.wic + BOOTP broadcast 1 + DHCP client bound to address 192.168.3.11 (101 ms) + Using ethernet@30be0000 device + TFTP from server 192.168.3.10; our IP address is 192.168.3.11 + Filename 'phytec-headless-image-|yocto-machinename|.rootfs.wic'. + Load address: 0x40480000 + Loading: ###################################### + ###################################### + ###################################### + ... + ... + ... + ###################################### + ############# + 11.2 MiB/s + done + Bytes transferred = 911842304 (36599c00 hex) + +* Write the image to the eMMC: + + .. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Take a compressed or decompressed image with the accompanying block map file +`*.bmap` on the host and send it with `ssh` through the network to the eMMC of +the target with a one-line command: + +.. code-block:: console + :substitutions: + + target:~$ scp @192.168.3.10:/srv/tftp/|yocto-imagename|-|yocto-machinename|.rootfs.wic.* /tmp && bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls /srv/tftp + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + |yocto-imagename|-|yocto-machinename|.rootfs.wic.bmap + +Send the image with the ``bmaptool`` command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ scp /srv/tftp/|yocto-imagename|-|yocto-machinename|.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2" + +Flash eMMC U-Boot image via Network from running U-Boot +....................................................... + +Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> dhcp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 2 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB stick +......................... + +Flash eMMC from USB stick in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. note:: + + Only the lower USB-A port is configured for storage devices and only + this port will work when trying to access a storage device in U-Boot. + +.. tip:: + + This step only works if the size of the image file is less than 1,28GB due to + limited RAM space available in the Bootloader. + +These steps will show how to update the eMMC via a USB device. Configure the +|ref-bootswitch| to SD Card and insert an SD card. Power on the board and stop +in U-Boot prompt. Insert a USB device with the copied uncompressed WIC image to +the USB slot. + +Load your image from the USB device to RAM: + +.. code-block:: + :substitutions: + + u-boot=> usb start + starting USB... + USB0: USB EHCI 1.00 + scanning bus 0 for devices... 2 USB Device(s) found + scanning usb for storage devices... 1 Storage Device(s) found + u-boot=> fatload usb 0:1 ${loadaddr} phytec-headless-image-|yocto-machinename|.rootfs.wic + 497444864 bytes read in 31577 ms (15 MiB/s) + +Write the image to the eMMC: + +.. code-block:: + + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK + u-boot=> boot + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.\ |yocto-imageext|). Set the |ref-bootswitch| to SD Card. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ ls /mnt + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + |yocto-imagename|-|yocto-machinename|.rootfs.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 without partition): + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy /mnt/|yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + +* After a complete write, your board can boot from eMMC. + + .. tip:: + + Before this will work, you need to configure the |ref-bootswitch| to + **eMMC**. + +Flash eMMC from SD Card +....................... + +Even if there is no network available, you can update the eMMC. For that, you +only need a ready-to-use image file (``*.wic``) located on the SD card. +Because the image file is quite large, you have to create a third partition. +To create a new partition or enlarge your SD card, see |ref-format-sd|. + +Alternatively, flash a partup package to the SD card, as described in +|ref-getting-started|. This will ensure the full space of the SD card is used. + +Flash eMMC from SD card in U-Boot on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. tip:: + + This step only works if the size of the image file is less than 1,28GB due to + limited RAM space available in the Bootloader. + + +* Flash an SD card with a working image and create a third ext4 partition. Copy + the WIC image (for example |yocto-imagename|.rootfs.wic) to this partition. +* Configure the |ref-bootswitch| to SD Card and insert the SD Card. +* Power on the board and stop in U-Boot. +* Load the image: + + .. code-block:: + :substitutions: + + u-boot=> mmc dev 1 + u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-|yocto-machinename|.rootfs.wic + reading + 911842304 bytes read in 39253 ms (22.2 MiB/s) + +* Switch the mmc dev to eMMC: + + .. code-block:: + + u-boot=> mmc list + FSL_SDHC: 1 (SD) + FSL_SDHC: 2 (eMMC) + u-boot=> mmc dev 2 + switch to partitions #0, OK + mmc2(part 0) is current device + +* Flash your WIC image (for example |yocto-imagename|.roots.wic) + from the SD card to eMMC. This will partition the card and copy imx-boot, + Image, dtb, dtbo, and root file system to eMMC. + + .. code-block:: + + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc write ${loadaddr} 0x0 ${nblk} + + MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK + +* Power off the board and change the |ref-bootswitch| to eMMC. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also flash the eMMC on Linux. You only need a partup package or WIC +image saved on the SD card. + +* Show your saved partup package or WIC image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.rootfs.partup + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + |yocto-imagename|-|yocto-machinename|.rootfs.wic.bmap + +* Write the image to the phyCORE-|soc| eMMC (MMC device 2 **without** + partition) using `partup`_: + + .. code-block:: console + :substitutions: + + target:~$ partup install |yocto-imagename|-|yocto-machinename|.rootfs.partup /dev/mmcblk2 + + Flashing the partup package has the advantage of using the full capacity of + the eMMC device, adjusting partitions accordingly. + + .. note:: + + Alternatively, ``bmaptool`` may be used instead: + + .. code-block:: console + :substitutions: + + target:~$ bmaptool copy |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /dev/mmcblk2 + + Keep in mind that the root partition does not make use of the full space when + flashing with ``bmaptool``. + +* After a complete write, your board can boot from eMMC. + + .. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to eMMC. + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A6 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.2-development: + +Development +=========== + +.. include:: /bsp/imx-common/development/host_network_setup.rsti + +Booting the Kernel from a Network +--------------------------------- + +Booting from a network means loading the kernel and device tree over TFTP and +the root file system over NFS. The bootloader itself must already be loaded from +another available boot device. + +Place Images on Host for Netboot +................................ + +* Copy the kernel image to your tftp directory: + + .. code-block:: console + + host:~$ cp Image /srv/tftp + +* Copy the devicetree to your tftp directory: + + .. code-block:: console + + host:~$ cp oftree /srv/tftp + +* Make sure other users have read access to all the files in the tftp directory, + otherwise they are not accessible from the target: + + .. code-block:: console + + host:~$ sudo chmod -R o+r /srv/tftp + +* Extract the rootfs to your nfs directory: + + .. code-block:: console + :substitutions: + + host:~$ sudo tar -xvzf |yocto-imagename|-|yocto-machinename|.rootfs.tar.gz -C /srv/nfs + +.. note:: + Make sure you extract with sudo to preserve the correct ownership. + +Booting from an Embedded Board +.............................. + +Boot the board into the U-boot prompt and press any key to hold. + +* To boot from a network, call: + + .. code-block:: console + + u-boot=> run netboot + + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.rootfs.wic + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.rootfs.wic + +.. include:: /bsp/imx-common/development/standalone_build_preface.rsti + +.. _imx8mp-pd24.1.2-development-build-uboot: +.. include:: /bsp/imx-common/development/standalone_build_u-boot_binman.rsti + +.. include:: development/uboot-standalone-fixed-ram-config.rsti + +.. include:: /bsp/imx-common/development/standalone_build_kernel.rsti + +.. include:: /bsp/imx8/development/development_manifests.rsti +.. include:: /bsp/imx8/development/upstream_manifest.rsti + +.. _imx8mp-pd24.1.2-format-sd: + +Format SD-Card +-------------- + +Most images are larger than the default root partition. To flash any storage +device with SD Card, the rootfs needs to be expanded or a separate partition +needs to be created. There are some different ways to format the SD Card. The +easiest way to do this is to use the UI program Gparted. + +Gparted +....... + +* Get GParted: + + .. code-block:: console + + host:~$ sudo apt install gparted + +* Insert the SD Card into your host and get the device name: + + .. code-block:: console + + host:~$ dmesg | tail + ... + [30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB) + [30436.179846] sdb: sdb1 sdb2 + ... + +* Unmount all SD Card partitions. +* Launch GParted: + + .. code-block:: console + + host:~$ sudo gparted + +.. image:: /bsp/imx-common/images/gparted1.png + +Expand rootfs +~~~~~~~~~~~~~ + +.. warning:: + Running gparted on host systems which are using resize2fs version 1.46.6 and older + (e.g. Ubuntu 22.04) are not able to expand the ext4 partition created with Yocto + Mickledore and newer. + This is due to a new default option in resize2fs which causes a incompatibility. + See `release notes `_. + +* Choose your SD Card device at the drop-down menu on the top right +* Choose the ext4 root partition and click on resize: + +.. image:: /bsp/imx-common/images/gparted5.png +.. image:: /bsp/imx-common/images/gparted2.png + +* Drag the slider as far as you like or enter the size manually. + +.. image:: /bsp/imx-common/images/gparted3.png + +* Confirm your entry by clicking on the "Change size" button. + +.. image:: /bsp/imx-common/images/gparted4.png + +* To apply your changes, press the green tick. +* Now you can mount the root partition and copy e.g. the + |yocto-imagename|-|yocto-machinename|.\ |yocto-imageext| image to it. Then unmount it again: + + .. code-block:: console + :substitutions: + + host:~$ sudo cp |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /mnt/ ; sync + host:~$ umount /mnt + +Create the Third Partition +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Choose your SD Card device at the drop-down menu on the top right + +.. image:: /bsp/imx-common/images/gparted1.png + +* Choose the bigger unallocated area and press "New": + +.. image:: /bsp/imx-common/images/gparted6.png + +* Click "Add" + +.. image:: /bsp/imx-common/images/gparted7.png + +* Confirm your changes by pressing the green tick. + +.. image:: /bsp/imx-common/images/gparted8.png + +* Now you can mount the new partition and copy e.g. + |yocto-imagename|-|yocto-machinename|.\ |yocto-imageext| image to it. Then unmount it again: + + .. code-block:: console + :substitutions: + + host:~$ sudo mount /dev/sde3 /mnt + host:~$ sudo cp |yocto-imagename|-|yocto-machinename|.|yocto-imageext| /mnt/ ; sync + host:~$ umount /mnt + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx8mp-pd24.1.2-device-tree: +.. include:: /bsp/device-tree.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 0x140 + MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX 0x140 + >; + }; + +The first part of the string MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX names the pad +(in this example UART1_RXD). The second part of the string (UART1_DCE_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal resistors are +disabled. + +The device tree representation for UART1 pinmuxing: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L387` + +RS232/RS485 +----------- + +The phyCORE-|soc| supports up to 4 UART units. On the |sbc|, TTL level signals +of UART1 (the standard console) and UART4 are routed to Silicon Labs CP2105 UART +to USB converter expansion. This USB is brought out at Micro-USB connector X1. +UART3 is at X6 (Expansion Connector) at TTL level. UART2 is connected to a +multi-protocol transceiver for RS-232 and RS-485, available at pin header +connector |ref-serial| at the RS-232 level, or at the RS-485 level. The +configuration of the multi-protocol transceiver is done by jumpers |ref-jp3| and +|ref-jp4| on the baseboard. For more information about the correct setup please +refer to the phyCORE-|soc|/|sbc| Hardware Manual section UARTs. + +We use the same device tree node for RS-232 and RS-485. RS-485 mode can be +enabled with ioctl TIOCSRS485. Also, full-duplex support is also configured +using ioctls. Have a look at our small example application rs485test, which is +also included in the BSP. The jumpers |ref-jp3| and |ref-jp4| need to be set +correctly. + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti +.. include:: /bsp/peripherals/rs485-halfduplex.rsti +.. include:: /bsp/peripherals/rs485-fullduplex.rsti + +The device tree representation for RS232 and RS485: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L251` + +.. _imx8mp-pd24.1.2-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A gigabit Ethernet is provided by our +module and board. + +.. warning:: + + The naming convention of the Ethernet interfaces in the hardware (ethernet0 + and ethernet1) do not align with the network interfaces (eth0 and eth1) in + Linux. So, be aware of these differences: + + | ethernet1 = eth0 + | ethernet0 = eth1 + +.. include:: /bsp/imx-common/peripherals/network.rsti + :end-before: .. u-boot-network-environment-marker + +U-boot network-environment +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* We currently use dynamic IP addresses in U-Boot. This is enabled by this variable: + + .. code-block:: + + u-boot=> printenv ip_dyn + ip_dyn=yes + +* Set up path for NFS. A modification could look like this: + + .. code-block:: + + u-boot=> setenv nfsroot /home/user/nfssrc + +Please note that these modifications will only affect the bootloader settings. + +.. include:: /bsp/imx-common/peripherals/network.rsti + :start-after: .. kernel-network-environment-marker + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:linux-phytec:`/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L261` + +DT configuration for the eMMC interface can be found here: +:linux-phytec:`/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L181` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/spi-master.rsti + :end-before: .. peripherals-spi-nor-flash-marker + +The definition of the SPI master node in the device tree can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L67` + +.. include:: ../peripherals/gpios.rsti + +.. include:: /bsp/peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L160` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L81` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L145` + + +EEPROM +------ + +On the |som| there is an i2c EEPROM flash populated. It has two addresses. The +main EEPROM space (bus: I2C-0 address: 0x51) can be accessed via the sysfs +interface in Linux. The first 256 bytes of the main EEPROM and the ID-page +(bus: I2C-0 address: 0x59) are used for board detection and must not be +overwritten. Therefore the ID-page can not be accessed via the sysfs interface. +Overwriting reserved spaces will result in boot issues. + +.. note:: + + If you deleted reserved EEPROM spaces, please contact our support! + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L169` + +RTC +--- + +RTCs can be accessed via ``/dev/rtc*``. Because PHYTEC boards have often more than +one RTC, there might be more than one RTC device file. + +* To find the name of the RTC device, you can read its sysfs entry with: + + .. code-block:: console + + target:~$ cat /sys/class/rtc/rtc*/name + +* You will get, for example: + + .. code-block:: + + rtc-rv3028 0-0052 + snvs_rtc 30370000.snvs:snvs-rtc-lp + +.. tip:: + + This will list all RTCs including the non-I²C RTCs. Linux assigns RTC device + IDs based on the device tree/aliases entries if present. + +Date and time can be manipulated with the ``hwclock`` tool and the date command. +To show the current date and time set on the target: + +.. code-block:: console + + target:~$ date + Thu Jan 1 00:01:26 UTC 1970 + +Change the date and time with the date command. The date command sets the time +with the following syntax "YYYY-MM-DD hh:mm:ss (+|-)hh:mm": + +.. code-block:: console + + target:~$ date -s "2022-03-02 11:15:00 +0100" + Wed Mar 2 10:15:00 UTC 2022 + +.. note:: + + Your timezone (in this example +0100) may vary. + +Using the date command does not change the time and date of the RTC, so if we +were to restart the target those changes would be discarded. To write to the RTC +we need to use the ``hwclock`` command. Write the current date and time (set +with the date command) to the RTC using the ``hwclock`` tool and reboot the +target to check if the changes were applied to the RTC: + +.. code-block:: console + + target:~$ hwclock -w + target:~$ reboot + . + . + . + target:~$ date + Wed Mar 2 10:34:06 UTC 2022 + +To set the time and date from the RTC use: + +.. code-block:: console + + target:~$ date + Thu Jan 1 01:00:02 UTC 1970 + target:~$ hwclock -s + target:~$ date + Wed Mar 2 10:45:01 UTC 2022 + +.. include:: ../../peripherals/rtc.rsti + :start-after: .. rtc_parameter_start_label + +DT representation for I²C RTCs: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L175` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 4 Gbit/s (SuperSpeed +'SS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host. Each is +connected to a USB 3.0 PHY. + +.. include:: /bsp/peripherals/usb-host.rsti + +DT representation for USB Host: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L220` + +CAN FD +------ + +The |sbc| has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L130` + +Video +----- + +Videos with Gstreamer +..................... + +One example video is installed by default in the BSP at `/usr/share/qtphy/videos/`. +Start the video playback with one of these commands: + +.. code-block:: console + + target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink fullscreen=true + +* Or: + +.. code-block:: console + + target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink + +.. note:: + The mainline BSP currently only supports software rendering. + +Display +------- + +The |sbc| supports LVDS output via the LVDS1 connector on the carrier board. The +LVDS interface is enabled by default. + +Weston Configuration +.................... + +Weston will work without any additional configuration. Configuration options are +done at /etc/xdg/weston/weston.ini. + +Device tree description of LVDS can be found here: +:linux-phytec:`blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L182` + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +.. note:: + We noticed some visible backlight flickering on brightness level 1 (probably + due to frequency problems with the hardware). + +Power Management +---------------- + +CPU Core Frequency Scaling +.......................... + +The CPU in the |soc| SoC is able to scale the clock frequency and the voltage. +This is used to save power when the full performance of the CPU is not needed. +Scaling the frequency and the voltage is referred to as 'Dynamic Voltage and +Frequency Scaling' (DVFS). The |soc| BSP supports the DVFS feature. +The Linux kernel provides a DVFS framework that allows each CPU core to have a +min/max frequency and a governor that governs it. Depending on the |socfamily| +variant used, several different frequencies are supported. + +.. tip:: + + Although the DVFS framework provides frequency settings for each CPU core, a + change in the frequency settings of one CPU core always affects all other CPU + cores too. So all CPU cores always share the same DVFS setting. An individual + DVFS setting for each core is not possible. + + +* To get a complete list type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies + + In case you have, for example, i.MX 8MPlus CPU with a maximum of approximately + 1,6 GHz, the result will be: + + .. code-block:: + + 1200000 1600000 + +* To ask for the current frequency type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq + +So-called governors are automatically selecting one of these frequencies in +accordance with their goals. + +* List all governors available with the following command: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors + + The result will be: + + .. code-block:: + + ondemand userspace performance schedutil + +* **ondemand** (default) switches between possible CPU core frequencies in + reference to the current system load. When the system load increases above a + specific limit, it increases the CPU core frequency immediately. +* **performance** always selects the highest possible CPU core frequency. +* **userspace** allows the user or userspace program running as root to set a + specific frequency (e.g. to 1600000). Type: + +* In order to ask for the current governor, type: + + .. code-block:: console + + target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor + + You will normally get: + + .. code-block:: + + schedutil + +* Switching over to another governor (e.g. userspace) is done with: + + .. code-block:: console + + target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor + +* Now you can set the speed: + + .. code-block:: console + + target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed + +For more detailed information about the governors, refer to the Linux kernel +documentation in the linux kernel repository at +``Documentation/admin-guide/pm/cpufreq.rst``. + +CPU Core Management +................... + +The |soc| SoC can have multiple processor cores on the die. The |soc|, for +example, has 4 ARM Cores which can be turned on and off individually at runtime. + +* To see all available cores in the system, execute: + + .. code-block:: console + + target:~$ ls /sys/devices/system/cpu -1 + +* This will show, for example: + + .. code-block:: + + cpu0 cpu1 cpu2 cpu3 cpufreq + [...] + + Here the system has four processor cores. By default, all available cores in the + system are enabled to get maximum performance. + +* To switch off a single-core, execute: + + .. code-block:: console + + target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online + + As confirmation, you will see: + + .. code-block:: + + [ 110.505012] psci: CPU3 killed + + Now the core is powered down and no more processes are scheduled on this core. + +* You can use top to see a graphical overview of the cores and processes: + + .. code-block:: console + + target:~$ htop + +* To power up the core again, execute: + + .. code-block:: console + + target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online + +.. include:: ../peripherals/tm.rsti + :end-before: .. tm-gpio-fan-marker + +.. include:: /bsp/peripherals/watchdog.rsti + +snvs Power Key +-------------- + +The X_ONOFF pin connected to the ON/OFF button can be pressed long to trigger +Power OFF without SW intervention. With the *snvs_pwrkey* driver, the KEY_POWER +event is also reported to userspace when the button is pressed. On default, systemd +is configured to ignore such events. The function of Power OFF without SW +intervention are not configured. Triggering a power off with systemd when pushing +the ON/OFF button can be configured under ``/etc/systemd/logind.conf`` and set using: + +.. code-block:: + + HandlePowerKey=poweroff + +.. include:: ../peripherals/ocotp-ctrl.rsti diff --git a/previews/271/zh_CN/_sources/bsp/imx9/imx9.rst.txt b/previews/271/zh_CN/_sources/bsp/imx9/imx9.rst.txt new file mode 100644 index 000000000..41577c72d --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx9/imx9.rst.txt @@ -0,0 +1,9 @@ +============== +i.MX 9 Manuals +============== + +.. toctree:: + :caption: i.MX 9 Manuals + :maxdepth: 2 + + i.MX 93 Manuals diff --git a/previews/271/zh_CN/_sources/bsp/imx9/imx93/imx93.rst.txt b/previews/271/zh_CN/_sources/bsp/imx9/imx93/imx93.rst.txt new file mode 100644 index 000000000..4a869bd41 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx9/imx93/imx93.rst.txt @@ -0,0 +1,34 @@ +==================== +i.MX 93 Manuals +==================== + +BSP-Yocto-NXP-i.MX93-PD24.2.0 +============================= + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd24.2.0 + +BSP-Yocto-NXP-i.MX93-PD24.1.1 +============================= + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd24.1.1 + +BSP-Yocto-NXP-i.MX93-PD24.1.0 +============================= + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + pd24.1.0 + diff --git a/previews/271/zh_CN/_sources/bsp/imx9/imx93/pd24.1.0.rst.txt b/previews/271/zh_CN/_sources/bsp/imx9/imx93/pd24.1.0.rst.txt new file mode 100644 index 000000000..d0e32f88a --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx9/imx93/pd24.1.0.rst.txt @@ -0,0 +1,841 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX93-PD24.1.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-91-93/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/sdk/ampliphy-vendor-wayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools/ +.. _`static-pdf-dl`: ../../../_static/imx93-pd24.1.0.pdf + +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx93 + +.. General Substitutions +.. |kit| replace:: **phyBOARD-Segin i.MX 93 Kit** +.. |kit-ram-size| replace:: 1GiB +.. |sbc| replace:: phyBOARD-Segin i.MX 93 +.. |soc| replace:: i.MX 93 +.. |socfamily| replace:: i.MX 9 +.. |som| replace:: phyCORE-i.MX93 +.. |debug-uart| replace:: ttyLP0 +.. |expansion-connector| replace:: X16 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx9_phytec_distro.config imx9_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx93 +.. |kernel-tag| replace:: v6.1.36_2.1.0-phy1 +.. |emmcdev| replace:: mmcblk0 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 0 +.. |u-boot-defconfig| replace:: phycore-imx93_defconfig +.. |u-boot-multiple-defconfig-note| replace:: In command above replace ```` with ``phycore-imx93_defconfig``. +.. |u-boot-multiple-dtb-note| replace:: In command above replace ```` with ``imx93-phyboard-segin.dtb``. +.. |u-boot-imx-mkimage-tag| replace:: lf-6.1.36_2.1.0 +.. |u-boot-soc-name| replace:: iMX9 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + + +.. IMX93 specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX93 +.. |u-boot-tag| replace:: v2023.04_2.1.0-phy1 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx93-phyboard-segin +.. |dt-som| replace:: imx93-phycore-som +.. |dtbo-rpmsg| replace:: imx93-phycore-rpmsg.dtso + +.. IMX93 specific +.. |dt-somnetwork| replace:: :imx-dt:`imx93-phycore-som.dtsi?h=v6.1.36_2.1.0-phy1#n61` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`mickledore` +.. |yocto-bsp-name| replace:: BSP-Yocto-i.MX93 +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: mickledore +.. |yocto-distro| replace:: ampliphy-vendor-wayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: wic.xz +.. |yocto-machinename| replace:: phyboard-segin-imx93-2 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX93-PD24.1.0 +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (mickledore) ` +.. |yocto-sdk-rev| replace:: 4.2.2 +.. |yocto-sdk-a-core| replace:: cortexa55 + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: serial connector on PEB-EVAL-01 +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X8 (USB micro/OTG connector) ` + + +.. IMX93 specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :imx-dt:`imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n114`. + +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M33 Core +.. |ref-m-core-connections| replace:: :ref:`X16 ` +.. |mcore-jtag-dev| replace:: MIMX8MM6_M4 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Yocto Manual | Mickledore | ++-----------------------+----------------------+ +| Release Date | 2024/01/31 | ++-----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================ ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================ ========== +|yocto-manifestname| Major 2024/01/31 Released +==================== ================ ================ ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname|, see `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware. + +.. _imx93-pd24.1.0-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx93-pd24.1.0-getting-started: +.. include:: /bsp/getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the following + position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the target (|ref-debugusbconnector|) and the host with **serial + cable** +* Power up the board +* Open serial port with 115200 baud and 8N1 (you should see u-boot/linux start on the console + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx93-pd24.1.0-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx93.bin**: ARM Trusted Firmware binary +* **lpddr4_dmem_1d_v202201.bin, lpddr4_dmem_2d_v202201.bin, + lpddr4_imem_1d_v202201.bin, + lpddr4_imem_2d_v202201.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which is + bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx93-phyboard-segin.dtb**: Kernel device tree file +* **imx93-phy\*.dtbo**: Kernel device tree overlay files +* **phytec-\*.tar.gz**: Root file system, + of bitbake-image that was built. + + * **phytec-qt6demo-image-phyboard-segin-imx93-2.tar.gz**: when bitbake-build + was processed for ``phytec-qt6demo-image`` + * **phytec-headless-image-phyboard-segin-imx93-2.tar.gz**: when bitbake-build + was processed for ``phytec-headless-image`` +* **phytec-\*.wic.xz**: Compressed bootable SD + card image of bitbake-image that was built. Includes bootloader, DTBs, Kernel + and Root file system. + + * **phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz**: when bitbake-build + was processed for ``phytec-qt6demo-image`` + * **phytec-headless-image-phyboard-segin-imx93-2.wic.xz**: when bitbake-build + was processed for ``phytec-headless-image`` +* **imx93-11x11-evk_m33_\*.bin**, binaries of demo applications for the + Cortex-M33 MCU; can be manually loaded and started with U-Boot or Linux + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: 1472.5 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx93-pd24.1.0-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **eMMC**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If |emmcdev|\p1 + and mmcblk1p1 have an identical UUID, the setup is affected. + +Flash eMMC from SD Card +....................... + +If there is no network available, you can update the eMMC from SD card. For +that, you only need a ready-to-use image file (``*.wic``) located on the +SD card. Because the image file is quite large, you have to enlarge your SD card +to use its full space (if it was not enlarged before). To enlarge your SD card, +see Resizing ext4 Root Filesystem. + +Alternatively, flash a partup package to the SD card, as described in +|ref-getting-started|. This will ensure the full space of the SD card is used. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can flash the eMMC on Linux. You only need a partup package or WIC image +saved on the SD card. + +* Show your saved partup package or WIC image or WIC.XZ image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.partup + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + +* Show list of available MMC devices: + + .. code-block:: console + :substitutions: + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + |emmcdev| + |emmcdev|boot0 + |emmcdev|boot1 + |emmcdev|p1 + |emmcdev|p2 + |emmcdev|rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (|emmcdev|\ **boot0**; |emmcdev|\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (/dev/|emmcdev| **without** + partition) using `partup`_: + + .. code-block:: console + :substitutions: + + target:~$ partup install |yocto-imagename|-|yocto-machinename|.partup /dev/|emmcdev| + + .. tip:: + + **Using partup is highly recommended since it is easier to use and has the + advantage of using the full capacity of the eMMC device, adjusting + partitions accordingly.** + + .. note:: + + Alternatively, ``dd`` may be used instead. + + For uncompressed WIC images (\*.wic): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/|emmcdev| bs=1M conv=fsync status=progress + + For compressed WIC images (\*.wic.xz): + + .. code-block:: console + :substitutions: + + target:~$ zstdcat |yocto-imagename|-|yocto-machinename|.wic.xz | sudo dd of=/dev/|emmcdev| bs=1M conv=fsync status=progress + + Keep in mind that the root partition does not make use of the full space + when flashing with ``dd``. + +* After a complete write, your board can boot from eMMC. + + .. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to eMMC. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +.. note:: + + Some PHYTECs BSPs produce compressed ``.wic.xz`` images. In this case, the + compressed image must first be uncompressed. + + .. code-block:: console + :substitutions: + + host:~$ unxz phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Take an uncompressed image on the host and send it with ssh through +the network to the eMMC of the target with a one-line command: + +.. code-block:: console + :substitutions: + + target:~$ ssh @192.168.3.10 "dd if=/|yocto-imagename|-|yocto-machinename|.wic" | dd of=/dev/|emmcdev| bs=1M conv=fsync status=progress + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +Send the image with the ``dd`` command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic bs=1M status=progress | ssh root@192.168.3.11 "dd of=/dev/|emmcdev| conv=fsync" + +Flash eMMC U-Boot image via Network from running U-Boot +....................................................... + +Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 0 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB +................... + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the |ref-bootswitch| to SD Card. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ cd /mnt + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + :substitutions: + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + |emmcdev| + |emmcdev|boot0 + |emmcdev|boot1 + |emmcdev|p1 + |emmcdev|p2 + |emmcdev|rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (|emmcdev|\ **boot0**; |emmcdev|\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (/dev/|emmcdev| without partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/|emmcdev| bs=1M conv=fsync status=progress + +* After a complete write, your board can boot from eMMC. + + .. tip:: + + Before this will work, you need to configure the |ref-bootswitch| to + **eMMC**. + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A5 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx93-pd24.1.0-development: + +Development +=========== + +.. include:: ../../imx-common/development/host_network_setup.rsti +.. include:: ../../imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: ../../imx-common/development/standalone_build_preface.rsti +.. include:: ../../imx-common/development/standalone_build_u-boot_imxmkimage.rsti +.. include:: ../../imx-common/development/standalone_build_kernel.rsti + +.. include:: ../../imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx93-pd24.1.0-device-tree: +.. include:: /bsp/device-tree.rsti + +:: + + imx93-phyboard-segin-peb-av-02.dtbo + imx93-phyboard-segin-peb-eval-01.dtbo + imx93-phycore-rpmsg.dtbo + +.. _imx93-pd24.1.0-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX93_PAD_UART1_RXD__LPUART1_RX 0x31e + MX93_PAD_UART1_TXD__LPUART1_TX 0x30e + >; + }; + +The first part of the string MX93_PAD_UART1_RXD__LPUART1_RX names the pad +(in this example UART1_RXD). The second part of the string (LPUART1_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal pull up is +activated. + +The device tree representation for UART1 pinmuxing: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n267` + +.. _imx93-pd24.1.0-network: + +Network +------- + +|sbc|-|soc| provides two ethernet interfaces. A 100 megabit Ethernet is provided by our +module and board. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n216` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx93-phycore-som.dtsi?h=v6.1.36_2.1.0-phy1#n195` + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/gpios.rsti + +.. include:: ../peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx93-phyboard-segin-peb-eval-01.dtso?h=v6.1.36_2.1.0-phy1#n33` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx93-phycore-som.dtsi?h=v6.1.36_2.1.0-phy1#n88` + +General I²C2 bus configuration (e.g. |dt-carrierboard|.dts) +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n155` + + +EEPROM +------ + +There are two different I2C EEPROM flashes populated on |som| SoM and on the +|sbc|. For now only the one on the |som| is enabled, and it is used for board +detection. + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file can be found in our PHYTEC git: +:imx-dt:`imx93-phycore-som.dtsi?h=v6.1.36_2.1.0-phy1#n173` + +.. include:: ../../peripherals/rtc.rsti + +DT representation for I²C RTCs: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n173` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 480 Mbps (HighSpeed +'HS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host, but on the |sbc| +one of them is used as a host-only port (USB-A connector). + +.. include:: /bsp/peripherals/usb-host.rsti + +The OTG port provides an additional pin for over-current protection, which is +not used on the |sbc|. Since it's not used, the driver part is also disabled +from within the device tree. In case this pin is used, activate this +over-current in the device tree and set the correct polarity (active high/low) +according to the device specification. For the correct setup, please refer to +the Kernel documentation under +Linux/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt. + +DT representation for USB Host: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n190` + +CAN FD +------ + +The |sbc| has one flexCAN interface supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon the Linux network layer. Using +this framework, the CAN interfaces behave like an ordinary Linux network device, +with some additional features special to CAN. More information can be found in +the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n147` + +Audio +----- + +On |sbc| the TI TLV320AIC3007 audio codec is used. It uses I2S for data +transmission and I2C for codec control. The audio signals available are: + +* Stereo LINE IN, +* Stereo LINE OUT, +* Output where D-Class 1W speaker can be connected + +.. include:: /bsp/peripherals/audio.rsti + :end-before: .. audio_alsa_configuration_start_label + +.. include:: /bsp/peripherals/audio.rsti + :start-after: .. audio_playback_start_label + :end-before: .. audio_capture_start_label + +If Speaker volume it too low you can increase its volume with (values 0-3): + +.. code-block:: console + + target:~$ amixer -c 0 sset Class-D 3 + +.. hint:: + + Speaker output is only mono so when stereo track is played only left channel + will be played by speaker. + +Capture +....... + +``arecord`` is a command-line tool for capturing audio streams which use Line In +as the default input source. + +.. code-block:: console + + target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav + +.. hint:: + + Since playback and capture share hardware interfaces, it is not possible to + use different sampling rates and formats for simultaneous playback and + capture operations. + +Device Tree Audio configuration: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n62` + +.. include:: /bsp/peripherals/video.rsti + +.. include:: display.rsti + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +The device tree of PEB-AV-02 can be found here: +:imx-dt:`imx93-phyboard-segin-peb-av-02.dtso?h=v6.1.36_2.1.0-phy1` + +.. include:: peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/bbnsm-power-key.rsti + +.. include:: ../peripherals/pxp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti diff --git a/previews/271/zh_CN/_sources/bsp/imx9/imx93/pd24.1.1.rst.txt b/previews/271/zh_CN/_sources/bsp/imx9/imx93/pd24.1.1.rst.txt new file mode 100644 index 000000000..3f9097290 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx9/imx93/pd24.1.1.rst.txt @@ -0,0 +1,933 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX93-PD24.1.1 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-91-93/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/sdk/ampliphy-vendor-wayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools/ +.. _`static-pdf-dl`: ../../../_static/imx93-pd24.1.1.pdf + +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx93 + +.. General Substitutions +.. |kit| replace:: **phyBOARD-Segin i.MX 93 and phyBOARD-Nash i.MX 93 Kit** +.. |kit-ram-size| replace:: 1GiB +.. |sbc| replace:: phyBOARD-Segin/Nash i.MX 93 +.. |soc| replace:: i.MX 93 +.. |socfamily| replace:: i.MX 9 +.. |som| replace:: phyCORE-i.MX93 +.. |debug-uart| replace:: ttyLP0 +.. |serial-uart| replace:: ttyLP6 +.. |expansion-connector| replace:: X16 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx_v8_defconfig imx9_phytec_distro.config imx9_phytec_platform.config +.. |kernel-recipe-path| replace:: meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb +.. |kernel-repo-name| replace:: linux-imx +.. |kernel-repo-url| replace:: git://git.phytec.de/linux-imx +.. |kernel-socname| replace:: imx93 +.. |kernel-tag| replace:: v6.1.55_2.2.0-phy3 +.. |emmcdev| replace:: mmcblk0 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 0 +.. |u-boot-defconfig| replace:: imx93-phyboard-segin_defconfig +.. |u-boot-multiple-defconfig-note| replace:: In command above replace ```` with ``imx93-phyboard-segin_defconfig`` or ``imx93-phyboard-nash_defconfig``, depending on the board you are about to build for. +.. |u-boot-multiple-dtb-note| replace:: In command above replace ```` with ``imx93-phyboard-segin.dtb`` or ``imx93-phyboard-nash.dtb``, depending on the board you are about to build for. +.. |u-boot-imx-mkimage-tag| replace:: lf-6.1.55-2.2.0 +.. |u-boot-soc-name| replace:: iMX9 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX93 specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX93 +.. |u-boot-tag| replace:: v2023.04_2.2.0-phy3 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx93-phyboard-segin +.. |dt-som| replace:: imx93-phycore-som +.. |dtbo-rpmsg| replace:: imx93-phycore-rpmsg.dtso + +.. IMX93 specific +.. |dt-somnetwork| replace:: :imx-dt:`imx93-phycore-som.dtsi?h=v6.1.55_2.2.0-phy3#n61` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`mickledore` +.. |yocto-bsp-name| replace:: BSP-Yocto-i.MX93 +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: mickledore +.. |yocto-distro| replace:: ampliphy-vendor-wayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: wic.xz +.. |yocto-machinename| replace:: phyboard-segin-imx93-2 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX93-PD24.1.1 +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (mickledore) ` +.. |yocto-sdk-rev| replace:: 4.2.3 +.. |yocto-sdk-a-core| replace:: cortexa55 + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: UART1 console on PEB-EVAL-01 for **phyBOARD-Segin** and X-37 + USB-C debug for **phyBOARD-Nash** +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X8 (USB micro/OTG connector) ` + + +.. IMX93 specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :imx-dt:`imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n114` or here: + :imx-dt:`imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n83`. + +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M33 Core +.. |ref-m-core-connections| replace:: :ref:`X16 ` +.. |mcore-jtag-dev| replace:: MIMX8MM6_M4 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Yocto Manual | Mickledore | ++-----------------------+----------------------+ +| Release Date | 2024/01/31 | ++-----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================ ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================ ========== +|yocto-manifestname| Minor 2024/05/07 Released +==================== ================ ================ ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname|, see `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware. + +.. tip:: + + **Console examples in this BSP manual only focus on phyBOARD-Segin i.MX 93. + Similar commands can also be executed for/on phyBOARD-Nash i.MX 93** + +.. _imx93-PD24.1.1-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx93-PD24.1.1-getting-started: +.. include:: /bsp/getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the + following position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the targets debug console with your host. Use |ref-debugusbconnector|. +* Power up the board +* Open serial/usb port with 115200 baud and 8N1 (you should see u-boot/linux + start on the console + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx93-PD24.1.1-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx93.bin**: ARM Trusted Firmware binary +* **lpddr4_dmem_1d_v202201.bin, lpddr4_dmem_2d_v202201.bin, + lpddr4_imem_1d_v202201.bin, + lpddr4_imem_2d_v202201.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which + is bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx93-phyboard-*.dtb**: Kernel device tree file +* **imx93-phy\*.dtbo**: Kernel device tree overlay files +* **phytec-\*.tar.gz**: Root file system, + of bitbake-image that was built. + + * **phytec-qt6demo-image-phyboard-*-imx93-*.tar.gz**: when bitbake-build + was processed for ``phytec-qt6demo-image`` + * **phytec-headless-image-phyboard-*-imx93-*.tar.gz**: when bitbake-build + was processed for ``phytec-headless-image`` +* **phytec-\*.wic.xz**: Compressed bootable SD + card image of bitbake-image that was built. Includes bootloader, DTBs, Kernel + and Root file system. + + * **phytec-qt6demo-image-phyboard-*-imx93-*.wic.xz**: when bitbake-build + was processed for ``phytec-qt6demo-image`` + * **phytec-headless-image-phyboard-*-imx93-*.wic.xz**: when bitbake-build + was processed for ``phytec-headless-image`` +* **imx93-11x11-evk_m33_\*.bin**, binaries of demo applications for the + Cortex-M33 MCU; can be manually loaded and started with U-Boot or Linux + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: + + * phyBOARD-Segin-i.MX 93: 1472.5 + * phyBOARD-Nash-i.MX 93: 1616.0 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx93-PD24.1.1-bootswitch: +.. include:: bootmode-switch.rsti + +Flash eMMC +---------- + +To boot from eMMC, make sure that the BSP image is flashed correctly to the eMMC +and the |ref-bootswitch| is set to **eMMC**. + +.. warning:: + When eMMC and SD card are flashed with the same (identical) image, the UUIDs + of the boot partitions are also identical. If the SD card is connected when + booting, this leads to non-deterministic behavior as Linux mounts the boot + partition based on UUID. + + .. code-block:: console + + target:~$ blkid + + can be run to inspect whether the current setup is affected. If |emmcdev|\p1 + and mmcblk1p1 have an identical UUID, the setup is affected. + +Flash eMMC from SD Card +....................... + +If there is no network available, you can update the eMMC from SD card. For +that, you only need a ready-to-use image file (``*.wic``) located on the +SD card. Because the image file is quite large, you have to enlarge your SD card +to use its full space (if it was not enlarged before). To enlarge your SD card, +see Resizing ext4 Root Filesystem. + +Alternatively, flash a partup package to the SD card, as described in +|ref-getting-started|. This will ensure the full space of the SD card is used. + +Flash eMMC from SD card in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can flash the eMMC on Linux. You only need a partup package or WIC image +saved on the SD card. + +* Show your saved partup package or WIC image or WIC.XZ image files on the SD card: + + .. code-block:: console + :substitutions: + + target:~$ ls + |yocto-imagename|-|yocto-machinename|.partup + |yocto-imagename|-|yocto-machinename|.|yocto-imageext| + +* Show list of available MMC devices: + + .. code-block:: console + :substitutions: + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + |emmcdev| + |emmcdev|boot0 + |emmcdev|boot1 + |emmcdev|p1 + |emmcdev|p2 + |emmcdev|rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (|emmcdev|\ **boot0**; |emmcdev|\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (/dev/|emmcdev| **without** + partition) using `partup`_: + + .. code-block:: console + :substitutions: + + target:~$ partup install |yocto-imagename|-|yocto-machinename|.partup /dev/|emmcdev| + + .. tip:: + + **Using partup is highly recommended since it is easier to use and has the + advantage of using the full capacity of the eMMC device, adjusting + partitions accordingly.** + + .. note:: + + Alternatively, ``dd`` may be used instead. + + For uncompressed WIC images (\*.wic): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/|emmcdev| bs=1M conv=fsync status=progress + + For compressed WIC images (\*.wic.xz): + + .. code-block:: console + :substitutions: + + target:~$ zstdcat |yocto-imagename|-|yocto-machinename|.wic.xz | sudo dd of=/dev/|emmcdev| bs=1M conv=fsync status=progress + + Keep in mind that the root partition does not make use of the full space + when flashing with ``dd``. + +* After a complete write, your board can boot from eMMC. + + .. warning:: + + Before this will work, you need to configure the |ref-bootswitch| to eMMC. + +Flash eMMC from Network +....................... + +|soc| boards have an Ethernet connector and can be updated over a network. Be +sure to set up the development host correctly. The IP needs to be set to +192.168.3.10, the netmask to 255.255.255.0, and a TFTP server needs to be +available. From a high-level point of view, an eMMC device is like an SD card. +Therefore, it is possible to flash the **WIC image** (``.wic``) from +the Yocto build system directly to the eMMC. The image contains the +bootloader, kernel, device tree, device tree overlays, and root file system. + +.. note:: + + Some PHYTECs BSPs produce compressed ``.wic.xz`` images. In this case, the + compressed image must first be uncompressed. + + .. code-block:: console + :substitutions: + + host:~$ unxz phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz + +Flash eMMC via Network in Linux on Target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can update the eMMC from your target. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Take an uncompressed image on the host and send it with ssh through +the network to the eMMC of the target with a one-line command: + +.. code-block:: console + :substitutions: + + target:~$ ssh @192.168.3.10 "dd if=/|yocto-imagename|-|yocto-machinename|.wic" | dd of=/dev/|emmcdev| bs=1M conv=fsync status=progress + +Flash eMMC via Network in Linux on Host +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is also possible to install the OS at eMMC from your Linux host. As before, +you need a complete image on your host. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Show your available image files on the host: + +.. code-block:: console + :substitutions: + + host:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +Send the image with the ``dd`` command combined with ssh through the network +to the eMMC of your device: + +.. code-block:: console + :substitutions: + + host:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic bs=1M status=progress | ssh root@192.168.3.11 "dd of=/dev/|emmcdev| conv=fsync" + +Flash eMMC U-Boot image via Network from running U-Boot +....................................................... + +Update the standalone U-Boot image imx-boot is also possible from U-Boot. This +can be used if the bootloader on eMMC is located in the eMMC user area. + +.. tip:: + + A working network is necessary! |ref-setup-network-host| + +Load image over tftp into RAM and then write it to eMMC: + +.. code-block:: + :substitutions: + + u-boot=> tftp ${loadaddr} imx-boot + u-boot=> setexpr nblk ${filesize} / 0x200 + u-boot=> mmc dev 0 + u-boot=> mmc write ${loadaddr} |u-boot-mmc-flash-offset| ${nblk} + +.. hint:: + The hexadecimal value represents the offset as a multiple of 512 byte + blocks. See the `offset table <#offset-table>`__ for the correct value + of the corresponding SoC. + +Flash eMMC from USB +................... + +Flash eMMC from USB in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +|yocto-imagename|-|yocto-machinename|.wic). Set the |ref-bootswitch| to SD Card. + +* Insert and mount the USB stick: + + .. code-block:: console + + [ 60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected + [ 60.467286] scsi host0: usb-storage 1-1.1:1.0 + [ 61.504607] scsi 0:0:0:0: Direct-Access 8.07 PQ: 0 ANSI: 2 + [ 61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB) + [ 61.523285] sd 0:0:0:0: [sda] Write Protect is off + [ 61.528509] sd 0:0:0:0: [sda] No Caching mode page found + [ 61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through + [ 61.665969] sda: sda1 + [ 61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk + target:~$ mount /dev/sda1 /mnt + +* Now show your saved image files on the USB Stick: + + .. code-block:: console + :substitutions: + + target:~$ cd /mnt + target:~$ ls + |yocto-imagename|-|yocto-machinename|.wic + +* Show list of available MMC devices: + + .. code-block:: console + :substitutions: + + target:~$ ls /dev | grep mmc + mmcblk1 + mmcblk1p1 + mmcblk1p2 + |emmcdev| + |emmcdev|boot0 + |emmcdev|boot1 + |emmcdev|p1 + |emmcdev|p2 + |emmcdev|rpmb + +* The eMMC device can be recognized by the fact that it contains two boot + partitions: (|emmcdev|\ **boot0**; |emmcdev|\ **boot1**) +* Write the image to the phyCORE-|soc| eMMC (/dev/|emmcdev| without partition): + + .. code-block:: console + :substitutions: + + target:~$ dd if=|yocto-imagename|-|yocto-machinename|.wic of=/dev/|emmcdev| bs=1M conv=fsync status=progress + +* After a complete write, your board can boot from eMMC. + + .. tip:: + + Before this will work, you need to configure the |ref-bootswitch| to + **eMMC**. + +RAUC +---- + +The RAUC (Robust Auto-Update Controller) mechanism support has been added to +meta-ampliphy. It controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. +PHYTEC has written an online manual on how we have intergraded RAUC into our +BSPs: `L-1006e.A5 RAUC Update & Device Management Manual +`__. + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx93-PD24.1.1-development: + +Development +=========== + +.. include:: ../../imx-common/development/host_network_setup.rsti +.. include:: ../../imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: ../../imx-common/development/standalone_build_preface.rsti +.. include:: ../../imx-common/development/standalone_build_u-boot_imxmkimage.rsti +.. include:: ../../imx-common/development/standalone_build_kernel.rsti + +.. include:: ../../imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx93-PD24.1.1-device-tree: +.. include:: /bsp/device-tree.rsti + +:: + + imx93-phyboard-segin-peb-av-02.dtbo + imx93-phyboard-segin-peb-eval-01.dtbo + imx93-phycore-rpmsg.dtbo + imx93-phycore-no-emmc.dtbo + imx93-phycore-no-eth.dtbo + +Available overlays for phyboard-nash-imx93-1.conf are: + +:: + + imx93-phyboard-nash-peb-av-010.dtbo + imx93-phycore-rpmsg.dtbo + imx93-phycore-no-emmc.dtbo + imx93-phycore-no-eth.dtbo + +.. _imx93-PD24.1.1-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX93_PAD_UART1_RXD__LPUART1_RX 0x31e + MX93_PAD_UART1_TXD__LPUART1_TX 0x30e + >; + }; + +The first part of the string MX93_PAD_UART1_RXD__LPUART1_RX names the pad +(in this example UART1_RXD). The second part of the string (LPUART1_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal pull up is +activated. + +The device tree representation for UART1 pinmuxing: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n262` + +.. _imx93-PD24.1.1-network: + +Network +------- + +|sbc| provides two ethernet interfaces. + +* On **phyBOARD-Segin** we have: + + * a 100 megabit Ethernet provided by |som| + * and 100 megabit Ethernet provided by phyBOARD. + +* On **phyBOARD-Nash** we have: + + * a 100 megabit Ethernet provided by |som| + * and 1 gigabit Ethernet provided by phyBOARD. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n216` or here: +:imx-dt:`imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n201` + +DT configuration for the eMMC interface can be found here: +:imx-dt:`imx93-phycore-som.dtsi?h=v6.1.55_2.2.0-phy3#n194` or here: + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/gpios.rsti + +.. include:: /bsp/peripherals/adc.rsti + +On phyBOARD-Nash the ADC lines are accessible on X16 expansion connector: + +========= ======== +ADC input X16 pin +========= ======== +ADC_IN0 47 +ADC_IN2 49 +========= ======== + +.. include:: ../peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:imx-dt:`imx93-phyboard-segin-peb-eval-01.dtso?h=v6.1.55_2.2.0-phy3#n33` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C1 bus configuration (e.g. |dt-som|.dtsi): +:imx-dt:`imx93-phycore-som.dtsi?h=v6.1.55_2.2.0-phy3#n88` + +General I²C2 bus configuration for |dt-carrierboard|.dts: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n155` or for +imx93-phyboard-nash.dts: +:imx-dt:`imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n113` + + +EEPROM +------ + +There are two different I2C EEPROM flashes populated on |som| SoM and on the +|sbc|. For now only the one on the |som| is enabled, and it is used for board +detection. + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file can be found in our PHYTEC git: +:imx-dt:`imx93-phycore-som.dtsi?h=v6.1.55_2.2.0-phy3#n172` + +.. include:: ../../peripherals/rtc.rsti + +DT representation for I²C RTCs: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n173` or +:imx-dt:`imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n122` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 480 Mbps (HighSpeed +'HS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host, but on the |sbc| +one of them is used as a host-only port (USB-A connector). + +.. include:: /bsp/peripherals/usb-host.rsti + +The OTG port provides an additional pin for over-current protection, which is +not used on the |sbc|. Since it's not used, the driver part is also disabled +from within the device tree. In case this pin is used, activate this +over-current in the device tree and set the correct polarity (active high/low) +according to the device specification. For the correct setup, please refer to +the Kernel documentation under +Linux/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt. + +DT representation for USB Host: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n190` or +:imx-dt:`imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n180` + +RS232/RS485 +----------- + +The **phyBOARD-Nash** i.MX 93 SoC provides one RS232/RS485 serial port. + +.. warning:: + RS232 with HW flow control and RS485 are not working due to HW bug on the + phyBOARD-Nash PCB revision 1616.0 + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti + +The device tree representation for RS232 and RS485: +:imx-dt:`imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n173` + +CAN FD +------ + +The |sbc| has one flexCAN interface supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon the Linux network layer. Using +this framework, the CAN interfaces behave like an ordinary Linux network device, +with some additional features special to CAN. More information can be found in +the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n147` or +:imx-dt:`imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n105` + +Audio on phyBOARD-Segin +----------------------- + +On phyBOARD-Segin i.MX 93 the TI TLV320AIC3007 audio codec is used. It uses I2S +for data transmission and I2C for codec control. The audio signals available +are: + +* Stereo LINE IN, +* Stereo LINE OUT, +* Output where D-Class 1W speaker can be connected + +.. include:: /bsp/peripherals/audio.rsti + :end-before: .. audio_alsa_configuration_start_label + +.. include:: /bsp/peripherals/audio.rsti + :start-after: .. audio_playback_start_label + :end-before: .. audio_capture_start_label + +If Speaker volume it too low you can increase its volume with (values 0-3): + +.. code-block:: console + + target:~$ amixer -c 0 sset Class-D 3 + +.. hint:: + + Speaker output is only mono so when stereo track is played only left channel + will be played by speaker. + +Capture +....... + +``arecord`` is a command-line tool for capturing audio streams which use Line In +as the default input source. + +.. code-block:: console + + target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav + +.. hint:: + + Since playback and capture share hardware interfaces, it is not possible to + use different sampling rates and formats for simultaneous playback and + capture operations. + +Device Tree Audio configuration: +:imx-dt:`imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n62` + +Audio on phyBOARD-Nash +---------------------- + +.. warning:: + + Due to HW bug Audio is broken on phyBOARD-Nash i.MX 93 PCB revision: 1616.0 + +To use audio with phyBOARD-Nash an additional adapter for the Audio/Video +connector is needed. The PEB-AV-10 (1531.1 revision) can be bought separately to +the Kit. PEB-AV-10 is populated with a TI TLV320AIC3007 audio codec. Audio +support is done via the I2S interface and controlled via I2C. + +There is a 3.5mm headset jack with OMTP standard and an 8-pin header to connect +audio devices with the AV-Connector. The 8-pin header contains a mono speaker, +headphones, and line-in signals. + +.. include:: /bsp/peripherals/audio.rsti + +Device Tree Audio configuration: +:imx-dt:`imx93-phyboard-nash-peb-av-010.dtso?h=v6.1.55_2.2.0-phy3#n57` + +.. include:: /bsp/peripherals/video.rsti + +.. include:: display.rsti + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +The device tree of PEB-AV-02 can be found here: +:imx-dt:`imx93-phyboard-segin-peb-av-02.dtso?h=v6.1.55_2.2.0-phy3` + +The device tree of PEB-AV-10 can be found here: +:imx-dt:`imx93-phyboard-nash-peb-av-010.dtso?h=v6.1.55_2.2.0-phy3` + +.. include:: peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/bbnsm-power-key.rsti + +.. include:: ../peripherals/pxp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. include:: /bsp/imx9/imx93/peripherals/tpm.rsti + +Device tree TPM configuration can be found here: +:imx-dt:`imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n151` + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti diff --git a/previews/271/zh_CN/_sources/bsp/imx9/imx93/pd24.2.0.rst.txt b/previews/271/zh_CN/_sources/bsp/imx9/imx93/pd24.2.0.rst.txt new file mode 100644 index 000000000..35fa7bf43 --- /dev/null +++ b/previews/271/zh_CN/_sources/bsp/imx9/imx93/pd24.2.0.rst.txt @@ -0,0 +1,676 @@ +.. Download links +.. |dlpage-bsp| replace:: our BSP +.. _dlpage-bsp: https://www.phytec.de/bsp-download/?bsp=BSP-Yocto-NXP-i.MX93-PD24.2.0 +.. |dlpage-product| replace:: https://www.phytec.de/produkte/system-on-modules/phycore-imx-91-93/#downloads +.. _dl-server: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/ +.. _dl-sdk: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/sdk/ampliphy-vendor-wayland/ +.. |link-image| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic.xz +.. |link-partup-package| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.partup +.. |link-boot-tools| replace:: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools/ +.. _`static-pdf-dl`: ../../../_static/imx93-pd24.2.0.pdf + +.. _releasenotes: https://git.phytec.de/phy2octo/tree/releasenotes?h=imx93 + +.. General Substitutions +.. |kit| replace:: **phyBOARD-Segin i.MX 93 and phyBOARD-Nash i.MX 93 Kit** +.. |kit-ram-size| replace:: 1GiB +.. |sbc| replace:: phyBOARD-Segin/Nash i.MX 93 +.. |sbc-segin| replace:: phyBOARD-Segin i.MX 93 +.. |sbc-nash| replace:: phyBOARD-Nash i.MX 93 +.. |soc| replace:: i.MX 93 +.. |socfamily| replace:: i.MX 9 +.. |som| replace:: phyCORE-i.MX93 +.. |debug-uart| replace:: ttyLP0 +.. |serial-uart| replace:: ttyLP6 +.. |expansion-connector| replace:: X16 + + +.. Linux Kernel +.. |kernel-defconfig| replace:: imx9_phytec_defconfig +.. |kernel-recipe-path| replace:: meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb +.. |kernel-repo-name| replace:: linux-phytec-imx +.. |kernel-repo-url| replace:: git://github.com/phytec/linux-phytec-imx.git +.. |kernel-socname| replace:: imx93 +.. |kernel-tag| replace:: v6.6.23-2.0.0-phy8 +.. |emmcdev| replace:: mmcblk0 + +.. Bootloader +.. |u-boot-offset| replace:: 32 +.. |u-boot-offset-boot-part| replace:: 0 +.. |u-boot-mmc-flash-offset| replace:: 0x40 +.. |u-boot-emmc-devno| replace:: 0 +.. |u-boot-defconfig| replace:: imx93-phycore_defconfig +.. |u-boot-multiple-defconfig-note| replace:: In command above replace ```` with ``imx93-phycore_defconfig`` +.. |u-boot-multiple-dtb-note| replace:: In command above replace ```` with ``imx93-phyboard-segin.dtb`` +.. |u-boot-imx-mkimage-tag| replace:: lf-6.6.23-2.0.0 +.. |u-boot-soc-name| replace:: iMX9 +.. |u-boot-recipe-path| replace:: meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb +.. |u-boot-repo-name| replace:: u-boot-imx +.. |u-boot-repo-url| replace:: git://git.phytec.de/u-boot-imx + +.. IMX93 specific +.. |u-boot-socname-config| replace:: PHYCORE_IMX93 +.. |u-boot-tag| replace:: v2024.04-2.0.0-phy6 + + +.. Devicetree +.. |dt-carrierboard| replace:: imx93-phyboard-segin +.. |dt-som| replace:: imx93-phycore-som +.. |dtbo-rpmsg| replace:: imx93-phycore-rpmsg.dtso + +.. IMX93 specific +.. |dt-somnetwork| replace:: :linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi#L61` + +.. Yocto +.. |yocto-bootenv-link| replace:: :yocto-bootenv:`scarthgap` +.. |yocto-bsp-name| replace:: BSP-Yocto-i.MX93 +.. _yocto-bsp-name: `dl-server`_ +.. |yocto-codename| replace:: scarthgap +.. |yocto-distro| replace:: ampliphy-vendor-wayland +.. |yocto-imagename| replace:: phytec-qt6demo-image +.. |yocto-imageext| replace:: wic.xz +.. |yocto-machinename| replace:: phyboard-segin-imx93-2 +.. |yocto-manifestname| replace:: BSP-Yocto-NXP-i.MX93-PD24.2.0 +.. |yocto-ref-manual| replace:: :ref:`Yocto Reference Manual (scarthgap) ` +.. |yocto-sdk-rev| replace:: 5.0 +.. |yocto-sdk-a-core| replace:: cortexa55 + +.. Ref Substitutions +.. |ref-bootswitch| replace:: :ref:`bootmode switch (S3) ` +.. |ref-bsp-images| replace:: :ref:`BSP Images ` +.. |ref-debugusbconnector| replace:: UART1 console on PEB-EVAL-01 for **phyBOARD-Segin** and X-37 + USB-C debug for **phyBOARD-Nash** +.. |ref-dt| replace:: :ref:`device tree ` +.. |ref-getting-started| replace:: :ref:`Getting Started ` +.. |ref-network| replace:: :ref:`Network Environment Customization ` +.. |ref-setup-network-host| replace:: :ref:`Setup Network Host ` +.. |ref-usb-otg| replace:: :ref:`X8 (USB micro/OTG connector) ` + + +.. IMX93 specific +.. |sbc-network| replace:: + The device tree set up for EQOS Ethernet IP core where the PHY is populated + on the |sbc| can be found here: + :linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L114` or here: + :linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L83`. + +.. |ubootexternalenv| replace:: U-boot External Environment subsection of the + :ref:`device tree overlay section ` + + +.. M-Core specific +.. |mcore| replace:: M33 Core +.. |ref-m-core-connections| replace:: :ref:`X16 ` +.. |mcore-jtag-dev| replace:: MIMX8MM6_M4 +.. |mcore-sdk-version| replace:: 2.13.0 + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-----------------------+----------------------+ +| |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Title | |soc| BSP Manual | ++-----------------------+----------------------+ +| Document Type | BSP Manual | ++-----------------------+----------------------+ +| Yocto Manual | Scarthgap | ++-----------------------+----------------------+ +| Release Date | 2024/10/08 | ++-----------------------+----------------------+ +| Is Branch of | |soc| BSP Manual | ++-----------------------+----------------------+ + +The table below shows the Compatible BSPs for this manual: + +==================== ================ ================ ========== +Compatible BSPs BSP Release Type BSP Release Date BSP Status + +==================== ================ ================ ========== +|yocto-manifestname| Major 2024/10/08 Released +==================== ================ ================ ========== + + +.. include:: ../../intro.rsti + +Supported Hardware +------------------ + +On our web page, you can see all supported Machines with the available Article +Numbers for this release: |yocto-manifestname|, see `download `_. + +If you choose a specific **Machine Name** in the section **Supported Machines**, +you can see which **Article Numbers** are available under this machine and also +a short description of the hardware information. In case you only have +the **Article Number** of your hardware, you can leave the **Machine +Name** drop-down menu empty and only choose your **Article Number**. Now it +should show you the necessary **Machine Name** for your specific hardware. + +.. tip:: + + **Console examples in this BSP manual only focus on phyBOARD-Segin i.MX 93. + Similar commands can also be executed for/on phyBOARD-Nash i.MX 93** + +.. _imx93-PD24.2.0-components: +.. include:: components.rsti + +.. +---------------------------------------------------------------------------+ +.. Getting Started +.. +---------------------------------------------------------------------------+ + +.. _imx93-PD24.2.0-getting-started: +.. include:: /bsp/getting-started.rsti + +First Start-up +-------------- + +* To boot from an SD card, the |ref-bootswitch| needs to be set to the + following position: + +.. image:: images/SD_Card_Boot.png + +* Insert the SD card +* Connect the targets debug console with your host. Use |ref-debugusbconnector|. +* Power up the board +* Open serial/usb port with 115200 baud and 8N1 (you should see u-boot/linux + start on the console + +.. +---------------------------------------------------------------------------+ +.. Building the BSP +.. +---------------------------------------------------------------------------+ + +.. include:: /bsp/building-bsp.rsti + +.. _imx93-PD24.2.0-images: + +* **u-boot.bin**: Binary compiled U-boot bootloader (U-Boot). Not the final + Bootloader image! +* **oftree**: Default kernel device tree +* **u-boot-spl.bin**: Secondary program loader (SPL) +* **bl31-imx93.bin**: ARM Trusted Firmware binary +* **lpddr4_dmem_1d_v202201.bin, lpddr4_dmem_2d_v202201.bin, + lpddr4_imem_1d_v202201.bin, + lpddr4_imem_2d_v202201.bin**: DDR PHY firmware images +* **imx-boot**: Bootloader build by imx-mkimage which includes SPL, U-Boot, ARM + Trusted Firmware and DDR firmware. This is the final bootloader image which + is bootable. +* **Image**: Linux kernel image +* **Image.config**: Kernel configuration +* **imx93-phyboard-*.dtb**: Kernel device tree file +* **imx93-phy\*.dtbo**: Kernel device tree overlay files +* **phytec-\*.tar.gz**: Root file system, + of bitbake-image that was built. + + * **phytec-qt6demo-image-phyboard-*-imx93-*.tar.gz**: when bitbake-build + was processed for ``phytec-qt6demo-image`` + * **phytec-headless-image-phyboard-*-imx93-*.tar.gz**: when bitbake-build + was processed for ``phytec-headless-image`` +* **phytec-\*.rootfs.wic.xz**: Compressed bootable SD + card image of bitbake-image that was built. Includes bootloader, DTBs, Kernel + and Root file system. + + * **phytec-qt6demo-image-phyboard-*-imx93-*.rootfs.wic.xz**: when bitbake-build + was processed for ``phytec-qt6demo-image`` + * **phytec-headless-image-phyboard-*-imx93-*.rootfs.wic.xz**: when bitbake-build + was processed for ``phytec-headless-image`` +* **imx93-11x11-evk_m33_\*.bin**, binaries of demo applications for the + Cortex-M33 MCU; can be manually loaded and started with U-Boot or Linux + +.. +---------------------------------------------------------------------------+ +.. INSTALLING THE OS +.. +---------------------------------------------------------------------------+ + +Installing the OS +================= + +Bootmode Switch (S3) +-------------------- + +.. tip:: + + Hardware revision baseboard: + + * |sbc-segin|: 1472.5 + * |sbc-nash|: 1616.0, 1616.1 + +The |sbc| features a boot switch with four individually switchable ports to +select the phyCORE-|soc| default bootsource. + +.. _imx93-PD24.2.0-bootswitch: +.. include:: bootmode-switch.rsti + +.. include:: ../installing-os.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVELOPMENT +.. +---------------------------------------------------------------------------+ + +.. _imx93-PD24.2.0-development: + +Development +=========== + +.. include:: ../../imx-common/development/host_network_setup.rsti +.. include:: ../../imx-common/development/netboot.rsti + +Working with UUU-Tool +--------------------- + +The Universal Update Utility Tool (UUU-Tool) from NXP is a software to execute +on the host to load and run the bootloader on the board through SDP (Serial +Download Protocol). For detailed information visit +https://github.com/nxp-imx/mfgtools or download the `Official UUU-tool +documentation `_. + +Host preparations for UUU-Tool Usage +.................................... + +* Follow the instructions from https://github.com/nxp-imx/mfgtools#linux. + +* If you built UUU from source, add it to ``PATH``: + + This BASH command adds UUU only temporarily to ``PATH``. To add it permanently, add this line to + ``~/.bashrc``. + + .. code-block:: console + + export PATH=~/mfgtools/uuu/:"$PATH" + +* Set udev rules (documented in ``uuu -udev``): + + .. code-block:: console + + host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules" + host:~$ sudo udevadm control --reload + +Get Images +.......... + +Download imx-boot from our server or get it from your Yocto build directory at +build/deploy/images/|yocto-machinename|/. For flashing a wic image to eMMC, +you will also need |yocto-imagename|-|yocto-machinename|.wic. + +Prepare Target +.............. + +Set the |ref-bootswitch| to **USB Serial Download**. Also, connect USB port +|ref-usb-otg| to your host. + +Starting bootloader via UUU-Tool +................................ + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b spl imx-boot + +You can see the bootlog on the console via |ref-debugusbconnector|, as usual. + +.. note:: + The default boot command when booting with UUU-Tool is set to fastboot. If + you want to change this, please adjust the environment variable bootcmd_mfg + in U-boot prompt with setenv bootcmd_mfg. Please note, when booting with + UUU-tool the default environment is loaded. Saveenv has no effect. If you + want to change the boot command permanently for UUU-boot, you need to change + this in U-Boot code. + +Flashing U-boot Image to eMMC via UUU-Tool +........................................... + +.. warning:: + + UUU flashes U-boot into eMMC BOOT (hardware) boot partitions, and it sets + the BOOT_PARTITION_ENABLE in the eMMC! This is a problem since we want the + bootloader to reside in the eMMC USER partition. Flashing next U-Boot version + .wic image and not disabling BOOT_PARTITION_ENABLE bit will result in device + always using U-boot saved in BOOT partitions. To fix this in U-Boot: + + .. code-block:: console + :substitutions: + + u-boot=> mmc partconf |u-boot-emmc-devno| 0 0 0 + u-boot=> mmc partconf |u-boot-emmc-devno| + EXT_CSD[179], PARTITION_CONFIG: + BOOT_ACK: 0x0 + BOOT_PARTITION_ENABLE: 0x0 + PARTITION_ACCESS: 0x0 + + or check :ref:`Disable booting from eMMC boot partitions ` + from Linux. + + This way the bootloader is still flashed to eMMC BOOT partitions but it is + not used! + + When using **partup** tool and ``.partup`` package for eMMC flashing this is + done by default, which makes partup again superior flash option. + +Execute and power up the board: + +.. code-block:: console + + host:~$ sudo uuu -b emmc imx-boot + +Flashing wic Image to eMMC via UUU-Tool +........................................... + +Execute and power up the board: + +.. code-block:: console + :substitutions: + + host:~$ sudo uuu -b emmc_all imx-boot |yocto-imagename|-|yocto-machinename|.wic + +.. include:: ../../imx-common/development/standalone_build_preface.rsti +.. include:: ../../imx-common/development/standalone_build_u-boot_imxmkimage.rsti +.. include:: ../../imx-common/development/standalone_build_kernel.rsti + +.. include:: ../../imx-common/development/format_sd-card.rsti + +.. +---------------------------------------------------------------------------+ +.. DEVICE TREE +.. +---------------------------------------------------------------------------+ + +.. _imx93-PD24.2.0-device-tree: +.. include:: /bsp/device-tree.rsti + +:: + + imx93-phyboard-segin-peb-av-02.dtbo + imx93-phyboard-segin-peb-eval-01.dtbo + imx93-phyboard-segin-peb-wlbt-05.dtbo + imx93-phycore-rpmsg.dtbo + imx93-phycore-no-emmc.dtbo + imx93-phycore-no-eth.dtbo + +Available overlays for phyboard-nash-imx93-1.conf are: + +:: + + imx93-phyboard-nash-jtag.dtbo + imx93-phyboard-nash-peb-av-10.dtbo + imx93-phyboard-nash-pwm-fan.dtbo + imx93-phyboard-nash-vm016.dtbo + imx93-phycore-rpmsg.dtbo + imx93-phycore-no-emmc.dtbo + imx93-phycore-no-eth.dtbo + +.. _imx93-PD24.2.0-ubootexternalenv: +.. include:: ../dt-overlays.rsti + +.. +---------------------------------------------------------------------------+ +.. ACCESSING PERIPHERALS +.. +---------------------------------------------------------------------------+ + + +.. include:: /bsp/peripherals/introduction.rsti + +.. include:: /bsp/imx-common/peripherals/pin-muxing.rsti + +The following is an example of the pin muxing of the UART1 device in +|dt-carrierboard|.dts: + +.. code-block:: + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX93_PAD_UART1_RXD__LPUART1_RX 0x31e + MX93_PAD_UART1_TXD__LPUART1_TX 0x30e + >; + }; + +The first part of the string MX93_PAD_UART1_RXD__LPUART1_RX names the pad +(in this example UART1_RXD). The second part of the string (LPUART1_RX) is the +desired muxing option for this pad. The pad setting value (hex value on the +right) defines different modes of the pad, for example, if internal pull +resistors are activated or not. In this case, the internal pull up is +activated. + +The device tree representation for UART1 pinmuxing: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L259` + +.. _imx93-PD24.2.0-network: + +Network +------- + +|sbc| provides two ethernet interfaces. + +* On |sbc-segin| we have: + + * a 100 megabit Ethernet provided by |som| + * and 100 megabit Ethernet provided by phyBOARD. + +* On |sbc-nash| we have: + + * a 100 megabit Ethernet provided by |som| + * and 1 gigabit Ethernet provided by phyBOARD. + +.. include:: /bsp/imx-common/peripherals/network.rsti + +.. include:: wireless-network.rsti + +.. include:: ../../peripherals/wireless-network.rsti + :end-before: .. no-bluetooth-marker + +.. include:: /bsp/imx-common/peripherals/sd-card.rsti + +DT configuration for the MMC (SD card slot) interface can be found here: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L213` or here: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L202` + +DT configuration for the eMMC interface can be found here: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi#L194` or here: + +.. include:: /bsp/peripherals/emmc.rsti + +.. include:: /bsp/imx-common/emmc.rsti + +.. include:: ../peripherals/gpios.rsti + +.. include:: /bsp/peripherals/adc.rsti + +On |sbc-nash| the ADC lines are accessible on X16 expansion connector: + +========= ======== +ADC input X16 pin +========= ======== +ADC_IN0 47 +ADC_IN2 49 +========= ======== + +.. include:: ../peripherals/leds.rsti + +Device tree configuration for the User I/O configuration can be found here: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-eval-01.dtso#L33` + +.. include:: /bsp/imx-common/peripherals/i2c-bus.rsti + +General I²C3 bus configuration (e.g. |dt-som|.dtsi): +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi#L88` + +General I²C2 bus configuration for |dt-carrierboard|.dts: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L155` or for +imx93-phyboard-nash.dts: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L113` + + +EEPROM +------ + +There are two different I2C EEPROM flashes populated on |som| SoM and on the +|sbc|. For now only the one on the |som| is enabled, and it is used for board +detection. + +.. include:: ../peripherals/eeprom.rsti + +DT representation, e.g. in phyCORE-|soc| file can be found in our PHYTEC git: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi#L172` + +.. include:: ../../peripherals/rtc.rsti + +DT representation for I²C RTCs: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L173` or +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L122` + +USB Host Controller +------------------- + +The USB controller of the |soc| SoC provides a low-cost connectivity solution +for numerous consumer portable devices by providing a mechanism for data +transfer between USB devices with a line/bus speed of up to 480 Mbps (HighSpeed +'HS'). The USB subsystem has two independent USB controller cores. Both cores +are capable of acting as a USB peripheral device or a USB host, but on the |sbc| +one of them is used as a host-only port (USB-A connector). + +.. include:: /bsp/peripherals/usb-host.rsti + +The OTG port provides an additional pin for over-current protection, which is +not used on the |sbc|. Since it's not used, the driver part is also disabled +from within the device tree. In case this pin is used, activate this +over-current in the device tree and set the correct polarity (active high/low) +according to the device specification. For the correct setup, please refer to +the Kernel documentation under +Linux/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt. + +DT representation for USB Host: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L193` or +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L181` + +RS232/RS485 +----------- + +The |sbc-nash| i.MX 93 SoC provides one RS232/RS485 serial port. + +.. warning:: + RS232 with HW flow control and RS485 are not working due to HW bug on the + |sbc-nash| PCB revision 1616.0 + +.. include:: /bsp/peripherals/rs232.rsti +.. include:: /bsp/peripherals/rs485.rsti + +The device tree representation for RS232 and RS485: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L174` + +CAN FD +------ + +The |sbc| has one flexCAN interface supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon the Linux network layer. Using +this framework, the CAN interfaces behave like an ordinary Linux network device, +with some additional features special to CAN. More information can be found in +the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html + +.. include:: ../peripherals/canfd.rsti + +Device Tree CAN configuration of |dt-carrierboard|.dts: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L147` or +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L105` + +Audio on |sbc-segin| +-------------------- + +On |sbc-segin| the TI TLV320AIC3007 audio codec is used. It uses I2S +for data transmission and I2C for codec control. The audio signals available +are: + +* Stereo LINE IN, +* Stereo LINE OUT, +* Output where D-Class 1W speaker can be connected + +.. include:: /bsp/peripherals/audio.rsti + :end-before: .. audio_alsa_configuration_start_label + +.. include:: /bsp/peripherals/audio.rsti + :start-after: .. audio_playback_start_label + :end-before: .. audio_capture_start_label + +If Speaker volume it too low you can increase its volume with (values 0-3): + +.. code-block:: console + + target:~$ amixer -c 0 sset Class-D 3 + +.. hint:: + + Speaker output is only mono so when stereo track is played only left channel + will be played by speaker. + +Capture +....... + +``arecord`` is a command-line tool for capturing audio streams which use Line In +as the default input source. + +.. code-block:: console + + target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav + +.. hint:: + + Since playback and capture share hardware interfaces, it is not possible to + use different sampling rates and formats for simultaneous playback and + capture operations. + +Device Tree Audio configuration: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L62` + +Audio on |sbc-nash| +------------------- + +.. warning:: + + Due to HW bug Audio is broken on |sbc-nash| PCB revision: 1616.0 + +To use audio with |sbc-nash| an additional adapter for the Audio/Video +connector is needed. The PEB-AV-10 (1531.1 revision) can be bought separately to +the Kit. PEB-AV-10 is populated with a TI TLV320AIC3007 audio codec. Audio +support is done via the I2S interface and controlled via I2C. + +There is a 3.5mm headset jack with OMTP standard and an 8-pin header to connect +audio devices with the AV-Connector. The 8-pin header contains a mono speaker, +headphones, and line-in signals. + +.. include:: /bsp/peripherals/audio.rsti + +Device Tree Audio configuration: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash-peb-av-10.dtso#L56` + +.. include:: /bsp/peripherals/video.rsti + +.. include:: display.rsti + +.. include:: /bsp/qt6.rsti + +.. include:: /bsp/imx-common/peripherals/display.rsti + +The device tree of PEB-AV-02 can be found here: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-02.dtso` + +The device tree of PEB-AV-10 can be found here: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash-peb-av-10.dtso` + +.. include:: peripherals/pm.rsti + +.. include:: ../peripherals/tm.rsti + +.. include:: /bsp/peripherals/watchdog.rsti + +.. include:: ../peripherals/bbnsm-power-key.rsti + +.. include:: ../peripherals/pxp.rsti + +.. include:: ../peripherals/ocotp-ctrl.rsti + +.. include:: /bsp/imx9/imx93/peripherals/tpm.rsti + +Device tree TPM configuration can be found here: +:linux-phytec-imx:`blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L151` + +.. +---------------------------------------------------------------------------+ +.. i.MX 8M Plus M7 Core +.. +---------------------------------------------------------------------------+ + +.. include:: ../mcu.rsti diff --git a/previews/271/zh_CN/_sources/contributing_links.rst.txt b/previews/271/zh_CN/_sources/contributing_links.rst.txt new file mode 100644 index 000000000..7397e9c7f --- /dev/null +++ b/previews/271/zh_CN/_sources/contributing_links.rst.txt @@ -0,0 +1,15 @@ +========== +Contribute +========== + +Phytec's Yocto BSPs are released under open source licenses and we welcome +contributions to our Yocto BSPs and this documentation. Please check the Git +repositories for the individual projects and layers for contribution +guidelines. + +If you have a **question related to our Yocto BSPs** or notice **issues with +this documentation**, we encourage you to open an Issue or Pull-Request on the +Github repository `doc-bsp-yocto `__. +Have a look at the `Contributing guide +`__ for +more information. diff --git a/previews/271/zh_CN/_sources/index.rst.txt b/previews/271/zh_CN/_sources/index.rst.txt new file mode 100644 index 000000000..4c702990a --- /dev/null +++ b/previews/271/zh_CN/_sources/index.rst.txt @@ -0,0 +1,19 @@ +Welcome to the PHYTEC BSP Documentation +======================================= + +Welcome to the Documentation for our Yocto BSPs. + +.. toctree:: + :maxdepth: 1 + :caption: Contents + + yocto/manual-index + rauc/manual-index + bsp/imx8/imx8 + bsp/imx9/imx9 + +.. toctree:: + :maxdepth: 1 + :caption: Contribute + + contributing_links diff --git a/previews/271/zh_CN/_sources/rauc/kirkstone.rst.txt b/previews/271/zh_CN/_sources/rauc/kirkstone.rst.txt new file mode 100644 index 000000000..15f08b50d --- /dev/null +++ b/previews/271/zh_CN/_sources/rauc/kirkstone.rst.txt @@ -0,0 +1,1107 @@ +.. Download links +.. _`static-pdf-dl`: ../_static/rauc-kirkstone.pdf + +.. RAUC +.. |yocto-codename| replace:: Kirkstone +.. |rauc-manual| replace:: RAUC Update & Device Management Manual + +.. only:: html + + Documentation in pdf format: `Download `_ + ++---------------------------------------------------------------+ +| |rauc-manual| | ++=======================+=======================================+ +| Document Title | |rauc-manual| |yocto-codename| | ++-----------------------+---------------------------------------+ +| Document Type | RAUC Update & Device Management | +| | Manual | ++-----------------------+---------------------------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+---------------------------------------+ +| Is Branch of | |rauc-manual| | ++-----------------------+---------------------------------------+ + ++-------------------------------------+------------------+------------------+------------+ +| Compatible BSPs | BSP Release Type | BSP Release Date | BSP Status | ++=====================================+==================+==================+============+ +| BSP-Yocto-Ampliphy-i.MX6-PD22.1.0 | Major | 14.12.2022 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX6-PD22.1.1 | Minor | 20.06.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.0 | Major | 11.08.2022 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1 | Minor | 23.05.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX8MM-PD23.1.0 | Major | 12.12.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX8MP-PD23.1.0 | Major | 12.12.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM62x-PD23.2.0 | Major | 28.09.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM62Ax-PD23.1.0 | Major | 28.09.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM64x-PD23.2.0 | Major | 28.09.2023 | released | ++-------------------------------------+------------------+------------------+------------+ + +This manual was tested using the Yocto version |yocto-codename|. + +Introduction +============ + +PHYTEC's Yocto distribution Ampliphy (former Yogurt) supports the `RAUC +`_ (Robust Auto-Update Controller) +mechanism. RAUC controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. For +eMMC devices only, it can also update the bootloader. + +This manual describes how RAUC is used and implemented on various PHYTEC +platforms. Note, that different modules use different bootloaders and flash +storage devices, which affects the way things are handled by RAUC. Make sure to +read the correct sections fitting your platform. + +.. note:: + + This manual contains machine-specific paths and variable contents. Make sure + you are using the correct machine and device names for your application when + executing any commands. + + +System Configuration +==================== + +RAUC can be used with both eMMC and NAND flash storage. Using the distro +``ampliphy-rauc`` or ``ampliphy-vendor-rauc``, it is enabled by default and requires +no additional setup to get started. RAUC can be used in different update +scenarios. As an example, we configured the BSP to use an A/B setup to have a +completely redundant system (including the bootloader on eMMC devices). Note, +that there is an additional partition named ``config`` storing persistent +configuration data not being changed when updating. + +.. image:: /rauc/images/rauc-ab-system.png + +RAUC BSP Example Setup +---------------------- + +The partition layout is defined in the ``/etc/rauc/system.conf`` file. As an +example, this is what it looks like for i.MX 8M Mini with eMMC flash storage: + +.. code-block:: cfg + :caption: /etc/rauc/system.conf + + [system] + compatible=phyboard-polis-imx8mm-4 + bootloader=uboot + mountprefix=/mnt/rauc + + [handlers] + pre-install=/usr/lib/rauc/rauc-pre-install.sh + post-install=/usr/lib/rauc/rauc-post-install.sh + + [keyring] + path=mainca-rsa.crt.pem + + [slot.bootloader.0] + device=/dev/mmcblk2 + type=boot-emmc + + # System A + [slot.rootfs.0] + device=/dev/mmcblk2p5 + type=ext4 + bootname=system0 + + [slot.boot.0] + device=/dev/mmcblk2p1 + type=vfat + parent=rootfs.0 + + # System B + [slot.rootfs.1] + device=/dev/mmcblk2p6 + type=ext4 + bootname=system1 + + [slot.boot.1] + device=/dev/mmcblk2p2 + type=vfat + parent=rootfs.1 + +Note, that the devices specified in the slots are different depending on the +selected machine. + +.. warning:: + + Updates with RAUC use an OpenSSL certificate to verify the validity of an + image. The BSP includes a certificate that can be used for development. In a + productive system, however, it is highly recommended to use a self-created + key and certificate. If you need to change the keyring on an existing device, + see :ref:`Switching RAUC Keyrings ` for more + information. + +Design Considerations +===================== + +In order to prevent the system from locking up, it may be a good idea to utilize +a hardware watchdog. In case the Linux Kernel does not boot or another +catastrophic event occurs that prevents the system from operating normally, the +hardware watchdog then resets the system. By default, the hardware watchdog is +disabled. To enable it, refer to the corresponding BSP manual that fits your +SoM. + +Other important design considerations, as well as a checklist, can be found in +the official RAUC documentation: +https://rauc.readthedocs.io/en/latest/checklist.html + +Initial Setup +============= + +To use RAUC, the flash device needs to be written with a complete Linux system +and bootloader. The preferred method to do this is using the included tool +`partup `_. + +Flash Storage +------------- + +To flash the device with the correct partitions/volumes, use a partup package +built with the ``ampliphy-rauc`` or ``ampliphy-vendor-rauc`` distribution. +Prebuilt partup packages can be found in the BSP release. It is also possible to +build a package with this distribution yourself using Yocto. Change +``local.conf`` so separate build directories are created, storing the images and +packages for the RAUC system: + +.. code-block:: + :caption: build/conf/local.conf + + # When building multiple distros in the same TOPDIR + TMPDIR = "${TOPDIR}/tmp-${DISTRO}" + DEPLOY_DIR = "${TOPDIR}/deploy-${DISTRO}" + +Then initialize the build directory with the OE init script: + +.. code-block:: console + + host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source sources/poky/oe-init-build-env + +Change the distribution to ``ampliphy-rauc`` (for i.MX6, AM6x) or +``ampliphy-vendor-rauc`` (for i.MX8): + +.. code-block:: + :caption: build/conf/local.conf + + DISTRO ?= "ampliphy-rauc" + +Any image built with this distro now includes a full A/B system. Build the image +as usual: + +.. code-block:: console + + host:~$ bitbake phytec-headless-image + +The resulting partup package is stored in the ``deploy-ampliphy-vendor-rauc`` directory, e.g.: + +.. code-block:: + + deploy-ampliphy-vendor-rauc/images/phyboard-segin-imx93-2/phytec-headless-image-phyboard-segin-imx93-2.partup + +This partup package contains all the necessary data and configuration to flash +an eMMC. `Partup `__ can be obtained from its +`release page `_. Also, see its +README for detailed `installation instructions +`_. Partup is already installed +in our Ampliphy images, ``phytec-headless-image`` and can be directly used e.g. +from an SD card. + +.. note:: + To flash the initial RAUC system, a booted non-RAUC system is needed first on + a different flash device. E.g. you could boot a regular + ``phytec-headless-image`` image with distro ``ampliphy`` from an SD card. + +eMMC +.... + +While running a non-RAUC system from an SD card on the target, copy the +``.partup`` package built with distro ``ampliphy-rauc`` or +``ampliphy-vendor-rauc`` to the running target first: + +.. code-block:: console + + host:~$ scp phytec-headless-image-phyboard-segin-imx93-2.partup 192.168.3.11:/root + +Then install the partup package to the eMMC: + +.. code-block:: console + + target:~$ partup install phytec-headless-image-phyboard-segin-imx93-2.partup /dev/mmcblk0 + +Now the target can boot the flashed A/B system. + +NAND +.... + +.. note:: + + There are scripts provided with the bootloader barebox that previously were + used to initialize NAND flash with an A/B system: ``rauc_init_nand``, + ``rauc_flash_nand_from_tftp`` and ``rauc_flash_nand_from_mmc``. These scripts + are deprecated. It is advised to use the script ``rauc-flash-nand`` provided + in the Linux environment with PHYTEC's distribution *Ampliphy*. + +With raw NAND flash the kernel, device tree, and root filesystem are written +individually. Initialize the NAND flash with the correct volumes from a Linux on +the target: + +.. code-block:: console + + target:~$ rauc-flash-nand -k /path/to/zImage -d /path/to/oftree -r /path/to/root.ubifs + +The initialization script will automatically utilize all available space of NAND +flash. The NAND device is also determined automatically by finding the device +root in ``/proc/mtd``. + +On i.MX6 and i.MX6UL devices with barebox, use bbu (barebox update) to flash the +bootloader: + +.. code-block:: console + + target:~$ bbu.sh -f /path/to/barebox.bin + +The A/B system on NAND Flash is now ready to be booted. + +Bootloader +---------- + +Booting the A/B System by Default +................................. + +Booting the A/B system is done mostly automatically by the bootloader since the +Yocto release *hardknott*. For devices with eMMC flash storage, the +corresponding setting is written into the bootloader environment during the +building of the BSP. In particular, if the distribution ``ampliphy-rauc`` or +``ampliphy-vendor-rauc`` is used, as described previously, the bootloader should +automatically start the A/B system and have the variables set for RAUC +accordingly. + +This automatic setting can be manually changed by setting one variable in the +bootloader. The procedure is described in more detail in the following chapters +for U-Boot and barebox. + +U-Boot +...... + +After a successful boot into a Linux environment, this command is used to view +the available parameters: + +.. code-block:: console + + target:~$ fw_printenv + +You may see this parameter along with others in the output: + +.. code-block:: + + doraucboot=1 + +To manually disable or enable booting the A/B system with RAUC, set this +variable to ``0`` or ``1``: + +.. code-block:: console + + target:~$ fw_setenv doraucboot 1 + +This parameter can also be edited in U-Boot. Restart your board and hit any key +to stop the automatic boot. The environment variables can now be viewed: + +.. code-block:: + + u-boot=> printenv + +and set: + +.. code-block:: + + u-boot=> setenv doraucboot 1 + u-boot=> saveenv + +Barebox +....... + +In barebox, the system to be booted can be selected directly by its name. To +boot the A/B system, including RAUC, ``bootchooser`` is used. To boot e.g. a +regular SD card without RAUC use ``mmc`` instead, or ``nand`` for NAND devices: + +.. code-block:: + + barebox$ nv boot.default=bootchooser + +Creating RAUC Bundles +===================== + +To update your system with RAUC, a RAUC bundle (``.raucb``) needs to be created. +It contains all required images and scripts for the update and a RAUC +``manifest.raucm`` that describes the content of the bundle for the RAUC update +on the target. The BSP includes a Yocto target that lets you build a RAUC bundle +from your Yocto build. + +To create the bundle with Yocto, run the following in ``build/`` with the +distribution ``ampliphy-rauc`` or ``ampliphy-vendor-rauc`` set up, as described +previously: + +.. code-block:: console + + host:~$ bitbake phytec-headless-bundle + +This results in the creation of a ``.raucb`` bundle file in +``deploy/images//`` which can be used for updating the system as +described later. There is no need to create a ``manifest.raucm`` manually as it +is created automatically during the build of the bundle. As a reference, the +created manifest would look something like this: + +.. code-block:: cfg + :caption: manifest.raucm + + [update] + compatible=phyboard-polis-imx8mm-3 + version=r0 + description=PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0 + build=20200624074335 + + [image.rootfs] + sha256=cc3f65cd1c1993951d7a39bdb7b7d723617ac46460f8b640cd8d1622ad6e4c17 + size=99942000 + filename=phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz + + [image.boot] + sha256=bafe46679af8c6292dba22b9d402e3119ef78c6f8b458bcb6993326060de3aa4 + size=12410534 + filename=boot.tar.gz.img + +For more information about the manifest format, see +https://rauc.readthedocs.io/en/latest/reference.html#manifest. + +Updating with RAUC +================== + +To update the target system with RAUC, the RAUC bundle file previously created +first needs to be copied to the board or to a memory device that can be mounted +in Linux. One way is to copy the bundle file with ``scp``, but this requires +enough space left on the board's filesystem. To do this, boot the target board +to Linux and connect it via Ethernet to your host PC. + +On the host, run: + +.. code-block:: console + + host:~$ scp phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb root@192.168.3.11:/tmp/ + +On the target, the bundle can be verified: + +.. code-block:: console + + target:~$ rauc info /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + +and the output should look similar to this: + +.. code-block:: + + rauc-Message: 12:52:49.821: Reading bundle: /phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + rauc-Message: 12:52:49.830: Verifying bundle... + Compatible: 'phyboard-polis-imx8mm-3' + Version: 'r0' + Description: 'PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0' + Build: '20200624073212' + Hooks: '' + 2 Images: + (1) phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz + Slotclass: rootfs + Checksum: 342f67f7678d7af3f77710e1b68979f638c7f4d20393f6ffd0c36beff2789070 + Size: 180407809 + Hooks: + (2) boot.tar.gz.img + Slotclass: boot + Checksum: 8c84465b4715cc142eca2785fea09804bd970755142c9ff57e08c791e2b71f28 + Size: 12411786 + Hooks: + 0 Files + + Certificate Chain: + 0 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH Development-1 + Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + SPKI sha256: E2:47:5F:32:05:37:04:D4:8C:48:8D:A6:74:A8:21:2E:97:41:EE:88:74:B5:F4:65:75:97:76:1D:FF:1D:7B:EE + Not Before: Jan 1 00:00:00 1970 GMT + Not After: Dec 31 23:59:59 9999 GMT + 1 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + SPKI sha256: AB:5C:DB:C6:0A:ED:A4:48:B9:40:AC:B1:48:06:AA:BA:92:09:83:8C:DC:6F:E1:5F:B6:FB:0C:39:3C:3B:E6:A2 + Not Before: Jan 1 00:00:00 1970 GMT + Not After: Dec 31 23:59:59 9999 GMT + +To check the current state of the system, run: + +.. code-block:: console + + target:~$ rauc status + +and get output similar to this: + +.. code-block:: + + === System Info === + Compatible: phyboard-segin-imx6ul-6 + Variant: + Booted from: rootfs.0 (system0) + + === Bootloader === + Activated: rootfs.0 (system0) + + === Slot States === + o [rootfs.1] (/dev/ubi0_6, ubifs, inactive) + bootname: system1 + boot status: good + [dtb.1] (/dev/ubi0_3, ubivol, inactive) + [kernel.1] (/dev/ubi0_2, ubivol, inactive) + + x [rootfs.0] (/dev/ubi0_5, ubifs, booted) + bootname: system0 + boot status: good + [kernel.0] (/dev/ubi0_0, ubivol, active) + [dtb.0] (/dev/ubi0_1, ubivol, active) + +To update the currently inactive system with the downloaded bundle, run: + +.. code-block:: console + + target:~$ rauc install /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + +and reboot afterward: + +.. code-block:: console + + target:~$ reboot + +With the success of the update, RAUC automatically switches the active system to +the newly updated system. Now during reboot, RAUC counts the boot attempts of +the kernel and if it fails more often than specified in the state framework of +the system, RAUC switches back to the old system and marks the new system as +bad. If the boot attempt to the kernel is successful, the new system is marked +as good and the old system can now be updated with the same instructions. After +two successful ``rauc install`` and ``reboot``, both systems are updated. + +.. tip:: + + When you update from a USB stick, make sure to remove the stick after a + successful update before rebooting. If not, an automatic update will be + started after each boot. This is due to the :ref:`Automatic Update from USB Flash + Drive with RAUC ` you can find below. + +Changing the Active Boot Slot +----------------------------- + +It is possible to switch the active system manually: + +.. code-block:: console + + target:~$ rauc status mark-active other + +After a reboot, the target now starts from the other system. + +.. _kirkstone_rauc-switch-keyrings: + +Switching RAUC Keyrings +======================= + +PHYTEC's distribution comes with keys and certificates used for development and +demonstration purposes only. To change to a different PKI when devices are +already rolled out, RAUC's keyring must be changed. This chapter describes the +full procedure from a development state to a production state. Keep in mind, +that it is always a better idea to roll out your devices with a production +keyring in the first place, instead of relying on a development one for too +long. The following diagram shows the general process of switching keyrings for +RAUC: + +.. image:: /rauc/images/rauc-switching-keyrings.png + +Keyring Switching Process +------------------------- + +Create new certificates and keys for your own PKI. See our security manual for a +detailed description on how to create a custom PKI. For this document, we refer +to this newly created PKI as "production", as opposed to the existing +"development" keys. + +Move the generated keys and certificates, to your main Yocto build directory +root, alongside with ``build/`` and ``sources/``. + +.. warning:: + + Be careful where you store the private keys! These should in no way be made + publicly available. E.g. do not store the private keys in a public Git + repository. Otherwise, unauthorized entities could create RAUC bundles that + can be installed on your target system! + +Now, a RAUC bundle must be created that contains the new "production" CA keyring +in its root filesystem but is still signed by the "development" CA. With this, +the system is converted from a "development" system to a "production" system. To +achieve this, exchange the file ``ca.cert.pem`` installed by the RAUC recipe in +the Yocto sources. Create a file ``rauc_%.bbappend`` in your own Yocto layer: + +.. code-block:: + :caption: recipes-core/rauc/rauc_%.bbappend + + FILESEXTRAPATHS_prepend := "${THISDIR}/files:" + + RAUC_KEYRING_FILE = "${CERT_PATH}/rauc-customer/ca.cert.pem" + +Build the same RAUC bundle as before, now with the exchanged keyring: + +.. code-block:: console + + host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source source/poky/oe-init-build-env + host:~$ bitbake phytec-headless-bundle # Build the desired RAUC bundle + +Install the resulting RAUC bundle as usual. The target now has the image with +the "production" keyring installed in its other slot ("System B" in the figure +above). Reboot to start that system. + +All future RAUC bundles for the "production" system must now also be signed by +the "production" CA. For this, change the key and certificate to your newly +generated "production" ones in the bundle recipe: + +.. code-block:: + :caption: recipes-images/bundles/customer-headless-bundle.bb + + require phytec-base-bundle.inc + + RAUC_SLOT_rootfs ?= "phytec-headless-image" + + RAUC_KEY_FILE = "${CERT_PATH}/rauc-customer/private/production-1.key.pem" + RAUC_CERT_FILE = "${CERT_PATH/rauc-customer/production-1.cert.pem" + + RAUC_INTERMEDIATE_CERT_FILE = "" + +Rebuild the RAUC bundle: + +.. code-block:: console + + host:~$ bitbake customer-headless-bundle + +These and any future bundles are now ready to be installed on your "production" +target system and have been fully migrated away from the "development" system. +This also means that now only bundles signed by the "production" CA can be +installed on the target (and e.g. "development" bundles cannot). + +Use Case Examples +================= + +.. _kirkstone_rauc-automatic-updates-usb: + +Automatic Updates from USB Flash Drive with RAUC +------------------------------------------------ + +One of the most prominent use cases for RAUC might be an automatic update system +from a USB flash drive. This use case is implemented in the BSP as a reference +example. We combine only standard Linux mechanisms with RAUC to build the +system. The kernel notifies *udev* when a device gets plugged into the USB port. +We use a custom *udev* rule to trigger a systemd service when this event +happens. + +.. code-block:: + :caption: 10-update-usb.rules + + KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end" + + # Trigger systemd service + ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}="update-usb@%k.service" + + # Exit + LABEL="media_by_label_auto_mount_end" + +The service automatically mounts the USB flash drive and notifies the +application. + +.. code-block:: systemd + :caption: update-usb@.service + + [Unit] + Description=usb media RAUC service + After=multi-user.target + Requires=rauc.service + + [Service] + Type=oneshot + Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket + ExecStartPre=/bin/mkdir -p /media/%I + ExecStartPre=/bin/mount -t auto /dev/%I /media/%I + ExecStart=/usr/bin/update_usb.sh %I + ExecStop=/bin/umount -l /media/%i + ExecStopPost=-/bin/rmdir /media/%I + +In our reference implementation, we simply use a shell script for the +application logic. + +.. code-block:: sh + :caption: update_usb.sh + + #!/bin/sh + + MOUNT=/media/$1 + + NUMRAUCM=$(find ${MOUNT}/*.raucb -maxdepth 0 | wc -l) + + [ "$NUMRAUCM" -eq 0 ] && echo "${MOUNT}*.raucb not found" && exit + [ "$NUMRAUCM" -ne 1 ] && echo "more than one ${MOUNT}/*.raucb" && exit + + rauc install $MOUNT/*.raucb + if [ "$?" -ne 0 ]; then + echo "Failed to install RAUC bundle." + else + echo "Update successful." + fi + exit $? + +The update logic can be integrated into an application using the *systemd D-Bus +API*. RAUC does not need to be called by its command-line interface but can be +integrated with D-Bus. + +.. tip:: + + RAUC features a D-Bus API interface (see + https://rauc.readthedocs.io/en/latest/using.html#using-the-d-bus-api). + +Security Measurement: Downgrade Barrier +--------------------------------------- + +As a second reference example, we will implement a security mechanism: a +downgrade barrier. When you detect a security vulnerability on your system, you +will fix it and update your system. The systems with the new software will now +be secure again. If an attacker gets a hold of the old software update bundle, +which still has a valid signature, the attacker might have the possibility to +install the old software and still take advantage of the previously fixed +security vulnerability. To prevent this from happening, you could revoke the +updated certificate for every single update and create a new one. This might be +difficult to handle, depending on the environment. A simpler solution would be +to allow updates only in one direction using a version check. + +.. code-block:: sh + :caption: rauc_downgrade_barrier.sh + + #!/bin/sh + + VERSION_FILE=/etc/rauc/downgrade_barrier_version + MANIFEST_FILE=${RAUC_UPDATE_SOURCE}/manifest.raucm + + [ ! -f ${VERSION_FILE} ] && exit 1 + [ ! -f ${MANIFEST_FILE} ] && exit 2 + + VERSION=`cat ${VERSION_FILE} | cut -d 'r' -f 2` + BUNDLE_VERSION=`grep "version" -rI ${MANIFEST_FILE} | cut -d 'r' -f 3` + + # check from empty or unset variables + [ -z "${VERSION}" ] && exit 3 + [ -z "${BUNDLE_VERSION}" ] && exit 4 + + # developer mode, allow all updates if version is r0 + #[ ${VERSION} -eq 0 ] && exit 0 + + # downgrade barrier + if [ ${VERSION} -gt ${BUNDLE_VERSION} ]; then + echo "Downgrade barrier blocked rauc update! CODE5\n" + else + exit 0 + fi + exit 5 + +The script is installed on the target but it is not activated. You need to +remove the developer mode line in the script to activate it. + +Streaming Bundles over HTTP +--------------------------- + +Instead of copying the bundle to the device, the bundle can be streamed over +HTTP. Using bundle streaming has the advantage of not requiring local storage on +the target. A simple approach to this is running NGINX inside a Docker +container. The following example shows how to implement a minimal download +server enabling HTTP range requests to support this feature. + +Create a Dockerfile with the following content: + +.. code-block:: dockerfile + :caption: Dockerfile + + FROM nginx + + COPY bundles /bundles + COPY nginx.conf /etc/nginx/nginx.conf + +Configure NGINX to enable HTTP range requests and point it to the bundle file. + +.. code-block:: nginx + :caption: nginx.conf + + events {} + http { + server { + proxy_force_ranges on; + + location / { + root /bundles; + } + } + } + +Place a bundle in the ``bundles`` sub-directory. The folder structure looks like +the following after creating all configuration files: + +.. code-block:: console + + user@host:rauc-bundle-streaming$ find + . + ./bundles + ./bundles/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb + ./nginx.conf + ./Dockerfile + +Build and run the docker container on the host system: + +.. code-block:: console + + host:~$ sudo docker build -t rauc-bundle-streaming . + host:~$ sudo docker run --name bundles -p 80:80 -d rauc-bundle-streaming + +Install the bundle on the currently inactive target partitions: + +.. code-block:: console + + target:~$ rauc install http://192.168.3.10/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb + +.. note:: + + After the update finishes the target may display the following error which + has no impact on the success of the update: + + .. code-block:: + + [ 7416.336609] block nbd0: NBD_DISCONNECT + [ 7416.340413] block nbd0: Send disconnect failed -32 + +Reference +========= + +Boot Logic Implementation +------------------------- + +.. tip:: + + The implementation details described in this chapter serve as a reference + guide. PHYTEC BSPs that have RAUC support include these by default and the + changes are already incorporated. + +U-Boot Environment Variables +............................ + +For U-Boot, the boot logic that selects the correct partitions to boot from is +implemented in its environment. As a reference, these are the most important +U-Boot variables that are used for the A/B system with RAUC: + +For BSP-Yocto-NXP-i.MX8M*-PD23.1.0: + ++-------------------+--------------------------------------------------------+ +| Name | Function | ++===================+========================================================+ +| BOOT_ORDER | Contains a space-separated list of boot targets in the | +| | order they should be tried. This parameter is | +| | automatically set by RAUC. | ++-------------------+--------------------------------------------------------+ +| BOOT__LEFT | Contains the number of remaining boot attempts to | +| | perform for the respective slot. This parameter is | +| | automatically set by RAUC. | ++-------------------+--------------------------------------------------------+ +| ``raucboot`` | Contains the boot logic that sets the partitions so | +| | the correct system is loaded. | ++-------------------+--------------------------------------------------------+ +| ``doraucboot`` | Enables booting the A/B system if set to 1 and | +| | disables it if set to 0. | ++-------------------+--------------------------------------------------------+ +| ``raucslot`` | Contains the current boot slot used in | +| | BOOT__LEFT. | ++-------------------+--------------------------------------------------------+ +| ``raucargs`` | Sets the Kernel bootargs like console, root, and RAUC | +| | lot. | ++-------------------+--------------------------------------------------------+ +| ``raucdev`` | Sets the eMMC as the boot device. | ++-------------------+--------------------------------------------------------+ +| ``raucrootpart`` | Sets the root filesystem partitions of the device. | ++-------------------+--------------------------------------------------------+ +| ``raucpart`` | Sets the boot partitions of the device. | ++-------------------+--------------------------------------------------------+ +| ``loadraucimage`` | Loads the Kernel image into RAM. | ++-------------------+--------------------------------------------------------+ +| ``loadraucfdt`` | Loads the device tree into RAM. | ++-------------------+--------------------------------------------------------+ + +These environment variables are defined in ``include/configs/phycore_.h`` +in the u-boot source code. + +For BSP-Yocto-Ampliphy-AM6xx-PD23.2.0: + ++-------------------+--------------------------------------------------------+ +| Name | Function | ++===================+========================================================+ +| BOOT_ORDER | Contains a space-separated list of boot targets in the | +| | order they should be tried. This parameter is | +| | automatically set by RAUC. | ++-------------------+--------------------------------------------------------+ +| BOOT__LEFT | Contains the number of remaining boot attempts to | +| | perform for the respective slot. This parameter is | +| | automatically set by RAUC. | ++-------------------+--------------------------------------------------------+ +| ``init_rauc`` | Contains the boot logic that sets the partitions so | +| | the correct system is loaded. | ++-------------------+--------------------------------------------------------+ +| ``doraucboot`` | Enables booting the A/B system if set to 1 and | +| | disables it if set to 0. | ++-------------------+--------------------------------------------------------+ +| ``raucslot`` | Contains the current boot slot used in | +| | BOOT__LEFT. | ++-------------------+--------------------------------------------------------+ +| ``raucrootpart`` | Sets the root filesystem partitions of the device. | ++-------------------+--------------------------------------------------------+ +| ``raucbootpart`` | Sets the boot partitions of the device. | ++-------------------+--------------------------------------------------------+ + +These environment variables are defined in +``include/environment/phytec/rauc.env`` in the u-boot source code. + +.. note:: + + A change in the partition layout, e.g. when using an additional data + partition, may require changing the variables ``raucrootpart`` and + ``raucpart``. Make sure to rebuild your image with the new bootloader + environment after you have made the appropriate changes. + +Barebox Bootchooser Framework +............................. + +For the barebox, the boot logic that selects the correct partitions to boot from +is implemented using the bootchooser and state framework. See the barebox +documentation for detailed information about these: `Barebox Bootchooser +Framework `_, `Barebox +State Framework `_. + +First, the state framework configuration needs to be added to the barebox device +tree. Check out the :ref:`Customizing the BSP ` +chapter in the Yocto reference manual. The state framework configuration is +already included with our BSP for the supported SoC and can be directly included +in the main barebox device tree. E.g. for i.MX6 based module: + +.. code-block:: devicetree + + #include "imx6qdl-phytec-state.dtsi" + +Afterward, rebuild the image and flash the new bootloader. + +.. warning:: + + Be aware that by adding the state framework configuration, the first 160 + bytes of the EEPROM are occupied and can no longer be used for user-specific + purposes. + +The following device tree snippet shows an example of the state framework +configuration used with the BSP. As can be seen, the EEPROM is used as a backend +for the state information: + +.. code-block:: devicetree + + / { + aliases { + state = &state; + }; + + state: imx6qdl_phytec_boot_state { + magic = <0x883b86a6>; + compatible = "barebox,state"; + backend-type = "raw"; + backend = <&backend_update_eeprom>; + backend-stridesize = <54>; + + #address-cells = <1>; + #size-cells = <1>; + bootstate { + #address-cells = <1>; + #size-cells = <1>; + last_chosen { + reg = <0x0 0x4>; + type = "uint32"; + }; + system0 { + #address-cells = <1>; + #size-cells = <1>; + remaining_attempts { + reg = <0x4 0x4>; + type = "uint32"; + default = <3>; + }; + priority { + reg = <0x8 0x4>; + type = "uint32"; + default = <21>; + }; + ok { + reg = <0xc 0x4>; + type = "uint32"; + default = <0>; + }; + }; + system1 { + #address-cells = <1>; + #size-cells = <1>; + remaining_attempts { + reg = <0x10 0x4>; + type = "uint32"; + default = <3>; + }; + priority { + reg = <0x14 0x4>; + type = "uint32"; + default = <20>; + }; + ok { + reg = <0x18 0x4>; + type = "uint32"; + default = <0>; + }; + }; + }; + }; + }; + + &eeprom { + status = "okay"; + partitions { + compatible = "fixed-partitions"; + #size-cells = <1>; + #address-cells = <1>; + backend_update_eeprom: state@0 { + reg = <0x0 0x100>; + label = "update-eeprom"; + }; + }; + }; + +To be able to boot from two systems alternately, the bootchooser needs to be +aware of the state framework configuration. For each system, a boot script is +required. For a system with NAND flash, the boot script of the first system may +look like the following: + +.. code-block:: sh + :caption: /env/boot/system0 + + #!/bin/sh + + [ -e /env/config-expansions ] && /env/config-expansions + + [ ! -e /dev/nand0.root.ubi ] && ubiattach /dev/nand0.root + + global.bootm.image="/dev/nand0.root.ubi.kernel0" + global.bootm.oftree="/dev/nand0.root.ubi.oftree0" + global.linux.bootargs.dyn.root="root=ubi0:root0 ubi.mtd=root rootfstype=ubifs" + +The second boot script has the same structure but uses the partitions containing +the second system. Machines with eMMC flash use similar boot scripts, albeit the +mounting and boot arguments look different. + +Run the following commands to create the required bootchooser non-volatile +environment variables: + +.. code-block:: + + barebox$ nv bootchooser.state_prefix=state.bootstate + barebox$ nv bootchooser.system0.boot=system0 + barebox$ nv bootchooser.system1.boot=system1 + barebox$ nv bootchooser.targets="system0 system1" + +eMMC Boot Partitions +-------------------- + +With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. + +By default, bundles built with our BSP (e.g. ``phytec-headless-bundle``) contain +the bootloader for updating eMMC boot partitions accordingly. + +Note, that the U-Boot environment still resides in the user area before the +first partition. The user area also still contains the bootloader which the +image first shipped during its initialization process. + +To manually write the bootloader to the eMMC boot partitions, first disable the +write protection: + +.. code-block:: console + + target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro + target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro + +Write the bootloader to the eMMC boot partitions: + +.. code-block:: console + + target:~$ dd if=imx-boot of=/dev/mmcblk2boot0 bs=1k seek=33 + target:~$ dd if=imx-boot of=/dev/mmcblk2boot1 bs=1k seek=33 + +This example is valid for the i.MX 8M Mini SoC. Note, that other SoCs may have +different bootloader files and require different offsets where the bootloader is +expected, specified by the seek parameter. See the following table for the +different offsets being required by each SoC: + ++--------------+------------------+-----------------------+--------------+-------------+ +| SoC | Offset User Area | Offset Boot Partition | eMMC Device | Bootloader | ++==============+==================+=======================+==============+=============+ +| i.MX 6 | 1 kiB | 0 kiB | /dev/mmcblk3 | barebox.bin | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 6UL | 1 kiB | 0 kiB | /dev/mmcblk1 | barebox.bin | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M | 33 kiB | 33 kiB | /dev/mmcblk0 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Mini | 33 kiB | 33 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Nano | 32 kiB | 0 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Plus | 32 kiB | 0 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| AM62x | N/A | 0 kiB | /dev/mmcblk0 | tiboot3.bin | +| AM62Ax | | 512 kiB | | tispl.bin | +| AM64x | | 2560 kiB | | u-boot.img | ++--------------+------------------+-----------------------+--------------+-------------+ + +Bootloader Offsets +.................. + +Note that the offset is different, depending on whether the bootloader resides +in the user area or the boot partitions of the eMMC. + +After a bootloader has been written to the eMMC boot partitions, booting from +these can be enabled by using the following command: + +.. code-block:: console + + target:~$ mmc bootpart enable 1 0 /dev/mmcblk2 + +This also means that only the bootloaders written in the eMMC boot partitions +are used. The bootloader in the user area is not used anymore. These steps are +also executed by RAUC internally when updating the target system with a bundle. + +To disable booting from the eMMC boot partitions simply enter the following +command: + +.. code-block:: console + + target:~$ mmc bootpart enable 0 0 /dev/mmcblk2 + +After this command, the eMMC user area is used to provide the bootloader. + +When using U-Boot, a similar command is also available in the bootloader: + +.. code-block:: + + u-boot=> mmc partconf 2 0 0 0 # disable + u-boot=> mmc partconf 2 0 1 0 # enable diff --git a/previews/271/zh_CN/_sources/rauc/manual-index.rst.txt b/previews/271/zh_CN/_sources/rauc/manual-index.rst.txt new file mode 100644 index 000000000..7a2efb1f0 --- /dev/null +++ b/previews/271/zh_CN/_sources/rauc/manual-index.rst.txt @@ -0,0 +1,33 @@ +======================================= +RAUC Update & Device Management Manuals +======================================= + +Kirkstone +========= + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + kirkstone + +Mickledore +========== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + mickledore + +Scarthgap +========= + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + scarthgap diff --git a/previews/271/zh_CN/_sources/rauc/mickledore.rst.txt b/previews/271/zh_CN/_sources/rauc/mickledore.rst.txt new file mode 100644 index 000000000..8441d18b3 --- /dev/null +++ b/previews/271/zh_CN/_sources/rauc/mickledore.rst.txt @@ -0,0 +1,1045 @@ +.. Download links +.. _`static-pdf-dl`: ../_static/rauc-mickledore.pdf + +.. RAUC +.. |yocto-codename| replace:: Mickledore +.. |rauc-manual| replace:: RAUC Update & Device Management Manual + +.. only:: html + + Documentation in pdf format: `Download `_ + ++---------------------------------------------------------------+ +| |rauc-manual| | ++=======================+=======================================+ +| Document Title | |rauc-manual| |yocto-codename| | ++-----------------------+---------------------------------------+ +| Document Type | RAUC Update & Device Management | +| | Manual | ++-----------------------+---------------------------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+---------------------------------------+ +| Is Branch of | |rauc-manual| | ++-----------------------+---------------------------------------+ + ++-------------------------------------+------------------+------------------+------------+ +| Compatible BSPs | BSP Release Type | BSP Release Date | BSP Status | ++=====================================+==================+==================+============+ +| BSP-Yocto-NXP-i.MX93-PD24.1.0 | Major | 05.02.2024 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX93-PD24.1.1 | Minor | 08.05.2024 | released | ++-------------------------------------+------------------+------------------+------------+ + +This manual was tested using the Yocto version |yocto-codename|. + +Introduction +============ + +PHYTEC's Yocto distribution Ampliphy (former Yogurt) supports the `RAUC +`_ (Robust Auto-Update Controller) +mechanism. RAUC controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. For +eMMC devices only, it can also update the bootloader. + +This manual describes how RAUC is used and implemented on various PHYTEC +platforms. Note, that different modules use different bootloaders and flash +storage devices, which affects the way things are handled by RAUC. Make sure to +read the correct sections fitting your platform. + +.. note:: + + This manual contains machine-specific paths and variable contents. Make sure + you are using the correct machine and device names for your application when + executing any commands. + + +System Configuration +==================== + +RAUC can be used with both eMMC and NAND flash storage. Using the distro +``ampliphy-rauc`` or ``ampliphy-vendor-rauc``, it is enabled by default and requires +no additional setup to get started. RAUC can be used in different update +scenarios. As an example, we configured the BSP to use an A/B setup to have a +completely redundant system (including the bootloader on eMMC devices). Note, +that there is an additional partition named ``config`` storing persistent +configuration data not being changed when updating. + +.. image:: /rauc/images/rauc-ab-system.png + +RAUC BSP Example Setup +---------------------- + +The partition layout is defined in the ``/etc/rauc/system.conf`` file. As an +example, this is what it looks like for i.MX 8M Mini with eMMC flash storage: + +.. code-block:: cfg + :caption: /etc/rauc/system.conf + + [system] + compatible=phyboard-polis-imx8mm-4 + bootloader=uboot + mountprefix=/mnt/rauc + + [handlers] + pre-install=/usr/lib/rauc/rauc-pre-install.sh + post-install=/usr/lib/rauc/rauc-post-install.sh + + [keyring] + path=mainca-rsa.crt.pem + + [slot.bootloader.0] + device=/dev/mmcblk2 + type=boot-emmc + + # System A + [slot.rootfs.0] + device=/dev/mmcblk2p5 + type=ext4 + bootname=system0 + + [slot.boot.0] + device=/dev/mmcblk2p1 + type=vfat + parent=rootfs.0 + + # System B + [slot.rootfs.1] + device=/dev/mmcblk2p6 + type=ext4 + bootname=system1 + + [slot.boot.1] + device=/dev/mmcblk2p2 + type=vfat + parent=rootfs.1 + +Note, that the devices specified in the slots are different depending on the +selected machine. + +.. warning:: + + Updates with RAUC use an OpenSSL certificate to verify the validity of an + image. The BSP includes a certificate that can be used for development. In a + productive system, however, it is highly recommended to use a self-created + key and certificate. If you need to change the keyring on an existing device, + see :ref:`Switching RAUC Keyrings ` for more + information. + +Design Considerations +===================== + +In order to prevent the system from locking up, it may be a good idea to utilize +a hardware watchdog. In case the Linux Kernel does not boot or another +catastrophic event occurs that prevents the system from operating normally, the +hardware watchdog then resets the system. By default, the hardware watchdog is +disabled. To enable it, refer to the corresponding BSP manual that fits your +SoM. + +Other important design considerations, as well as a checklist, can be found in +the official RAUC documentation: +https://rauc.readthedocs.io/en/latest/checklist.html + +Initial Setup +============= + +To use RAUC, the flash device needs to be written with a complete Linux system +and bootloader. The preferred method to do this is using the included tool +`partup `_. + +Flash Storage +------------- + +To flash the device with the correct partitions/volumes, use a partup package +built with the ``ampliphy-rauc`` or ``ampliphy-vendor-rauc`` distribution. +Prebuilt partup packages can be found in the BSP release. It is also possible to +build an image with this distribution yourself using Yocto. Separate build +directories are created, storing the images and packages for the RAUC system. +Initialize the build directory with the OE init script: + +.. code-block:: console + + host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source sources/poky/oe-init-build-env + +Change the distribution to ``ampliphy-rauc`` (for i.MX6, AM6x, i.MX8 mainline BSP) or +``ampliphy-vendor-rauc`` (for i.MX8, i.MX9 vendor BSP): + +.. code-block:: + :caption: build/conf/local.conf + + DISTRO ?= "ampliphy-rauc" + +Any image built with this distro now includes a full A/B system. Build the image +as usual: + +.. code-block:: console + + host:~$ bitbake phytec-headless-image + +The resulting partup package is stored in the ``deploy-ampliphy-vendor-rauc`` directory, e.g.: + +.. code-block:: + + deploy-ampliphy-vendor-rauc/images/phyboard-segin-imx93-2/phytec-headless-image-phyboard-segin-imx93-2.partup + +This partup package contains all the necessary data and configuration to flash +an eMMC. `Partup `__ can be obtained from its +`release page `_. Also, see its +README for detailed `installation instructions +`_. Partup is already installed +in our Ampliphy images, ``phytec-headless-image`` and can be directly used e.g. +from an SD card. + +.. note:: + To flash the initial RAUC system, a booted non-RAUC system is needed first on + a different flash device. E.g. you could boot a regular + ``phytec-headless-image`` image with distro ``ampliphy`` from an SD card. + +eMMC +.... + +While running a non-RAUC system from an SD card on the target, copy the +``.partup`` package built with distro ``ampliphy-rauc`` or +``ampliphy-vendor-rauc`` to the running target first: + +.. code-block:: console + + host:~$ scp phytec-headless-image-phyboard-segin-imx93-2.partup 192.168.3.11:/root + +Then install the partup package to the eMMC: + +.. code-block:: console + + target:~$ partup install phytec-headless-image-phyboard-segin-imx93-2.partup /dev/mmcblk0 + +Now the target can boot the flashed A/B system. + +NAND +.... + +.. note:: + + There are scripts provided with the bootloader barebox that previously were + used to initialize NAND flash with an A/B system: ``rauc_init_nand``, + ``rauc_flash_nand_from_tftp`` and ``rauc_flash_nand_from_mmc``. These scripts + are deprecated. It is advised to use the script ``rauc-flash-nand`` provided + in the Linux environment with PHYTEC's distribution *Ampliphy*. + +With raw NAND flash the kernel, device tree, and root filesystem are written +individually. Initialize the NAND flash with the correct volumes from a Linux on +the target: + +.. code-block:: console + + target:~$ rauc-flash-nand -k /path/to/zImage -d /path/to/oftree -r /path/to/root.ubifs + +The initialization script will automatically utilize all available space of NAND +flash. The NAND device is also determined automatically by finding the device +root in ``/proc/mtd``. + +On i.MX6 and i.MX6UL devices with barebox, use bbu (barebox update) to flash the +bootloader: + +.. code-block:: console + + target:~$ bbu.sh -f /path/to/barebox.bin + +The A/B system on NAND Flash is now ready to be booted. + +Bootloader +---------- + +Booting the A/B System by Default +................................. + +Booting the A/B system is done mostly automatically by the bootloader since the +Yocto release *hardknott*. For devices with eMMC flash storage, the +corresponding setting is written into the bootloader environment during the +building of the BSP. In particular, if the distribution ``ampliphy-rauc`` or +``ampliphy-vendor-rauc`` is used, as described previously, the bootloader should +automatically start the A/B system and have the variables set for RAUC +accordingly. + +This automatic setting can be manually changed by setting one variable in the +bootloader. The procedure is described in more detail in the following chapters +for U-Boot and barebox. + +U-Boot +...... + +After a successful boot into a Linux environment, this command is used to view +the available parameters: + +.. code-block:: console + + target:~$ fw_printenv + +You may see this parameter along with others in the output: + +.. code-block:: + + doraucboot=1 + +To manually disable or enable booting the A/B system with RAUC, set this +variable to ``0`` or ``1``: + +.. code-block:: console + + target:~$ fw_setenv doraucboot 1 + +This parameter can also be edited in U-Boot. Restart your board and hit any key +to stop the automatic boot. The environment variables can now be viewed: + +.. code-block:: + + u-boot=> printenv + +and set: + +.. code-block:: + + u-boot=> setenv doraucboot 1 + u-boot=> saveenv + +Barebox +....... + +In barebox, the system to be booted can be selected directly by its name. To +boot the A/B system, including RAUC, ``bootchooser`` is used. To boot e.g. a +regular SD card without RAUC use ``mmc`` instead, or ``nand`` for NAND devices: + +.. code-block:: + + barebox$ nv boot.default=bootchooser + +Creating RAUC Bundles +===================== + +To update your system with RAUC, a RAUC bundle (``.raucb``) needs to be created. +It contains all required images and scripts for the update and a RAUC +``manifest.raucm`` that describes the content of the bundle for the RAUC update +on the target. The BSP includes a Yocto target that lets you build a RAUC bundle +from your Yocto build. + +To create the bundle with Yocto, run the following in ``build/`` with the +distribution ``ampliphy-rauc`` or ``ampliphy-vendor-rauc`` set up, as described +previously: + +.. code-block:: console + + host:~$ bitbake phytec-headless-bundle + +This results in the creation of a ``.raucb`` bundle file in +``deploy/images//`` which can be used for updating the system as +described later. There is no need to create a ``manifest.raucm`` manually as it +is created automatically during the build of the bundle. As a reference, the +created manifest would look something like this: + +.. code-block:: cfg + :caption: manifest.raucm + + [update] + compatible=phyboard-polis-imx8mm-3 + version=r0 + description=PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0 + build=20200624074335 + + [image.rootfs] + sha256=cc3f65cd1c1993951d7a39bdb7b7d723617ac46460f8b640cd8d1622ad6e4c17 + size=99942000 + filename=phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz + + [image.boot] + sha256=bafe46679af8c6292dba22b9d402e3119ef78c6f8b458bcb6993326060de3aa4 + size=12410534 + filename=boot.tar.gz.img + +For more information about the manifest format, see +https://rauc.readthedocs.io/en/latest/reference.html#manifest. + +Updating with RAUC +================== + +To update the target system with RAUC, the RAUC bundle file previously created +first needs to be copied to the board or to a memory device that can be mounted +in Linux. One way is to copy the bundle file with ``scp``, but this requires +enough space left on the board's filesystem. To do this, boot the target board +to Linux and connect it via Ethernet to your host PC. + +On the host, run: + +.. code-block:: console + + host:~$ scp phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb root@192.168.3.11:/tmp/ + +On the target, the bundle can be verified: + +.. code-block:: console + + target:~$ rauc info /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + +and the output should look similar to this: + +.. code-block:: + + rauc-Message: 12:52:49.821: Reading bundle: /phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + rauc-Message: 12:52:49.830: Verifying bundle... + Compatible: 'phyboard-polis-imx8mm-3' + Version: 'r0' + Description: 'PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0' + Build: '20200624073212' + Hooks: '' + 2 Images: + (1) phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz + Slotclass: rootfs + Checksum: 342f67f7678d7af3f77710e1b68979f638c7f4d20393f6ffd0c36beff2789070 + Size: 180407809 + Hooks: + (2) boot.tar.gz.img + Slotclass: boot + Checksum: 8c84465b4715cc142eca2785fea09804bd970755142c9ff57e08c791e2b71f28 + Size: 12411786 + Hooks: + 0 Files + + Certificate Chain: + 0 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH Development-1 + Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + SPKI sha256: E2:47:5F:32:05:37:04:D4:8C:48:8D:A6:74:A8:21:2E:97:41:EE:88:74:B5:F4:65:75:97:76:1D:FF:1D:7B:EE + Not Before: Jan 1 00:00:00 1970 GMT + Not After: Dec 31 23:59:59 9999 GMT + 1 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + SPKI sha256: AB:5C:DB:C6:0A:ED:A4:48:B9:40:AC:B1:48:06:AA:BA:92:09:83:8C:DC:6F:E1:5F:B6:FB:0C:39:3C:3B:E6:A2 + Not Before: Jan 1 00:00:00 1970 GMT + Not After: Dec 31 23:59:59 9999 GMT + +To check the current state of the system, run: + +.. code-block:: console + + target:~$ rauc status + +and get output similar to this: + +.. code-block:: + + === System Info === + Compatible: phyboard-segin-imx6ul-6 + Variant: + Booted from: rootfs.0 (system0) + + === Bootloader === + Activated: rootfs.0 (system0) + + === Slot States === + o [rootfs.1] (/dev/ubi0_6, ubifs, inactive) + bootname: system1 + boot status: good + [dtb.1] (/dev/ubi0_3, ubivol, inactive) + [kernel.1] (/dev/ubi0_2, ubivol, inactive) + + x [rootfs.0] (/dev/ubi0_5, ubifs, booted) + bootname: system0 + boot status: good + [kernel.0] (/dev/ubi0_0, ubivol, active) + [dtb.0] (/dev/ubi0_1, ubivol, active) + +To update the currently inactive system with the downloaded bundle, run: + +.. code-block:: console + + target:~$ rauc install /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + +and reboot afterward: + +.. code-block:: console + + target:~$ reboot + +With the success of the update, RAUC automatically switches the active system to +the newly updated system. Now during reboot, RAUC counts the boot attempts of +the kernel and if it fails more often than specified in the state framework of +the system, RAUC switches back to the old system and marks the new system as +bad. If the boot attempt to the kernel is successful, the new system is marked +as good and the old system can now be updated with the same instructions. After +two successful ``rauc install`` and ``reboot``, both systems are updated. + +.. tip:: + + When you update from a USB stick, make sure to remove the stick after a + successful update before rebooting. If not, an automatic update will be + started after each boot. This is due to the :ref:`Automatic Update from USB Flash + Drive with RAUC ` you can find below. + +Changing the Active Boot Slot +----------------------------- + +It is possible to switch the active system manually: + +.. code-block:: console + + target:~$ rauc status mark-active other + +After a reboot, the target now starts from the other system. + +.. _mickledore_rauc-switch-keyrings: + +Switching RAUC Keyrings +======================= + +PHYTEC's distribution comes with keys and certificates used for development and +demonstration purposes only. To change to a different PKI when devices are +already rolled out, RAUC's keyring must be changed. This chapter describes the +full procedure from a development state to a production state. Keep in mind, +that it is always a better idea to roll out your devices with a production +keyring in the first place, instead of relying on a development one for too +long. The following diagram shows the general process of switching keyrings for +RAUC: + +.. image:: /rauc/images/rauc-switching-keyrings.png + +Keyring Switching Process +------------------------- + +Create new certificates and keys for your own PKI. See our security manual for a +detailed description on how to create a custom PKI. For this document, we refer +to this newly created PKI as "production", as opposed to the existing +"development" keys. + +Move the generated keys and certificates, to your main Yocto build directory +root, alongside with ``build/`` and ``sources/``. + +.. warning:: + + Be careful where you store the private keys! These should in no way be made + publicly available. E.g. do not store the private keys in a public Git + repository. Otherwise, unauthorized entities could create RAUC bundles that + can be installed on your target system! + +Now, a RAUC bundle must be created that contains the new "production" CA keyring +in its root filesystem but is still signed by the "development" CA. With this, +the system is converted from a "development" system to a "production" system. To +achieve this, exchange the file ``ca.cert.pem`` installed by the RAUC recipe in +the Yocto sources. Create a file ``rauc_%.bbappend`` in your own Yocto layer: + +.. code-block:: + :caption: recipes-core/rauc/rauc_%.bbappend + + FILESEXTRAPATHS_prepend := "${THISDIR}/files:" + + RAUC_KEYRING_FILE = "${CERT_PATH}/rauc-customer/ca.cert.pem" + +Build the same RAUC bundle as before, now with the exchanged keyring: + +.. code-block:: console + + host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source source/poky/oe-init-build-env + host:~$ bitbake phytec-headless-bundle # Build the desired RAUC bundle + +Install the resulting RAUC bundle as usual. The target now has the image with +the "production" keyring installed in its other slot ("System B" in the figure +above). Reboot to start that system. + +All future RAUC bundles for the "production" system must now also be signed by +the "production" CA. For this, change the key and certificate to your newly +generated "production" ones in the bundle recipe: + +.. code-block:: + :caption: recipes-images/bundles/customer-headless-bundle.bb + + require phytec-base-bundle.inc + + RAUC_SLOT_rootfs ?= "phytec-headless-image" + + RAUC_KEY_FILE = "${CERT_PATH}/rauc-customer/private/production-1.key.pem" + RAUC_CERT_FILE = "${CERT_PATH/rauc-customer/production-1.cert.pem" + + RAUC_INTERMEDIATE_CERT_FILE = "" + +Rebuild the RAUC bundle: + +.. code-block:: console + + host:~$ bitbake customer-headless-bundle + +These and any future bundles are now ready to be installed on your "production" +target system and have been fully migrated away from the "development" system. +This also means that now only bundles signed by the "production" CA can be +installed on the target (and e.g. "development" bundles cannot). + +Use Case Examples +================= + +.. _mickledore_rauc-automatic-updates-usb: + +Automatic Updates from USB Flash Drive with RAUC +------------------------------------------------ + +One of the most prominent use cases for RAUC might be an automatic update system +from a USB flash drive. This use case is implemented in the BSP as a reference +example. We combine only standard Linux mechanisms with RAUC to build the +system. The kernel notifies *udev* when a device gets plugged into the USB port. +We use a custom *udev* rule to trigger a systemd service when this event +happens. + +.. code-block:: + :caption: 10-update-usb.rules + + KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end" + + # Trigger systemd service + ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}="update-usb@%k.service" + + # Exit + LABEL="media_by_label_auto_mount_end" + +The service automatically mounts the USB flash drive and notifies the +application. + +.. code-block:: systemd + :caption: update-usb@.service + + [Unit] + Description=usb media RAUC service + After=multi-user.target + Requires=rauc.service + + [Service] + Type=oneshot + Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket + ExecStartPre=/bin/mkdir -p /media/%I + ExecStartPre=/bin/mount -t auto /dev/%I /media/%I + ExecStart=/usr/bin/update_usb.sh %I + ExecStop=/bin/umount -l /media/%i + ExecStopPost=-/bin/rmdir /media/%I + +In our reference implementation, we simply use a shell script for the +application logic. + +.. code-block:: sh + :caption: update_usb.sh + + #!/bin/sh + + MOUNT=/media/$1 + + NUMRAUCM=$(find ${MOUNT}/*.raucb -maxdepth 0 | wc -l) + + [ "$NUMRAUCM" -eq 0 ] && echo "${MOUNT}*.raucb not found" && exit + [ "$NUMRAUCM" -ne 1 ] && echo "more than one ${MOUNT}/*.raucb" && exit + + rauc install $MOUNT/*.raucb + if [ "$?" -ne 0 ]; then + echo "Failed to install RAUC bundle." + else + echo "Update successful." + fi + exit $? + +The update logic can be integrated into an application using the *systemd D-Bus +API*. RAUC does not need to be called by its command-line interface but can be +integrated with D-Bus. + +.. tip:: + + RAUC features a D-Bus API interface (see + https://rauc.readthedocs.io/en/latest/using.html#using-the-d-bus-api). + +Security Measurement: Downgrade Barrier +--------------------------------------- + +As a second reference example, we will implement a security mechanism: a +downgrade barrier. When you detect a security vulnerability on your system, you +will fix it and update your system. The systems with the new software will now +be secure again. If an attacker gets a hold of the old software update bundle, +which still has a valid signature, the attacker might have the possibility to +install the old software and still take advantage of the previously fixed +security vulnerability. To prevent this from happening, you could revoke the +updated certificate for every single update and create a new one. This might be +difficult to handle, depending on the environment. A simpler solution would be +to allow updates only in one direction using a version check. + +.. code-block:: sh + :caption: rauc_downgrade_barrier.sh + + #!/bin/sh + + VERSION_FILE=/etc/rauc/downgrade_barrier_version + MANIFEST_FILE=${RAUC_UPDATE_SOURCE}/manifest.raucm + + [ ! -f ${VERSION_FILE} ] && exit 1 + [ ! -f ${MANIFEST_FILE} ] && exit 2 + + VERSION=`cat ${VERSION_FILE} | cut -d 'r' -f 2` + BUNDLE_VERSION=`grep "version" -rI ${MANIFEST_FILE} | cut -d 'r' -f 3` + + # check from empty or unset variables + [ -z "${VERSION}" ] && exit 3 + [ -z "${BUNDLE_VERSION}" ] && exit 4 + + # developer mode, allow all updates if version is r0 + #[ ${VERSION} -eq 0 ] && exit 0 + + # downgrade barrier + if [ ${VERSION} -gt ${BUNDLE_VERSION} ]; then + echo "Downgrade barrier blocked rauc update! CODE5\n" + else + exit 0 + fi + exit 5 + +The script is installed on the target but it is not activated. You need to +remove the developer mode line in the script to activate it. + +Streaming Bundles over HTTP +--------------------------- + +Instead of copying the bundle to the device, the bundle can be streamed over +HTTP. Using bundle streaming has the advantage of not requiring local storage on +the target. A simple approach to this is running NGINX inside a Docker +container. The following example shows how to implement a minimal download +server enabling HTTP range requests to support this feature. + +Create a Dockerfile with the following content: + +.. code-block:: dockerfile + :caption: Dockerfile + + FROM nginx + + COPY bundles /bundles + COPY nginx.conf /etc/nginx/nginx.conf + +Configure NGINX to enable HTTP range requests and point it to the bundle file. + +.. code-block:: nginx + :caption: nginx.conf + + events {} + http { + server { + proxy_force_ranges on; + + location / { + root /bundles; + } + } + } + +Place a bundle in the ``bundles`` sub-directory. The folder structure looks like +the following after creating all configuration files: + +.. code-block:: console + + user@host:rauc-bundle-streaming$ find + . + ./bundles + ./bundles/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb + ./nginx.conf + ./Dockerfile + +Build and run the docker container on the host system: + +.. code-block:: console + + host:~$ sudo docker build -t rauc-bundle-streaming . + host:~$ sudo docker run --name bundles -p 80:80 -d rauc-bundle-streaming + +Install the bundle on the currently inactive target partitions: + +.. code-block:: console + + target:~$ rauc install http://192.168.3.10/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb + +.. note:: + + After the update finishes the target may display the following error which + has no impact on the success of the update: + + .. code-block:: + + [ 7416.336609] block nbd0: NBD_DISCONNECT + [ 7416.340413] block nbd0: Send disconnect failed -32 + +Reference +========= + +Boot Logic Implementation +------------------------- + +.. tip:: + + The implementation details described in this chapter serve as a reference + guide. PHYTEC BSPs that have RAUC support include these by default and the + changes are already incorporated. + +U-Boot Environment Variables +............................ + +For U-Boot, the boot logic that selects the correct partitions to boot from is +implemented in its environment. As a reference, these are the most important +U-Boot variables that are used for the A/B system with RAUC: + ++-------------------+--------------------------------------------------------+ +| Name | Function | ++===================+========================================================+ +| BOOT_ORDER | Contains a space-separated list of boot targets in the | +| | order they should be tried. This parameter is | +| | automatically set by RAUC. | ++-------------------+--------------------------------------------------------+ +| BOOT__LEFT | Contains the number of remaining boot attempts to | +| | perform for the respective slot. This parameter is | +| | automatically set by RAUC. | ++-------------------+--------------------------------------------------------+ +| ``raucinit`` | Contains the boot logic that sets the partitions so | +| | the correct system is loaded. | ++-------------------+--------------------------------------------------------+ +| ``doraucboot`` | Enables booting the A/B system if set to 1 and | +| | disables it if set to 0. | ++-------------------+--------------------------------------------------------+ +| ``raucargs`` | Sets the Kernel bootargs like console, root, and RAUC | +| | slot. | ++-------------------+--------------------------------------------------------+ +| ``raucrootpart`` | Sets the root filesystem partitions of the device. | ++-------------------+--------------------------------------------------------+ +| ``raucbootpart`` | Sets the boot partitions of the device. | ++-------------------+--------------------------------------------------------+ + +These environment variables are defined in ``include/environment/phytec/rauc.env`` in +the u-boot source code. + +.. note:: + + A change in the partition layout, e.g. when using an additional data + partition, may require changing the variables ``raucrootpart`` and + ``raucbootpart``. Make sure to rebuild your image with the new bootloader + environment after you have made the appropriate changes. + +Barebox Bootchooser Framework +............................. + +For the barebox, the boot logic that selects the correct partitions to boot from +is implemented using the bootchooser and state framework. See the barebox +documentation for detailed information about these: `Barebox Bootchooser +Framework `_, `Barebox +State Framework `_. + +First, the state framework configuration needs to be added to the barebox device +tree. Check out the :ref:`Customizing the BSP ` +chapter in the Yocto reference manual. The state framework configuration is +already included with our BSP for the supported SoC and can be directly included +in the main barebox device tree. E.g. for i.MX6 based module: + +.. code-block:: devicetree + + #include "imx6qdl-phytec-state.dtsi" + +Afterward, rebuild the image and flash the new bootloader. + +.. warning:: + + Be aware that by adding the state framework configuration, the first 160 + bytes of the EEPROM are occupied and can no longer be used for user-specific + purposes. + +The following device tree snippet shows an example of the state framework +configuration used with the BSP. As can be seen, the EEPROM is used as a backend +for the state information: + +.. code-block:: devicetree + + / { + aliases { + state = &state; + }; + + state: imx6qdl_phytec_boot_state { + magic = <0x883b86a6>; + compatible = "barebox,state"; + backend-type = "raw"; + backend = <&backend_update_eeprom>; + backend-stridesize = <54>; + + #address-cells = <1>; + #size-cells = <1>; + bootstate { + #address-cells = <1>; + #size-cells = <1>; + last_chosen { + reg = <0x0 0x4>; + type = "uint32"; + }; + system0 { + #address-cells = <1>; + #size-cells = <1>; + remaining_attempts { + reg = <0x4 0x4>; + type = "uint32"; + default = <3>; + }; + priority { + reg = <0x8 0x4>; + type = "uint32"; + default = <21>; + }; + ok { + reg = <0xc 0x4>; + type = "uint32"; + default = <0>; + }; + }; + system1 { + #address-cells = <1>; + #size-cells = <1>; + remaining_attempts { + reg = <0x10 0x4>; + type = "uint32"; + default = <3>; + }; + priority { + reg = <0x14 0x4>; + type = "uint32"; + default = <20>; + }; + ok { + reg = <0x18 0x4>; + type = "uint32"; + default = <0>; + }; + }; + }; + }; + }; + + &eeprom { + status = "okay"; + partitions { + compatible = "fixed-partitions"; + #size-cells = <1>; + #address-cells = <1>; + backend_update_eeprom: state@0 { + reg = <0x0 0x100>; + label = "update-eeprom"; + }; + }; + }; + +To be able to boot from two systems alternately, the bootchooser needs to be +aware of the state framework configuration. For each system, a boot script is +required. For a system with NAND flash, the boot script of the first system may +look like the following: + +.. code-block:: sh + :caption: /env/boot/system0 + + #!/bin/sh + + [ -e /env/config-expansions ] && /env/config-expansions + + [ ! -e /dev/nand0.root.ubi ] && ubiattach /dev/nand0.root + + global.bootm.image="/dev/nand0.root.ubi.kernel0" + global.bootm.oftree="/dev/nand0.root.ubi.oftree0" + global.linux.bootargs.dyn.root="root=ubi0:root0 ubi.mtd=root rootfstype=ubifs" + +The second boot script has the same structure but uses the partitions containing +the second system. Machines with eMMC flash use similar boot scripts, albeit the +mounting and boot arguments look different. + +Run the following commands to create the required bootchooser non-volatile +environment variables: + +.. code-block:: + + barebox$ nv bootchooser.state_prefix=state.bootstate + barebox$ nv bootchooser.system0.boot=system0 + barebox$ nv bootchooser.system1.boot=system1 + barebox$ nv bootchooser.targets="system0 system1" + +eMMC Boot Partitions +-------------------- + +With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. + +By default, bundles built with our BSP (e.g. ``phytec-headless-bundle``) contain +the bootloader for updating eMMC boot partitions accordingly. + +Note, that the U-Boot environment still resides in the user area before the +first partition. The user area also still contains the bootloader which the +image first shipped during its initialization process. + +To manually write the bootloader to the eMMC boot partitions, first disable the +write protection: + +.. code-block:: console + + target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro + target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro + +Write the bootloader to the eMMC boot partitions: + +.. code-block:: console + + target:~$ dd if=imx-boot of=/dev/mmcblk2boot0 bs=1k seek=33 + target:~$ dd if=imx-boot of=/dev/mmcblk2boot1 bs=1k seek=33 + +This example is valid for the i.MX 8M Mini SoC. Note, that other SoCs may have +different bootloader files and require different offsets where the bootloader is +expected, specified by the seek parameter. See the following table for the +different offsets being required by each SoC: + ++--------------+------------------+-----------------------+--------------+-------------+ +| SoC | Offset User Area | Offset Boot Partition | eMMC Device | Bootloader | ++==============+==================+=======================+==============+=============+ +| i.MX 6 | 1 kiB | 0 kiB | /dev/mmcblk3 | barebox.bin | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 6UL | 1 kiB | 0 kiB | /dev/mmcblk1 | barebox.bin | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M | 33 kiB | 33 kiB | /dev/mmcblk0 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Mini | 33 kiB | 33 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Nano | 32 kiB | 0 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Plus | 32 kiB | 0 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 93 | 32 kiB | 0 kiB | /dev/mmcblk0 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| AM62x | N/A | 0 kiB | /dev/mmcblk0 | tiboot3.bin | +| AM62Ax | | 512 kiB | | tispl.bin | +| AM64x | | 2560 kiB | | u-boot.img | ++--------------+------------------+-----------------------+--------------+-------------+ + +Bootloader Offsets +.................. + +Note that the offset is different, depending on whether the bootloader resides +in the user area or the boot partitions of the eMMC. + +After a bootloader has been written to the eMMC boot partitions, booting from +these can be enabled by using the following command: + +.. code-block:: console + + target:~$ mmc bootpart enable 1 0 /dev/mmcblk2 + +This also means that only the bootloaders written in the eMMC boot partitions +are used. The bootloader in the user area is not used anymore. These steps are +also executed by RAUC internally when updating the target system with a bundle. + +To disable booting from the eMMC boot partitions simply enter the following +command: + +.. code-block:: console + + target:~$ mmc bootpart enable 0 0 /dev/mmcblk2 + +After this command, the eMMC user area is used to provide the bootloader. + +When using U-Boot, a similar command is also available in the bootloader: + +.. code-block:: console + + u-boot=> mmc partconf 2 0 0 0 # disable + u-boot=> mmc partconf 2 0 1 0 # enable diff --git a/previews/271/zh_CN/_sources/rauc/scarthgap.rst.txt b/previews/271/zh_CN/_sources/rauc/scarthgap.rst.txt new file mode 100644 index 000000000..09063ef86 --- /dev/null +++ b/previews/271/zh_CN/_sources/rauc/scarthgap.rst.txt @@ -0,0 +1,1073 @@ +.. Download links +.. _`static-pdf-dl`: ../_static/rauc-scarthgap.pdf + +.. RAUC +.. |yocto-codename| replace:: Scarthgap +.. |rauc-manual| replace:: RAUC Update & Device Management Manual + +.. only:: html + + Documentation in pdf format: `Download `_ + ++---------------------------------------------------------------+ +| |rauc-manual| | ++=======================+=======================================+ +| Document Title | |rauc-manual| |yocto-codename| | ++-----------------------+---------------------------------------+ +| Document Type | RAUC Update & Device Management | +| | Manual | ++-----------------------+---------------------------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+---------------------------------------+ +| Is Branch of | |rauc-manual| | ++-----------------------+---------------------------------------+ + ++-------------------------------------+------------------+------------------+------------+ +| Compatible BSPs | BSP Release Type | BSP Release Date | BSP Status | ++=====================================+==================+==================+============+ +| BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.0 | Major | 2024-04-02 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 | Minor | 2024-04-09 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 | Minor | 2024-06-26 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX8MP-PD24.1.0 | Major | 2024-11-07 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX93-PD24.2.0 | Major | 2024-10-08 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX6UL-PD24.1.0 | Major | 2024-07-19 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM62Ax-PD24.1.0 | Major | 2024-06-27 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM62x-PD24.1.0 | Major | 2024-06-27 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM64x-PD24.1.0 | Major | 2024-06-27 | released | ++-------------------------------------+------------------+------------------+------------+ + +This manual was tested using the Yocto version |yocto-codename|. + +Introduction +============ + +PHYTEC's Yocto distribution Ampliphy (former Yogurt) supports the `RAUC +`_ (Robust Auto-Update Controller) +mechanism. RAUC controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. For +eMMC devices only, it can also update the bootloader. + +This manual describes how RAUC is used and implemented on various PHYTEC +platforms. Note, that different modules use different bootloaders and flash +storage devices, which affects the way things are handled by RAUC. Make sure to +read the correct sections fitting your platform. + +.. note:: + + This manual contains machine-specific paths and variable contents. Make sure + you are using the correct machine and device names for your application when + executing any commands. + + +System Configuration +==================== + +RAUC can be used with both eMMC and NAND flash storage. Using the distro +``ampliphy-rauc`` or ``ampliphy-vendor-rauc``, it is enabled by default and requires +no additional setup to get started. RAUC can be used in different update +scenarios. As an example, we configured the BSP to use an A/B setup to have a +completely redundant system (including the bootloader on eMMC devices). Note, +that there is an additional partition named ``config`` storing persistent +configuration data not being changed when updating. + +.. image:: /rauc/images/rauc-ab-system.png + +RAUC BSP Example Setup +---------------------- + +The partition layout is defined in the ``/etc/rauc/system.conf`` file. As an +example, this is what it looks like for i.MX 8M Mini with eMMC flash storage: + +.. code-block:: cfg + :caption: /etc/rauc/system.conf + + [system] + compatible=phyboard-polis-imx8mm-4 + bootloader=uboot + mountprefix=/mnt/rauc + + [handlers] + pre-install=/usr/lib/rauc/rauc-pre-install.sh + post-install=/usr/lib/rauc/rauc-post-install.sh + + [keyring] + path=mainca-rsa.crt.pem + + [slot.bootloader.0] + device=/dev/mmcblk2 + type=boot-emmc + + # System A + [slot.rootfs.0] + device=/dev/mmcblk2p5 + type=ext4 + bootname=system0 + + [slot.boot.0] + device=/dev/mmcblk2p1 + type=vfat + parent=rootfs.0 + + # System B + [slot.rootfs.1] + device=/dev/mmcblk2p6 + type=ext4 + bootname=system1 + + [slot.boot.1] + device=/dev/mmcblk2p2 + type=vfat + parent=rootfs.1 + +Note, that the devices specified in the slots are different depending on the +selected machine. + +.. warning:: + + Updates with RAUC use an OpenSSL certificate to verify the validity of an + image. The BSP includes a certificate that can be used for development. In a + productive system, however, it is highly recommended to use a self-created + key and certificate. If you need to change the keyring on an existing device, + see :ref:`Switching RAUC Keyrings ` for more + information. + +Design Considerations +===================== + +In order to prevent the system from locking up, it may be a good idea to utilize +a hardware watchdog. In case the Linux Kernel does not boot or another +catastrophic event occurs that prevents the system from operating normally, the +hardware watchdog then resets the system. By default, the hardware watchdog is +disabled. To enable it, refer to the corresponding BSP manual that fits your +SoM. + +Other important design considerations, as well as a checklist, can be found in +the official RAUC documentation: +https://rauc.readthedocs.io/en/latest/checklist.html + +Initial Setup +============= + +To use RAUC, the flash device needs to be written with a complete Linux system +and bootloader. The preferred method to do this is using the included tool +`partup `_. + +Flash Storage +------------- + +To flash the device with the correct partitions/volumes, use a partup package +built with the ``ampliphy-rauc`` or ``ampliphy-vendor-rauc`` distribution. +Prebuilt partup packages can be found in the BSP release. It is also possible to +build an image with this distribution yourself using Yocto. Separate build +directories are created, storing the images and packages for the RAUC system. +Initialize the build directory with the OE init script: + +.. code-block:: console + + host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source sources/poky/oe-init-build-env + +Change the distribution to ``ampliphy-rauc`` (for i.MX6, AM6x, i.MX8 mainline BSP) or +``ampliphy-vendor-rauc`` (for i.MX8, i.MX9 vendor BSP): + +.. code-block:: + :caption: build/conf/local.conf + + DISTRO ?= "ampliphy-rauc" + +Any image built with this distro now includes a full A/B system. Build the image +as usual: + +.. code-block:: console + + host:~$ bitbake phytec-headless-image + +The resulting partup package is stored in the ``deploy-ampliphy-vendor-rauc`` directory, e.g.: + +.. code-block:: + + deploy-ampliphy-vendor-rauc/images/phyboard-segin-imx93-2/phytec-headless-image-phyboard-segin-imx93-2.partup + +This partup package contains all the necessary data and configuration to flash +an eMMC. `Partup `__ can be obtained from its +`release page `_. Also, see its +README for detailed `installation instructions +`_. Partup is already installed +in our Ampliphy images, ``phytec-headless-image`` and can be directly used e.g. +from an SD card. + +.. note:: + To flash the initial RAUC system, a booted non-RAUC system is needed first on + a different flash device. E.g. you could boot a regular + ``phytec-headless-image`` image with distro ``ampliphy`` from an SD card. + +eMMC +.... + +While running a non-RAUC system from an SD card on the target, copy the +``.partup`` package built with distro ``ampliphy-rauc`` or +``ampliphy-vendor-rauc`` to the running target first: + +.. code-block:: console + + host:~$ scp phytec-headless-image-phyboard-segin-imx93-2.partup 192.168.3.11:/root + +Then install the partup package to the eMMC: + +.. code-block:: console + + target:~$ partup install phytec-headless-image-phyboard-segin-imx93-2.partup /dev/mmcblk0 + +Now the target can boot the flashed A/B system. + +NAND +.... + +.. note:: + + There are scripts provided with the bootloader barebox that previously were + used to initialize NAND flash with an A/B system: ``rauc_init_nand``, + ``rauc_flash_nand_from_tftp`` and ``rauc_flash_nand_from_mmc``. These scripts + are deprecated. It is advised to use the script ``rauc-flash-nand`` provided + in the Linux environment with PHYTEC's distribution *Ampliphy*. + +With raw NAND flash the kernel, device tree, and root filesystem are written +individually. Initialize the NAND flash with the correct volumes from a Linux on +the target: + +.. code-block:: console + + target:~$ rauc-flash-nand -k /path/to/zImage -d /path/to/oftree -r /path/to/root.ubifs + +The initialization script will automatically utilize all available space of NAND +flash. The NAND device is also determined automatically by finding the device +root in ``/proc/mtd``. + +On i.MX6 and i.MX6UL devices with barebox, use bbu (barebox update) to flash the +bootloader: + +.. code-block:: console + + target:~$ bbu.sh -f /path/to/barebox.bin + +The A/B system on NAND Flash is now ready to be booted. + +Bootloader +---------- + +Booting the A/B System by Default +................................. + +Booting the A/B system is done mostly automatically by the bootloader since the +Yocto release *hardknott*. For devices with eMMC flash storage, the +corresponding setting is written into the bootloader environment during the +building of the BSP. In particular, if the distribution ``ampliphy-rauc`` or +``ampliphy-vendor-rauc`` is used, as described previously, the bootloader should +automatically start the A/B system and have the variables set for RAUC +accordingly. + +This automatic setting can be manually changed by setting one variable in the +bootloader. The procedure is described in more detail in the following chapters +for U-Boot and barebox. + +U-Boot +...... + +After a successful boot into a Linux environment, this command is used to view +the available parameters: + +.. code-block:: console + + target:~$ fw_printenv + +You may see this parameter along with others in the output: + +.. code-block:: + + doraucboot=1 + +To manually disable or enable booting the A/B system with RAUC, set this +variable to ``0`` or ``1``: + +.. code-block:: console + + target:~$ fw_setenv doraucboot 1 + +This parameter can also be edited in U-Boot. Restart your board and hit any key +to stop the automatic boot. The environment variables can now be viewed: + +.. code-block:: + + u-boot=> printenv + +and set: + +.. code-block:: + + u-boot=> setenv doraucboot 1 + u-boot=> saveenv + +Barebox +....... + +In barebox, the system to be booted can be selected directly by its name. To +boot the A/B system, including RAUC, ``bootchooser`` is used. To boot e.g. a +regular SD card without RAUC use ``mmc`` instead, or ``nand`` for NAND devices: + +.. code-block:: + + barebox$ nv boot.default=bootchooser + +Creating RAUC Bundles +===================== + +To update your system with RAUC, a RAUC bundle (``.raucb``) needs to be created. +It contains all required images and scripts for the update and a RAUC +``manifest.raucm`` that describes the content of the bundle for the RAUC update +on the target. The BSP includes a Yocto target that lets you build a RAUC bundle +from your Yocto build. + +To create the bundle with Yocto, run the following in ``build/`` with the +distribution ``ampliphy-rauc`` or ``ampliphy-vendor-rauc`` set up, as described +previously: + +.. code-block:: console + + host:~$ bitbake phytec-headless-bundle + +This results in the creation of a ``.raucb`` bundle file in +``deploy/images//`` which can be used for updating the system as +described later. There is no need to create a ``manifest.raucm`` manually as it +is created automatically during the build of the bundle. As a reference, the +created manifest would look something like this: + +.. code-block:: cfg + :caption: manifest.raucm + + [update] + compatible=phyboard-polis-imx8mm-3 + version=r0 + description=PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0 + build=20200624074335 + + [image.rootfs] + sha256=cc3f65cd1c1993951d7a39bdb7b7d723617ac46460f8b640cd8d1622ad6e4c17 + size=99942000 + filename=phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz + + [image.boot] + sha256=bafe46679af8c6292dba22b9d402e3119ef78c6f8b458bcb6993326060de3aa4 + size=12410534 + filename=boot.tar.gz.img + +For more information about the manifest format, see +https://rauc.readthedocs.io/en/latest/reference.html#manifest. + +Creating transition bundles +--------------------------- + +Updating to a new major release can require a special RAUC bundle. + +When updating to a Scarthgap based release, add the following to your +``local.conf`` and rebuild the RAUC bundle: + +.. code-block:: + :caption: build/conf/local.conf + + RAUC_IMAGE_FSTYPE = "tar.gz" + RAUC_SLOT_rootfs[adaptive] = "" + +Updating with RAUC +================== + +To update the target system with RAUC, the RAUC bundle file previously created +first needs to be copied to the board or to a memory device that can be mounted +in Linux. One way is to copy the bundle file with ``scp``, but this requires +enough space left on the board's filesystem. To do this, boot the target board +to Linux and connect it via Ethernet to your host PC. + +On the host, run: + +.. code-block:: console + + host:~$ scp phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb root@192.168.3.11:/tmp/ + +On the target, the bundle can be verified: + +.. code-block:: console + + target:~$ rauc info /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + +and the output should look similar to this: + +.. code-block:: + + rauc-Message: 12:52:49.821: Reading bundle: /phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + rauc-Message: 12:52:49.830: Verifying bundle... + Compatible: 'phyboard-polis-imx8mm-3' + Version: 'r0' + Description: 'PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0' + Build: '20200624073212' + Hooks: '' + 2 Images: + (1) phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz + Slotclass: rootfs + Checksum: 342f67f7678d7af3f77710e1b68979f638c7f4d20393f6ffd0c36beff2789070 + Size: 180407809 + Hooks: + (2) boot.tar.gz.img + Slotclass: boot + Checksum: 8c84465b4715cc142eca2785fea09804bd970755142c9ff57e08c791e2b71f28 + Size: 12411786 + Hooks: + 0 Files + + Certificate Chain: + 0 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH Development-1 + Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + SPKI sha256: E2:47:5F:32:05:37:04:D4:8C:48:8D:A6:74:A8:21:2E:97:41:EE:88:74:B5:F4:65:75:97:76:1D:FF:1D:7B:EE + Not Before: Jan 1 00:00:00 1970 GMT + Not After: Dec 31 23:59:59 9999 GMT + 1 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development + SPKI sha256: AB:5C:DB:C6:0A:ED:A4:48:B9:40:AC:B1:48:06:AA:BA:92:09:83:8C:DC:6F:E1:5F:B6:FB:0C:39:3C:3B:E6:A2 + Not Before: Jan 1 00:00:00 1970 GMT + Not After: Dec 31 23:59:59 9999 GMT + +To check the current state of the system, run: + +.. code-block:: console + + target:~$ rauc status + +and get output similar to this: + +.. code-block:: + + === System Info === + Compatible: phyboard-segin-imx6ul-6 + Variant: + Booted from: rootfs.0 (system0) + + === Bootloader === + Activated: rootfs.0 (system0) + + === Slot States === + o [rootfs.1] (/dev/ubi0_6, ubifs, inactive) + bootname: system1 + boot status: good + [dtb.1] (/dev/ubi0_3, ubivol, inactive) + [kernel.1] (/dev/ubi0_2, ubivol, inactive) + + x [rootfs.0] (/dev/ubi0_5, ubifs, booted) + bootname: system0 + boot status: good + [kernel.0] (/dev/ubi0_0, ubivol, active) + [dtb.0] (/dev/ubi0_1, ubivol, active) + +To update the currently inactive system with the downloaded bundle, run: + +.. code-block:: console + + target:~$ rauc install /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb + +and reboot afterward: + +.. code-block:: console + + target:~$ reboot + +With the success of the update, RAUC automatically switches the active system to +the newly updated system. Now during reboot, RAUC counts the boot attempts of +the kernel and if it fails more often than specified in the state framework of +the system, RAUC switches back to the old system and marks the new system as +bad. If the boot attempt to the kernel is successful, the new system is marked +as good and the old system can now be updated with the same instructions. After +two successful ``rauc install`` and ``reboot``, both systems are updated. + +.. tip:: + + When you update from a USB stick, make sure to remove the stick after a + successful update before rebooting. If not, an automatic update will be + started after each boot. This is due to the :ref:`Automatic Update from USB Flash + Drive with RAUC ` you can find below. + +Changing the Active Boot Slot +----------------------------- + +It is possible to switch the active system manually: + +.. code-block:: console + + target:~$ rauc status mark-active other + +After a reboot, the target now starts from the other system. + +.. _scarthgap_rauc-switch-keyrings: + +Switching RAUC Keyrings +======================= + +PHYTEC's distribution comes with keys and certificates used for development and +demonstration purposes only. To change to a different PKI when devices are +already rolled out, RAUC's keyring must be changed. This chapter describes the +full procedure from a development state to a production state. Keep in mind, +that it is always a better idea to roll out your devices with a production +keyring in the first place, instead of relying on a development one for too +long. The following diagram shows the general process of switching keyrings for +RAUC: + +.. image:: /rauc/images/rauc-switching-keyrings.png + +Keyring Switching Process +------------------------- + +Create new certificates and keys for your own PKI. See our security manual for a +detailed description on how to create a custom PKI. For this document, we refer +to this newly created PKI as "production", as opposed to the existing +"development" keys. + +Move the generated keys and certificates, to your main Yocto build directory +root, alongside with ``build/`` and ``sources/``. + +.. warning:: + + Be careful where you store the private keys! These should in no way be made + publicly available. E.g. do not store the private keys in a public Git + repository. Otherwise, unauthorized entities could create RAUC bundles that + can be installed on your target system! + +Now, a RAUC bundle must be created that contains the new "production" CA keyring +in its root filesystem but is still signed by the "development" CA. With this, +the system is converted from a "development" system to a "production" system. To +achieve this, exchange the file ``ca.cert.pem`` installed by the RAUC recipe in +the Yocto sources. Create a file ``rauc_%.bbappend`` in your own Yocto layer: + +.. code-block:: + :caption: recipes-core/rauc/rauc_%.bbappend + + FILESEXTRAPATHS_prepend := "${THISDIR}/files:" + + RAUC_KEYRING_FILE = "${CERT_PATH}/rauc-customer/ca.cert.pem" + +Build the same RAUC bundle as before, now with the exchanged keyring: + +.. code-block:: console + + host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source source/poky/oe-init-build-env + host:~$ bitbake phytec-headless-bundle # Build the desired RAUC bundle + +Install the resulting RAUC bundle as usual. The target now has the image with +the "production" keyring installed in its other slot ("System B" in the figure +above). Reboot to start that system. + +All future RAUC bundles for the "production" system must now also be signed by +the "production" CA. For this, change the key and certificate to your newly +generated "production" ones in the bundle recipe: + +.. code-block:: + :caption: recipes-images/bundles/customer-headless-bundle.bb + + require phytec-base-bundle.inc + + RAUC_SLOT_rootfs ?= "phytec-headless-image" + + RAUC_KEY_FILE = "${CERT_PATH}/rauc-customer/private/production-1.key.pem" + RAUC_CERT_FILE = "${CERT_PATH/rauc-customer/production-1.cert.pem" + + RAUC_INTERMEDIATE_CERT_FILE = "" + +Rebuild the RAUC bundle: + +.. code-block:: console + + host:~$ bitbake customer-headless-bundle + +These and any future bundles are now ready to be installed on your "production" +target system and have been fully migrated away from the "development" system. +This also means that now only bundles signed by the "production" CA can be +installed on the target (and e.g. "development" bundles cannot). + +Use Case Examples +================= + +.. _scarthgap_rauc-automatic-updates-usb: + +Automatic Updates from USB Flash Drive with RAUC +------------------------------------------------ + +One of the most prominent use cases for RAUC might be an automatic update system +from a USB flash drive. This use case is implemented in the BSP as a reference +example. We combine only standard Linux mechanisms with RAUC to build the +system. The kernel notifies *udev* when a device gets plugged into the USB port. +We use a custom *udev* rule to trigger a systemd service when this event +happens. + +.. code-block:: + :caption: 10-update-usb.rules + + KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end" + + # Trigger systemd service + ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}="update-usb@%k.service" + + # Exit + LABEL="media_by_label_auto_mount_end" + +The service automatically mounts the USB flash drive and notifies the +application. + +.. code-block:: systemd + :caption: update-usb@.service + + [Unit] + Description=usb media RAUC service + After=multi-user.target + Requires=rauc.service + + [Service] + Type=oneshot + Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket + ExecStartPre=/bin/mkdir -p /media/%I + ExecStartPre=/bin/mount -t auto /dev/%I /media/%I + ExecStart=/usr/bin/update_usb.sh %I + ExecStop=/bin/umount -l /media/%i + ExecStopPost=-/bin/rmdir /media/%I + +In our reference implementation, we simply use a shell script for the +application logic. + +.. code-block:: sh + :caption: update_usb.sh + + #!/bin/sh + + MOUNT=/media/$1 + + NUMRAUCM=$(find ${MOUNT}/*.raucb -maxdepth 0 | wc -l) + + [ "$NUMRAUCM" -eq 0 ] && echo "${MOUNT}*.raucb not found" && exit + [ "$NUMRAUCM" -ne 1 ] && echo "more than one ${MOUNT}/*.raucb" && exit + + rauc install $MOUNT/*.raucb + if [ "$?" -ne 0 ]; then + echo "Failed to install RAUC bundle." + else + echo "Update successful." + fi + exit $? + +The update logic can be integrated into an application using the *systemd D-Bus +API*. RAUC does not need to be called by its command-line interface but can be +integrated with D-Bus. + +.. tip:: + + RAUC features a D-Bus API interface (see + https://rauc.readthedocs.io/en/latest/using.html#using-the-d-bus-api). + +Security Measurement: Downgrade Barrier +--------------------------------------- + +As a second reference example, we will implement a security mechanism: a +downgrade barrier. When you detect a security vulnerability on your system, you +will fix it and update your system. The systems with the new software will now +be secure again. If an attacker gets a hold of the old software update bundle, +which still has a valid signature, the attacker might have the possibility to +install the old software and still take advantage of the previously fixed +security vulnerability. To prevent this from happening, you could revoke the +updated certificate for every single update and create a new one. This might be +difficult to handle, depending on the environment. A simpler solution would be +to allow updates only in one direction using a version check. + +.. code-block:: sh + :caption: rauc_downgrade_barrier.sh + + #!/bin/sh + + VERSION_FILE=/etc/rauc/downgrade_barrier_version + MANIFEST_FILE=${RAUC_UPDATE_SOURCE}/manifest.raucm + + [ ! -f ${VERSION_FILE} ] && exit 1 + [ ! -f ${MANIFEST_FILE} ] && exit 2 + + VERSION=`cat ${VERSION_FILE} | cut -d 'r' -f 2` + BUNDLE_VERSION=`grep "version" -rI ${MANIFEST_FILE} | cut -d 'r' -f 3` + + # check from empty or unset variables + [ -z "${VERSION}" ] && exit 3 + [ -z "${BUNDLE_VERSION}" ] && exit 4 + + # developer mode, allow all updates if version is r0 + #[ ${VERSION} -eq 0 ] && exit 0 + + # downgrade barrier + if [ ${VERSION} -gt ${BUNDLE_VERSION} ]; then + echo "Downgrade barrier blocked rauc update! CODE5\n" + else + exit 0 + fi + exit 5 + +The script is installed on the target but it is not activated. You need to +remove the developer mode line in the script to activate it. + +Streaming Bundles over HTTP +--------------------------- + +Instead of copying the bundle to the device, the bundle can be streamed over +HTTP. Using bundle streaming has the advantage of not requiring local storage on +the target. A simple approach to this is running NGINX inside a Docker +container. The following example shows how to implement a minimal download +server enabling HTTP range requests to support this feature. + +Create a Dockerfile with the following content: + +.. code-block:: dockerfile + :caption: Dockerfile + + FROM nginx + + COPY bundles /bundles + COPY nginx.conf /etc/nginx/nginx.conf + +Configure NGINX to enable HTTP range requests and point it to the bundle file. + +.. code-block:: nginx + :caption: nginx.conf + + events {} + http { + server { + proxy_force_ranges on; + + location / { + root /bundles; + } + } + } + +Place a bundle in the ``bundles`` sub-directory. The folder structure looks like +the following after creating all configuration files: + +.. code-block:: console + + user@host:rauc-bundle-streaming$ find + . + ./bundles + ./bundles/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb + ./nginx.conf + ./Dockerfile + +Build and run the docker container on the host system: + +.. code-block:: console + + host:~$ sudo docker build -t rauc-bundle-streaming . + host:~$ sudo docker run --name bundles -p 80:80 -d rauc-bundle-streaming + +Install the bundle on the currently inactive target partitions: + +.. code-block:: console + + target:~$ rauc install http://192.168.3.10/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb + +.. note:: + + After the update finishes the target may display the following error which + has no impact on the success of the update: + + .. code-block:: + + [ 7416.336609] block nbd0: NBD_DISCONNECT + [ 7416.340413] block nbd0: Send disconnect failed -32 + +Reference +========= + +Boot Logic Implementation +------------------------- + +.. tip:: + + The implementation details described in this chapter serve as a reference + guide. PHYTEC BSPs that have RAUC support include these by default and the + changes are already incorporated. + +U-Boot Environment Variables +............................ + +For U-Boot, the boot logic that selects the correct partitions to boot from is +implemented in its environment. As a reference, these are the most important +U-Boot variables that are used for the A/B system with RAUC: + ++-------------------+--------------------------------------------------------+ +| Name | Function | ++===================+========================================================+ +| BOOT_ORDER | Contains a space-separated list of boot targets in the | +| | order they should be tried. This parameter is | +| | automatically set by RAUC. | ++-------------------+--------------------------------------------------------+ +| BOOT__LEFT | Contains the number of remaining boot attempts to | +| | perform for the respective slot. This parameter is | +| | automatically set by RAUC. | ++-------------------+--------------------------------------------------------+ +| ``raucinit`` | Contains the boot logic that sets the partitions so | +| | the correct system is loaded. | ++-------------------+--------------------------------------------------------+ +| ``doraucboot`` | Enables booting the A/B system if set to 1 and | +| | disables it if set to 0. | ++-------------------+--------------------------------------------------------+ +| ``raucargs`` | Sets the Kernel bootargs like console, root, and RAUC | +| | slot. | ++-------------------+--------------------------------------------------------+ +| ``raucrootpart`` | Sets the root filesystem partitions of the device. | ++-------------------+--------------------------------------------------------+ +| ``raucbootpart`` | Sets the boot partitions of the device. | ++-------------------+--------------------------------------------------------+ + +These environment variables are defined in ``include/env/phytec/rauc.env`` in +the u-boot source code. + +.. note:: + + A change in the partition layout, e.g. when using an additional data + partition, may require changing the variables ``raucrootpart`` and + ``raucbootpart``. Make sure to rebuild your image with the new bootloader + environment after you have made the appropriate changes. + +Barebox Bootchooser Framework +............................. + +For the barebox, the boot logic that selects the correct partitions to boot from +is implemented using the bootchooser and state framework. See the barebox +documentation for detailed information about these: `Barebox Bootchooser +Framework `_, `Barebox +State Framework `_. + +First, the state framework configuration needs to be added to the barebox device +tree. Check out the :ref:`Customizing the BSP ` +chapter in the Yocto reference manual. The state framework configuration is +already included with our BSP for the supported SoC and can be directly included +in the main barebox device tree. E.g. for i.MX6 based module: + +.. code-block:: devicetree + + #include "imx6qdl-phytec-state.dtsi" + +Afterward, rebuild the image and flash the new bootloader. + +.. warning:: + + Be aware that by adding the state framework configuration, the first 160 + bytes of the EEPROM are occupied and can no longer be used for user-specific + purposes. + +The following device tree snippet shows an example of the state framework +configuration used with the BSP. As can be seen, the EEPROM is used as a backend +for the state information: + +.. code-block:: devicetree + + / { + aliases { + state = &state; + }; + + state: imx6qdl_phytec_boot_state { + magic = <0x883b86a6>; + compatible = "barebox,state"; + backend-type = "raw"; + backend = <&backend_update_eeprom>; + backend-stridesize = <54>; + + #address-cells = <1>; + #size-cells = <1>; + bootstate { + #address-cells = <1>; + #size-cells = <1>; + last_chosen { + reg = <0x0 0x4>; + type = "uint32"; + }; + system0 { + #address-cells = <1>; + #size-cells = <1>; + remaining_attempts { + reg = <0x4 0x4>; + type = "uint32"; + default = <3>; + }; + priority { + reg = <0x8 0x4>; + type = "uint32"; + default = <21>; + }; + ok { + reg = <0xc 0x4>; + type = "uint32"; + default = <0>; + }; + }; + system1 { + #address-cells = <1>; + #size-cells = <1>; + remaining_attempts { + reg = <0x10 0x4>; + type = "uint32"; + default = <3>; + }; + priority { + reg = <0x14 0x4>; + type = "uint32"; + default = <20>; + }; + ok { + reg = <0x18 0x4>; + type = "uint32"; + default = <0>; + }; + }; + }; + }; + }; + + &eeprom { + status = "okay"; + partitions { + compatible = "fixed-partitions"; + #size-cells = <1>; + #address-cells = <1>; + backend_update_eeprom: state@0 { + reg = <0x0 0x100>; + label = "update-eeprom"; + }; + }; + }; + +To be able to boot from two systems alternately, the bootchooser needs to be +aware of the state framework configuration. For each system, a boot script is +required. For a system with NAND flash, the boot script of the first system may +look like the following: + +.. code-block:: sh + :caption: /env/boot/system0 + + #!/bin/sh + + [ -e /env/config-expansions ] && /env/config-expansions + + [ ! -e /dev/nand0.root.ubi ] && ubiattach /dev/nand0.root + + global.bootm.image="/dev/nand0.root.ubi.kernel0" + global.bootm.oftree="/dev/nand0.root.ubi.oftree0" + global.linux.bootargs.dyn.root="root=ubi0:root0 ubi.mtd=root rootfstype=ubifs" + +The second boot script has the same structure but uses the partitions containing +the second system. Machines with eMMC flash use similar boot scripts, albeit the +mounting and boot arguments look different. + +Run the following commands to create the required bootchooser non-volatile +environment variables: + +.. code-block:: + + barebox$ nv bootchooser.state_prefix=state.bootstate + barebox$ nv bootchooser.system0.boot=system0 + barebox$ nv bootchooser.system1.boot=system1 + barebox$ nv bootchooser.targets="system0 system1" + +eMMC Boot Partitions +-------------------- + +With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader. + +By default, bundles built with our BSP (e.g. ``phytec-headless-bundle``) contain +the bootloader for updating eMMC boot partitions accordingly. + +Note, that the U-Boot environment still resides in the user area before the +first partition. The user area also still contains the bootloader which the +image first shipped during its initialization process. + +To manually write the bootloader to the eMMC boot partitions, first disable the +write protection: + +.. code-block:: console + + target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro + target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro + +Write the bootloader to the eMMC boot partitions: + +.. code-block:: console + + target:~$ dd if=imx-boot of=/dev/mmcblk2boot0 bs=1k seek=33 + target:~$ dd if=imx-boot of=/dev/mmcblk2boot1 bs=1k seek=33 + +This example is valid for the i.MX 8M Mini SoC. Note, that other SoCs may have +different bootloader files and require different offsets where the bootloader is +expected, specified by the seek parameter. See the following table for the +different offsets being required by each SoC: + ++--------------+------------------+-----------------------+--------------+-------------+ +| SoC | Offset User Area | Offset Boot Partition | eMMC Device | Bootloader | ++==============+==================+=======================+==============+=============+ +| i.MX 6 | 1 kiB | 0 kiB | /dev/mmcblk3 | barebox.bin | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 6UL | 1 kiB | 0 kiB | /dev/mmcblk1 | barebox.bin | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M | 33 kiB | 33 kiB | /dev/mmcblk0 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Mini | 33 kiB | 33 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Nano | 32 kiB | 0 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 8M Plus | 32 kiB | 0 kiB | /dev/mmcblk2 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| i.MX 93 | 32 kiB | 0 kiB | /dev/mmcblk0 | imx-boot | ++--------------+------------------+-----------------------+--------------+-------------+ +| AM62x | N/A | 0 kiB | /dev/mmcblk0 | tiboot3.bin | +| AM62Ax | | 512 kiB | | tispl.bin | +| AM64x | | 2560 kiB | | u-boot.img | ++--------------+------------------+-----------------------+--------------+-------------+ + +Bootloader Offsets +.................. + +Note that the offset is different, depending on whether the bootloader resides +in the user area or the boot partitions of the eMMC. + +After a bootloader has been written to the eMMC boot partitions, booting from +these can be enabled by using the following command: + +.. code-block:: console + + target:~$ mmc bootpart enable 1 0 /dev/mmcblk2 + +This also means that only the bootloaders written in the eMMC boot partitions +are used. The bootloader in the user area is not used anymore. These steps are +also executed by RAUC internally when updating the target system with a bundle. + +To disable booting from the eMMC boot partitions simply enter the following +command: + +.. code-block:: console + + target:~$ mmc bootpart enable 0 0 /dev/mmcblk2 + +After this command, the eMMC user area is used to provide the bootloader. + +When using U-Boot, a similar command is also available in the bootloader: + +.. code-block:: + + u-boot=> mmc partconf 2 0 0 0 # disable + u-boot=> mmc partconf 2 0 1 0 # enable diff --git a/previews/271/zh_CN/_sources/yocto/kirkstone.rst.txt b/previews/271/zh_CN/_sources/yocto/kirkstone.rst.txt new file mode 100644 index 000000000..bfb5eca76 --- /dev/null +++ b/previews/271/zh_CN/_sources/yocto/kirkstone.rst.txt @@ -0,0 +1,3128 @@ +.. Download links +.. _`static-pdf-dl`: ../_static/kirkstone.pdf + +.. Yocto +.. |yocto-codename| replace:: Kirkstone +.. |yocto-ref-manual| replace:: Yocto Reference Manual +.. |distro| replace:: ampliphy-vendor-xwayland + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-------------------------------------------------------------+ +| |yocto-ref-manual| | ++=======================+=====================================+ +| Document Title | |yocto-ref-manual| |yocto-codename| | ++-----------------------+-------------------------------------+ +| Document Type | Yocto Manual | ++-----------------------+-------------------------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+-------------------------------------+ +| Is Branch of | |yocto-ref-manual| | ++-----------------------+-------------------------------------+ + ++-------------------------------------+------------------+------------------+------------+ +| Compatible BSPs | BSP Release Type | BSP Release Date | BSP Status | ++=====================================+==================+==================+============+ +| BSP-Yocto-Ampliphy-i.MX6-PD22.1.0 | Major | 14.12.2022 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX6-PD22.1.1 | Minor | 20.06.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.0 | Major | 11.08.2022 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1 | Minor | 23.05.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM335x-PD23.1.0 | Major | 25.04.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX8MM-PD23.1.0 | Major | 12.12.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX8MP-PD23.1.0 | Major | 12.12.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM62x-PD23.2.0 | Major | 28.09.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM62Ax-PD23.1.0 | Major | 28.09.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM64x-PD23.2.0 | Major | 28.09.2023 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX7-PD23.1.0 | Major | 15.12.2023 | released | ++-------------------------------------+------------------+------------------+------------+ + + +This manual applies to all |yocto-codename| based PHYTEC releases. + +.. _yocto-man-kirkstone: + +The Yocto Project +================= + +PHYTEC Documentation +-------------------- + +PHYTEC will provide a variety of hardware and software documentation for all of +our products. This includes any or all of the following: + +- **QS Guide**: A short guide on how to set up and boot a phyCORE board along + with brief information on building a BSP, the device tree, and accessing + peripherals. +- **Hardware Manual**: A detailed description of the System on Module and + accompanying carrier board. +- **Yocto Guide**: A comprehensive guide for the Yocto version the phyCORE + uses. This guide contains an overview of Yocto; introducing, installing, and + customizing the PHYTEC BSP; how to work with programs like Poky and Bitbake; + and much more. +- **BSP Manual**: A manual specific to the BSP version of the phyCORE. + Information such as how to build the BSP, booting, updating software, device + tree, and accessing peripherals can be found here. +- **Development Environment Guide**: This guide shows how to work with the + Virtual Machine (VM) Host PHYTEC has developed and prepared to run various + Development Environments. There are detailed step-by-step instructions for + Eclipse and Qt Creator, which are included in the VM. There are instructions + for running demo projects for these programs on a phyCORE product as well. + Information on how to build a Linux host PC yourself is also a part of this + guide. +- **Pin Muxing Table**: phyCORE SOMs have an accompanying pin table (in Excel + format). This table will show the complete default signal path, from + processor to carrier board. The default device tree muxing option will also + be included. This gives a developer all the information needed in one + location to make muxing changes and design options when developing a + specialized carrier board or adapting a PHYTEC phyCORE SOM to an application. + +On top of these standard manuals and guides, PHYTEC will also provide Product +Change Notifications, Application Notes, and Technical Notes. These will be done +on a case-by-case basis. Most of the documentation can be found in the +applicable download page of our products. + +Yocto Introduction +------------------ + +Yocto is the smallest SI metric system prefix. Like milli equates to ``m = +10^-3``, and so is yocto ``y = 10^-24``. Yocto is also a project working group +of the `Linux Foundation `_ and therefore +backed up by several major companies in the field. On the `Yocto Project website +`_ you can read the official introduction: + + The Yocto Project is an open-source collaboration project that provides + templates, tools, and methods to help you create custom Linux-based systems + for embedded products regardless of the hardware architecture. It was founded + in 2010 as a collaboration among many hardware manufacturers, open-source + operating systems vendors, and electronics companies to bring some order to + the chaos of embedded Linux development. + +As said, the project wants to provide toolsets for embedded developers. It +builds on top of the long-lasting `OpenEmbedded +`_ project. It is not a Linux +distribution. But it contains the tools to create a Linux distribution +specially fitted to the product requirements. The most important step in +bringing order to the set of tools is to define a common versioning scheme and +a reference system. All subprojects have then to comply with the reference +system and have to comply with the versioning scheme. + +The release process is similar to the `Linux kernel `_. +Yocto increases its version number every six months and gives the release a +codename. The release list can be found here: +https://wiki.yoctoproject.org/wiki/Releases + +Core Components +--------------- + +The most important tools or subprojects of the *Yocto* Project are: + +- Bitbake: build engine, a task scheduler like make, interprets metadata +- OpenEmbedded-Core, a set of base layers, containing metadata of software, no + sources +- Yocto kernel + + - Optimized for embedded devices + - Includes many subprojects: rt-kernel, vendor patches + - The infrastructure provided by Wind River + - Alternative: classic kernel build → we use it to integrate our kernel into + *Yocto* + +- *Yocto* Reference BSP: *beagleboneblack*, *minnow max* +- *Poky*, the reference system, a collection of projects and tools, used to + bootstrap a new distribution based on *Yocto* + +Vocabulary +---------- + +Recipes +....... + +Recipes contain information about the software project (author, homepage, and +license). A recipe is versioned, defines dependencies, contains the URL of the +source code, and describes how to fetch, configure, and compile the sources. It +describes how to package the software, e.g. into different .deb packages, which +then contain the installation path. Recipes are basically written in *Bitbake's* +own programming language, which has a simple syntax. However, a recipe can +contain *Python* as well as a bash code. + +Classes +....... + +Classes combine functionality used inside recipes into reusable blocks. + +Layers +...... + +A layer is a collection of recipes, classes, and configuration metadata. +A layer can depend on other layers and can be included or excluded one +by one. It encapsulates a specific functionality and fulfills a specific +purpose. Each layer falls into a specific category: + +- Base +- Machine (BSP) +- Software +- Distribution +- Miscellaneous + +*Yocto's* versioning scheme is reflected in every layer as version branches. For +each *Yocto* version, every layer has a named branch in its *Git* repository. +You can add one or many layers of each category in your build. + +A collection of OpenEmbedded layers can be found here. The search function is +very helpful to see if a software package can be retrieved and integrated +easily: https://layers.openembedded.org/layerindex/branch/kirkstone/layers/ + +Machine +....... + +Machines are configuration variables that describe the aspects of the target +hardware. + +Distribution (Distro) +..................... + +Distribution describes the software configuration and comes with a set of +software features. + +Poky +---- + +*Poky* is the reference system to define *Yocto* Project compatibility. It +combines several subprojects into releases: + +- *Bitbake* +- *Toaster* +- OpenEmbedded Core +- *Yocto* Documentation +- *Yocto* Reference BSP + +Bitbake +....... + +*Bitbake* is the task scheduler. It is written in *Python* and interprets +recipes that contain code in *Bitbake's* own programming language, *Python*, and +bash code. The official documentation can be found here: +https://docs.yoctoproject.org/bitbake/2.0/index.html + +Toaster +....... + +*Toaster* is a web frontend for *Bitbake* to start and investigate builds. It +provides information about the build history and statistics on created images. +There are several use cases where the installation and maintenance of +a *Toaster* instance are beneficial. PHYTEC did not add or remove any features +to the upstream *Toaster*, provided by *Poky*. The best source for more +information is the official documentation: +https://docs.yoctoproject.org/4.0.6/toaster-manual/index.html + +Official Documentation +---------------------- + +For more general questions about *Bitbake* and *Poky* consult the mega-manual: +https://docs.yoctoproject.org/4.0.6/singleindex.html + +Compatible Linux Distributions +============================== + +To build *Yocto* you need a compatible *Linux* host development machine. The +list of supported distributions can be found in the reference manual: +https://docs.yoctoproject.org/4.0.6/ref-manual/system-requirements.html#supported-linux-distributions + +PHYTEC BSP Introduction +======================= + +BSP Structure +------------- + +The BSP consists roughly of three parts. BSP management, BSP metadata, and BSP +content. The management consists of *Repo* and phyLinux while the metadata +depends on the SOC, which describes how to build the software. The content +comprises PHYTEC's *Git* repositories and external sources. + +BSP Management +.............. + +*Yocto* is an umbrella project. Naturally, this will force the user to base +their work on several external repositories. They need to be managed in a +deterministic way. We use manifest files, which contain an XML data structure, +to describe all git repositories with pinned-down versions. The *Repo* tool and +our phyLinux wrapper script are used to manage the manifests and set up the BSP, +as described in the manifest file. + +phyLinux +~~~~~~~~ + +phyLinux is a wrapper for *Repo* to handle downloading and setting up the BSP +with an "out of the box" experience. + +Repo +~~~~ + +*Repo* is a wrapper around the *Repo* toolset. The phyLinux script will install +the wrapper in a global path. This is only a wrapper, though. Whenever you run +``repo init -u ``, you first download the *Repo* tools from *Googles* Git +server in a specific version to the ``.repo/repo`` directory. The next time you +run *Repo*, all the commands will be available. Be aware that the *Repo* version +in different build directories can differ over the years if you do not run *Repo +sync*. Also if you store information for your archives, you need to include the +complete ``.repo`` folder. + +*Repo* expects a *Git* repository which will be parsed from the command line. In +the PHYTEC BSP, it is called phy²octo. In this repository, all information about +a software BSP release is stored in the form of a *Repo* XML manifest. This data +structure defines URLs of *Git* servers (called "remotes") and *Git* +repositories and their states (called "projects"). The *Git* repositories can be +seen in different states. The revision field can be a branch, tag, or commit id +of a repository. This means the state of the software is not necessarily unique +and can change over time. That is the reason we use only tags or commit ids for +our releases. The state of the working directory is then unique and does not +change. + +The manifests for the releases have the same name as the release itself. It is a +unique identifier for the complete BSP. The releases are sorted by the SoC +platform. The selected SoC will define the branch of the phy²octo *Git* +repository which will be used for the manifest selection. + +BSP Metadata +............ + +We include several third-party layers in our BSP to get a complete *Linux* +distribution up and running without the need to integrate external projects. All +used repositories are described in the following section. + +Poky +~~~~ + +The PHYTEC BSP is built on top of *Poky*. It comes with a specific version, +defined in the *Repo* manifest. *Poky* comes with a specific version of +*Bitbake*. The OpenEmbedded-core layer "meta" is used as a base for our *Linux* +system. + +meta-openembedded +~~~~~~~~~~~~~~~~~ + +OpenEmbedded is a collection of different layers containing the meta description +for many open-source software projects. We ship all OpenEmbedded layers with our +BSP, but not all of them are activated. Our example images pull several software +packages generated from OpenEmbedded recipes. + +meta-qt6 +~~~~~~~~ + +This layer provides an integration of *Qt6* in the *Poky*-based root filesystem +and is integrated into our BSP. + +meta-nodejs +~~~~~~~~~~~ + +This is an application layer to add recent Node.js versions. + +meta-gstreamer1.0 +~~~~~~~~~~~~~~~~~ + +This is an application layer to add recent GStreamer versions. + +meta-rauc +~~~~~~~~~ + +This layer contains the tools required to build an updated infrastructure with +`RAUC `_. A comparison with +other update systems can be found here: `Yocto update tools +`_. + +meta-phytec +~~~~~~~~~~~ + +This layer contains all machines and common features for all our BSPs. It is +PHYTEC's `Yocto Board Support Package +`_ for all supported +hardware (since *fido*) and is designed to be standalone with *Poky*. Only these +two parts are required if you want to integrate the PHYTEC's hardware into your +existing *Yocto* workflow. The features are: + +- Bootloaders in ``recipes-bsp/barebox/`` and ``recipes-bsp/u-boot/`` +- Kernels in ``recipes-kernel/linux/`` and + ``dynamic-layers/fsl-bsp-release/recipes-kernel/linux/`` +- Many machines in ``conf/machine/`` +- Proprietary *OpenGL ES/EGL* user space libraries for AM335x and i.MX 6 + platforms +- Proprietary *OpenCL* libraries for i.MX 6 platforms + +meta-ampliphy +~~~~~~~~~~~~~ + +This is our example distribution and BSP layer. It extends the basic +configuration of *Poky* with software projects described by all the other BSP +components. It provides a base for your specific development scenarios. The +current features are: + +- `systemd `_ init system +- Images: ``phytec-headless-image`` for non-graphics applications +- Camera integration with OpenCV and GStreamer examples for the i.MX 6 platform + bundled in a ``phytec-vision-image`` +- RAUC integration: we set up basic support for an A/B system image update, + which is possible locally and over-the-air + +meta-qt6-phytec +~~~~~~~~~~~~~~~ + +This is our layer for Qt6 board integration and examples. The features are: + +- `Qt6 with eglfs backend `_ for + PHYTEC's AM335x, i.MX 6 and RK3288 platforms +- Images: ``phytec-qt6demo-image`` for *Qt6* and video applications +- A *Qt6* demo application demonstrating how to create a *Qt6* project using + *QML* widgets and a *Bitbake* recipe for the *Yocto* and *systemd* + integration. It can be found in + ``sources/meta-qt6-phytec/recipes-qt/examples/phytec-qtdemo_git.bb`` + +meta-virtualization +~~~~~~~~~~~~~~~~~~~ + +- This layer provides support for building Xen, KVM, Libvirt, and associated + packages necessary for constructing OE-based virtualized solutions. + +meta-security +~~~~~~~~~~~~~ + +- This layer provides security tools, hardening tools for Linux kernels, and + libraries for implementing security mechanisms. + +meta-selinux +~~~~~~~~~~~~ + +- This layer's purpose is to enable SE Linux support. The majority of this + layer's work is accomplished in *bbappend* files, used to enable SE Linux + support in existing recipes. + +meta-browser +~~~~~~~~~~~~ + +- This is an application layer to add recent web browsers (Chromium, Firefox, + etc.). + +meta-rust +~~~~~~~~~ + +- Includes the Rust compiler and the Cargo package manager for Rust. + +meta-timesys +~~~~~~~~~~~~ + +- Timesys layer for Vigiles Yocto CVE monitoring, security notifications, and + image manifest generation. + +meta-freescale +~~~~~~~~~~~~~~ + +- This layer provides support for the i.MX, Layerscape, and QorIQ product + lines. + +meta-freescale-3rdparty +~~~~~~~~~~~~~~~~~~~~~~~ + +- Provides support for boards from various vendors. + +meta-freescale-distro +~~~~~~~~~~~~~~~~~~~~~ + +- This layer provides support for Freescale's Demonstration images for use with + OpenEmbedded and/or Yocto Freescale's BSP layer. + +base (fsl-community-bsp-base) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- This layer provides BSP base files of NXP. + +meta-fsl-bsp-release +~~~~~~~~~~~~~~~~~~~~ + +- This is the i.MX Yocto Project Release Layer. + +BSP Content +........... + +The BSP content gets pulled from different online sources when you first start +using *Bitbake*. All files will be downloaded and cloned in a local directory +configured as ``DL_DIR`` in *Yocto*. If you backup your BSP with the complete +content, those sources have to be backed up, too. How you can do this will be +explained in the chapter :ref:`kirkstone_gen-source-mirrors`. + +Build Configuration +------------------- + +The BSP initializes a build folder that will contain all files you +create by running *Bitbake* commands. It contains a ``conf`` folder +that handles build input variables. + +- ``bblayers.conf`` defines activated meta-layers, +- ``local.conf`` defines build input variables specific to your build +- ``site.conf`` defines build input variables specific to the development host + +The two topmost build input variables are ``DISTRO`` and ``MACHINE``. They are +preconfigured ``local.conf`` when you check out the BSP using phyLinux. + +We use "*Ampliphy*" as ``DISTRO`` with our BSP. This distribution will be +preselected and give you a starting point for implementing your own +configuration. + +A ``MACHINE`` defines a binary image that supports specific hardware +combinations of module and baseboard. Check the ``machine.conf`` file or our +webpage for a description of the hardware. + +Pre-built Images +================ + +For each BSP we provide pre-built target images that can be downloaded from the +PHYTEC FTP server: https://download.phytec.de/Software/Linux/ + +These images are also used for the BSP tests, which are flashed to the boards +during production. You can use the provided ``.wic`` images to create a bootable +SD card at any time. Identify your hardware and flash the downloaded image file +to an empty SD card using ``dd``. Please see section Images for information +about the correct usage of the command. + +BSP Workspace Installation +========================== + +Setting Up the Host +------------------- + +You can set up the host or use one of our build-container to run a Yocto build. +You need to have a running *Linux* distribution. It should be running on a +powerful machine since a lot of compiling will need to be done. + +If you want to use a build-container, you only need to install following +packages on your host + +.. code-block:: console + + host:~$ sudo apt install wget git + +Continue with the next step :ref:`kirkstone_git-config` after that. The documentation for +using build-container can be found in this manual after +:ref:`kirkstone_phylinux-advanced-usage` of phyLinux. + +Else *Yocto* needs a handful of additional packages on your host. For *Ubuntu +20.04* you need + +.. code-block:: console + + host:~$ sudo apt install gawk wget git diffstat unzip texinfo \ + gcc build-essential chrpath socat cpio python3 python3-pip \ + python3-pexpect xz-utils debianutils iputils-ping python3-git \ + python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm \ + python3-subunit mesa-common-dev zstd liblz4-tool + +For other distributions you can find information in the *Yocto* Quick Build: +https://docs.yoctoproject.org/4.0.6/brief-yoctoprojectqs/index.html + +.. _kirkstone_git-config: + +Git Configuration +----------------- + +The BSP heavily utilizes *Git*. *Git* needs some information from +you as a user to identify who made changes. Create a ``~/.gitconfig`` with the +following content, if you do not have one + +.. code-block:: kconfig + + [user] + name = + email = + [core] + editor = vim + [merge] + tool = vimdiff + [alias] + co = checkout + br = branch + ci = commit + st = status + unstage = reset HEAD -- + last = log -1 HEAD + [push] + default = current + [color] + ui = auto + +You should set ``name`` and ``email`` in your *Git* configuration, otherwise, +*Bitbake* will complain during the first build. You can use the two commands to +set them directly without editing ``~/.gitconfig`` manually + +.. code-block:: console + + host:~$ git config --global user.email "your_email@example.com" + host:~$ git config --global user.name "name surname" + +site.conf Setup +--------------- + +Before starting the *Yocto* build, it is advisable to configure the development +setup. Two things are most important: the download directory and the cache +directory. PHYTEC strongly recommends configuring the setup as it will reduce +the compile time of consequent builds. + +A download directory is a place where *Yocto* stores all sources fetched from +the internet. It can contain tar.gz, *Git* mirror, etc. It is very useful to set +this to a common shared location on the machine. Create this directory with 777 +access rights. To share this directory with different users, all files need to +have group write access. This will most probably be in conflict with default +*umask* settings. One possible solution would be to use ACLs for this +directory + +.. code-block:: console + + host:~$ sudo apt-get install acl + host:~$ sudo setfacl -R -d -m g::rwx + +If you have already created a download directory and want to fix the permissions +afterward, you can do so with + +.. code-block:: console + + host:~$ sudo find /home/share/ -perm /u=r ! -perm /g=r -exec chmod g+r \{\} \; + host:~$ sudo find /home/share/ -perm /u=w ! -perm /g=w -exec chmod g+w \{\} \; + host:~$ sudo find /home/share/ -perm /u=x ! -perm /g=x -exec chmod g+x \{\} \; + +The cache directory stores all stages of the build process. *Poky* has quite an +involved caching infrastructure. It is advisable to create a shared directory, +as all builds can access this cache directory, called the shared state cache. + +Create the two directories on a drive where you have approximately 50 GB of +space and assign the two variables in your ``build/conf/local.conf`` + +.. code-block:: kconfig + + DL_DIR ?= "/yocto_downloads" + SSTATE_DIR ?= "/yocto_sstate" + +If you want to know more about configuring your build, see the documented +example settings + +.. code-block:: + + sources/poky/meta-yocto/conf/local.conf.sample + sources/poky/meta-yocto/conf/local.conf.sample.extended + +phyLinux Documentation +====================== + +The phyLinux script is a basic management tool for PHYTEC *Yocto* BSP releases +written in *Python*. It is mainly a helper to get started with the BSP +structure. You can get all the BSP sources without the need of interacting with +*Repo* or *Git*. + +The phyLinux script has only one real dependency. It requires the *wget* tool +installed on your host. It will also install the `Repo tool +`_ in a global path +(/usr/local/bin) on your host PC. You can install it in a different location +manually. *Repo* will be automatically detected by phyLinux if it is found in +the PATH. The *Repo* tool will be used to manage the different *Git* +repositories of the *Yocto* BSP. + +Get phyLinux +------------ + +The phyLinux script can be found on the PHYTEC download server: +https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux + +Basic Usage +----------- + +For the basic usage of phyLinux, type + +.. code-block:: console + + host:~$ ./phyLinux --help + +which will result in + +.. code-block:: + + usage: phyLinux [-h] [-v] [--verbose] {init,info,clean} ... + + This Programs sets up an environment to work with The Yocto Project on Phytecs + Development Kits. Use phyLinx -h to display the help text for the + available commands. + + positional arguments: + {init,info,clean} commands + init init the phytec bsp in the current directory + info print info about the phytec bsp in the current directory + clean Clean up the current working directory + + optional arguments: + -h, --help show this help message and exit + -v, --version show program's version number and exit + --verbose + +Initialization +-------------- + +Create a fresh project folder + +.. code-block:: console + + host:~$ mkdir ~/yocto + +Calling phyLinux will use the default Python version. Starting with Ubuntu 20.04 +it will be Python3. If you want to initiate a BSP, which is not compatible with +Python3, you need to set Python2 as default (temporarily) before running +phyLinux + +.. code-block:: console + + host:~$ ln -s \`which python2\` python && export PATH=`pwd`:$PATH + +Now run phyLinux from the new folder + +.. code-block:: console + + host:~$ ./phyLinux init + +A clean folder is important because phyLinux will clean its working directory. +Calling phyLinux from a directory that isn't empty will result in the following +**warning**:: + + This current directory is not empty. It could lead to errors in the BSP configuration + process if you continue from here. At the very least, you have to check your build directory + for settings in bblayers.conf and local.conf, which will not be handled correctly in + all cases. It is advisable to start from an empty directory of call: + $ ./phyLinux clean + Do you really want to continue from here? + [yes/no]: + +On the first initialization, the phyLinux script will ask you to install the +*Repo* tool in your */usr/local/bin* directory. During the execution of the +*init* command, you need to choose your processor platform (SoC), PHYTEC's BSP +release number, and the hardware you are working on + +.. code-block:: + + *************************************************** + * Please choose one of the available SoC Platforms: + * + * 1: am335x + * 2: am57x + * 3: am62ax + * 4: am62x + * 5: am64x + * 6: am68x + * 7: imx6 + * 8: imx6ul + * 9: imx7 + * 10: imx8 + * 11: imx8m + * 12: imx8mm + * 13: imx8mp + * 14: imx8x + * 15: imx93 + * 16: nightly + * 17: rk3288 + * 18: stm32mp13x + * 19: stm32mp15x + * 20: topic + + # Exemplary output for chosen imx6ul + *************************************************** + * Please choose one of the available Releases: + * + * 1: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc1 + * 2: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc2 + * 3: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc3 + * 4: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc4 + * 5: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc5 + * 6: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2.0 + * 7: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2.1-rc1 + * 8: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2.1 + * 9: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1-rc2 + * 10: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1-rc3 + * 11: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1-rc4 + * 12: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.0 + * 13: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1-rc1 + * 14: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1 + * 15: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.y + * 16: BSP-Yocto-Vendor-phyBOARD-Segin-PD17.1.0 + * 17: BSP-Yocto-Vendor-phyBOARD-Segin-PD17.1.1 + * 18: BSP-Yocto-Vendor-phyBOARD-Segin-PD17.1.2 + * 19: BSP-Yocto-i.MX6UL-PD19.1-rc1 + * 20: BSP-Yocto-i.MX6UL-PD19.1-rc2 + * 21: BSP-Yocto-i.MX6UL-PD19.1-rc3 + * 22: BSP-Yocto-i.MX6UL-PD19.1.0 + * 23: BSP-Yocto-i.MX6UL-PD19.1.1-rc1 + * 24: BSP-Yocto-i.MX6UL-PD19.1.1 + * 25: BSP-Yocto-i.MX6UL-PD19.1.2-rc1 + * 26: BSP-Yocto-i.MX6UL-PD19.1.2-rc2 + * 27: BSP-Yocto-i.MX6UL-PD19.1.2 + * 28: BSP-Yocto-i.MX6UL-PD21.1.0 + * 29: BSP-Yocto-i.MX6UL-PD21.1.y + * 30: BSP-Yocto-phyBOARD-Segin-PD17.2.0 + * 31: BSP-Yocto-phyBOARD-Segin-i.MX6UL-ALPHA1 + * 32: BSP-Yocto-phyBOARD-Segin-i.MX6UL-ALPHA2 + + # Exemplary output for chosen BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1 + ********************************************************************* + * Please choose one of the available builds: + * + no: machine: description and article number + distro: supported yocto distribution + target: supported build target + + 1: phyboard-segin-imx6ul-2: PHYTEC phyBOARD-Segin i.MX6 UltraLite + 512MB RAM, NAND + PB-02013-001.A2, PB-02013-110I.A2, PCL-063-23300CI.A2 + distro: ampliphy + target: phytec-headless-image + target: phytec-qt5demo-image + 2: phyboard-segin-imx6ul-6: PHYTEC phyBOARD-Segin i.MX6 ULL + 512MB RAM, NAND + PB-02013-001.A5, PB-02013-310I.A0, PCL-063-23900CI.A0 + distro: ampliphy + target: -c populate_sdk phytec-qt5demo-image + target: phytec-headless-image + target: phytec-qt5demo-image + target: phytec-vision-image + 3: phyboard-segin-imx6ul-6: PHYTEC phyBOARD-Segin i.MX6 ULL + 512MB RAM, NAND + PB-02013-001.A5, PB-02013-310I.A0, PCL-063-23900CI.A0 + distro: ampliphy-rauc + target: phytec-headless-bundle + target: phytec-headless-image + ... + + 10: phygate-tauri-s-imx6ul-1: PHYTEC phyGATE-Tauri-S i.MX6 ULL + 512MB RAM, eMMC + PB-03513.A1, PCL-063-20910CI.A0 + distro: ampliphy + target: phytec-headless-image + 11: phygate-tauri-s-imx6ul-1: PHYTEC phyGATE-Tauri-S i.MX6 ULL + 512MB RAM, eMMC + PB-03513.A1, PCL-063-20910CI.A0 + distro: ampliphy-provisioning + target: phytec-provisioning-image + 12: phygate-tauri-s-imx6ul-1: PHYTEC phyGATE-Tauri-S i.MX6 ULL + 512MB RAM, eMMC + PB-03513.A1, PCL-063-20910CI.A0 + distro: ampliphy-secure + target: phytec-security-bundle + target: phytec-security-image + +If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. After the configuration is done, +you can always run + +.. code-block:: console + + host:~$ ./phyLinux info + + # Exemplary output + *********************************************** + * The current BSP configuration is: + * + * SoC: refs/heads/imx6ul + * Release: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1 + * + *********************************************** + +to see which SoC and Release are selected in the current workspace. If +you do not want to use the selector, phyLinux also supports command-line +arguments for several settings + +.. code-block:: console + + host:~$ MACHINE=phyboard-segin-imx6ul-2 ./phyLinux init -p imx6ul -r BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1 + +or view the help command for more information + +.. code-block:: console + + host:~$ ./phyLinux init --help + + usage: phyLinux init [-h] [--verbose] [--no-init] [-o REPOREPO] [-b REPOREPO_BRANCH] [-x XML] [-u URL] [-p PLATFORM] [-r RELEASE] + + options: + -h, --help show this help message and exit + --verbose + --no-init dont execute init after fetch + -o REPOREPO Use repo tool from another url + -b REPOREPO_BRANCH Checkout different branch of repo tool + -x XML Use a local XML manifest + -u URL Manifest git url + -p PLATFORM Processor platform + -r RELEASE Release version + +After the execution of the *init* command, phyLinux will print a few important +notes as well as information for the next steps in the build process. + +.. _kirkstone_phylinux-advanced-usage: + +Advanced Usage +-------------- + +phyLinux can be used to transport software states over any medium. The state of +the software is uniquely identified by *manifest.xml*. You can create a +manifest, send it to another place and recover the software state with + +.. code-block:: console + + host:~$ ./phyLinux init -x manifest.xml + +You can also create a *Git* repository containing your software states. The +*Git* repository needs to have branches other than master, as we reserved the +master branch for different usage. Use phyLinux to check out the states + +.. code-block:: console + + host:~$ ./phyLinux -u + +Using build-container +===================== + +.. warning:: + Currently, it is not possible to run the phyLinux script inside of a container. + After a complete init with the phyLinux script on your host machine, you can use a container for the build. + If you do not have phyLinux script running on your machine, please see phyLinux Documentation. + +There are various possibilities to run a build-container. Commonly used is +docker and podman, though we prefer podman as it does not need root privileges +to run. + +Installation +------------ + +How to install podman: https://podman.io +How to install docker: https://docs.docker.com/engine/install/ + +Available container +------------------- + +Right now we provide 4 different container based on Ubuntu LTS versions: +https://hub.docker.com/u/phybuilder + +- yocto-ubuntu-16.04 +- yocto-ubuntu-18.04 +- yocto-ubuntu-20.04 +- yocto-ubuntu-22.04 + +These containers can be run with podman or docker. With Yocto Project branch |yocto-codename| the container "yocto-ubuntu-20.04" is preferred. + +Download/Pull container +----------------------- + +.. code-block:: console + + host:~$ podman pull docker.io/phybuilder/yocto-ubuntu-20.04 + + OR + + host:~$ docker pull docker.io/phybuilder/yocto-ubuntu-20.04 + +By adding a tag at the end separated by a colon, you can also pull or run a special tagged container. + + podman pull docker.io/phybuilder/yocto-ubuntu-20.04:phy2 + +You can find all available tags in our duckerhub space: + +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-16.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-18.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-20.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-22.04/tags + +If you try to run a container, which is not pulled/downloaded, it will be pulled/downloaded automatically. + +You can have a look at all downloaded/pulled container with: + +.. code-block:: console + + $USERNAME@$HOSTNAME:~$ podman images + REPOSITORY TAG IMAGE ID CREATED SIZE + docker.io/phybuilder/yocto-ubuntu-22.04 latest d626178e448d 4 months ago 935 MB + docker.io/phybuilder/yocto-ubuntu-22.04 phy2 d626178e448d 4 months ago 935 MB + docker.io/phybuilder/yocto-ubuntu-20.04 phy2 e29a88b7172a 4 months ago 900 MB + docker.io/phybuilder/yocto-ubuntu-20.04 latest e29a88b7172a 4 months ago 900 MB + docker.io/phybuilder/yocto-ubuntu-18.04 phy1 14c9c3e477d4 7 months ago 567 MB + docker.io/phybuilder/yocto-ubuntu-18.04 latest 14c9c3e477d4 7 months ago 567 MB + docker.io/phybuilder/yocto-ubuntu-16.04 phy1 28c73e13ab4f 7 months ago 599 MB + docker.io/phybuilder/yocto-ubuntu-16.04 latest 28c73e13ab4f 7 months ago 599 MB + docker.io/phybuilder/yocto-ubuntu-22.04 phy1 5a0ef4b41935 8 months ago 627 MB + docker.io/phybuilder/yocto-ubuntu-20.04 phy1 b5a26a86c39f 8 months ago 680 MB + +Run container +------------- + +To run and use container for a Yocto build, first enter to your folder, where +you run phyLinux init before. Then start the container + +.. code-block:: console + + host:~$ podman run --rm=true -v /home:/home --userns=keep-id --workdir=$PWD -it docker.io/phybuilder/yocto-ubuntu-20.04 bash + +.. note:: + To run and use a container with docker, it is not that simple like with podman. + Therefore the container-user has to be defined and configured. + Furthermore forwarding of credentials is not given per default and has to be configured as well. + +Now your commandline should look something like that (where $USERNAME is the +user, who called "podman run" and the char/number code diffs every time a +container is started) + +.. code-block:: console + + $USERNAME@6593e2c7b8f6:~$ + +.. warning:: + If the given username is "root" you will not be able to run bitbake at all. + Please be sure, you run the container with your own user. + +Now you are ready to go on and starting the build. +To stop/close the container, just call + +.. code-block:: console + + $USERNAME@6593e2c7b8f6:~$ exit + +Working with Poky and Bitbake +============================= + +Start the Build +--------------- + +After you download all the metadata with phyLinux init, you have to set up the +shell environment variables. This needs to be done every time you open a new +shell for starting builds. We use the shell script provided by *Poky* in its +default configuration. From the root of your project directory type + +.. code-block:: console + + host:~$ source sources/poky/oe-init-build-env + +The abbreviation for the source command is a single dot + +.. code-block:: console + + host:~$ . sources/poky/oe-init-build-env + +The current working directory of the shell should change to *build/*. Before +building for the first time, you should take a look at the main configuration +file + +.. code-block:: console + + host:~$ vim conf/local.conf + +Your local modifications for the current build are stored here. Depending on +the SoC, you might need to accept license agreements. For example, to build the +image for Freescale/NXP processors you need to accept the GPU and VPU binary +license agreements. You have to uncomment the corresponding line + +.. code-block:: kconfig + + # Uncomment to accept NXP EULA # EULA can be found under + ../sources/meta-freescale/EULA ACCEPT_FSL_EULA = "1" + +Now you are ready to build your first image. We suggest starting with our +smaller non-graphical image *phytec-headless-image* to see if everything is +working correctly + +.. code-block:: console + + host:~$ bitbake phytec-headless-image + +The first compile process takes about 40 minutes on a modern Intel Core i7. All +subsequent builds will use the filled caches and should take about 3 minutes. + +Images +------ + +If everything worked, the images can be found under + +.. code-block:: console + + host:~$ cd deploy/images/ + +The easiest way to test your image is to configure your board for SD card boot +and to flash the build image to the SD card + +.. code-block:: console + + host:~$ sudo dd if=phytec-headless-image-.wic of=/dev/ bs=1M conv=fsync + +Here could be "sde", for example, depending on your system. Be +very careful when selecting the right drive! Selecting the wrong drive can +erase your hard drive! The parameter conv=fsync forces a data buffer to write +to the device before dd returns. + +After booting you can log in using a serial cable or over *ssh*. There is no +root password. That is because of the debug settings in *conf/local.conf*. If +you uncomment the line + +.. code-block:: kconfig + + #EXTRA_IMAGE_FEATURES = "debug-tweaks" + +the debug settings, like setting an empty root password, will not be applied. + +Accessing the Development States between Releases +------------------------------------------------- + +Special release manifests exist to give you access to the current development +states of the *Yocto* BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line + +.. code-block:: console + + host:~$ ./phyLinux init -p master -r kirkstone + +This will initialize a BSP that will track the latest development state. From +now on running + +.. code-block:: console + + host:~$ repo sync + +this folder will pull all the latest changes from our Git repositories. + +Inspect your Build Configuration +-------------------------------- + +*Poky* includes several tools to inspect your build layout. You can inspect the +commands of the layer tool + +.. code-block:: console + + host:~$ bitbake-layers + +It can, for example, be used to view in which layer a specific recipe gets +modified + +.. code-block:: console + + host:~$ bitbake-layers show-appends + +Before running a build you can also launch *Toaster* to be able to inspect the +build details with the Toaster web GUI + +.. code-block:: console + + host:~$ source toaster start + +Maybe you need to install some requirements, first + +.. code-block:: console + + host:~$ pip3 install -r + ../sources/poky/bitbake/toaster-requirements.txt + +You can then point your browser to *http://0.0.0.0:8000/* and continue working +with *Bitbake*. All build activity can be monitored and analyzed from this web +server. If you want to learn more about *Toaster*, look at +https://docs.yoctoproject.org/4.0.6/toaster-manual/index.html. +To shut down the *Toaster* web GUI again, execute + +.. code-block:: console + + host:~$ source toaster stop + +BSP Features of meta-phytec and meta-ampliphy +--------------------------------------------- + +*Buildinfo* +........... + +The *buildinfo* task is a feature in our recipes that prints instructions to +fetch the source code from the public repositories. So you do not have to look +into the recipes yourself. To see the instructions, e.g. for the *barebox* +package, execute + +.. code-block:: console + + host:~$ bitbake barebox -c buildinfo + +in your shell. This will print something like + +.. code-block:: + + (mini) HOWTO: Use a local git repository to build barebox: + + To get source code for this package and version (barebox-2022.02.0-phy1), execute + + $ mkdir -p ~/git + $ cd ~/git + $ git clone git://git.phytec.de/barebox barebox + $ cd ~/git/barebox + $ git switch --create v2022.02.0-phy1-local-development 7fe12e65d770f7e657e683849681f339a996418b + + You now have two possible workflows for your changes: + + 1. Work inside the git repository: + Copy and paste the following snippet to your "local.conf": + + SRC_URI:pn-barebox = "git://${HOME}/git/barebox;branch=${BRANCH}" + SRCREV:pn-barebox = "${AUTOREV}" + BRANCH:pn-barebox = "v2022.02.0-phy1-local-development" + + After that you can recompile and deploy the package with + + $ bitbake barebox -c compile + $ bitbake barebox -c deploy + + Note: You have to commit all your changes. Otherwise yocto doesn't pick them up! + + 2. Work and compile from the local working directory + To work and compile in an external source directory we provide the + externalsrc.bbclass. To use it, copy and paste the following snippet to your + "local.conf": + + INHERIT += "externalsrc" + EXTERNALSRC:pn-barebox = "${HOME}/git/barebox" + EXTERNALSRC_BUILD:pn-barebox = "${HOME}/git/barebox" + + Note: All the compiling is done in the EXTERNALSRC directory. Every time + you build an Image, the package will be recompiled and build. + + NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded. + NOTE: Writing buildhistory + +As you can see, everything is explained in the output. + +.. warning:: + + Using *externalsrc* breaks a lot of *Yocto's* internal dependency + mechanisms. It is not guaranteed that any changes to the source + directory are automatically picked up by the build process and + incorporated into the root filesystem or SD card image. You have to + always use *--force*. E.g. to compile *barebox* and redeploy it to + *deploy/images/* execute + + .. code-block:: console + + host:~$ bitbake barebox -c compile --force + host:~$ bitbake barebox -c deploy + +To update the SD card image with a new kernel or image first force the +compilation of it and then force a rebuild of the root filesystem. Use + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image -c rootfs --force + +Note that the build system is not modifying the external source directory. If +you want to apply all patches the *Yocto* recipe is carrying to the external +source directory, run the line + +.. code-block:: kconfig + + SRCTREECOVEREDTASKS="" BB_ENV_PASSTHROUGH_ADDITIONS="$BB_ENV_PASSTHROUGH_ADDITIONS SRCTREECOVEREDTASKS" bitbake -c patch + +.. _kirkstone_bsp-customization: + +BSP Customization +----------------- + +To get you started with the BSP, we have summarized some basic tasks from the +*Yocto* official documentation. It describes how to add additional software to +the image, change the kernel and bootloader configuration, and integrate +patches for the kernel and bootloader. + +Minor modifications, such as adding software, are done in the file +*build/conf/local.conf*. There you can overwrite global configuration variables +and make small modifications to recipes. + +There are 2 ways to make major changes: + +1. Either create your own layer and use *bbappend* files. +2. Add everything to PHYTEC's Distro layer *meta-ampliphy*. + +Creating your own layer is described in the section Create your own Layer. + +Disable Qt Demo +............... + +By default, the BSP image *phytec-qt6demo-image* starts a Qt6 Demo application +on the attached display or monitor. If you want to stop the demo and use the +*Linux* framebuffer console behind it, connect to the target via serial cable +or *ssh* and execute the shell command + +.. code-block:: console + + target:~$ systemctl stop phytec-qtdemo.service + +This command stops the demo temporarily. To start it again, reboot the +board or execute + +.. code-block:: console + + target:~$ systemctl start phytec-qtdemo.service + +You can disable the service permanently, so it does not start on boot + +.. code-block:: console + + target:~$ systemctl disable phytec-qtdemo.service + +.. tip:: + + The last command only disables the service. It does not *stop* immediately. + To see the current status execute + + .. code-block:: console + + target:~$ systemctl status phytec-qtdemo.service + +If you want to disable the service by default, edit the file +*build/conf/local.conf* and add the following line + +.. code-block:: kconfig + + # file build/conf/local.conf + SYSTEMD_AUTO_ENABLE:pn-phytec-qtdemo = "disable" + +After that, rebuild the image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +Framebuffer Console +................... + +On boards with a display interface, the framebuffer console is enabled per +default. You can attach a USB keyboard and log in. To change the keyboard +layout from the English default to German, type + +.. code-block:: console + + target:~$ loadkeys /usr/share/keymaps/i386/qwertz/de-latin1.map.gz + +To detach the framebuffer console, run + +.. code-block:: console + + target:~$ echo 0 > sys/class/vtconsole/vtcon1/bind + +To completely deactivate the framebuffer console, disable the following kernel +configuration option + +.. code-block:: + + Device Drivers->Graphics Support->Support for framebuffer devices->Framebuffer Console Support + +More information can be found at: +https://www.kernel.org/doc/Documentation/fb/fbcon.txt + +Tools Provided in the Prebuild Image +.................................... + +RAM Benchmark +~~~~~~~~~~~~~ + +Performing RAM and cache performance tests can best be done by using *pmbw* +(Parallel Memory Bandwidth Benchmark/Measurement Tool). *Pmbw* runs several +assembly routines which all use different access patterns to the caches and RAM +of the SoC. Before running the test, make sure that you have about 2 MiB of +space left on the device for the log files. We also lower the level of the +benchmark to ask the kernel more aggressively for resources. The benchmark test +will take several hours. + +To start the test type + +.. code-block:: console + + target:~$ nice -n -2 pmbw + +Upon completion of the test run, the log file can be converted to a *gnuplot* +script with + +.. code-block:: console + + target:~$ stats2gnuplot stats.txt > run1.gnuplot + +Now you can transfer the file to the host machine and install any version of +*gnuplot* + +.. code-block:: console + + host:~$ sudo apt-get install gnuplot host:~$ gnuplot run1.gnuplot + +The generated *plots-.pdf* file contains all plots. To render single +plots as *png* files for any web output you can use *Ghostscript* + +.. code-block:: console + + host:~$ sudo apt-get install ghostscript + host:~$ gs -dNOPAUSE -dBATCH -sDEVICE=png16m -r150 -sOutputFile='page-%00d.png' plots-phyboard-wega-am335x-1.pdf + +Add Additional Software for the BSP Image +......................................... + +To add additional software to the image, look at the OpenEmbedded layer index: +https://layers.openembedded.org/layerindex/branch/kirkstone/layers/ + +First, select the *Yocto* version of the BSP you have from the drop-down list in +the top left corner and click **Recipes**. Now you can search for a software +project name and find which layer it is in. In some cases, the program is in +*meta-openembedded*, *openembedded-core*, or *Poky* which means that the recipe +is already in your build tree. This section describes how to add additional +software when this is the case. If the package is in another layer, see the next +section. + +You can also search the list of available recipes + +.. code-block:: console + + host:~$ bitbake -s | grep # fill in program name, like in + host:~$ bitbake -s | grep lsof + +When the recipe for the program is already in the *Yocto* build, you can simply +add it by appending a configuration option to your file *build/conf/local.conf*. +The general syntax to add additional software to an image is + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " " + +For example, the line + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " ldd strace file lsof" + +installs some helper programs on the target image. + +.. warning:: + + The leading whitespace is essential for the append command. + +All configuration options in local.conf apply to all images. Consequently, the +tools are now included in both images phytec-headless-image and +phytec-qt6demo-image. + +Notes about Packages and Recipes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You are adding packages to the IMAGE_INSTALL variable. Those are not necessarily +equivalent to the recipes in your meta-layers. A recipe defines per default a +package with the same name. But a recipe can set the PACKAGES variable to +something different and is able to generate packages with arbitrary names. +Whenever you look for software, you have to search for the package name and, +strictly speaking, not for the recipe. In the worst case, you have to look at +all PACKAGES variables. A tool such as *Toaster* can be helpful in some cases. + +If you can not find your software in the layers provided in the folder +*sources*, see the next section to include another layer into the *Yocto* +build. + +References: `Yocto 4.0.6 Documentation - Customizing Yocto builds +`_ + +Add an Additional Layer +....................... + +This is a step-by-step guide on how to add another layer to your *Yocto* build +and install additional software from it. As an example, we include the network +security scanner *nmap* in the layer *meta-security*. First, you must locate the +layer on which the software is hosted. Check out the `OpenEmbedded MetaData +Index `_ +and guess a little bit. The network scanner *nmap* is in the *meta-security* +layer. See `meta-security on layers.openembedded.org +`_. +To integrate it into the *Yocto* build, you have to check out the repository and +then switch to the correct stable branch. Since the BSP is based on the *Yocto* +'sumo' build, you should try to use the 'sumo' branch in the layer, too. + +.. code-block:: console + + host:~$ cd sources + host:~$ git clone git://git.yoctoproject.org/meta-security + host:~$ cd meta-security + host:~$ git branch -r + +All available remote branches will show up. Usually there should be 'fido', +'jethro', 'krogoth', 'master', ... + +.. code-block:: console + + host:~$ git checkout kirkstone + +Now we add the directory of the layer to the file *build/conf/bblayers.conf* by +appending the line + +.. code-block:: kconfig + + # file build/conf/bblayers.conf + BBLAYERS += "${BSPDIR}/sources/meta-security" + +to the end of the file. After that, you can check if the layer is available in +the build configuration by executing + +.. code-block:: console + + host:~$ bitbake-layers show-layers + +If there is an error like + +.. code-block:: + + ERROR: Layer 'security' depends on layer 'perl-layer', but this layer is not enabled in your configuration + +the layer that you want to add (here *meta-security*), depends on another layer, +which you need to enable first. E.g. the dependency required here is a layer in +*meta-openembedded* (in the PHYTEC BSP it is in the path +*sources/meta-openembedded/meta-perl/*). To enable it, add the following line to +*build/conf/bblayers.conf* + +.. code-block:: kconfig + + # file build/conf/bblayers.conf + BBLAYERS += "${BSPDIR}/sources/meta-openembedded/meta-perl" + +Now the command *bitbake-layers show-layers* should print a list of all layers +enabled including *meta-security* and *meta-perl*. After the layer is included, +you can install additional software from it as already described above. The +easiest way is to add the following line (here is the package *nmap*) + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " nmap" + +to your *build/conf/local.conf*. Do not forget to rebuild the image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +Create your own layer +.................................. + +Creating your layer should be one of the first tasks when customizing the BSP. +You have two basic options. You can either copy and rename our *meta-ampliphy*, +or you can create a new layer that will contain your changes. The better option +depends on your use case. *meta-ampliphy* is our example of how to create a +custom *Linux* distribution that will be updated in the future. If you want to +benefit from those changes and are, in general, satisfied with the userspace +configuration, it could be the best solution to create your own layer on top of +*Ampliphy*. If you need to rework a lot of information and only need the basic +hardware support from PHYTEC, it would be better to copy *meta-ampliphy*, rename +it, and adapt it to your needs. You can also have a look at the OpenEmbedded +layer index to find different distribution layers. If you just need to add your +own application to the image, create your own layer. + +In the following chapter, we have an embedded project called "racer" which we +will implement using our *Ampliphy Linux* distribution. First, we need to create +a new layer. + +*Yocto* provides a script for that. If you set up the BSP and the shell is +ready, type + +.. code-block:: console + + host:~$ bitbake-layers create-layer meta-racer + +Default options are fine for now. Move the layer to the source directory + +.. code-block:: console + + host:~$ mv meta-racer ../sources/ + +Create a *Git* repository in this layer to track your changes + +.. code-block:: console + + host:~$ cd ../sources/meta-racer + host:~$ git init && git add . && git commit -s + +Now you can add the layer directly to your build/conf/bblayers.conf + +.. code-block:: kconfig + + BBLAYERS += "${BSPDIR}/sources/meta-racer" + +or with a script provided by *Yocto* + +.. code-block:: console + + host:~$ bitbake-layers add-layer meta-racer + +Kernel and Bootloader Recipe and Version +........................................ + +First, you need to know which kernel and version are used for your target +machine. PHYTEC provides multiple kernel recipes *linux-mainline*, *linux-ti* +and *linux-imx*. The first one provides support for PHYTEC's i.MX 6 and AM335x +modules and is based on the *Linux* kernel stable releases from `kernel.org +`_. +The *Git* repositories URLs are: + +- *linux-mainline*: git://git.phytec.de/linux-mainline +- *linux-ti*: git://git.phytec.de/linux-ti +- *linux-imx:* git://git.phytec.de/linux-imx +- *barebox*: git://git.phytec.de/barebox +- *u-boot-imx*: git://git.phytec.de/u-boot-imx + +To find your kernel provider, execute the following command + +.. code-block:: console + + host:~$ bitbake virtual/kernel -e | grep "PREFERRED_PROVIDER_virtual/kernel" + +The command prints the value of the variable +*PREFERRED_PROVIDER_virtual/kernel*. The variable is used in the internal +*Yocto* build process to select the kernel recipe to use. The following lines +are different outputs you might see + +.. code-block:: kconfig + + PREFERRED_PROVIDER_virtual/kernel="linux-mainline" + PREFERRED_PROVIDER_virtual/kernel="linux-ti" + PREFERRED_PROVIDER_virtual/kernel="linux-imx" + +To see which version is used, execute *bitbake -s*. For example + +.. code-block:: console + + host:~$ bitbake -s | egrep -e "linux-mainline|linux-ti|linux-imx|barebox|u-boot-imx" + +The parameter *-s* prints the version of all recipes. The output contains the +recipe name on the left and the version on the right + +.. code-block:: + + barebox :2022.02.0-phy1-r7.0 + barebox-hosttools-native :2022.02.0-phy1-r7.0 + barebox-targettools :2022.02.0-phy1-r7.0 + linux-mainline :5.15.102-phy1-r0.0 + +As you can see, the recipe *linux-mainline* has version *5.15.102-phy1*. In +the PHYTEC's *linux-mainline* *Git* repository, you will find a corresponding +tag *v5.15.102-phy1*. The version of the *barebox* recipe is 2022.02.0-phy1. +On i.MX8M\* modules the output will contain *linux-imx* and *u-boot-imx*. + +.. _yocto-man-kirkstone-kernel-and-bootloader-conf: + +Kernel and Bootloader Configuration +................................... + +The bootloader used by PHYTEC, *barebox*, uses the same build system as the +*Linux* kernel. Therefore, all commands in this section can be used to configure +the kernel and bootloader. To configure the kernel or bootloader, execute one of +the following commands + +.. code-block:: console + + host:~$ bitbake -c menuconfig virtual/kernel # Using the virtual provider name + host:~$ bitbake -c menuconfig linux-ti # Or use the recipe name directly + host:~$ bitbake -c menuconfig linux-mainline # Or use the recipe name directly (If you use an i.MX 6 or RK3288 Module) + host:~$ bitbake -c menuconfig linux-imx # Or use the recipe name directly (If you use an i.MX 8M*) + host:~$ bitbake -c menuconfig barebox # Or change the configuration of the bootloader + host:~$ bitbake -c menuconfig u-boot-imx # Or change the configuration of the bootloader (If you use an i.MX 8M*) + +After that, you can recompile and redeploy the kernel or bootloader + +.. code-block:: console + + host:~$ bitbake virtual/kernel -c compile # Or 'barebox' for the bootloader + host:~$ bitbake virtual/kernel -c deploy # Or 'barebox' for the bootloader + +Instead, you can also just rebuild the complete build output with + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # To update the kernel/bootloader, modules and the images + +In the last command, you can replace the image name with the name of an image of +your choice. The new images and binaries are in +*build/deploy/images//*. + +.. warning:: + + The build configuration is not permanent yet. Executing *bitbake + virtual/kernel -c clean* will remove everything. + +To make your changes permanent in the build system, you have to integrate your +configuration modifications into a layer. For the configuration you have two +options: + +- Include only a configuration fragment (a minimal *diff* between the + old and new configuration) +- Complete default configuration (*defconfig*) after your + modifications. + +Having a set of configuration fragments makes what was changed at which stage +more transparent. You can turn on and off the changes, you can manage +configurations for different situations and it helps when porting changes to new +kernel versions. You can also group changes together to reflect specific use +cases. A fully assembled kernel configuration will be deployed in the directory +*build/deploy/images/*. If you do not have any of those requirements, +it might be simpler to just manage a separate *defconfig* file. + +Add a Configuration Fragment to a Recipe +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The following steps can be used for both kernel and bootloader. Just replace the +recipe name *linux-mainline* in the commands with *linux-ti*, or *barebox* for +the bootloader. If you did not already take care of this, start with a clean +build. Otherwise, the diff of the configuration may be wrong + +.. code-block:: console + + host:~$ bitbake linux-mainline -c clean + host:~$ bitbake linux-mainline -c menuconfig + +Make your configuration changes in the menu and generate a config +fragment + +.. code-block:: console + + host:~$ bitbake linux-mainline -c diffconfig + +which prints the path of the written file + +.. code-block:: + + Config fragment has been dumped into: + /home//build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg + +All config changes are in the file *fragment.cfg* which should consist of only +some lines. The following example shows how to create a *bbappend* file and how +to add the necessary lines for the config fragment. You just have to adjust the +directories and names for the specific recipe: *linux-mainline*, *linux-ti*, +linux-imx, u-boot-imx, or *barebox*. + +.. code-block:: + + sources//recipes-kernel/linux/linux-mainline_%.bbappend # For the recipe linux-mainline + sources//recipes-kernel/linux/linux-ti_%.bbappend # For the recipe linux-ti + sources//recipes-kernel/linux/linux-imx_%.bbappend # For the recipe linux-imx + sources//recipes-bsp/barebox/barebox_%.bbappend # For the recipe barebox + sources//recipes-bsp/u-boot/u-boot-imx_%.bbappend # For the recipe u-boot-imx + +Replace the string *layer* with your own layer created as shown above (e.g. +*meta-racer*), or just use *meta-ampliphy*. To use *meta-ampliphy*, first, +create the directory for the config fragment and give it a new name (here +*enable-r8169.cfg*) and move the fragment to the layer. + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features + # copy the path from the output of *diffconfig* + host:~$ cp /home//build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg \ + sources/meta-ampliphy/recipes-kernel/linux/features/enable-r8169.cfg + +Then open the *bbappend* file (in this case +*sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend* ) with +your favorite editor and add the following lines + +.. code-block:: kconfig + + # contents of the file linux-mainline_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://enable-r8169.cfg \ + " + +.. warning:: + + Do not forget to use the correct *bbappend* filenames: *linux-ti_%.bbappend* + for the linux-ti recipe and *barebox_%.bbappend* for the bootloader in the + folder *recipes-bsp/barebox/* ! + +After saving the *bbappend* file, you have to rebuild the image. *Yocto* should +pick up the recipe changes automatically and generate a new image + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +Add a Complete Default Configuration (*defconfig*) to a Recipe +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This approach is similar to the one above, but instead of adding a fragment, a +*defconfig* is used. First, create the necessary folders in the layer you want +to use, either your own layer or *meta-ampliphy* + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features/ # For both linux-mainline and linux-ti + host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features/ # Or for the bootloader + +Then you have to create a suitable *defconfig* file. Make your configuration +changes using *menuconfig* and then save the *defconfig* file to the layer + +.. code-block:: console + + host:~$ bitbake linux-mainline -c menuconfig # Or use recipe name linux-ti or barebox + host:~$ bitbake linux-mainline -c savedefconfig # Create file 'defconfig.temp' in the work directory + +This will print the path to the generated file + +.. code-block:: + + Saving defconfig to ..../defconfig.temp + +Then, as above, copy the generated file to your layer, rename it to *defconfig*, +and add the following lines to the *bbappend* file (here +*sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend*) + +.. code-block:: kconfig + + # contents of the file linux-mainline_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://defconfig \ + " + +.. tip:: + + Do not forget to use the correct bbappend filenames: *linux-ti_%.bbappend* + for the linux-ti recipe and *barebox_%.bbappend* for the bootloader in the + folder *recipes-bsp/barebox/* ! + +After that, rebuild your image as the changes are picked up automatically + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +Patch the Kernel or Bootloader with *devtool* +............................................. + +*Apart from using the standard versions of kernel and bootloader which are +provided in the recipes, you can modify the source code or use our own +repositories to build your customized kernel.* + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| Standard workflow of the | Uses additional hard drive space | +| official *Yocto* documentation | as the sources get duplicated | ++----------------------------------+----------------------------------+ +| Toolchain does not have to | No optimal cache usage, build | +| recompile everything | overhead | ++----------------------------------+----------------------------------+ + +*Devtool* is a set of helper scripts to enhance the user workflow of *Yocto*. It +was integrated with version 1.8. It is available as soon as you set up your +shell environment. *Devtool* can be used to: + +- modify existing sources +- integrate software projects into your build setup +- build software and deploy software modifications to your target + +Here we will use *devtool* to patch the kernel. We use *linux-mainline* as an +example for the AM335x Kernel. The first command we use is *devtool modify - x + * + +.. code-block:: console + + host:~$ devtool modify -x linux-mainline linux-mainline + +*Devtool* will create a layer in *build/workspace* where you can see all +modifications done by *devtool* . It will extract the sources corresponding to +the recipe to the specified directory. A *bbappend* will be created in the +workspace directing the SRC_URI to this directory. Building an image with +*Bitbake* will now use the sources in this directory. Now you can modify lines +in the kernel + +.. code-block:: console + + host:~$ vim linux-mainline/arch/arm/boot/dts/am335x-phycore-som.dtsi + -> make a change + host:~$ bitbake phytec-qt6demo-image + +Your changes will now be recompiled and added to the image. If you want to store +your changes permanently, it is advisable to create a patch from the changes, +then store and backup only the patch. You can go into the *linux-mainline* +directory and create a patch using *Git*. How to create a patch is described in +:ref:`kirkstone_temporary-method` and is the same for all methods. + +If you want to learn more about *devtool*, visit: + +`Yocto 4.0.6 - Devtool +`_ +or `Devtool Quick Reference +`_ + +.. _kirkstone_temporary-method: + +Patch the Kernel or Bootloader using the "Temporary Method" +........................................................... + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| No overhead, no extra | Changes are easily overwritten | +| configuration | by *Yocto* (Everything is | +| | lost!!). | ++----------------------------------+----------------------------------+ +| Toolchain does not have to | | +| recompile everything | | ++----------------------------------+----------------------------------+ + +It is possible to alter the source code before *Bitbake* configures and compiles +the recipe. Use *Bitbake'* s *devshell* command to jump into the source +directory of the recipe. Here is the *barebox* recipe + +.. code-block:: console + + host:~$ bitbake barebox -c devshell # or linux-mainline, linux-ti, linux-imx, u-boot-imx + +After executing the command, a shell window opens. The current working directory +of the shell will be changed to the source directory of the recipe inside the +*tmp* folder. Here you can use your favorite editor, e.g. *vim*, *emacs*, or any +other graphical editor, to alter the source code. When you are finished, exit +the *devshell* by typing *exit* or hitting **CTRL-D**. + +After leaving the *devshell* you can recompile the package + +.. code-block:: console + + host:~$ bitbake barebox -c compile --force # or linux-mainline, linux-ti, linux-imx, u-boot-imx + +The extra argument '--force' is important because *Yocto* does not recognize +that the source code was changed. + +.. tip:: + + You cannot execute the *bitbake* command in the *devshell* . You have + to leave it first. + +If the build fails, execute the devshell command again and fix it. If the build +is successful, you can deploy the package and create a new SD card image + +.. code-block:: console + + host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox.bin + host:~$ bitbake phytec-headless-image # new WIC image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic + +.. warning:: + + If you execute a clean e.g *bitbake barebox -c clean* , or if *Yocto* fetches + the source code again, all your changes are lost!!! + + To avoid this, you can create a patch and add it to a *bbappend* file. It is + the same workflow as described in the section about changing the + configuration. + + You have to create the patch in the *devshell* if you use the temporary + method and in the subdirectory created by *devtool* if you used *devtool*. + +.. code-block:: console + + host:~$ bitbake barebox -c devshell # Or linux-mainline, linux-ti + host(devshell):~$ git status # Show changes files + host(devshell):~$ git add # Add a special file to the staging area + host(devshell):~$ git commit -m "important modification" # Creates a commit with a not so useful commit message + host(devshell):~$ git format-patch -1 -o ~/ # Creates a patch of the last commit and saves it in your home folder + /home//0001-important-modification.patch # Git prints the path of the written patch file + host(devshell):~$ exit + +After you have created the patch, you must create a *bbappend* file for it. The +locations for the three different recipes - *linux-mainline* , *linux-ti* , and +*barebox* - are + +.. code-block:: + + sources//recipes-kernel/linux/linux-mainline_%.bbappend # For the recipe linux-mainline + sources//recipes-kernel/linux/linux-ti_%.bbappend # For the recipe linux-ti + sources//recipes-kernel/linux/linux-imx_%.bbappend # For the recipe linux-imx + sources//recipes-bsp/barebox/barebox_%.bbappend # For the recipe barebox + sources//recipes-bsp/u-boot/u-boot-imx_%.bbappend # For the recipe u-boot-imx + +The following example is for the recipe *barebox*. You have to adjust the paths. +First, create the folders and move the patch into them. Then create the +*bbappend* file + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features # Or use your own layer instead of *meta-ampliphy* + host:~$ cp ~/0001-important-modification.patch sources/meta-ampliphy/recipes-bsp/barebox/features # copy patch + host:~$ touch sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend + +.. tip:: + + Pay attention to your current work directory. You have to execute the + commands in the BSP top-level directory. Not in the *build* directory! + +After that use your favorite editor to add the following snipped into the +*bbappend* file (here +*sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend*) + +.. code-block:: kconfig + + # contents of the file barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://0001-important-modification.patch \ + " + +Save the file and rebuild the *barebox* recipe with + +.. code-block:: console + + host:~$ bitbake barebox -c clean # Or linux-ti, linux-mainline, linux-imx, u-boot-imx + host:~$ bitbake barebox + +If the build is successful, you can rebuild the final image with + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +**Further Resources:** + +The *Yocto* Project has some documentation for software developers. Check the +'Kernel Development Manual' for more information about how to configure the +kernel. Please note that not all of the information from the *Yocto* manual can +be applied to the PHYTEC BSP as we use the classic kernel approach of *Yocto* +and most of the documentation assumes the *Yocto* kernel approach. + +- `Yocto - Kernel Development Manual + `_ +- `Yocto - Development Manual + `_ + +Working with the Kernel and Bootloader using SRC_URI in *local.conf* +.................................................................... + +*Here we present a third option to make kernel and bootloader changes. You have +external checkouts of the linux-mainline, linux-ti, or barebox Git +repositories. You will overwrite the URL of the source code fetcher, the +variable SRC_URI, to point to your local checkout instead of the remote +repositories.* + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| All changes are saved with | Many working directories in | +| *Git* | *build/tmp-\ | +| | glibc/work///* | ++----------------------------------+----------------------------------+ +| | You have to commit every change | +| | before recompiling | ++----------------------------------+----------------------------------+ +| | For each change, the toolchain | +| | compiles everything from scratch | +| | (avoidable with *ccache*) | ++----------------------------------+----------------------------------+ + +First, you need a local clone of the *Git* repository *barebox* or +kernel. If you do not have one, use the commands + +.. code-block:: console + + host:~$ mkdir ~/git + host:~$ cd ~/git + host:~$ git clone git://git.phytec.de/barebox + host:~$ cd barebox + host:~$ git switch --create v2022.02.0-phy remotes/origin/v2022.02.0-phy + +Add the following snippet to the file build/conf/local.conf + +.. code-block:: kconfig + + # Use your own path to the git repository + # NOTE: Branch name in variable "BRANCH_pn-barebox" should be the same as the + # branch which is used in the repository folder. Otherwise your commits won't be recognized later. + BRANCH:pn-barebox = "v2022.02.0-phy" + SRC_URI:pn-barebox = "git:///${HOME}/git/barebox;branch=${BRANCH}" + SRCREV:pn-barebox = "${AUTOREV}" + +You also have to set the correct BRANCH name in the file. Either you create your +own branch in the *Git* repository, or you use the default (here +"v2015.02.0-phy"). Now you should recompile *barebox* from your own source + +.. code-block:: console + + host:~$ bitbake barebox -c clean + host:~$ bitbake barebox -c compile + +The build should be successful because the source was not changed yet. + +You can alter the source in *~/git/barebox* or the default *defconfig* (e.g. +*~/git/barebox/arch/arm/configs/imx_v7_defconfig*). After you are satisfied with +your changes, you have to make a dummy commit for *Yocto*. If you do not, +*Yocto* will not notice that the source code was modified in your repository +folder (e.g. ~/git/barebox/) + +.. code-block:: console + + host:~$ git status # show modified files + host:~$ git diff # show changed lines + host:~$ git commit -a -m "dummy commit for yocto" # This command is important! + +Try to compile your new changes. *Yocto* will automatically notice that the +source code was changed and fetches and configures everything from scratch. + +.. code-block:: console + + host:~$ bitbake barebox -c compile + +If the build fails, go back to the source directory, fix the problem, and +recommit your changes. If the build was successful, you can deploy *barebox* and +even create a new SD card image. + +.. code-block:: console + + host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox-phyflex-imx6-2.bin + host:~$ bitbake phytec-headless-image # new sd-card image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic + +If you want to make additional changes, just make another commit in the +repository and rebuild *barebox* again. + +Add Existing Software with "Sustainable Method" +............................................... + +Now that you have created your own layer, you have a second option to add +existing software to existing image definitions. Our standard image is defined +in meta-ampliphy + +.. code-block:: + + meta-ampliphy/recipes-images/images/phytec-headless-image.bb + +In your layer, you can now modify the recipe with a *bbappend* without modifying +any BSP code + +.. code-block:: + + meta-racer/recipes-images/images/phytec-headless-image.bbappend + +The append will be parsed together with the base recipe. As a result, you can +easily overwrite all variables set in the base recipe, which is not always what +you want. If we want to include additional software, we need to append it to the +IMAGE_INSTALL variable + +.. code-block:: kconfig + + IMAGE_INSTALL:append = " rsync" + +Add Linux Firmware Files to the Root Filesystem +............................................... + +It is a common task to add an extra firmware file to your root filesystem into +*/lib/firmware/*. For example, WiFi adapters or PCIe Ethernet cards might need +proprietary firmware. As a solution, we use a *bbappend* in our layer. To create +the necessary folders, *bbappend* and copy the firmware file type + +.. code-block:: console + + host:~$ cd meta-racer # go into your layer + host:~$ mkdir -p recipes-kernel/linux-firmware/linux-firmware/ + host:~$ touch recipes-kernel/linux-firmware/linux-firmware_%.bbappend + host:~$ cp ~/example-firmware.bin recipes-kernel/linux-firmware/linux-firmware/ # adapt filename + +Then add the following content to the *bbappend* file and replace every +occurrence of *example-firmware.bin* with your firmware file name. + +.. code-block:: kconfig + + # file recipes-kernel/linux-firmware/linux-firmware_%.bbappend + + FILESEXTRAPATHS:prepend := "${THISDIR}/linux-firmware:" + SRC_URI += "file://example-firmware.bin" + + do_install:append () { + install -m 0644 ${WORKDIR}/example-firmware.bin ${D}/lib/firmware/example-firmware.bin + } + + # NOTE: Use "=+" instead of "+=". Otherwise file is placed into the linux-firmware package. + PACKAGES =+ "${PN}-example" + FILES:${PN}-example = "/lib/firmware/example-firmware.bin" + +Now try to build the linux-firmware recipe + +.. code-block:: console + + host:~$ . sources/poky/oe-init-build-env + host:~$ bitbake linux-firmware + +This should generate a new package *deploy/ipk/all/linux-firmware-example*. + +As the final step, you have to install the firmware package to your image. You +can do that in your *local.conf* or image recipe via + +.. code-block:: kconfig + + # file local.conf or image recipe + IMAGE_INSTALL += "linux-firmware-example" + +.. warning:: + + Ensure that you have adapted the package name *linux-firmware-example* with + the name you assigned in *linux-firmware_%.bbappend*. + +Change the *u-boot* Environment via *bbappend* Files +.................................................... + +All i.MX8M\* products use the u-boot bootloader. The u-boot environment can be +modified using the Temporary Method. In the *u-boot-imx* sources modify the +header file corresponding to the processor located in +*include/configs/phycore_imx8m\**. New environment variables should be added at +the end of *CONFIG_EXTRA_ENV_SETTINGS* + +.. code-block:: kconfig + + #define CONFIG_EXTRA_ENV_SETTINGS \ + [...] + PHYCORE_FITIMAGE_ENV_BOOTLOGIC \ + "newvariable=1\0" + +Commit the changes and and create the file *u-boot-imx_%.bbappend* in your layer +at */recipes-bsp/u-boot/u-boot-imx_%.bbappend* + +.. code-block:: kconfig + + # contents of the file u-boot-imx_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://0001-environment-addition.patch \ + " + +Change the *barebox* Environment via *bbappend* Files +..................................................... + +Since *BSP-Yocto-AM335x-16.2.0* and *BSP-Yocto-i.MX6-PD16.1.0*, the *barebox* +environment handling in *meta-phytec* has changed. Now it is possible to add, +change, and remove files in the *barebox* environment via the *Python* bitbake +task *do_env*. There are two *Python* functions to change the environment. Their +signatures are: + +- *env_add(d, *\ **filename as string**\ *, *\ **file content as string**\ *)*: + to add a new file or overwrite an existing file +- *env_rm(d, *\ **filename as string**\ *)*: to remove a file + +The first example of a *bbappend* file in the custom layer *meta-racer* shows +how to add a new non-volatile variable *linux.bootargs.fb* in the *barebox* +environment folder */env/nv/* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_add(d, "nv/linux.bootargs.fb", "imxdrm.legacyfb_depth=32\n") + } + +The next example shows how to replace the network configuration file +*/env/network/eth0* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_add(d, "network/eth0", + """#!/bin/sh + + # ip setting (static/dhcp) + ip=static + global.dhcp.vendor_id=barebox-${global.hostname} + + # static setup used if ip=static + ipaddr=192.168.178.5 + netmask=255.255.255.0 + gateway=192.168.178.1 + serverip=192.168.178.1 + """) + } + +In the above example, the *Python* multiline string syntax **""" text """** is +used to avoid adding multiple newline characters *\\n* into the recipe *Python* +code. The *Python* function *env_add* can add and overwrite environment files. + +The next example shows how to remove an already added environment file, for +example *,* */env/boot/mmc* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_rm(d, "boot/mmc") + } + +Debugging the Environment +~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you want to see all environment files that are added in the build process, +you can enable a debug flag in the *local.conf* + +.. code-block:: kconfig + + # file local.conf + ENV_VERBOSE = "1" + +After that, you have to rebuild the *barebox* recipe to see the debugging +output + +.. code-block:: console + + host:~$ bitbake barebox -c clean + host:~$ bitbake barebox -c configure + +The output of the last command looks like this + +.. code-block:: + + [...] + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/allow_color' content "false" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.base' content "consoleblank=0" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.fb' content "imxdrm.legacyfb_depth=32" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.rootfs' content "rootwait ro fsck.repair=yes" + +Changing the Environment (depending on Machines) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you need to apply some *barebox* environment modifications only to a single +or only a few machines, you can use *Bitbake'* s machine overwrite syntax. For +the machine overwrite syntax, you append a machine name or SoC name (such as +*mx6* , *ti33x,* or *rk3288* ) with an underscore to a variable or task + +.. code-block:: kconfig + + DEPENDS:remove:mx6 = "virtual/libgl" or + python do_env_append_phyboard-mira-imx6-4(). + +The next example adds the environment variables only if the MACHINE is set to +*phyboard-mira-imx6-4* + +.. code-block:: kconfig + + # file meta-phytec/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append:phyboard-mira-imx6-4() { + env_add(d, "nv/linux.bootargs.cma", "cma=64M\n") + } + +*Bitbake's* override syntax for variables is explained in more detail at: +https://docs.yoctoproject.org/bitbake/2.0/bitbake-user-manual/bitbake-user-manual-metadata.html#conditional-metadata + +Upgrading the *barebox* Environment from Previous BSP Releases +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Prior to BSP version *BSP-Yocto-AM335x-16.2.0* and *BSP-Yocto-i.MX6-PD16.1.0* , +*barebox* environment changes via *bbappend* file were done differently. For +example, the directory structure in your meta layer (here *meta-skeleton* ) may +have looked like this + +.. code-block:: console + + $ tree -a sources/meta-skeleton/recipes-bsp/barebox/ + sources/meta-skeleton/recipes-bsp/barebox + ├── barebox + │ └── phyboard-wega-am335x-3 + │ ├── boardenv + │ │ └── .gitignore + │ └── machineenv + │ └── nv + │ └── linux.bootargs.cma + └── barebox_%.bbappend + +and the file *barebox_%.bbappend* contained + +.. code-block:: kconfig + + # file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:" + +In this example, all environment changes from the directory *boardenv* in the +layer *meta-phytec* are ignored and the file *nv/linux.bootargs.cma* is added. +For the new handling of the *barebox* environment, you use the *Python* +functions *env_add* and *env_rm* in the *Python* task *do_env*. Now the above +example translates to a single *Python* function in the file +*barebox_%.bbappend* that looks like + +.. code-block:: kconfig + + # file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:" + python do_env:append() { + # Removing files (previously boardenv) + env_rm(d, "config-expansions") + # Adding new files (previously machineenv) + env_add(d, "nv/linux.bootargs.cma", "cma=64M\n") + } + +.. _kirkstone_changing-net-config: + +Changing the Network Configuration +.................................. + +To tweak IP addresses, routes, and gateways at runtime you can use the tools +*ifconfig* and *ip* . Some examples + +.. code-block:: console + + target:~$ ip addr # Show all network interfaces + target:~$ ip route # Show all routes + target:~$ ip addr add 192.168.178.11/24 dev eth0 # Add static ip and route to interface eth0 + target:~$ ip route add default via 192.168.178.1 dev eth0 # Add default gateway 192.168.178.1 + target:~$ ip addr del 192.168.178.11/24 dev eth0 # Remove static ip address from interface eth0 + +The network configuration is managed by *systemd-networkd* . To query the +current status use + +.. code-block:: console + + target:~$ networkctl status + target:~$ networkctl list + +The network daemon reads its configuration from the directories +*/etc/systemd/network/* , */run/systemd/network/* , and */lib/systemd/network/* +(from higher to lower priority). A sample configuration in +*/lib/systemd/network/10-eth0.network* looks like this + +.. code-block:: kconfig + + # file /lib/systemd/network/10-eth0.network + [Match] + Name=eth0 + + [Network] + Address=192.168.3.11/24 + Gateway=192.168.3.10 + +These files *\*.network* replace */etc/network/interfaces* from other +distributions. You can either edit the file *10-eth0.network* in-place or copy +it to */etc/systemd/network/* and make your changes there. After changing a file +you must restart the daemon to apply your changes + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +To see the syslog message of the network daemon, use + +.. code-block:: console + + target:~$ journalctl --unit=systemd-networkd.service + +To modify the network configuration at build time, look at the recipe +*sources/meta-ampliphy/recipes-core/systemd/systemd-machine-units.bb* +and the interface files in the folder +*meta-ampliphy/recipes-core/systemd/systemd-machine-units/* where the static IP +address configuration for *eth0* (and optionally *eth1*) is done. + +For more information, see https://wiki.archlinux.org/title/Systemd-networkd +and https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html. + +Changing the Wireless Network Configuration +........................................... + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- First set the correct regulatory domain for your country + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +- Set up the wireless interface + +.. code-block:: console + + target:~$ ip link # list all interfaces. Search for wlan* + target:~$ ip link set up dev wlan0 + +- Now you can scan for available networks + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for *WEP*, *WPA*, and +*WPA2* called *wpa_supplicant* for an encrypted connection. + +- To do so, add the network credentials to the file + */etc/wpa_supplicant.conf* + +.. code-block:: kconfig + + Confluence country=DE network={ ssid="" proto=WPA2 psk="" } + +- Now a connection can be established + +.. code-block:: console + + target:~$ wpa_supplicant -Dnl80211 -c/etc/wpa_supplicant.conf -iwlan0 -B + +This should result in the following output + +.. code-block:: + + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see the section :ref:`kirkstone_changing-net-config`. + +- First, create the directory + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +- Then add the following configuration snippet in + */etc/systemd/network/10-wlan0.network* + +.. code-block:: kconfig + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +- Now, restart the network daemon so that the configuration takes effect + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Creating a WLAN Access Point +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This section provides a basic access point (AP) configuration for a +secured *WPA2* network. + +Find the name of the WLAN interface with + +.. code-block:: console + + target:~$ ip link + +Edit the configuration in */etc/hostapd.conf*. It is strongly dependent on +the use case. The following shows an example + +.. code-block:: kconfig + + # file /etc/hostapd.conf + interface=wlan0 + driver=nl80211 + ieee80211d=1 + country_code=DE + hw_mode=g + ieee80211n=1 + ssid=Test-Wifi + channel=2 + wpa=2 + wpa_passphrase=12345678 + wpa_key_mgmt=WPA-PSK + wpa_pairwise=CCMP + +Set up and start the DHCP server for the network interface *wlan0* via +*systemd-networkd* + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + target:~$ vi /etc/systemd/network/10-wlan0.network + +Insert the following text into the file + +.. code-block:: kconfig + + [Match] + Name=wlan0 + + [Network] + Address=192.168.0.1/24 + DHCPServer=yes + + [DHCPServer] + EmitDNS=yes + target:~$ systemctl restart systemd-networkd + target:~$ systemctl status systemd-networkd -l # check status and see errors + +Start the userspace daemon *hostapd* + +.. code-block:: console + + target:~$ systemctl start hostapd + target:~$ systemctl status hostapd -l # check for errors + +Now, you should see the WLAN network *Test-Wifi* on your terminal device +(laptop, smartphone, etc.). + +If there are problems with the access point, you can either check the log +messages with + +.. code-block:: console + + target:~$ journalctl --unit=hostapd + +or start the daemon in debugging mode from the command line + +.. code-block:: console + + target:~$ systemctl stop hostapd + target:~$ hostapd -d /etc/hostapd.conf -P /var/run/hostapd.pid + +You should see + +.. code-block:: + + ... + wlan0: interface state UNINITIALIZED->ENABLED + wlan0: AP-ENABLED + +Further information about AP settings and the userspace daemon +*hostapd* can be found at + +.. code-block:: + + https://wireless.wiki.kernel.org/en/users/documentation/hostapd + https://w1.fi/hostapd/ + +phyCORE-i.MX 6UL/ULL Bluetooth +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Special consideration must be paid when working with any Bluetooth on a +phyCORE-i.MX 6UL/ULL. For further information, please check `L-844e.A5 i.MX +6UL/ULL BSP Manual - Bluetooth +`_. + +Add OpenCV Libraries and Examples +................................. + +*OpenCV* (Opensource Computer Vision https://opencv.org/) is an open-source +library for computer vision applications. + +To install the libraries and examples edit the file *conf/local.conf* in the +*Yocto* build system and add + +.. code-block:: kconfig + + # file conf/local.conf + # Installing OpenCV libraries and examples + LICENSE_FLAGS_ACCEPTED += "commercial_libav" + LICENSE_FLAGS_ACCEPTED += "commercial_x264" + IMAGE_INSTALL:append = " \ + opencv \ + opencv-samples \ + libopencv-calib3d2.4 \ + libopencv-contrib2.4 \ + libopencv-core2.4 \ + libopencv-flann2.4 \ + libopencv-gpu2.4 \ + libopencv-highgui2.4 \ + libopencv-imgproc2.4 \ + libopencv-legacy2.4 \ + libopencv-ml2.4 \ + libopencv-nonfree2.4 \ + libopencv-objdetect2.4 \ + libopencv-ocl2.4 \ + libopencv-photo2.4 \ + libopencv-stitching2.4 \ + libopencv-superres2.4 \ + libopencv-video2.4 \ + libopencv-videostab2.4 \ + " + +Then rebuild your image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +.. tip:: + + Most examples do not work out of the box, because they depend on the *GTK* + graphics library. The BSP only supports *Qt6* . + +Add Minimal PHP web runtime with *lightpd* +.......................................... + +This is one example of how to add a small runtime for PHP applications and a web +server on your target. Lighttpd can be used together with the PHP command line +tool over cgi. This solution weights only 5.5 MiB of disk storage. It is already +preconfigured in meta-ampliphy. Just modify the build configuration to install +it on the image + +.. code-block:: kconfig + + # file conf/local.conf + # install lighttpd with php cgi module + IMAGE_INSTALL:append = " lighttpd" + +After booting the image, you should find the example web content in */www/pages* +. For testing php, you can delete the *index.html* and replace it with a +*index.php* file + +.. code-block:: html + + + + PHP-Test + + + + + + +On your host, you can point your browser to the board's IP, (e.g. 192.168.3.11) +and the phpinfo should show up. + +Common Tasks +------------ + +Debugging a User Space Application +.................................. + +The phytec-qt6demo-image can be cross-debugged without any change. For +cross-debugging, you just have to match the host sysroot with the image in use. +So you need to create a toolchain for your image + +.. code-block:: console + + host:~$ bitbake -c populate_sdk phytec-qt6demo-image + +Additionally, if you want to have full debug and backtrace capabilities for all +programs and libraries in the image, you could add + +.. code-block:: kconfig + + DEBUG_BUILD = "1" + +to the ``conf/local.conf``. This is not necessary in all cases. The compiler +options will then be switched from FULL_OPTIMIZATION to DEBUG_OPTIMIZATION. Look +at the *Poky* source code for the default assignment of DEBUG_OPTIMIZATION. + +To start a cross debug session, install the SDK as mentioned previously, source +the SDK environment, and run *Qt Creator* in the same shell. If you do not use +*Qt Creator*, you can directly call the arm-<..>-gdb debugger instead which +should be in your path after sourcing the environment script. + +If you work with *Qt Creator*, have a look at the appropriate documentation +delivered with your product (either QuickStart or Application Guide) for +information on how to set up the toolchain. + +When starting the debugger with your userspace application you will get a +SIGILL, an illegal instruction from the *libcrypto*. *Openssl* probes for the +system capabilities by trapping illegal instructions, which will trigger *GDB*. +You can ignore this and hit **Continue** (c command). You can permanently ignore +this stop by adding + +.. code-block:: kconfig + + handle SIGILL nostop + +to your *GDB* startup script or in the *Qt Creator GDB* configuration panel. +Secondly, you might need to disable a security feature by adding + +.. code-block:: kconfig + + set auto-load safe-path / + +to the same startup script, which will enable the automatic loading of libraries +from any location. + +If you need to have native debugging, you might want to install the debug +symbols on the target. You can do this by adding the following line to your +*conf/local.conf* + +.. code-block:: kconfig + + EXTRA_IMAGE_FEATURES += "dbg-pkgs" + +For cross-debugging, this is not required as the debug symbols will be loaded +from the host side and the dbg-pkgs are included in the SDK of your image +anyway. + +.. _kirkstone_gen-source-mirrors: + +Generating Source Mirrors, working Offline +.......................................... + +Modify your *site.conf* (or *local.conf* if you do not use a *site.conf* ) as +follows + +.. code-block:: kconfig + + #DL_DIR ?= "" don't set it! It will default to a directory inside /build + SOURCE_MIRROR_URL = "file:///home/share/yocto_downloads/" + INHERIT += "own-mirrors" + BB_GENERATE_MIRROR_TARBALLS = "1" + +Now run + +.. code-block:: console + + host:~$ bitbake --runall=fetch + +for all images and for all machines you want to provide sources for. This will +create all the necessary *tar* archives. We can remove all SCM subfolders, as +they are duplicated with the tarballs + +.. code-block:: console + + host:~$ rm -rf build/download/git2/ + etc... + +Please consider that we used a local source mirror for generating the dl_dir. +Because of that, some archives will be linked locally. + +First, we need to copy all files, resolving symbolic links into the new mirror +directory + +.. code-block:: console + + host:~$ rsync -vaL ${TOPDIR}/../src_mirror/ + +Now we clean the */build* directory by deleting everything except */build/conf/* +but including */build/conf/sanity*. We change *site.conf* as follows + +.. code-block:: kconfig + + SOURCE_MIRROR_URL = "file://${TOPDIR}/../src_mirror" + INHERIT += "own-mirrors" + BB_NO_NETWORK = "1" + SCONF_VERSION = "1" + +The BSP directory can now be compressed with + +.. code-block:: console + + host:~$ tar cfJ .tar.xz + +where filename and folder should be the full BSP Name. + +Compiling on the Target +....................... + +To your *local.conf* add + +.. code-block:: kconfig + + IMAGE_FEATURES:append = " tools-sdk dev-pkgs" + +Different Toolchains +.................... + +There are several ways to create a toolchain installer in *Poky*. One option is +to run + +.. code-block:: console + + host:~$ bitbake meta-toolchain + +This will generate a toolchain installer in *build/deploy/sdk* which can be used +for cross-compiling of target applications. However, the installer does not +include libraries added to your image, so it is a bare *GCC* compiler only. This +is suited for bootloader and kernel development. + +Another you can run is + +.. code-block:: console + + host:~$ bitbake -c populate_sdk + +This will generate a toolchain installer containing all necessary development +packages of the software installed on the root filesystem of the target. This +installer can be handed over to the user space application development team and +includes all necessary parts to develop an application. If the image contains +the *QT* libraries, all of those will be available in the installer too. + +The third option is to create the ADT (Application Development Toolkit) +installer. It will contain the cross-toolchain and some tools to aid the +software developers, for example, an *Eclipse* plugin and a *QEMU* target +simulator. + +.. code-block:: console + + host:~$ bitbake adt-installer + +The ADT is untested for our BSP at the moment. + +Using the SDK +~~~~~~~~~~~~~ + +After generating the SDK with + +.. code-block:: console + + host:~$ source sources/poky/oe-init-build-env + host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image + +run the generated binary with + +.. code-block:: console + + host:~$ deploy/sdk/ampliphy-glibc-x86_64-phytec-qt6demo-image-cortexa9hf-vfp-neon-toolchain-i.MX6-PD15.3-rc.sh + Enter target directory for SDK (default: /opt/ampliphy/i.MX6-PD15.3-rc): + You are about to install the SDK to "/opt/ampliphy/i.MX6-PD15.3-rc". Proceed[Y/n]? + Extracting SDK...done + Setting it up...done + SDK has been successfully set up and is ready to be used. + +You can activate the toolchain for your shell by sourcing the file +*environment-setup* in the toolchain directory + +.. code-block:: console + + host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + +Then the necessary tools like the cross compiler and linker are in your PATH. To +compile a simple *C* program, use + +.. code-block:: console + + host:~$ $CC main.c -o main + +The environment variable $CC contains the path to the ARM cross compiler and +other compiler arguments needed like *-march* , *-sysroot* and *--mfloat-abi*. + +.. tip:: + + You cannot compile programs only with the compiler name like + + .. code-block:: console + + host:~$ arm-phytec-linux-gnueabi-gcc main.c -o main + + It will fail in many cases. Always use *CC*, CFLAGS, LDFLAGS, and so on. + +For convenience, the *environment-setup* exports other environment variables +like CXX, LD, SDKTARGETSYSROOT. + +A simple makefile compiling a *C* and *C++* program may look like this + +.. code-block:: kconfig + + # Makefile + TARGETS=c-program cpp-program + + all: $(TARGETS) + + c-program: c-program.c + $(CC) $(CFLAGS) $(LDFLAGS) $< -o $@ + + cpp-program: cpp-program.cpp + $(CXX) $(CXXFLAGS) $(LDFLAGS) $< -o $@ + + .PHONY: clean + clean: + rm -f $(TARGETS) + +To compile for the target, just source the toolchain in your shell before +executing make + +.. code-block:: console + + host:~$ make # Compiling with host CC, CXX for host architecture + host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + host:~$ make # Compiling with target CC, CXX for target architecture + +If you need to specify additionally included directories in the sysroot of the +toolchain, you can use an '=' sign in the *-I* argument like + +.. code-block:: kconfig + + -I=/usr/include/SDL + +*GCC* replaces it by the sysroot path (here +*/opt/ampliphy/i.MX6-PD15.3-rc/sysroots/cortexa9hf-vfp-neon-phytec-linux-gnueabi/*). +See the main page of *GCC* for more information. + +.. tip:: + + The variables $CFLAGS and $CXXFLAGS contain the compiler debug flag '-g' by + default. This includes debugging information in the binary and making it + bigger. Those should be removed from the production image. If you create a + *Bitbake* recipe, the default behavior is to turn on '-g' too. The debugging + symbols are used in the SDK rootfs to be able to get debugging information + when invoking *GDB* from the host. Before installing the package to the + target rootfs, *Bitbake* will invoke *strip* on the program which removes the + debugging symbols. By default, they are not found nor required on the target + root filesystem + +Using the SDK with GNU Autotools +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +*Yocto* SDK is a straightforward tool for a project that uses the *GNU +Autotools*. The traditional compile steps for the host are usually + +.. code-block:: console + + host:~$ ./autogen.sh # maybe not needed + host:~$ ./configure + host:~$ make + host:~$ make install DESTDIR=$PWD/build/ + +The commands to compile for the target machine with the *Yocto* SDK are quite +similar. The following commands assume that the SDK was unpacked to the +directory */opt/phytec-ampliphy/i.MX6-PD15.3.0/* (adapt the path as needed) + +.. code-block:: console + + host:~$ source /opt/phytec-ampliphy/i.MX6-PD15.3.0/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + host:~$ ./autogen.sh # maybe not needed + host:~$ ./configure ${CONFIGURE_FLAGS} + host:~$ make + host:~$ make install DESTDIR=$PWD/build/ + +Refer to the official *Yocto* documentation for more information: +https://docs.yoctoproject.org/4.0.6/singleindex.html#autotools-based-projects + +Working with Kernel Modules +........................... + +You will come to the point where you either need to set some options for a +kernel module or you want to blacklist a module. Those things are handled by +*udev* and go into *\*.conf* files in + +.. code-block:: + + /etc/modprobe.d/\*.conf. + +If you want to specify an option at build time, there are three relevant +variables. If you just want to autoload a module that has no autoload +capabilities, add it to + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + +either in the kernel recipe or in the global variable scope. If you need to +specify options for a module, you can do so with + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + KERNEL_MODULE_PROBECONF += "your-module" + module_conf_your-module = "options your-module parametername=parametervalue" + +if you want to blacklist a module from autoloading, you can do it intuitively +with + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + KERNEL_MODULE_PROBECONF += "your-module" + module_conf_your-module = "blacklist your-module" + +Working with *udev* +................... + +Udev (Linux dynamic device management) is a system daemon that handles dynamic +device management in /dev. It is controlled by *udev* \ rules that are located +in */etc/udev/rules.d* (sysadmin configuration space) and\ */lib/udev/rules.d/* +(vendor-provided). Here is an example of an *udev* \ rule file + +.. code-block:: kconfig + + # file /etc/udev/rules.d/touchscreen.rules + # Create a symlink to any touchscreen input device + SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="input:*-e0*,3,*a0,1,*18,*", SYMLINK+="input/touchscreen0" + SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="ads7846", SYMLINK+="input/touchscreen0" + +See https://www.freedesktop.org/software/systemd/man/latest/udev.html for more details +about the syntax and usage. To get the list of attributes for a specific device +that can be used in an *udev* rule you can use the *udevadm info* tool. It +prints all existing attributes of the device node and its parents. The key-value +pairs from the output can be copied and pasted into a rule file. Some examples + +.. code-block:: console + + target:~$ udevadm info -a /dev/mmcblk0 + target:~$ udevadm info -a /dev/v4l-subdev25 + target:~$ udevadm info -a -p /sys/class/net/eth0 + +After changing an *udev* rule, you have to notify the daemon. Otherwise, your +changes are not reflected. Use the following command + +.. code-block:: console + + target:~$ udevadm control --reload-rules + +While developing *udev* rules you should monitor the events in order to see when +devices are attached or unattached to the system. Use + +.. code-block:: console + + target:~$ udevadm monitor + +Furthermore, it is very useful to monitor the system log in another shell, +especially if the rule executes external scripts. Execute + +.. code-block:: console + + target:~$ journalctl -f + +.. tip:: + + You cannot start daemons or heavy scripts in a *RUN* attribute. See + https://www.freedesktop.org/software/systemd/man/latest/udev.html . + + This can only be used for very short-running foreground tasks. Running an + event process for a long period of time may block all further events for this + or a dependent device. Starting daemons or other long-running processes is + not appropriate for *udev*; the forked processes, detached or not, will be + unconditionally killed after the event handling has finished. You can use the + special attribute *ENV{SYSTEMD_WANTS}="service-name.service"* and a + *systemd*\ service instead. + + See + https://unix.stackexchange.com/questions/63232/what-is-the-correct-way-to-write-a-udev-rule-to-stop-a-service-under-systemd. + +Troubleshooting +=============== + +Setscene Task Warning +--------------------- + +This warning occurs when the Yocto cache is in a dirty state. + +.. code-block:: + + WARNING: Setscene task X ([...]) failed with exit code '1' - real task + +You should avoid canceling the build process or if you have to, press Ctrl-C +once and wait until the build process has stopped. To remove all these warnings +just clean the sstate cache and remove the build folders. + +.. code-block:: console + + host:~$ bitbake phytec-headless-image -c cleansstate && rm -rf tmp deploy/ipk + +Yocto Documentation +=================== + +The most important piece of documentation for a BSP user is probably the +developer manual. +https://docs.yoctoproject.org/4.0.6/dev-manual/index.html + +The chapter about common tasks is a good starting point. +https://docs.yoctoproject.org/4.0.6/dev-manual/common-tasks.html#common-tasks + +The complete documentation is available on one single HTML page, which is good +for searching for a feature or a variable name. +https://docs.yoctoproject.org/4.0.6/singleindex.html diff --git a/previews/271/zh_CN/_sources/yocto/manual-index.rst.txt b/previews/271/zh_CN/_sources/yocto/manual-index.rst.txt new file mode 100644 index 000000000..e1f7541d3 --- /dev/null +++ b/previews/271/zh_CN/_sources/yocto/manual-index.rst.txt @@ -0,0 +1,33 @@ +======================= +Yocto Reference Manuals +======================= + +Kirkstone +========= + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + kirkstone + +Mickledore +========== + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + mickledore + +Scarthgap +========= + +.. toctree:: + :caption: Table of Contents + :numbered: + :maxdepth: 2 + + scarthgap \ No newline at end of file diff --git a/previews/271/zh_CN/_sources/yocto/mickledore.rst.txt b/previews/271/zh_CN/_sources/yocto/mickledore.rst.txt new file mode 100644 index 000000000..6e7ccddb6 --- /dev/null +++ b/previews/271/zh_CN/_sources/yocto/mickledore.rst.txt @@ -0,0 +1,3077 @@ +.. Download links +.. _`static-pdf-dl`: ../_static/mickledore.pdf + +.. Yocto +.. |yocto-codename| replace:: Mickledore +.. |yocto-ref-manual| replace:: Yocto Reference Manual +.. |distro| replace:: ampliphy-vendor-xwayland + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-------------------------------------------------------------+ +| |yocto-ref-manual| | ++=======================+=====================================+ +| Document Title | |yocto-ref-manual| |yocto-codename| | ++-----------------------+-------------------------------------+ +| Document Type | Yocto Manual | ++-----------------------+-------------------------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+-------------------------------------+ +| Is Branch of | |yocto-ref-manual| | ++-----------------------+-------------------------------------+ + ++----------------------------------+------------------+------------------+------------+ +| Compatible BSPs | BSP Release Type | BSP Release Date | BSP Status | ++==================================+==================+==================+============+ +| BSP-Yocto-NXP-i.MX93-PD24.1.0 | Major | 05.02.2024 | released | ++----------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX93-PD24.1.1 | Minor | 08.05.2024 | released | ++----------------------------------+------------------+------------------+------------+ + + +This manual applies to all |yocto-codename| based PHYTEC releases. + +.. _yocto-man-mickledore: + +The Yocto Project +================= + +PHYTEC Documentation +-------------------- + +PHYTEC will provide a variety of hardware and software documentation for all of +our products. This includes any or all of the following: + +- **QS Guide**: A short guide on how to set up and boot a phyCORE board along + with brief information on building a BSP, the device tree, and accessing + peripherals. +- **Hardware Manual**: A detailed description of the System on Module and + accompanying carrier board. +- **Yocto Guide**: A comprehensive guide for the Yocto version the phyCORE + uses. This guide contains an overview of Yocto; introducing, installing, and + customizing the PHYTEC BSP; how to work with programs like Poky and Bitbake; + and much more. +- **BSP Manual**: A manual specific to the BSP version of the phyCORE. + Information such as how to build the BSP, booting, updating software, device + tree, and accessing peripherals can be found here. +- **Development Environment Guide**: This guide shows how to work with the + Virtual Machine (VM) Host PHYTEC has developed and prepared to run various + Development Environments. There are detailed step-by-step instructions for + Eclipse and Qt Creator, which are included in the VM. There are instructions + for running demo projects for these programs on a phyCORE product as well. + Information on how to build a Linux host PC yourself is also a part of this + guide. +- **Pin Muxing Table**: phyCORE SOMs have an accompanying pin table (in Excel + format). This table will show the complete default signal path, from + processor to carrier board. The default device tree muxing option will also + be included. This gives a developer all the information needed in one + location to make muxing changes and design options when developing a + specialized carrier board or adapting a PHYTEC phyCORE SOM to an application. + +On top of these standard manuals and guides, PHYTEC will also provide Product +Change Notifications, Application Notes, and Technical Notes. These will be done +on a case-by-case basis. Most of the documentation can be found in the +applicable download page of our products. + +Yocto Introduction +------------------ + +Yocto is the smallest SI metric system prefix. Like milli equates to ``m = +10^-3``, and so is yocto ``y = 10^-24``. Yocto is also a project working group +of the `Linux Foundation `_ and therefore +backed up by several major companies in the field. On the `Yocto Project website +`_ you can read the official introduction: + + The Yocto Project is an open-source collaboration project that provides + templates, tools, and methods to help you create custom Linux-based systems + for embedded products regardless of the hardware architecture. It was founded + in 2010 as a collaboration among many hardware manufacturers, open-source + operating systems vendors, and electronics companies to bring some order to + the chaos of embedded Linux development. + +As said, the project wants to provide toolsets for embedded developers. It +builds on top of the long-lasting `OpenEmbedded +`_ project. It is not a Linux distribution. But +it contains the tools to create a Linux distribution specially fitted to the +product requirements. The most important step in bringing order to the set of +tools is to define a common versioning scheme and a reference system. All +subprojects have then to comply with the reference system and have to comply +with the versioning scheme. + +The release process is similar to the `Linux kernel `_. +Yocto increases its version number every six months and gives the release a +codename. The release list can be found here: +https://wiki.yoctoproject.org/wiki/Releases + +Core Components +--------------- + +The most important tools or subprojects of the *Yocto* Project are: + +- Bitbake: build engine, a task scheduler like make, interprets metadata +- OpenEmbedded-Core, a set of base layers, containing metadata of software, no + sources +- Yocto kernel + + - Optimized for embedded devices + - Includes many subprojects: rt-kernel, vendor patches + - The infrastructure provided by Wind River + - Alternative: classic kernel build → we use it to integrate our kernel into + *Yocto* + +- *Yocto* Reference BSP: *beagleboneblack*, *minnow max* +- *Poky*, the reference system, a collection of projects and tools, used to + bootstrap a new distribution based on *Yocto* + +Vocabulary +---------- + +Recipes +....... + +Recipes contain information about the software project (author, homepage, and +license). A recipe is versioned, defines dependencies, contains the URL of the +source code, and describes how to fetch, configure, and compile the sources. It +describes how to package the software, e.g. into different .deb packages, which +then contain the installation path. Recipes are basically written in *Bitbake's* +own programming language, which has a simple syntax. However, a recipe can +contain *Python* as well as a bash code. + +Classes +....... + +Classes combine functionality used inside recipes into reusable blocks. + +Layers +...... + +A layer is a collection of recipes, classes, and configuration metadata. +A layer can depend on other layers and can be included or excluded one +by one. It encapsulates a specific functionality and fulfills a specific +purpose. Each layer falls into a specific category: + +- Base +- Machine (BSP) +- Software +- Distribution +- Miscellaneous + +*Yocto's* versioning scheme is reflected in every layer as version branches. For +each *Yocto* version, every layer has a named branch in its *Git* repository. +You can add one or many layers of each category in your build. + +A collection of OpenEmbedded layers can be found here. The search function is +very helpful to see if a software package can be retrieved and integrated +easily: https://layers.openembedded.org/layerindex/branch/mickledore/layers/ + +Machine +....... + +Machines are configuration variables that describe the aspects of the target +hardware. + +Distribution (Distro) +..................... + +Distribution describes the software configuration and comes with a set of +software features. + +Poky +---- + +*Poky* is the reference system to define *Yocto* Project compatibility. It +combines several subprojects into releases: + +- *Bitbake* +- *Toaster* +- OpenEmbedded Core +- *Yocto* Documentation +- *Yocto* Reference BSP + +Bitbake +....... + +*Bitbake* is the task scheduler. It is written in *Python* and interprets +recipes that contain code in *Bitbake's* own programming language, *Python*, and +bash code. The official documentation can be found here: +https://docs.yoctoproject.org/bitbake/2.4/index.html + +Toaster +....... + +*Toaster* is a web frontend for *Bitbake* to start and investigate builds. It +provides information about the build history and statistics on created images. +There are several use cases where the installation and maintenance of +a *Toaster* instance are beneficial. PHYTEC did not add or remove any features +to the upstream *Toaster*, provided by *Poky*. The best source for more +information is the official documentation: +https://docs.yoctoproject.org/4.2.4/toaster-manual/index.html + +Official Documentation +---------------------- + +For more general questions about *Bitbake* and *Poky* consult the mega-manual: +https://docs.yoctoproject.org/4.2.4/singleindex.html + +Compatible Linux Distributions +============================== + +To build *Yocto* you need a compatible *Linux* host development machine. The +list of supported distributions can be found in the reference manual: +https://docs.yoctoproject.org/4.2.4/ref-manual/system-requirements.html#supported-linux-distributions + +PHYTEC BSP Introduction +======================= + +BSP Structure +------------- + +The BSP consists roughly of three parts. BSP management, BSP metadata, and BSP +content. The management consists of *Repo* and phyLinux while the metadata +depends on the SOC, which describes how to build the software. The content +comprises PHYTEC's *Git* repositories and external sources. + +BSP Management +.............. + +*Yocto* is an umbrella project. Naturally, this will force the user to base +their work on several external repositories. They need to be managed in a +deterministic way. We use manifest files, which contain an XML data structure, +to describe all git repositories with pinned-down versions. The *Repo* tool and +our phyLinux wrapper script are used to manage the manifests and set up the BSP, +as described in the manifest file. + +phyLinux +~~~~~~~~ + +phyLinux is a wrapper for *Repo* to handle downloading and setting up the BSP +with an "out of the box" experience. + +Repo +~~~~ + +*Repo* is a wrapper around the *Repo* toolset. The phyLinux script will install +the wrapper in a global path. This is only a wrapper, though. Whenever you run +``repo init -u ``, you first download the *Repo* tools from *Googles* Git +server in a specific version to the ``.repo/repo`` directory. The next time you +run *Repo*, all the commands will be available. Be aware that the *Repo* version +in different build directories can differ over the years if you do not run *Repo +sync*. Also if you store information for your archives, you need to include the +complete ``.repo`` folder. + +*Repo* expects a *Git* repository which will be parsed from the command line. In +the PHYTEC BSP, it is called phy²octo. In this repository, all information about +a software BSP release is stored in the form of a *Repo* XML manifest. This data +structure defines URLs of *Git* servers (called "remotes") and *Git* +repositories and their states (called "projects"). The *Git* repositories can be +seen in different states. The revision field can be a branch, tag, or commit id +of a repository. This means the state of the software is not necessarily unique +and can change over time. That is the reason we use only tags or commit ids for +our releases. The state of the working directory is then unique and does not +change. + +The manifests for the releases have the same name as the release itself. It is a +unique identifier for the complete BSP. The releases are sorted by the SoC +platform. The selected SoC will define the branch of the phy²octo *Git* +repository which will be used for the manifest selection. + +BSP Metadata +............ + +We include several third-party layers in our BSP to get a complete *Linux* +distribution up and running without the need to integrate external projects. All +used repositories are described in the following section. + +Poky +~~~~ + +The PHYTEC BSP is built on top of *Poky*. It comes with a specific version, +defined in the *Repo* manifest. *Poky* comes with a specific version of +*Bitbake*. The OpenEmbedded-core layer "meta" is used as a base for our *Linux* +system. + +meta-openembedded +~~~~~~~~~~~~~~~~~ + +OpenEmbedded is a collection of different layers containing the meta description +for many open-source software projects. We ship all OpenEmbedded layers with our +BSP, but not all of them are activated. Our example images pull several software +packages generated from OpenEmbedded recipes. + +meta-qt6 +~~~~~~~~ + +This layer provides an integration of *Qt6* in the *Poky*-based root filesystem +and is integrated into our BSP. + +meta-nodejs +~~~~~~~~~~~ + +This is an application layer to add recent Node.js versions. + +meta-gstreamer1.0 +~~~~~~~~~~~~~~~~~ + +This is an application layer to add recent GStreamer versions. + +meta-rauc +~~~~~~~~~ + +This layer contains the tools required to build an updated infrastructure with +`RAUC `_. A comparison with +other update systems can be found here: `Yocto update tools +`_. + +meta-phytec +~~~~~~~~~~~ + +This layer contains all machines and common features for all our BSPs. It is +PHYTEC's `Yocto Board Support Package +`_ for all supported +hardware (since *fido*) and is designed to be standalone with *Poky*. Only these +two parts are required if you want to integrate the PHYTEC's hardware into your +existing *Yocto* workflow. The features are: + +- Bootloaders in ``recipes-bsp/barebox/`` and ``recipes-bsp/u-boot/`` +- Kernels in ``recipes-kernel/linux/`` and + ``dynamic-layers/fsl-bsp-release/recipes-kernel/linux/`` +- Many machines in ``conf/machine/`` +- Proprietary *OpenGL ES/EGL* user space libraries for AM335x and i.MX 6 + platforms +- Proprietary *OpenCL* libraries for i.MX 6 platforms + +meta-ampliphy +~~~~~~~~~~~~~ + +This is our example distribution and BSP layer. It extends the basic +configuration of *Poky* with software projects described by all the other BSP +components. It provides a base for your specific development scenarios. The +current features are: + +- `systemd `_ init system +- Images: ``phytec-headless-image`` for non-graphics applications +- Camera integration with OpenCV and GStreamer examples for the i.MX 6 platform + bundled in a ``phytec-vision-image`` +- RAUC integration: we set up basic support for an A/B system image update, + which is possible locally and over-the-air + +meta-qt6-phytec +~~~~~~~~~~~~~~~ + +This is our layer for Qt6 board integration and examples. The features are: + +- `Qt6 with eglfs backend `_ for + PHYTEC's AM335x, i.MX 6 and RK3288 platforms +- Images: ``phytec-qt6demo-image`` for *Qt6* and video applications +- A *Qt6* demo application demonstrating how to create a *Qt6* project using + *QML* widgets and a *Bitbake* recipe for the *Yocto* and *systemd* + integration. It can be found in + ``sources/meta-qt6-phytec/recipes-qt/examples/phytec-qtdemo_git.bb`` + +meta-virtualization +~~~~~~~~~~~~~~~~~~~ + +- This layer provides support for building Xen, KVM, Libvirt, and associated + packages necessary for constructing OE-based virtualized solutions. + +meta-security +~~~~~~~~~~~~~ + +- This layer provides security tools, hardening tools for Linux kernels, and + libraries for implementing security mechanisms. + +meta-selinux +~~~~~~~~~~~~ + +- This layer's purpose is to enable SE Linux support. The majority of this + layer's work is accomplished in *bbappend* files, used to enable SE Linux + support in existing recipes. + +meta-browser +~~~~~~~~~~~~ + +- This is an application layer to add recent web browsers (Chromium, Firefox, + etc.). + +meta-rust +~~~~~~~~~ + +- Includes the Rust compiler and the Cargo package manager for Rust. + +meta-timesys +~~~~~~~~~~~~ + +- Timesys layer for Vigiles Yocto CVE monitoring, security notifications, and + image manifest generation. + +meta-freescale +~~~~~~~~~~~~~~ + +- This layer provides support for the i.MX, Layerscape, and QorIQ product + lines. + +meta-freescale-3rdparty +~~~~~~~~~~~~~~~~~~~~~~~ + +- Provides support for boards from various vendors. + +meta-freescale-distro +~~~~~~~~~~~~~~~~~~~~~ + +- This layer provides support for Freescale's Demonstration images for use with + OpenEmbedded and/or Yocto Freescale's BSP layer. + +base (fsl-community-bsp-base) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- This layer provides BSP base files of NXP. + +meta-fsl-bsp-release +~~~~~~~~~~~~~~~~~~~~ + +- This is the i.MX Yocto Project Release Layer. + +BSP Content +........... + +The BSP content gets pulled from different online sources when you first start +using *Bitbake*. All files will be downloaded and cloned in a local directory +configured as ``DL_DIR`` in *Yocto*. If you backup your BSP with the complete +content, those sources have to be backed up, too. How you can do this will be +explained in the chapter :ref:`mickledore_gen-source-mirrors`. + +Build Configuration +------------------- + +The BSP initializes a build folder that will contain all files you +create by running *Bitbake* commands. It contains a ``conf`` folder +that handles build input variables. + +- ``bblayers.conf`` defines activated meta-layers, +- ``local.conf`` defines build input variables specific to your build +- ``site.conf`` defines build input variables specific to the development host + +The two topmost build input variables are ``DISTRO`` and ``MACHINE``. They are +preconfigured ``local.conf`` when you check out the BSP using phyLinux. + +We use "*Ampliphy*" as ``DISTRO`` with our BSP. This distribution will be +preselected and give you a starting point for implementing your own +configuration. + +A ``MACHINE`` defines a binary image that supports specific hardware +combinations of module and baseboard. Check the ``machine.conf`` file or our +webpage for a description of the hardware. + +Pre-built Images +================ + +For each BSP we provide pre-built target images that can be downloaded from the +PHYTEC FTP server: https://download.phytec.de/Software/Linux/ + +These images are also used for the BSP tests, which are flashed to the boards +during production. You can use the provided ``.wic`` images to create a bootable +SD card at any time. Identify your hardware and flash the downloaded image file +to an empty SD card using ``dd``. Please see section Images for information +about the correct usage of the command. + +BSP Workspace Installation +========================== + +Setting Up the Host +------------------- + +You can set up the host or use one of our build-container to run a Yocto build. +You need to have a running *Linux* distribution. It should be running on a +powerful machine since a lot of compiling will need to be done. + +If you want to use a build-container, you only need to install following +packages on your host + +.. code-block:: console + + host:~$ sudo apt install wget git + +Continue with the next step :ref:`mickledore_git-config` after that. The documentation for +using build-container can be found in this manual after +:ref:`mickledore_phylinux-advanced-usage` of phyLinux. + +Else *Yocto* needs a handful of additional packages on your host. For *Ubuntu* you need + +.. code-block:: console + + host:~$ sudo apt install gawk wget git diffstat unzip texinfo \ + gcc build-essential chrpath socat cpio python3 python3-pip \ + python3-pexpect xz-utils debianutils iputils-ping python3-git \ + python3-jinja2 libegl1-mesa libsdl1.2-dev \ + python3-subunit mesa-common-dev zstd liblz4-tool file locales + + +For other distributions you can find information in the *Yocto* Quick Build: +https://docs.yoctoproject.org/4.2.4/brief-yoctoprojectqs/index.html + +.. _mickledore_git-config: + +Git Configuration +----------------- + +The BSP heavily utilizes *Git*. *Git* needs some information from +you as a user to identify who made changes. Create a ``~/.gitconfig`` with the +following content, if you do not have one + +.. code-block:: kconfig + + [user] + name = + email = + [core] + editor = vim + [merge] + tool = vimdiff + [alias] + co = checkout + br = branch + ci = commit + st = status + unstage = reset HEAD -- + last = log -1 HEAD + [push] + default = current + [color] + ui = auto + +You should set ``name`` and ``email`` in your *Git* configuration, otherwise, +*Bitbake* will complain during the first build. You can use the two commands to +set them directly without editing ``~/.gitconfig`` manually + +.. code-block:: console + + host:~$ git config --global user.email "your_email@example.com" + host:~$ git config --global user.name "name surname" + +site.conf Setup +--------------- + +Before starting the *Yocto* build, it is advisable to configure the development +setup. Two things are most important: the download directory and the cache +directory. PHYTEC strongly recommends configuring the setup as it will reduce +the compile time of consequent builds. + +A download directory is a place where *Yocto* stores all sources fetched from +the internet. It can contain tar.gz, *Git* mirror, etc. It is very useful to set +this to a common shared location on the machine. Create this directory with 777 +access rights. To share this directory with different users, all files need to +have group write access. This will most probably be in conflict with default +*umask* settings. One possible solution would be to use ACLs for this +directory + +.. code-block:: console + + host:~$ sudo apt-get install acl + host:~$ sudo setfacl -R -d -m g::rwx + +If you have already created a download directory and want to fix the permissions +afterward, you can do so with + +.. code-block:: console + + host:~$ sudo find /home/share/ -perm /u=r ! -perm /g=r -exec chmod g+r \{\} \; + host:~$ sudo find /home/share/ -perm /u=w ! -perm /g=w -exec chmod g+w \{\} \; + host:~$ sudo find /home/share/ -perm /u=x ! -perm /g=x -exec chmod g+x \{\} \; + +The cache directory stores all stages of the build process. *Poky* has quite an +involved caching infrastructure. It is advisable to create a shared directory, +as all builds can access this cache directory, called the shared state cache. + +Create the two directories on a drive where you have approximately 50 GB of +space and assign the two variables in your ``build/conf/local.conf``:: + + DL_DIR ?= "/yocto_downloads" + SSTATE_DIR ?= "/yocto_sstate" + +If you want to know more about configuring your build, see the documented +example settings + +.. code-block:: + + sources/poky/meta-yocto/conf/local.conf.sample + sources/poky/meta-yocto/conf/local.conf.sample.extended + +phyLinux Documentation +====================== + +The phyLinux script is a basic management tool for PHYTEC *Yocto* BSP releases +written in *Python*. It is mainly a helper to get started with the BSP +structure. You can get all the BSP sources without the need of interacting with +*Repo* or *Git*. + +The phyLinux script has only one real dependency. It requires the *wget* tool +installed on your host. It will also install the `Repo tool +`_ in a global path +(/usr/local/bin) on your host PC. You can install it in a different location +manually. *Repo* will be automatically detected by phyLinux if it is found in +the PATH. The *Repo* tool will be used to manage the different *Git* +repositories of the *Yocto* BSP. + +Get phyLinux +------------ + +The phyLinux script can be found on the PHYTEC download server: +https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux + +Basic Usage +----------- + +For the basic usage of phyLinux, type + +.. code-block:: console + + host:~$ ./phyLinux --help + +which will result in + +.. code-block:: + + usage: phyLinux [-h] [-v] [--verbose] {init,info,clean} ... + + This Programs sets up an environment to work with The Yocto Project on Phytecs + Development Kits. Use phyLinx -h to display the help text for the + available commands. + + positional arguments: + {init,info,clean} commands + init init the phytec bsp in the current directory + info print info about the phytec bsp in the current directory + clean Clean up the current working directory + + optional arguments: + -h, --help show this help message and exit + -v, --version show program's version number and exit + --verbose + +Initialization +-------------- + +Create a fresh project folder + +.. code-block:: console + + host:~$ mkdir ~/yocto + +Calling phyLinux will use the default Python version. Starting with Ubuntu 20.04 +it will be Python3. If you want to initiate a BSP, which is not compatible with +Python3, you need to set Python2 as default (temporarily) before running +phyLinux + +.. code-block:: console + + host:~$ ln -s \`which python2\` python && export PATH=`pwd`:$PATH + +Now run phyLinux from the new folder + +.. code-block:: console + + host:~$ ./phyLinux init + +A clean folder is important because phyLinux will clean its working directory. +Calling phyLinux from a directory that isn't empty will result in the following +**warning**:: + + This current directory is not empty. It could lead to errors in the BSP configuration + process if you continue from here. At the very least, you have to check your build directory + for settings in bblayers.conf and local.conf, which will not be handled correctly in + all cases. It is advisable to start from an empty directory of call: + $ ./phyLinux clean + Do you really want to continue from here? + [yes/no]: + +On the first initialization, the phyLinux script will ask you to install the +*Repo* tool in your */usr/local/bin* directory. During the execution of the +*init* command, you need to choose your processor platform (SoC), PHYTEC's BSP +release number, and the hardware you are working on + +.. code-block:: + + *************************************************** + * Please choose one of the available SoC Platforms: + * + * 1: am335x + * 2: am57x + * 3: am62ax + * 4: am62x + * 5: am64x + * 6: am68x + * 7: imx6 + * 8: imx6ul + * 9: imx7 + * 10: imx8 + * 11: imx8m + * 12: imx8mm + * 13: imx8mp + * 14: imx8x + * 15: imx93 + * 16: nightly + * 17: rk3288 + * 18: stm32mp13x + * 19: stm32mp15x + * 20: topic + + # Exemplary output for chosen imx93 + *************************************************** + * Please choose one of the available Releases: + * + * 1: BSP-Yocto-NXP-i.MX93-ALPHA1 + * 2: BSP-Yocto-NXP-i.MX93-PD24.1-rc1 + * 3: BSP-Yocto-NXP-i.MX93-PD24.1.0 + * 4: BSP-Yocto-NXP-i.MX93-PD24.1.1-rc1 + * 5: BSP-Yocto-NXP-i.MX93-PD24.1.1-rc2 + * 6: BSP-Yocto-NXP-i.MX93-PD24.1.1-rc3 + * 7: BSP-Yocto-NXP-i.MX93-PD24.1.1 + + # Exemplary output for chosen BSP-Yocto-NXP-i.MX93-PD24.1.1 + ********************************************************************* + * Please choose one of the available builds: + * + no: machine: description and article number + distro: supported yocto distribution + target: supported build target + + 1: phyboard-nash-imx93-1: PHYTEC phyBOARD-Nash i.MX93 + 2 GB RAM, eMMC + PB-04729-001, PCL-077-23231211I + distro: ampliphy-vendor + target: phytec-headless-image + 2: phyboard-nash-imx93-1: PHYTEC phyBOARD-Nash i.MX93 + 2 GB RAM, eMMC + PB-04729-001, PCL-077-23231211I + distro: ampliphy-vendor-rauc + target: phytec-headless-bundle + 3: phyboard-nash-imx93-1: PHYTEC phyBOARD-Nash i.MX93 + 2 GB RAM, eMMC + PB-04729-001, PCL-077-23231211I + distro: ampliphy-vendor-wayland + target: -c populate_sdk phytec-qt6demo-image + target: phytec-qt6demo-image + 4: phyboard-segin-imx93-2: PHYTEC phyBOARD-Segin i.MX93 + 1 GB RAM, eMMC, silicon revision A1 + PB-02029-001, PCL-077-11231010I + distro: ampliphy-vendor + target: phytec-headless-image + 5: phyboard-segin-imx93-2: PHYTEC phyBOARD-Segin i.MX93 + 1 GB RAM, eMMC, silicon revision A1 + PB-02029-001, PCL-077-11231010I + distro: ampliphy-vendor-rauc + target: phytec-headless-bundle + 6: phyboard-segin-imx93-2: PHYTEC phyBOARD-Segin i.MX93 + 1 GB RAM, eMMC, silicon revision A1 + PB-02029-001, PCL-077-11231010I + distro: ampliphy-vendor-wayland + target: phytec-qt6demo-image + +If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. After the configuration is done, +you can always run + +.. code-block:: console + + host:~$ ./phyLinux info + + # Exemplary output + ********************************************** + * The current BSP configuration is: + * + * SoC: refs/heads/imx93 + * Release: BSP-Yocto-NXP-i.MX93-PD24.1.1 + * Machine: phyboard-segin-imx93-2 + * + ********************************************** + +to see which SoC and Release are selected in the current workspace. If +you do not want to use the selector, phyLinux also supports command-line +arguments for several settings + +.. code-block:: console + + host:~$ MACHINE=phyboard-segin-imx93-2 ./phyLinux init -p imx93 -r BSP-Yocto-NXP-i.MX93-PD24.1.1 + +or view the help command for more information + +.. code-block:: console + + host:~$ ./phyLinux init --help + + usage: phyLinux init [-h] [--verbose] [--no-init] [-o REPOREPO] [-b REPOREPO_BRANCH] [-x XML] [-u URL] [-p PLATFORM] [-r RELEASE] + + options: + -h, --help show this help message and exit + --verbose + --no-init dont execute init after fetch + -o REPOREPO Use repo tool from another url + -b REPOREPO_BRANCH Checkout different branch of repo tool + -x XML Use a local XML manifest + -u URL Manifest git url + -p PLATFORM Processor platform + -r RELEASE Release version + +After the execution of the *init* command, phyLinux will print a few important +notes as well as information for the next steps in the build process. + +.. _mickledore_phylinux-advanced-usage: + +Advanced Usage +-------------- + +phyLinux can be used to transport software states over any medium. The state of +the software is uniquely identified by *manifest.xml*. You can create a +manifest, send it to another place and recover the software state with + +.. code-block:: console + + host:~$ ./phyLinux init -x manifest.xml + +You can also create a *Git* repository containing your software states. The +*Git* repository needs to have branches other than master, as we reserved the +master branch for different usage. Use phyLinux to check out the states + +.. code-block:: console + + host:~$ ./phyLinux -u + +Using build-container +===================== + +.. warning:: + Currently, it is not possible to run the phyLinux script inside of a container. + After a complete init with the phyLinux script on your host machine, you can use a container for the build. + If you do not have phyLinux script running on your machine, please see phyLinux Documentation. + +There are various possibilities to run a build-container. Commonly used is +docker and podman, though we prefer podman as it does not need root privileges +to run. + +Installation +------------ + +How to install podman: https://podman.io +How to install docker: https://docs.docker.com/engine/install/ + +Available container +------------------- + +Right now we provide 4 different container based on Ubuntu LTS versions: +https://hub.docker.com/u/phybuilder + +- yocto-ubuntu-16.04 +- yocto-ubuntu-18.04 +- yocto-ubuntu-20.04 +- yocto-ubuntu-22.04 + +These containers can be run with podman or docker. With Yocto Project branch |yocto-codename| the container "yocto-ubuntu-20.04" is preferred. + +Download/Pull container +----------------------- + +.. code-block:: console + + host:~$ podman pull docker.io/phybuilder/yocto-ubuntu-20.04 + + OR + + host:~$ docker pull docker.io/phybuilder/yocto-ubuntu-20.04 + +By adding a tag at the end separated by a colon, you can also pull or run a special tagged container. + + podman pull docker.io/phybuilder/yocto-ubuntu-20.04:phy2 + +You can find all available tags in our duckerhub space: + +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-16.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-18.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-20.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-22.04/tags + +If you try to run a container, which is not pulled/downloaded, it will be pulled/downloaded automatically. + +You can have a look at all downloaded/pulled container with: + +.. code-block:: console + + $USERNAME@$HOSTNAME:~$ podman images + REPOSITORY TAG IMAGE ID CREATED SIZE + docker.io/phybuilder/yocto-ubuntu-22.04 latest d626178e448d 4 months ago 935 MB + docker.io/phybuilder/yocto-ubuntu-22.04 phy2 d626178e448d 4 months ago 935 MB + docker.io/phybuilder/yocto-ubuntu-20.04 phy2 e29a88b7172a 4 months ago 900 MB + docker.io/phybuilder/yocto-ubuntu-20.04 latest e29a88b7172a 4 months ago 900 MB + docker.io/phybuilder/yocto-ubuntu-18.04 phy1 14c9c3e477d4 7 months ago 567 MB + docker.io/phybuilder/yocto-ubuntu-18.04 latest 14c9c3e477d4 7 months ago 567 MB + docker.io/phybuilder/yocto-ubuntu-16.04 phy1 28c73e13ab4f 7 months ago 599 MB + docker.io/phybuilder/yocto-ubuntu-16.04 latest 28c73e13ab4f 7 months ago 599 MB + docker.io/phybuilder/yocto-ubuntu-22.04 phy1 5a0ef4b41935 8 months ago 627 MB + docker.io/phybuilder/yocto-ubuntu-20.04 phy1 b5a26a86c39f 8 months ago 680 MB + +Run container +------------- + +To run and use container for a Yocto build, first enter to your folder, where +you run phyLinux init before. Then start the container + +.. code-block:: console + + host:~$ podman run --rm=true -v /home:/home --userns=keep-id --workdir=$PWD -it docker.io/phybuilder/yocto-ubuntu-20.04 bash + +.. note:: + To run and use a container with docker, it is not that simple like with podman. + Therefore the container-user has to be defined and configured. + Furthermore forwarding of credentials is not given per default and has to be configured as well. + +Now your commandline should look something like that (where $USERNAME is the +user, who called "podman run" and the char/number code diffs every time a +container is started) + +.. code-block:: console + + $USERNAME@6593e2c7b8f6:~$ + +.. warning:: + If the given username is "root" you will not be able to run bitbake at all. + Please be sure, you run the container with your own user. + +Now you are ready to go on and starting the build. +To stop/close the container, just call + +.. code-block:: console + + $USERNAME@6593e2c7b8f6:~$ exit + +Working with Poky and Bitbake +============================= + +Start the Build +--------------- + +After you download all the metadata with phyLinux init, you have to set up the +shell environment variables. This needs to be done every time you open a new +shell for starting builds. We use the shell script provided by *Poky* in its +default configuration. From the root of your project directory type + +.. code-block:: console + + host:~$ source sources/poky/oe-init-build-env + +The abbreviation for the source command is a single dot + +.. code-block:: console + + host:~$ . sources/poky/oe-init-build-env + +The current working directory of the shell should change to *build/*. Before +building for the first time, you should take a look at the main configuration +file + +.. code-block:: console + + host:~$ vim conf/local.conf + +Your local modifications for the current build are stored here. Depending on +the SoC, you might need to accept license agreements. For example, to build the +image for Freescale/NXP processors you need to accept the GPU and VPU binary +license agreements. You have to uncomment the corresponding line + +.. code-block:: kconfig + + # Uncomment to accept NXP EULA # EULA can be found under + ../sources/meta-freescale/EULA ACCEPT_FSL_EULA = "1" + +Now you are ready to build your first image. We suggest starting with our +smaller non-graphical image *phytec-headless-image* to see if everything is +working correctly + +.. code-block:: console + + host:~$ bitbake phytec-headless-image + +The first compile process takes about 40 minutes on a modern Intel Core i7. All +subsequent builds will use the filled caches and should take about 3 minutes. + +Images +------ + +If everything worked, the images can be found under + +.. code-block:: console + + host:~$ cd deploy/images/ + +The easiest way to test your image is to configure your board for SD card boot +and to flash the build image to the SD card + +.. code-block:: console + + host:~$ sudo dd if=phytec-headless-image-.wic of=/dev/ bs=1M conv=fsync + +Here could be "sde", for example, depending on your system. Be +very careful when selecting the right drive! Selecting the wrong drive can +erase your hard drive! The parameter conv=fsync forces a data buffer to write +to the device before dd returns. + +After booting you can log in using a serial cable or over *ssh*. There is no +root password. That is because of the debug settings in *conf/local.conf*. If +you uncomment the line + +.. code-block:: kconfig + + #EXTRA_IMAGE_FEATURES = "debug-tweaks" + +the debug settings, like setting an empty root password, will not be applied. + +Accessing the Development States between Releases +------------------------------------------------- + +Special release manifests exist to give you access to the current development +states of the *Yocto* BSP. They will not be displayed in the phyLinux selection +menu but need to be selected manually. This can be done using the following +command line + +.. code-block:: console + + host:~$ ./phyLinux init -p master -r mickledore + +This will initialize a BSP that will track the latest development state. From +now on running + +.. code-block:: console + + host:~$ repo sync + +this folder will pull all the latest changes from our Git repositories. + +Inspect your Build Configuration +-------------------------------- + +*Poky* includes several tools to inspect your build layout. You can inspect the +commands of the layer tool + +.. code-block:: console + + host:~$ bitbake-layers + +It can, for example, be used to view in which layer a specific recipe gets +modified + +.. code-block:: console + + host:~$ bitbake-layers show-appends + +Before running a build you can also launch *Toaster* to be able to inspect the +build details with the Toaster web GUI + +.. code-block:: console + + host:~$ source toaster start + +Maybe you need to install some requirements, first + +.. code-block:: console + + host:~$ pip3 install -r + ../sources/poky/bitbake/toaster-requirements.txt + +You can then point your browser to *http://0.0.0.0:8000/* and continue working +with *Bitbake*. All build activity can be monitored and analyzed from this web +server. If you want to learn more about *Toaster*, look at +https://docs.yoctoproject.org/4.2.4/toaster-manual/index.html. +To shut down the *Toaster* web GUI again, execute + +.. code-block:: console + + host:~$ source toaster stop + +BSP Features of meta-phytec and meta-ampliphy +--------------------------------------------- + +*Buildinfo* +........... + +The *buildinfo* task is a feature in our recipes that prints instructions to +fetch the source code from the public repositories. So you do not have to look +into the recipes yourself. To see the instructions, e.g. for the *barebox* +package, execute + +.. code-block:: console + + host:~$ bitbake barebox -c buildinfo + +in your shell. This will print something like + +.. code-block:: + + (mini) HOWTO: Use a local git repository to build barebox: + + To get source code for this package and version (barebox-2022.02.0-phy1), execute + + $ mkdir -p ~/git + $ cd ~/git + $ git clone git://git.phytec.de/barebox barebox + $ cd ~/git/barebox + $ git switch --create v2022.02.0-phy1-local-development 7fe12e65d770f7e657e683849681f339a996418b + + You now have two possible workflows for your changes: + + 1. Work inside the git repository: + Copy and paste the following snippet to your "local.conf": + + SRC_URI:pn-barebox = "git://${HOME}/git/barebox;branch=${BRANCH}" + SRCREV:pn-barebox = "${AUTOREV}" + BRANCH:pn-barebox = "v2022.02.0-phy1-local-development" + + After that you can recompile and deploy the package with + + $ bitbake barebox -c compile + $ bitbake barebox -c deploy + + Note: You have to commit all your changes. Otherwise yocto doesn't pick them up! + + 2. Work and compile from the local working directory + To work and compile in an external source directory we provide the + externalsrc.bbclass. To use it, copy and paste the following snippet to your + "local.conf": + + INHERIT += "externalsrc" + EXTERNALSRC:pn-barebox = "${HOME}/git/barebox" + EXTERNALSRC_BUILD:pn-barebox = "${HOME}/git/barebox" + + Note: All the compiling is done in the EXTERNALSRC directory. Every time + you build an Image, the package will be recompiled and build. + + NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded. + NOTE: Writing buildhistory + +As you can see, everything is explained in the output. + +.. warning:: + + Using *externalsrc* breaks a lot of *Yocto's* internal dependency + mechanisms. It is not guaranteed that any changes to the source + directory are automatically picked up by the build process and + incorporated into the root filesystem or SD card image. You have to + always use *--force*. E.g. to compile *barebox* and redeploy it to + *deploy/images/* execute + + .. code-block:: console + + host:~$ bitbake barebox -c compile --force + host:~$ bitbake barebox -c deploy + +To update the SD card image with a new kernel or image first force the +compilation of it and then force a rebuild of the root filesystem. Use + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image -c rootfs --force + +Note that the build system is not modifying the external source directory. If +you want to apply all patches the *Yocto* recipe is carrying to the external +source directory, run the line + +.. code-block:: kconfig + + SRCTREECOVEREDTASKS="" BB_ENV_PASSTHROUGH_ADDITIONS="$BB_ENV_PASSTHROUGH_ADDITIONS SRCTREECOVEREDTASKS" bitbake -c patch + +.. _mickledore_bsp-customization: + +BSP Customization +----------------- + +To get you started with the BSP, we have summarized some basic tasks from the +*Yocto* official documentation. It describes how to add additional software to +the image, change the kernel and bootloader configuration, and integrate +patches for the kernel and bootloader. + +Minor modifications, such as adding software, are done in the file +*build/conf/local.conf*. There you can overwrite global configuration variables +and make small modifications to recipes. + +There are 2 ways to make major changes: + +1. Either create your own layer and use *bbappend* files. +2. Add everything to PHYTEC's Distro layer *meta-ampliphy*. + +Creating your own layer is described in the section Create your own Layer. + +Disable Qt Demo +............... + +By default, the BSP image *phytec-qt6demo-image* starts a Qt6 Demo application +on the attached display or monitor. If you want to stop the demo and use the +*Linux* framebuffer console behind it, connect to the target via serial cable +or *ssh* and execute the shell command + +.. code-block:: console + + target:~$ systemctl stop phytec-qtdemo.service + +This command stops the demo temporarily. To start it again, reboot the +board or execute + +.. code-block:: console + + target:~$ systemctl start phytec-qtdemo.service + +You can disable the service permanently, so it does not start on boot + +.. code-block:: console + + target:~$ systemctl disable phytec-qtdemo.service + +.. tip:: + + The last command only disables the service. It does not *stop* immediately. + To see the current status execute + + .. code-block:: console + + target:~$ systemctl status phytec-qtdemo.service + +If you want to disable the service by default, edit the file +*build/conf/local.conf* and add the following line + +.. code-block:: kconfig + + # file build/conf/local.conf + SYSTEMD_AUTO_ENABLE:pn-phytec-qtdemo = "disable" + +After that, rebuild the image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +Framebuffer Console +................... + +On boards with a display interface, the framebuffer console is enabled per +default. You can attach a USB keyboard and log in. To change the keyboard +layout from the English default to German, type + +.. code-block:: console + + target:~$ loadkeys /usr/share/keymaps/i386/qwertz/de-latin1.map.gz + +To detach the framebuffer console, run + +.. code-block:: console + + target:~$ echo 0 > sys/class/vtconsole/vtcon1/bind + +To completely deactivate the framebuffer console, disable the following kernel +configuration option + +.. code-block:: + + Device Drivers->Graphics Support->Support for framebuffer devices->Framebuffer Console Support + +More information can be found at: +https://www.kernel.org/doc/Documentation/fb/fbcon.txt + +Tools Provided in the Prebuild Image +.................................... + +RAM Benchmark +~~~~~~~~~~~~~ + +Performing RAM and cache performance tests can best be done by using *pmbw* +(Parallel Memory Bandwidth Benchmark/Measurement Tool). *Pmbw* runs several +assembly routines which all use different access patterns to the caches and RAM +of the SoC. Before running the test, make sure that you have about 2 MiB of +space left on the device for the log files. We also lower the level of the +benchmark to ask the kernel more aggressively for resources. The benchmark test +will take several hours. + +To start the test type + +.. code-block:: console + + target:~$ nice -n -2 pmbw + +Upon completion of the test run, the log file can be converted to a *gnuplot* +script with + +.. code-block:: console + + target:~$ stats2gnuplot stats.txt > run1.gnuplot + +Now you can transfer the file to the host machine and install any version of +*gnuplot* + +.. code-block:: console + + host:~$ sudo apt-get install gnuplot host:~$ gnuplot run1.gnuplot + +The generated *plots-.pdf* file contains all plots. To render single +plots as *png* files for any web output you can use *Ghostscript* + +.. code-block:: console + + host:~$ sudo apt-get install ghostscript + host:~$ gs -dNOPAUSE -dBATCH -sDEVICE=png16m -r150 -sOutputFile='page-%00d.png' plots-phyboard-wega-am335x-1.pdf + +Add Additional Software for the BSP Image +......................................... + +To add additional software to the image, look at the OpenEmbedded layer index: +https://layers.openembedded.org/layerindex/branch/mickledore/layers/ + +First, select the *Yocto* version of the BSP you have from the drop-down list in +the top left corner and click **Recipes**. Now you can search for a software +project name and find which layer it is in. In some cases, the program is in +*meta-openembedded*, *openembedded-core*, or *Poky* which means that the recipe +is already in your build tree. This section describes how to add additional +software when this is the case. If the package is in another layer, see the next +section. + +You can also search the list of available recipes + +.. code-block:: console + + host:~$ bitbake -s | grep # fill in program name, like in + host:~$ bitbake -s | grep lsof + +When the recipe for the program is already in the *Yocto* build, you can simply +add it by appending a configuration option to your file *build/conf/local.conf*. +The general syntax to add additional software to an image is + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " " + +For example, the line + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " ldd strace file lsof" + +installs some helper programs on the target image. + +.. warning:: + + The leading whitespace is essential for the append command. + +All configuration options in local.conf apply to all images. Consequently, the +tools are now included in both images phytec-headless-image and +phytec-qt6demo-image. + +Notes about Packages and Recipes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You are adding packages to the IMAGE_INSTALL variable. Those are not necessarily +equivalent to the recipes in your meta-layers. A recipe defines per default a +package with the same name. But a recipe can set the PACKAGES variable to +something different and is able to generate packages with arbitrary names. +Whenever you look for software, you have to search for the package name and, +strictly speaking, not for the recipe. In the worst case, you have to look at +all PACKAGES variables. A tool such as *Toaster* can be helpful in some cases. + +If you can not find your software in the layers provided in the folder +*sources*, see the next section to include another layer into the *Yocto* +build. + +References: `Yocto 4.2.4 Documentation - Customizing Yocto builds +`_ + +Add an Additional Layer +....................... + +This is a step-by-step guide on how to add another layer to your *Yocto* build +and install additional software from it. As an example, we include the network +security scanner *nmap* in the layer *meta-security*. First, you must locate the +layer on which the software is hosted. Check out the `OpenEmbedded MetaData +Index `_ +and guess a little bit. The network scanner *nmap* is in the *meta-security* +layer. See `meta-security on layers.openembedded.org +`_. +To integrate it into the *Yocto* build, you have to check out the repository and +then switch to the correct stable branch. Since the BSP is based on the *Yocto* +'sumo' build, you should try to use the 'sumo' branch in the layer, too. + +.. code-block:: console + + host:~$ cd sources + host:~$ git clone git://git.yoctoproject.org/meta-security + host:~$ cd meta-security + host:~$ git branch -r + +All available remote branches will show up. Usually there should be 'fido', +'jethro', 'krogoth', 'master', ... + +.. code-block:: console + + host:~$ git checkout mickledore + +Now we add the directory of the layer to the file *build/conf/bblayers.conf* by +appending the line + +.. code-block:: kconfig + + # file build/conf/bblayers.conf + BBLAYERS += "${BSPDIR}/sources/meta-security" + +to the end of the file. After that, you can check if the layer is available in +the build configuration by executing + +.. code-block:: console + + host:~$ bitbake-layers show-layers + +If there is an error like + +.. code-block:: + + ERROR: Layer 'security' depends on layer 'perl-layer', but this layer is not enabled in your configuration + +the layer that you want to add (here *meta-security*), depends on another layer, +which you need to enable first. E.g. the dependency required here is a layer in +*meta-openembedded* (in the PHYTEC BSP it is in the path +*sources/meta-openembedded/meta-perl/*). To enable it, add the following line to +*build/conf/bblayers.conf* + +.. code-block:: kconfig + + # file build/conf/bblayers.conf + BBLAYERS += "${BSPDIR}/sources/meta-openembedded/meta-perl" + +Now the command *bitbake-layers show-layers* should print a list of all layers +enabled including *meta-security* and *meta-perl*. After the layer is included, +you can install additional software from it as already described above. The +easiest way is to add the following line (here is the package *nmap*) + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " nmap" + +to your *build/conf/local.conf*. Do not forget to rebuild the image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +Create your own layer +.................................. + +Creating your layer should be one of the first tasks when customizing the BSP. +You have two basic options. You can either copy and rename our *meta-ampliphy*, +or you can create a new layer that will contain your changes. The better option +depends on your use case. *meta-ampliphy* is our example of how to create a +custom *Linux* distribution that will be updated in the future. If you want to +benefit from those changes and are, in general, satisfied with the userspace +configuration, it could be the best solution to create your own layer on top of +*Ampliphy*. If you need to rework a lot of information and only need the basic +hardware support from PHYTEC, it would be better to copy *meta-ampliphy*, rename +it, and adapt it to your needs. You can also have a look at the OpenEmbedded +layer index to find different distribution layers. If you just need to add your +own application to the image, create your own layer. + +In the following chapter, we have an embedded project called "racer" which we +will implement using our *Ampliphy Linux* distribution. First, we need to create +a new layer. + +*Yocto* provides a script for that. If you set up the BSP and the shell is +ready, type + +.. code-block:: console + + host:~$ bitbake-layers create-layer meta-racer + +Default options are fine for now. Move the layer to the source directory + +.. code-block:: console + + host:~$ mv meta-racer ../sources/ + +Create a *Git* repository in this layer to track your changes + +.. code-block:: console + + host:~$ cd ../sources/meta-racer + host:~$ git init && git add . && git commit -s + +Now you can add the layer directly to your build/conf/bblayers.conf + +.. code-block:: kconfig + + BBLAYERS += "${BSPDIR}/sources/meta-racer" + +or with a script provided by *Yocto* + +.. code-block:: console + + host:~$ bitbake-layers add-layer meta-racer + +Kernel and Bootloader Recipe and Version +........................................ + +First, you need to know which kernel and version are used for your target +machine. PHYTEC provides multiple kernel recipes *linux-mainline*, *linux-ti* +and *linux-imx*. The first one provides support for PHYTEC's i.MX 6 and AM335x +modules and is based on the *Linux* kernel stable releases from `kernel.org +`_. +The *Git* repositories URLs are: + +- *linux-mainline*: git://git.phytec.de/linux-mainline +- *linux-ti*: git://git.phytec.de/linux-ti +- *linux-imx:* git://git.phytec.de/linux-imx +- *barebox*: git://git.phytec.de/barebox +- *u-boot-imx*: git://git.phytec.de/u-boot-imx + +To find your kernel provider, execute the following command + +.. code-block:: console + + host:~$ bitbake virtual/kernel -e | grep "PREFERRED_PROVIDER_virtual/kernel" + +The command prints the value of the variable +*PREFERRED_PROVIDER_virtual/kernel*. The variable is used in the internal +*Yocto* build process to select the kernel recipe to use. The following lines +are different outputs you might see + +.. code-block:: kconfig + + PREFERRED_PROVIDER_virtual/kernel="linux-mainline" + PREFERRED_PROVIDER_virtual/kernel="linux-ti" + PREFERRED_PROVIDER_virtual/kernel="linux-imx" + +To see which version is used, execute *bitbake -s*. For example + +.. code-block:: console + + host:~$ bitbake -s | egrep -e "linux-mainline|linux-ti|linux-imx|barebox|u-boot-imx" + +The parameter *-s* prints the version of all recipes. The output contains the +recipe name on the left and the version on the right + +.. code-block:: + + barebox :2022.02.0-phy1-r7.0 + barebox-hosttools-native :2022.02.0-phy1-r7.0 + barebox-targettools :2022.02.0-phy1-r7.0 + linux-mainline :5.15.102-phy1-r0.0 + +As you can see, the recipe *linux-mainline* has version *5.15.102-phy1*. In +the PHYTEC's *linux-mainline* *Git* repository, you will find a corresponding +tag *v5.15.102-phy1*. The version of the *barebox* recipe is 2022.02.0-phy1. +On i.MX8M\* modules the output will contain *linux-imx* and *u-boot-imx*. + +.. _yocto-man-mickledore-kernel-and-bootloader-conf: + +Kernel and Bootloader Configuration +................................... + +The bootloader used by PHYTEC, *barebox*, uses the same build system as the +*Linux* kernel. Therefore, all commands in this section can be used to configure +the kernel and bootloader. To configure the kernel or bootloader, execute one of +the following commands + +.. code-block:: console + + host:~$ bitbake -c menuconfig virtual/kernel # Using the virtual provider name + host:~$ bitbake -c menuconfig linux-ti # Or use the recipe name directly + host:~$ bitbake -c menuconfig linux-mainline # Or use the recipe name directly (If you use an i.MX 6 or RK3288 Module) + host:~$ bitbake -c menuconfig linux-imx # Or use the recipe name directly (If you use an i.MX 8M*) + host:~$ bitbake -c menuconfig barebox # Or change the configuration of the bootloader + host:~$ bitbake -c menuconfig u-boot-imx # Or change the configuration of the bootloader (If you use an i.MX 8M*) + +After that, you can recompile and redeploy the kernel or bootloader + +.. code-block:: console + + host:~$ bitbake virtual/kernel -c compile # Or 'barebox' for the bootloader + host:~$ bitbake virtual/kernel -c deploy # Or 'barebox' for the bootloader + +Instead, you can also just rebuild the complete build output with + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # To update the kernel/bootloader, modules and the images + +In the last command, you can replace the image name with the name of an image of +your choice. The new images and binaries are in +*build/deploy/images//*. + +.. warning:: + + The build configuration is not permanent yet. Executing *bitbake + virtual/kernel -c clean* will remove everything. + +To make your changes permanent in the build system, you have to integrate your +configuration modifications into a layer. For the configuration you have two +options: + +- Include only a configuration fragment (a minimal *diff* between the + old and new configuration) +- Complete default configuration (*defconfig*) after your + modifications. + +Having a set of configuration fragments makes what was changed at which stage +more transparent. You can turn on and off the changes, you can manage +configurations for different situations and it helps when porting changes to new +kernel versions. You can also group changes together to reflect specific use +cases. A fully assembled kernel configuration will be deployed in the directory +*build/deploy/images/*. If you do not have any of those requirements, +it might be simpler to just manage a separate *defconfig* file. + +Add a Configuration Fragment to a Recipe +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The following steps can be used for both kernel and bootloader. Just replace the +recipe name *linux-mainline* in the commands with *linux-ti*, or *barebox* for +the bootloader. If you did not already take care of this, start with a clean +build. Otherwise, the diff of the configuration may be wrong + +.. code-block:: console + + host:~$ bitbake linux-mainline -c clean + host:~$ bitbake linux-mainline -c menuconfig + +Make your configuration changes in the menu and generate a config +fragment + +.. code-block:: console + + host:~$ bitbake linux-mainline -c diffconfig + +which prints the path of the written file + +.. code-block:: + + Config fragment has been dumped into: + /home//build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg + +All config changes are in the file *fragment.cfg* which should consist of only +some lines. The following example shows how to create a *bbappend* file and how +to add the necessary lines for the config fragment. You just have to adjust the +directories and names for the specific recipe: *linux-mainline*, *linux-ti*, +linux-imx, u-boot-imx, or *barebox*. + +.. code-block:: + + sources//recipes-kernel/linux/linux-mainline_%.bbappend # For the recipe linux-mainline + sources//recipes-kernel/linux/linux-ti_%.bbappend # For the recipe linux-ti + sources//recipes-kernel/linux/linux-imx_%.bbappend # For the recipe linux-imx + sources//recipes-bsp/barebox/barebox_%.bbappend # For the recipe barebox + sources//recipes-bsp/u-boot/u-boot-imx_%.bbappend # For the recipe u-boot-imx + +Replace the string *layer* with your own layer created as shown above (e.g. +*meta-racer*), or just use *meta-ampliphy*. To use *meta-ampliphy*, first, +create the directory for the config fragment and give it a new name (here +*enable-r8169.cfg*) and move the fragment to the layer. + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features + # copy the path from the output of *diffconfig* + host:~$ cp /home//build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg \ + sources/meta-ampliphy/recipes-kernel/linux/features/enable-r8169.cfg + +Then open the *bbappend* file (in this case +*sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend* ) with +your favorite editor and add the following lines + +.. code-block:: kconfig + + # contents of the file linux-mainline_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://enable-r8169.cfg \ + " + +.. warning:: + + Do not forget to use the correct *bbappend* filenames: *linux-ti_%.bbappend* + for the linux-ti recipe and *barebox_%.bbappend* for the bootloader in the + folder *recipes-bsp/barebox/* ! + +After saving the *bbappend* file, you have to rebuild the image. *Yocto* should +pick up the recipe changes automatically and generate a new image + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +Add a Complete Default Configuration (*defconfig*) to a Recipe +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This approach is similar to the one above, but instead of adding a fragment, a +*defconfig* is used. First, create the necessary folders in the layer you want +to use, either your own layer or *meta-ampliphy* + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features/ # For both linux-mainline and linux-ti + host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features/ # Or for the bootloader + +Then you have to create a suitable *defconfig* file. Make your configuration +changes using *menuconfig* and then save the *defconfig* file to the layer + +.. code-block:: console + + host:~$ bitbake linux-mainline -c menuconfig # Or use recipe name linux-ti or barebox + host:~$ bitbake linux-mainline -c savedefconfig # Create file 'defconfig.temp' in the work directory + +This will print the path to the generated file + +.. code-block:: + + Saving defconfig to ..../defconfig.temp + +Then, as above, copy the generated file to your layer, rename it to *defconfig*, +and add the following lines to the *bbappend* file (here +*sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend*) + +.. code-block:: kconfig + + # contents of the file linux-mainline_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://defconfig \ + " + +.. tip:: + + Do not forget to use the correct bbappend filenames: *linux-ti_%.bbappend* + for the linux-ti recipe and *barebox_%.bbappend* for the bootloader in the + folder *recipes-bsp/barebox/* ! + +After that, rebuild your image as the changes are picked up automatically + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +Patch the Kernel or Bootloader with *devtool* +............................................. + +*Apart from using the standard versions of kernel and bootloader which are +provided in the recipes, you can modify the source code or use our own +repositories to build your customized kernel.* + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| Standard workflow of the | Uses additional hard drive space | +| official *Yocto* documentation | as the sources get duplicated | ++----------------------------------+----------------------------------+ +| Toolchain does not have to | No optimal cache usage, build | +| recompile everything | overhead | ++----------------------------------+----------------------------------+ + +*Devtool* is a set of helper scripts to enhance the user workflow of *Yocto*. It +was integrated with version 1.8. It is available as soon as you set up your +shell environment. *Devtool* can be used to: + +- modify existing sources +- integrate software projects into your build setup +- build software and deploy software modifications to your target + +Here we will use *devtool* to patch the kernel. We use *linux-mainline* as an +example for the AM335x Kernel. The first command we use is *devtool modify - x + * + +.. code-block:: console + + host:~$ devtool modify -x linux-mainline linux-mainline + +*Devtool* will create a layer in *build/workspace* where you can see all +modifications done by *devtool* . It will extract the sources corresponding to +the recipe to the specified directory. A *bbappend* will be created in the +workspace directing the SRC_URI to this directory. Building an image with +*Bitbake* will now use the sources in this directory. Now you can modify lines +in the kernel + +.. code-block:: console + + host:~$ vim linux-mainline/arch/arm/boot/dts/am335x-phycore-som.dtsi + -> make a change + host:~$ bitbake phytec-qt6demo-image + +Your changes will now be recompiled and added to the image. If you want to store +your changes permanently, it is advisable to create a patch from the changes, +then store and backup only the patch. You can go into the *linux-mainline* +directory and create a patch using *Git*. How to create a patch is described in +:ref:`mickledore_temporary-method` and is the same for all methods. + +If you want to learn more about *devtool*, visit: + +`Yocto 4.2.4 - Devtool +`_ +or `Devtool Quick Reference +`_ + +.. _mickledore_temporary-method: + +Patch the Kernel or Bootloader using the "Temporary Method" +........................................................... + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| No overhead, no extra | Changes are easily overwritten | +| configuration | by *Yocto* (Everything is | +| | lost!!). | ++----------------------------------+----------------------------------+ +| Toolchain does not have to | | +| recompile everything | | ++----------------------------------+----------------------------------+ + +It is possible to alter the source code before *Bitbake* configures and compiles +the recipe. Use *Bitbake'* s *devshell* command to jump into the source +directory of the recipe. Here is the *barebox* recipe + +.. code-block:: console + + host:~$ bitbake barebox -c devshell # or linux-mainline, linux-ti, linux-imx, u-boot-imx + +After executing the command, a shell window opens. The current working directory +of the shell will be changed to the source directory of the recipe inside the +*tmp* folder. Here you can use your favorite editor, e.g. *vim*, *emacs*, or any +other graphical editor, to alter the source code. When you are finished, exit +the *devshell* by typing *exit* or hitting **CTRL-D**. + +After leaving the *devshell* you can recompile the package + +.. code-block:: console + + host:~$ bitbake barebox -c compile --force # or linux-mainline, linux-ti, linux-imx, u-boot-imx + +The extra argument '--force' is important because *Yocto* does not recognize +that the source code was changed. + +.. tip:: + + You cannot execute the *bitbake* command in the *devshell* . You have + to leave it first. + +If the build fails, execute the devshell command again and fix it. If the build +is successful, you can deploy the package and create a new SD card image + +.. code-block:: console + + host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox.bin + host:~$ bitbake phytec-headless-image # new WIC image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic + +.. warning:: + + If you execute a clean e.g *bitbake barebox -c clean* , or if *Yocto* fetches + the source code again, all your changes are lost!!! + + To avoid this, you can create a patch and add it to a *bbappend* file. It is + the same workflow as described in the section about changing the + configuration. + + You have to create the patch in the *devshell* if you use the temporary + method and in the subdirectory created by *devtool* if you used *devtool*. + +.. code-block:: console + + host:~$ bitbake barebox -c devshell # Or linux-mainline, linux-ti + host(devshell):~$ git status # Show changes files + host(devshell):~$ git add # Add a special file to the staging area + host(devshell):~$ git commit -m "important modification" # Creates a commit with a not so useful commit message + host(devshell):~$ git format-patch -1 -o ~/ # Creates a patch of the last commit and saves it in your home folder + /home//0001-important-modification.patch # Git prints the path of the written patch file + host(devshell):~$ exit + +After you have created the patch, you must create a *bbappend* file for it. The +locations for the three different recipes - *linux-mainline* , *linux-ti* , and +*barebox* - are + +.. code-block:: + + sources//recipes-kernel/linux/linux-mainline_%.bbappend # For the recipe linux-mainline + sources//recipes-kernel/linux/linux-ti_%.bbappend # For the recipe linux-ti + sources//recipes-kernel/linux/linux-imx_%.bbappend # For the recipe linux-imx + sources//recipes-bsp/barebox/barebox_%.bbappend # For the recipe barebox + sources//recipes-bsp/u-boot/u-boot-imx_%.bbappend # For the recipe u-boot-imx + +The following example is for the recipe *barebox*. You have to adjust the paths. +First, create the folders and move the patch into them. Then create the +*bbappend* file + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features # Or use your own layer instead of *meta-ampliphy* + host:~$ cp ~/0001-important-modification.patch sources/meta-ampliphy/recipes-bsp/barebox/features # copy patch + host:~$ touch sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend + +.. tip:: + + Pay attention to your current work directory. You have to execute the + commands in the BSP top-level directory. Not in the *build* directory! + +After that use your favorite editor to add the following snipped into the +*bbappend* file (here +*sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend*) + +.. code-block:: kconfig + + # contents of the file barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://0001-important-modification.patch \ + " + +Save the file and rebuild the *barebox* recipe with + +.. code-block:: console + + host:~$ bitbake barebox -c clean # Or linux-ti, linux-mainline, linux-imx, u-boot-imx + host:~$ bitbake barebox + +If the build is successful, you can rebuild the final image with + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +**Further Resources:** + +The *Yocto* Project has some documentation for software developers. Check the +'Kernel Development Manual' for more information about how to configure the +kernel. Please note that not all of the information from the *Yocto* manual can +be applied to the PHYTEC BSP as we use the classic kernel approach of *Yocto* +and most of the documentation assumes the *Yocto* kernel approach. + +- `Yocto - Kernel Development Manual + `_ +- `Yocto - Development Manual + `_ + +Working with the Kernel and Bootloader using SRC_URI in *local.conf* +.................................................................... + +*Here we present a third option to make kernel and bootloader changes. You have +external checkouts of the linux-mainline, linux-ti, or barebox Git +repositories. You will overwrite the URL of the source code fetcher, the +variable SRC_URI, to point to your local checkout instead of the remote +repositories.* + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| All changes are saved with | Many working directories in | +| *Git* | *build/tmp-\ | +| | glibc/work///* | ++----------------------------------+----------------------------------+ +| | You have to commit every change | +| | before recompiling | ++----------------------------------+----------------------------------+ +| | For each change, the toolchain | +| | compiles everything from scratch | +| | (avoidable with *ccache*) | ++----------------------------------+----------------------------------+ + +First, you need a local clone of the *Git* repository *barebox* or +kernel. If you do not have one, use the commands + +.. code-block:: console + + host:~$ mkdir ~/git + host:~$ cd ~/git + host:~$ git clone git://git.phytec.de/barebox + host:~$ cd barebox + host:~$ git switch --create v2022.02.0-phy remotes/origin/v2022.02.0-phy + +Add the following snippet to the file build/conf/local.conf + +.. code-block:: kconfig + + # Use your own path to the git repository + # NOTE: Branch name in variable "BRANCH_pn-barebox" should be the same as the + # branch which is used in the repository folder. Otherwise your commits won't be recognized later. + BRANCH:pn-barebox = "v2022.02.0-phy" + SRC_URI:pn-barebox = "git:///${HOME}/git/barebox;branch=${BRANCH}" + SRCREV:pn-barebox = "${AUTOREV}" + +You also have to set the correct BRANCH name in the file. Either you create your +own branch in the *Git* repository, or you use the default (here +"v2015.02.0-phy"). Now you should recompile *barebox* from your own source + +.. code-block:: console + + host:~$ bitbake barebox -c clean + host:~$ bitbake barebox -c compile + +The build should be successful because the source was not changed yet. + +You can alter the source in *~/git/barebox* or the default *defconfig* (e.g. +*~/git/barebox/arch/arm/configs/imx_v7_defconfig*). After you are satisfied with +your changes, you have to make a dummy commit for *Yocto*. If you do not, +*Yocto* will not notice that the source code was modified in your repository +folder (e.g. ~/git/barebox/) + +.. code-block:: console + + host:~$ git status # show modified files + host:~$ git diff # show changed lines + host:~$ git commit -a -m "dummy commit for yocto" # This command is important! + +Try to compile your new changes. *Yocto* will automatically notice that the +source code was changed and fetches and configures everything from scratch. + +.. code-block:: console + + host:~$ bitbake barebox -c compile + +If the build fails, go back to the source directory, fix the problem, and +recommit your changes. If the build was successful, you can deploy *barebox* and +even create a new SD card image. + +.. code-block:: console + + host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox-phyflex-imx6-2.bin + host:~$ bitbake phytec-headless-image # new sd-card image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic + +If you want to make additional changes, just make another commit in the +repository and rebuild *barebox* again. + +Add Existing Software with "Sustainable Method" +............................................... + +Now that you have created your own layer, you have a second option to add +existing software to existing image definitions. Our standard image is defined +in meta-ampliphy + +.. code-block:: + + meta-ampliphy/recipes-images/images/phytec-headless-image.bb + +In your layer, you can now modify the recipe with a *bbappend* without modifying +any BSP code + +.. code-block:: + + meta-racer/recipes-images/images/phytec-headless-image.bbappend + +The append will be parsed together with the base recipe. As a result, you can +easily overwrite all variables set in the base recipe, which is not always what +you want. If we want to include additional software, we need to append it to the +IMAGE_INSTALL variable + +.. code-block:: kconfig + + IMAGE_INSTALL:append = " rsync" + +Add Linux Firmware Files to the Root Filesystem +............................................... + +It is a common task to add an extra firmware file to your root filesystem into +*/lib/firmware/*. For example, WiFi adapters or PCIe Ethernet cards might need +proprietary firmware. As a solution, we use a *bbappend* in our layer. To create +the necessary folders, *bbappend* and copy the firmware file type + +.. code-block:: console + + host:~$ cd meta-racer # go into your layer + host:~$ mkdir -p recipes-kernel/linux-firmware/linux-firmware/ + host:~$ touch recipes-kernel/linux-firmware/linux-firmware_%.bbappend + host:~$ cp ~/example-firmware.bin recipes-kernel/linux-firmware/linux-firmware/ # adapt filename + +Then add the following content to the *bbappend* file and replace every +occurrence of *example-firmware.bin* with your firmware file name. + +.. code-block:: kconfig + + # file recipes-kernel/linux-firmware/linux-firmware_%.bbappend + + FILESEXTRAPATHS:prepend := "${THISDIR}/linux-firmware:" + SRC_URI += "file://example-firmware.bin" + + do_install:append () { + install -m 0644 ${WORKDIR}/example-firmware.bin ${D}/lib/firmware/example-firmware.bin + } + + # NOTE: Use "=+" instead of "+=". Otherwise file is placed into the linux-firmware package. + PACKAGES =+ "${PN}-example" + FILES:${PN}-example = "/lib/firmware/example-firmware.bin" + +Now try to build the linux-firmware recipe + +.. code-block:: console + + host:~$ . sources/poky/oe-init-build-env + host:~$ bitbake linux-firmware + +This should generate a new package *deploy/ipk/all/linux-firmware-example*. + +As the final step, you have to install the firmware package to your image. You +can do that in your *local.conf* or image recipe via + +.. code-block:: kconfig + + # file local.conf or image recipe + IMAGE_INSTALL += "linux-firmware-example" + +.. warning:: + + Ensure that you have adapted the package name *linux-firmware-example* with + the name you assigned in *linux-firmware_%.bbappend*. + +Change the *u-boot* Environment via *bbappend* Files +.................................................... + +All i.MX8M\* products use the u-boot bootloader. The u-boot environment can be +modified using the Temporary Method. In the *u-boot-imx* sources modify the +header file corresponding to the processor located in +*include/configs/phycore_imx8m\**. New environment variables should be added at +the end of *CONFIG_EXTRA_ENV_SETTINGS* + +.. code-block:: kconfig + + #define CONFIG_EXTRA_ENV_SETTINGS \ + [...] + PHYCORE_FITIMAGE_ENV_BOOTLOGIC \ + "newvariable=1\0" + +Commit the changes and and create the file *u-boot-imx_%.bbappend* in your layer +at */recipes-bsp/u-boot/u-boot-imx_%.bbappend* + +.. code-block:: kconfig + + # contents of the file u-boot-imx_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://0001-environment-addition.patch \ + " + +Change the *barebox* Environment via *bbappend* Files +..................................................... + +Since *BSP-Yocto-AM335x-16.2.0* and *BSP-Yocto-i.MX6-PD16.1.0*, the *barebox* +environment handling in *meta-phytec* has changed. Now it is possible to add, +change, and remove files in the *barebox* environment via the *Python* bitbake +task *do_env*. There are two *Python* functions to change the environment. Their +signatures are: + +- *env_add(d, *\ **filename as string**\ *, *\ **file content as string**\ *)*: + to add a new file or overwrite an existing file +- *env_rm(d, *\ **filename as string**\ *)*: to remove a file + +The first example of a *bbappend* file in the custom layer *meta-racer* shows +how to add a new non-volatile variable *linux.bootargs.fb* in the *barebox* +environment folder */env/nv/* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_add(d, "nv/linux.bootargs.fb", "imxdrm.legacyfb_depth=32\n") + } + +The next example shows how to replace the network configuration file +*/env/network/eth0* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_add(d, "network/eth0", + """#!/bin/sh + + # ip setting (static/dhcp) + ip=static + global.dhcp.vendor_id=barebox-${global.hostname} + + # static setup used if ip=static + ipaddr=192.168.178.5 + netmask=255.255.255.0 + gateway=192.168.178.1 + serverip=192.168.178.1 + """) + } + +In the above example, the *Python* multiline string syntax **""" text """** is +used to avoid adding multiple newline characters *\\n* into the recipe *Python* +code. The *Python* function *env_add* can add and overwrite environment files. + +The next example shows how to remove an already added environment file, for +example *,* */env/boot/mmc* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_rm(d, "boot/mmc") + } + +Debugging the Environment +~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you want to see all environment files that are added in the build process, +you can enable a debug flag in the *local.conf* + +.. code-block:: kconfig + + # file local.conf + ENV_VERBOSE = "1" + +After that, you have to rebuild the *barebox* recipe to see the debugging +output + +.. code-block:: console + + host:~$ bitbake barebox -c clean + host:~$ bitbake barebox -c configure + +The output of the last command looks like this + +.. code-block:: + + [...] + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/allow_color' content "false" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.base' content "consoleblank=0" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.fb' content "imxdrm.legacyfb_depth=32" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.rootfs' content "rootwait ro fsck.repair=yes" + +Changing the Environment (depending on Machines) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you need to apply some *barebox* environment modifications only to a single +or only a few machines, you can use *Bitbake'* s machine overwrite syntax. For +the machine overwrite syntax, you append a machine name or SoC name (such as +*mx6* , *ti33x,* or *rk3288* ) with an underscore to a variable or task + +.. code-block:: kconfig + + DEPENDS:remove:mx6 = "virtual/libgl" or + python do_env_append_phyboard-mira-imx6-4(). + +The next example adds the environment variables only if the MACHINE is set to +*phyboard-mira-imx6-4* + +.. code-block:: kconfig + + # file meta-phytec/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append:phyboard-mira-imx6-4() { + env_add(d, "nv/linux.bootargs.cma", "cma=64M\n") + } + +*Bitbake's* override syntax for variables is explained in more detail at: +https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-metadata.html#conditional-metadata + +Upgrading the *barebox* Environment from Previous BSP Releases +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Prior to BSP version *BSP-Yocto-AM335x-16.2.0* and *BSP-Yocto-i.MX6-PD16.1.0* , +*barebox* environment changes via *bbappend* file were done differently. For +example, the directory structure in your meta layer (here *meta-skeleton* ) may +have looked like this + +.. code-block:: console + + host:~$ tree -a sources/meta-skeleton/recipes-bsp/barebox/ + sources/meta-skeleton/recipes-bsp/barebox + ├── barebox + │ └── phyboard-wega-am335x-3 + │ ├── boardenv + │ │ └── .gitignore + │ └── machineenv + │ └── nv + │ └── linux.bootargs.cma + └── barebox_%.bbappend + +and the file *barebox_%.bbappend* contained + +.. code-block:: kconfig + + # file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:" + +In this example, all environment changes from the directory *boardenv* in the +layer *meta-phytec* are ignored and the file *nv/linux.bootargs.cma* is added. +For the new handling of the *barebox* environment, you use the *Python* +functions *env_add* and *env_rm* in the *Python* task *do_env*. Now the above +example translates to a single *Python* function in the file +*barebox_%.bbappend* that looks like + +.. code-block:: kconfig + + # file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:" + python do_env:append() { + # Removing files (previously boardenv) + env_rm(d, "config-expansions") + # Adding new files (previously machineenv) + env_add(d, "nv/linux.bootargs.cma", "cma=64M\n") + } + +.. _mickledore_changing-net-config: + +Changing the Network Configuration +.................................. + +To tweak IP addresses, routes, and gateways at runtime you can use the tools +*ifconfig* and *ip* . Some examples + +.. code-block:: console + + target:~$ ip addr # Show all network interfaces + target:~$ ip route # Show all routes + target:~$ ip addr add 192.168.178.11/24 dev eth0 # Add static ip and route to interface eth0 + target:~$ ip route add default via 192.168.178.1 dev eth0 # Add default gateway 192.168.178.1 + target:~$ ip addr del 192.168.178.11/24 dev eth0 # Remove static ip address from interface eth0 + +The network configuration is managed by *systemd-networkd* . To query the +current status use + +.. code-block:: console + + target:~$ networkctl status + target:~$ networkctl list + +The network daemon reads its configuration from the directories +*/etc/systemd/network/* , */run/systemd/network/* , and */lib/systemd/network/* +(from higher to lower priority). A sample configuration in +*/lib/systemd/network/10-eth0.network* looks like this + +.. code-block:: kconfig + + # file /lib/systemd/network/10-eth0.network + [Match] + Name=eth0 + + [Network] + Address=192.168.3.11/24 + Gateway=192.168.3.10 + +These files *\*.network* replace */etc/network/interfaces* from other +distributions. You can either edit the file *10-eth0.network* in-place or copy +it to */etc/systemd/network/* and make your changes there. After changing a file +you must restart the daemon to apply your changes + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +To see the syslog message of the network daemon, use + +.. code-block:: console + + target:~$ journalctl --unit=systemd-networkd.service + +To modify the network configuration at build time, look at the recipe +*sources/meta-ampliphy/recipes-core/systemd/systemd-machine-units.bb* +and the interface files in the folder +*meta-ampliphy/recipes-core/systemd/systemd-machine-units/* where the static IP +address configuration for *eth0* (and optionally *eth1*) is done. + +For more information, see https://wiki.archlinux.org/title/Systemd-networkd +and https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html. + +Changing the Wireless Network Configuration +........................................... + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- First set the correct regulatory domain for your country + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +- Set up the wireless interface + +.. code-block:: console + + target:~$ ip link # list all interfaces. Search for wlan* + target:~$ ip link set up dev wlan0 + +- Now you can scan for available networks + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for *WEP*, *WPA*, and +*WPA2* called *wpa_supplicant* for an encrypted connection. + +- To do so, add the network credentials to the file + */etc/wpa_supplicant.conf* + +.. code-block:: kconfig + + Confluence country=DE network={ ssid="" proto=WPA2 psk="" } + +- Now a connection can be established + +.. code-block:: console + + target:~$ wpa_supplicant -Dnl80211 -c/etc/wpa_supplicant.conf -iwlan0 -B + +This should result in the following output + +.. code-block:: kconfig + + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see the section :ref:`mickledore_changing-net-config`. + +- First, create the directory + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +- Then add the following configuration snippet in + */etc/systemd/network/10-wlan0.network* + +.. code-block:: kconfig + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +- Now, restart the network daemon so that the configuration takes effect + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Creating a WLAN Access Point +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This section provides a basic access point (AP) configuration for a +secured *WPA2* network. + +Find the name of the WLAN interface with + +.. code-block:: console + + target:~$ ip link + +Edit the configuration in */etc/hostapd.conf*. It is strongly dependent on +the use case. The following shows an example + +.. code-block:: kconfig + + # file /etc/hostapd.conf + interface=wlan0 + driver=nl80211 + ieee80211d=1 + country_code=DE + hw_mode=g + ieee80211n=1 + ssid=Test-Wifi + channel=2 + wpa=2 + wpa_passphrase=12345678 + wpa_key_mgmt=WPA-PSK + wpa_pairwise=CCMP + +Set up and start the DHCP server for the network interface *wlan0* via +*systemd-networkd* + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + target:~$ vi /etc/systemd/network/10-wlan0.network + +Insert the following text into the file + +.. code-block:: kconfig + + [Match] + Name=wlan0 + + [Network] + Address=192.168.0.1/24 + DHCPServer=yes + + [DHCPServer] + EmitDNS=yes + target:~$ systemctl restart systemd-networkd + target:~$ systemctl status systemd-networkd -l # check status and see errors + +Start the userspace daemon *hostapd* + +.. code-block:: console + + target:~$ systemctl start hostapd + target:~$ systemctl status hostapd -l # check for errors + +Now, you should see the WLAN network *Test-Wifi* on your terminal device +(laptop, smartphone, etc.). + +If there are problems with the access point, you can either check the log +messages with + +.. code-block:: console + + target:~$ journalctl --unit=hostapd + +or start the daemon in debugging mode from the command line + +.. code-block:: console + + target:~$ systemctl stop hostapd + target:~$ hostapd -d /etc/hostapd.conf -P /var/run/hostapd.pid + +You should see + +.. code-block:: + + ... + wlan0: interface state UNINITIALIZED->ENABLED + wlan0: AP-ENABLED + +Further information about AP settings and the userspace daemon +*hostapd* can be found at + +.. code-block:: + + https://wireless.wiki.kernel.org/en/users/documentation/hostapd + https://w1.fi/hostapd/ + +phyCORE-i.MX 6UL/ULL Bluetooth +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Special consideration must be paid when working with any Bluetooth on a +phyCORE-i.MX 6UL/ULL. For further information, please check `L-844e.A5 i.MX +6UL/ULL BSP Manual - Bluetooth +`_. + +Add OpenCV Libraries and Examples +................................. + +*OpenCV* (Opensource Computer Vision https://opencv.org/) is an open-source +library for computer vision applications. + +To install the libraries and examples edit the file *conf/local.conf* in the +*Yocto* build system and add + +.. code-block:: kconfig + + # file conf/local.conf + # Installing OpenCV libraries and examples + LICENSE_FLAGS_ACCEPTED += "commercial_libav" + LICENSE_FLAGS_ACCEPTED += "commercial_x264" + IMAGE_INSTALL:append = " \ + opencv \ + opencv-samples \ + libopencv-calib3d2.4 \ + libopencv-contrib2.4 \ + libopencv-core2.4 \ + libopencv-flann2.4 \ + libopencv-gpu2.4 \ + libopencv-highgui2.4 \ + libopencv-imgproc2.4 \ + libopencv-legacy2.4 \ + libopencv-ml2.4 \ + libopencv-nonfree2.4 \ + libopencv-objdetect2.4 \ + libopencv-ocl2.4 \ + libopencv-photo2.4 \ + libopencv-stitching2.4 \ + libopencv-superres2.4 \ + libopencv-video2.4 \ + libopencv-videostab2.4 \ + " + +Then rebuild your image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +.. tip:: + + Most examples do not work out of the box, because they depend on the *GTK* + graphics library. The BSP only supports *Qt6* . + +Add Minimal PHP web runtime with *lightpd* +.......................................... + +This is one example of how to add a small runtime for PHP applications and a web +server on your target. Lighttpd can be used together with the PHP command line +tool over cgi. This solution weights only 5.5 MiB of disk storage. It is already +preconfigured in meta-ampliphy. Just modify the build configuration to install +it on the image + +.. code-block:: kconfig + + # file conf/local.conf + # install lighttpd with php cgi module + IMAGE_INSTALL:append = " lighttpd" + +After booting the image, you should find the example web content in */www/pages* +. For testing php, you can delete the *index.html* and replace it with a +*index.php* file + +.. code-block:: html + + + + PHP-Test + + + + + + +On your host, you can point your browser to the board's IP, (e.g. 192.168.3.11) +and the phpinfo should show up. + +Common Tasks +------------ + +Debugging a User Space Application +.................................. + +The phytec-qt6demo-image can be cross-debugged without any change. For +cross-debugging, you just have to match the host sysroot with the image in use. +So you need to create a toolchain for your image + +.. code-block:: console + + host:~$ bitbake -c populate_sdk phytec-qt6demo-image + +Additionally, if you want to have full debug and backtrace capabilities for all +programs and libraries in the image, you could add + +.. code-block:: kconfig + + DEBUG_BUILD = "1" + +to the ``conf/local.conf``. This is not necessary in all cases. The compiler +options will then be switched from FULL_OPTIMIZATION to DEBUG_OPTIMIZATION. Look +at the *Poky* source code for the default assignment of DEBUG_OPTIMIZATION. + +To start a cross debug session, install the SDK as mentioned previously, source +the SDK environment, and run *Qt Creator* in the same shell. If you do not use +*Qt Creator*, you can directly call the arm-<..>-gdb debugger instead which +should be in your path after sourcing the environment script. + +If you work with *Qt Creator*, have a look at the appropriate documentation +delivered with your product (either QuickStart or Application Guide) for +information on how to set up the toolchain. + +When starting the debugger with your userspace application you will get a +SIGILL, an illegal instruction from the *libcrypto*. *Openssl* probes for the +system capabilities by trapping illegal instructions, which will trigger *GDB*. +You can ignore this and hit **Continue** (c command). You can permanently ignore +this stop by adding + +.. code-block:: kconfig + + handle SIGILL nostop + +to your *GDB* startup script or in the *Qt Creator GDB* configuration panel. +Secondly, you might need to disable a security feature by adding + +.. code-block:: kconfig + + set auto-load safe-path / + +to the same startup script, which will enable the automatic loading of libraries +from any location. + +If you need to have native debugging, you might want to install the debug +symbols on the target. You can do this by adding the following line to your +*conf/local.conf* + +.. code-block:: kconfig + + EXTRA_IMAGE_FEATURES += "dbg-pkgs" + +For cross-debugging, this is not required as the debug symbols will be loaded +from the host side and the dbg-pkgs are included in the SDK of your image +anyway. + +.. _mickledore_gen-source-mirrors: + +Generating Source Mirrors, working Offline +.......................................... + +Modify your *site.conf* (or *local.conf* if you do not use a *site.conf* ) as +follows + +.. code-block:: kconfig + + #DL_DIR ?= "" don't set it! It will default to a directory inside /build + SOURCE_MIRROR_URL = "file:///home/share/yocto_downloads/" + INHERIT += "own-mirrors" + BB_GENERATE_MIRROR_TARBALLS = "1" + +Now run + +.. code-block:: console + + host:~$ bitbake --runall=fetch + +for all images and for all machines you want to provide sources for. This will +create all the necessary *tar* archives. We can remove all SCM subfolders, as +they are duplicated with the tarballs + +.. code-block:: console + + host:~$ rm -rf build/download/git2/ + etc... + +Please consider that we used a local source mirror for generating the dl_dir. +Because of that, some archives will be linked locally. + +First, we need to copy all files, resolving symbolic links into the new mirror +directory + +.. code-block:: console + + host:~$ rsync -vaL ${TOPDIR}/../src_mirror/ + +Now we clean the */build* directory by deleting everything except */build/conf/* +but including */build/conf/sanity*. We change *site.conf* as follows + +.. code-block:: kconfig + + SOURCE_MIRROR_URL = "file://${TOPDIR}/../src_mirror" + INHERIT += "own-mirrors" + BB_NO_NETWORK = "1" + SCONF_VERSION = "1" + +The BSP directory can now be compressed with + +.. code-block:: console + + host:~$ tar cfJ .tar.xz + +where filename and folder should be the full BSP Name. + +Compiling on the Target +....................... + +To your *local.conf* add + +.. code-block:: kconfig + + IMAGE_FEATURES:append = " tools-sdk dev-pkgs" + +Different Toolchains +.................... + +There are several ways to create a toolchain installer in *Poky*. One option is +to run + +.. code-block:: console + + host:~$ bitbake meta-toolchain + +This will generate a toolchain installer in *build/deploy/sdk* which can be used +for cross-compiling of target applications. However, the installer does not +include libraries added to your image, so it is a bare *GCC* compiler only. This +is suited for bootloader and kernel development. + +Another you can run is + +.. code-block:: console + + host:~$ bitbake -c populate_sdk + +This will generate a toolchain installer containing all necessary development +packages of the software installed on the root filesystem of the target. This +installer can be handed over to the user space application development team and +includes all necessary parts to develop an application. If the image contains +the *QT* libraries, all of those will be available in the installer too. + +The third option is to create the ADT (Application Development Toolkit) +installer. It will contain the cross-toolchain and some tools to aid the +software developers, for example, an *Eclipse* plugin and a *QEMU* target +simulator. + +.. code-block:: console + + host:~$ bitbake adt-installer + +The ADT is untested for our BSP at the moment. + +Using the SDK +~~~~~~~~~~~~~ + +After generating the SDK with + +.. code-block:: console + + host:~$ source sources/poky/oe-init-build-env + host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image + +run the generated binary with + +.. code-block:: console + + host:~$ deploy/sdk/ampliphy-glibc-x86_64-phytec-qt6demo-image-cortexa9hf-vfp-neon-toolchain-i.MX6-PD15.3-rc.sh + Enter target directory for SDK (default: /opt/ampliphy/i.MX6-PD15.3-rc): + You are about to install the SDK to "/opt/ampliphy/i.MX6-PD15.3-rc". Proceed[Y/n]? + Extracting SDK...done + Setting it up...done + SDK has been successfully set up and is ready to be used. + +You can activate the toolchain for your shell by sourcing the file +*environment-setup* in the toolchain directory + +.. code-block:: console + + host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + +Then the necessary tools like the cross compiler and linker are in your PATH. To +compile a simple *C* program, use + +.. code-block:: console + + host:~$ $CC main.c -o main + +The environment variable $CC contains the path to the ARM cross compiler and +other compiler arguments needed like *-march* , *-sysroot* and *--mfloat-abi*. + +.. tip:: + + You cannot compile programs only with the compiler name like + + .. code-block:: console + + host:~$ arm-phytec-linux-gnueabi-gcc main.c -o main + + It will fail in many cases. Always use *CC*, CFLAGS, LDFLAGS, and so on. + +For convenience, the *environment-setup* exports other environment variables +like CXX, LD, SDKTARGETSYSROOT. + +A simple makefile compiling a *C* and *C++* program may look like this + +.. code-block:: kconfig + + # Makefile + TARGETS=c-program cpp-program + + all: $(TARGETS) + + c-program: c-program.c + $(CC) $(CFLAGS) $(LDFLAGS) $< -o $@ + + cpp-program: cpp-program.cpp + $(CXX) $(CXXFLAGS) $(LDFLAGS) $< -o $@ + + .PHONY: clean + clean: + rm -f $(TARGETS) + +To compile for the target, just source the toolchain in your shell before +executing make + +.. code-block:: console + + host:~$ make # Compiling with host CC, CXX for host architecture + host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + host:~$ make # Compiling with target CC, CXX for target architecture + +If you need to specify additionally included directories in the sysroot of the +toolchain, you can use an '=' sign in the *-I* argument like + +.. code-block:: kconfig + + -I=/usr/include/SDL + +*GCC* replaces it by the sysroot path (here +*/opt/ampliphy/i.MX6-PD15.3-rc/sysroots/cortexa9hf-vfp-neon-phytec-linux-gnueabi/*). +See the main page of *GCC* for more information. + +.. tip:: + + The variables $CFLAGS and $CXXFLAGS contain the compiler debug flag '-g' by + default. This includes debugging information in the binary and making it + bigger. Those should be removed from the production image. If you create a + *Bitbake* recipe, the default behavior is to turn on '-g' too. The debugging + symbols are used in the SDK rootfs to be able to get debugging information + when invoking *GDB* from the host. Before installing the package to the + target rootfs, *Bitbake* will invoke *strip* on the program which removes the + debugging symbols. By default, they are not found nor required on the target + root filesystem + +Using the SDK with GNU Autotools +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +*Yocto* SDK is a straightforward tool for a project that uses the *GNU +Autotools*. The traditional compile steps for the host are usually + +.. code-block:: console + + host:~$ ./autogen.sh # maybe not needed + host:~$ ./configure + host:~$ make + host:~$ make install DESTDIR=$PWD/build/ + +The commands to compile for the target machine with the *Yocto* SDK are quite +similar. The following commands assume that the SDK was unpacked to the +directory */opt/phytec-ampliphy/i.MX6-PD15.3.0/* (adapt the path as needed) + +.. code-block:: console + + host:~$ source /opt/phytec-ampliphy/i.MX6-PD15.3.0/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + host:~$ ./autogen.sh # maybe not needed + host:~$ ./configure ${CONFIGURE_FLAGS} + host:~$ make + host:~$ make install DESTDIR=$PWD/build/ + +Refer to the official *Yocto* documentation for more information: +https://docs.yoctoproject.org/4.2.4/singleindex.html#autotools-based-projects + +Working with Kernel Modules +........................... + +You will come to the point where you either need to set some options for a +kernel module or you want to blacklist a module. Those things are handled by +*udev* and go into *\*.conf* files in + +.. code-block:: + + /etc/modprobe.d/\*.conf. + +If you want to specify an option at build time, there are three relevant +variables. If you just want to autoload a module that has no autoload +capabilities, add it to + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + +either in the kernel recipe or in the global variable scope. If you need to +specify options for a module, you can do so with + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + KERNEL_MODULE_PROBECONF += "your-module" + module_conf_your-module = "options your-module parametername=parametervalue" + +if you want to blacklist a module from autoloading, you can do it intuitively +with + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + KERNEL_MODULE_PROBECONF += "your-module" + module_conf_your-module = "blacklist your-module" + +Working with *udev* +................... + +Udev (Linux dynamic device management) is a system daemon that handles dynamic +device management in /dev. It is controlled by *udev* \ rules that are located +in */etc/udev/rules.d* (sysadmin configuration space) and\ */lib/udev/rules.d/* +(vendor-provided). Here is an example of an *udev* \ rule file + +.. code-block:: kconfig + + # file /etc/udev/rules.d/touchscreen.rules + # Create a symlink to any touchscreen input device + SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="input:*-e0*,3,*a0,1,*18,*", SYMLINK+="input/touchscreen0" + SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="ads7846", SYMLINK+="input/touchscreen0" + +See https://www.freedesktop.org/software/systemd/man/latest/udev.html for more details +about the syntax and usage. To get the list of attributes for a specific device +that can be used in an *udev* rule you can use the *udevadm info* tool. It +prints all existing attributes of the device node and its parents. The key-value +pairs from the output can be copied and pasted into a rule file. Some examples + +.. code-block:: console + + target:~$ udevadm info -a /dev/mmcblk0 + target:~$ udevadm info -a /dev/v4l-subdev25 + target:~$ udevadm info -a -p /sys/class/net/eth0 + +After changing an *udev* rule, you have to notify the daemon. Otherwise, your +changes are not reflected. Use the following command + +.. code-block:: console + + target:~$ udevadm control --reload-rules + +While developing *udev* rules you should monitor the events in order to see when +devices are attached or unattached to the system. Use + +.. code-block:: console + + target:~$ udevadm monitor + +Furthermore, it is very useful to monitor the system log in another shell, +especially if the rule executes external scripts. Execute + +.. code-block:: console + + target:~$ journalctl -f + +.. tip:: + + You cannot start daemons or heavy scripts in a *RUN* attribute. See + https://www.freedesktop.org/software/systemd/man/latest/udev.html#RUN%7Btype%7D . + + This can only be used for very short-running foreground tasks. Running an + event process for a long period of time may block all further events for this + or a dependent device. Starting daemons or other long-running processes is + not appropriate for *udev*; the forked processes, detached or not, will be + unconditionally killed after the event handling has finished. You can use the + special attribute *ENV{SYSTEMD_WANTS}="service-name.service"* and a + *systemd*\ service instead. + + See + https://unix.stackexchange.com/questions/63232/what-is-the-correct-way-to-write-a-udev-rule-to-stop-a-service-under-systemd. + +Troubleshooting +=============== + +Setscene Task Warning +--------------------- + +This warning occurs when the Yocto cache is in a dirty state. + +.. code-block:: + + WARNING: Setscene task X ([...]) failed with exit code '1' - real task + +You should avoid canceling the build process or if you have to, press Ctrl-C +once and wait until the build process has stopped. To remove all these warnings +just clean the sstate cache and remove the build folders. + +.. code-block:: console + + host:~$ bitbake phytec-headless-image -c cleansstate && rm -rf tmp deploy/ipk + +Yocto Documentation +=================== + +The most important piece of documentation for a BSP user is probably the +developer manual. +https://docs.yoctoproject.org/4.2.4/dev-manual/index.html + +The chapter about common tasks is a good starting point. +https://docs.yoctoproject.org/4.2.4/dev-manual/layers.html#understanding-and-creating-layers + +The complete documentation is available on one single HTML page, which is good +for searching for a feature or a variable name. +https://docs.yoctoproject.org/4.2.4/singleindex.html diff --git a/previews/271/zh_CN/_sources/yocto/scarthgap.rst.txt b/previews/271/zh_CN/_sources/yocto/scarthgap.rst.txt new file mode 100644 index 000000000..52f4e7472 --- /dev/null +++ b/previews/271/zh_CN/_sources/yocto/scarthgap.rst.txt @@ -0,0 +1,3131 @@ +.. Download links +.. _`static-pdf-dl`: ../_static/scarthgap.pdf + +.. Yocto +.. |yocto-codename| replace:: Scarthgap +.. |yocto-ref-manual| replace:: Yocto Reference Manual +.. |distro| replace:: ampliphy-vendor-xwayland + +.. only:: html + + Documentation in pdf format: `Download `_ + ++-------------------------------------------------------------+ +| |yocto-ref-manual| | ++=======================+=====================================+ +| Document Title | |yocto-ref-manual| |yocto-codename| | ++-----------------------+-------------------------------------+ +| Document Type | Yocto Manual | ++-----------------------+-------------------------------------+ +| Release Date | XXXX/XX/XX | ++-----------------------+-------------------------------------+ +| Is Branch of | |yocto-ref-manual| | ++-----------------------+-------------------------------------+ + ++-------------------------------------+------------------+------------------+------------+ +| Compatible BSPs | BSP Release Type | BSP Release Date | BSP Status | ++=====================================+==================+==================+============+ +| BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.0 | Major | 2024-04-02 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 | Minor | 2024-04-09 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 | Minor | 2024-06-26 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX8MP-PD24.1.0 | Major | 2024-11-07 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-NXP-i.MX93-PD24.2.0 | Major | 2024-10-08 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-i.MX6UL-PD24.1.0 | Major | 2024-07-19 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM62Ax-PD24.1.0 | Major | 2024-06-27 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM62x-PD24.1.0 | Major | 2024-06-27 | released | ++-------------------------------------+------------------+------------------+------------+ +| BSP-Yocto-Ampliphy-AM64x-PD24.1.0 | Major | 2024-06-27 | released | ++-------------------------------------+------------------+------------------+------------+ + + +This manual applies to all |yocto-codename| based PHYTEC releases. + +.. _yocto-man-scarthgap: + +The Yocto Project +================= + +PHYTEC Documentation +-------------------- + +PHYTEC will provide a variety of hardware and software documentation for all of +our products. This includes any or all of the following: + +- **QS Guide**: A short guide on how to set up and boot a phyCORE board along + with brief information on building a BSP, the device tree, and accessing + peripherals. +- **Hardware Manual**: A detailed description of the System on Module and + accompanying carrier board. +- **Yocto Guide**: A comprehensive guide for the Yocto version the phyCORE + uses. This guide contains an overview of Yocto; introducing, installing, and + customizing the PHYTEC BSP; how to work with programs like Poky and Bitbake; + and much more. +- **BSP Manual**: A manual specific to the BSP version of the phyCORE. + Information such as how to build the BSP, booting, updating software, device + tree, and accessing peripherals can be found here. +- **Development Environment Guide**: This guide shows how to work with the + Virtual Machine (VM) Host PHYTEC has developed and prepared to run various + Development Environments. There are detailed step-by-step instructions for + Eclipse and Qt Creator, which are included in the VM. There are instructions + for running demo projects for these programs on a phyCORE product as well. + Information on how to build a Linux host PC yourself is also a part of this + guide. +- **Pin Muxing Table**: phyCORE SOMs have an accompanying pin table (in Excel + format). This table will show the complete default signal path, from + processor to carrier board. The default device tree muxing option will also + be included. This gives a developer all the information needed in one + location to make muxing changes and design options when developing a + specialized carrier board or adapting a PHYTEC phyCORE SOM to an application. + +On top of these standard manuals and guides, PHYTEC will also provide Product +Change Notifications, Application Notes, and Technical Notes. These will be done +on a case-by-case basis. Most of the documentation can be found in the +applicable download page of our products. + +Yocto Introduction +------------------ + +Yocto is the smallest SI metric system prefix. Like milli equates to ``m = +10^-3``, and so is yocto ``y = 10^-24``. Yocto is also a project working group +of the `Linux Foundation `_ and therefore +backed up by several major companies in the field. On the `Yocto Project website +`_ you can read the official introduction: + + The Yocto Project is an open-source collaboration project that provides + templates, tools, and methods to help you create custom Linux-based systems + for embedded products regardless of the hardware architecture. It was founded + in 2010 as a collaboration among many hardware manufacturers, open-source + operating systems vendors, and electronics companies to bring some order to + the chaos of embedded Linux development. + +As said, the project wants to provide toolsets for embedded developers. It +builds on top of the long-lasting `OpenEmbedded +`_ project. It is not a Linux distribution. But +it contains the tools to create a Linux distribution specially fitted to the +product requirements. The most important step in bringing order to the set of +tools is to define a common versioning scheme and a reference system. All +subprojects have then to comply with the reference system and have to comply +with the versioning scheme. + +The release process is similar to the `Linux kernel `_. +Yocto increases its version number every six months and gives the release a +codename. The release list can be found here: +https://wiki.yoctoproject.org/wiki/Releases + +Core Components +--------------- + +The most important tools or subprojects of the *Yocto* Project are: + +- Bitbake: build engine, a task scheduler like make, interprets metadata +- OpenEmbedded-Core, a set of base layers, containing metadata of software, no + sources +- Yocto kernel + + - Optimized for embedded devices + - Includes many subprojects: rt-kernel, vendor patches + - The infrastructure provided by Wind River + - Alternative: classic kernel build → we use it to integrate our kernel into + *Yocto* + +- *Yocto* Reference BSP: *beagleboneblack*, *minnow max* +- *Poky*, the reference system, a collection of projects and tools, used to + bootstrap a new distribution based on *Yocto* + +Vocabulary +---------- + +Recipes +....... + +Recipes contain information about the software project (author, homepage, and +license). A recipe is versioned, defines dependencies, contains the URL of the +source code, and describes how to fetch, configure, and compile the sources. It +describes how to package the software, e.g. into different .deb packages, which +then contain the installation path. Recipes are basically written in *Bitbake's* +own programming language, which has a simple syntax. However, a recipe can +contain *Python* as well as a bash code. + +Classes +....... + +Classes combine functionality used inside recipes into reusable blocks. + +Layers +...... + +A layer is a collection of recipes, classes, and configuration metadata. +A layer can depend on other layers and can be included or excluded one +by one. It encapsulates a specific functionality and fulfills a specific +purpose. Each layer falls into a specific category: + +- Base +- Machine (BSP) +- Software +- Distribution +- Miscellaneous + +*Yocto's* versioning scheme is reflected in every layer as version branches. For +each *Yocto* version, every layer has a named branch in its *Git* repository. +You can add one or many layers of each category in your build. + +A collection of OpenEmbedded layers can be found here. The search function is +very helpful to see if a software package can be retrieved and integrated +easily: https://layers.openembedded.org/layerindex/branch/scarthgap/layers/ + +Machine +....... + +Machines are configuration variables that describe the aspects of the target +hardware. + +Distribution (Distro) +..................... + +Distribution describes the software configuration and comes with a set of +software features. + +Poky +---- + +*Poky* is the reference system to define *Yocto* Project compatibility. It +combines several subprojects into releases: + +- *Bitbake* +- *Toaster* +- OpenEmbedded Core +- *Yocto* Documentation +- *Yocto* Reference BSP + +Bitbake +....... + +*Bitbake* is the task scheduler. It is written in *Python* and interprets +recipes that contain code in *Bitbake's* own programming language, *Python*, and +bash code. The official documentation can be found here: +https://docs.yoctoproject.org/bitbake/2.8/index.html + +Toaster +....... + +*Toaster* is a web frontend for *Bitbake* to start and investigate builds. It +provides information about the build history and statistics on created images. +There are several use cases where the installation and maintenance of +a *Toaster* instance are beneficial. PHYTEC did not add or remove any features +to the upstream *Toaster*, provided by *Poky*. The best source for more +information is the official documentation: +https://docs.yoctoproject.org/dev/toaster-manual/index.html + +Official Documentation +---------------------- + +For more general questions about *Bitbake* and *Poky* consult the mega-manual: +https://docs.yoctoproject.org/dev/singleindex.html + +Compatible Linux Distributions +============================== + +To build *Yocto* you need a compatible *Linux* host development machine. The +list of supported distributions can be found in the reference manual: +https://docs.yoctoproject.org/dev/ref-manual/system-requirements.html#supported-linux-distributions + +PHYTEC BSP Introduction +======================= + +BSP Structure +------------- + +The BSP consists roughly of three parts. BSP management, BSP metadata, and BSP +content. The management consists of *Repo* and phyLinux while the metadata +depends on the SOC, which describes how to build the software. The content +comprises PHYTEC's *Git* repositories and external sources. + +BSP Management +.............. + +*Yocto* is an umbrella project. Naturally, this will force the user to base +their work on several external repositories. They need to be managed in a +deterministic way. We use manifest files, which contain an XML data structure, +to describe all git repositories with pinned-down versions. The *Repo* tool and +our phyLinux wrapper script are used to manage the manifests and set up the BSP, +as described in the manifest file. + +phyLinux +~~~~~~~~ + +phyLinux is a wrapper for *Repo* to handle downloading and setting up the BSP +with an "out of the box" experience. + +Repo +~~~~ + +*Repo* is a wrapper around the *Repo* toolset. The phyLinux script will install +the wrapper in a global path. This is only a wrapper, though. Whenever you run +``repo init -u ``, you first download the *Repo* tools from *Googles* Git +server in a specific version to the ``.repo/repo`` directory. The next time you +run *Repo*, all the commands will be available. Be aware that the *Repo* version +in different build directories can differ over the years if you do not run *Repo +sync*. Also if you store information for your archives, you need to include the +complete ``.repo`` folder. + +*Repo* expects a *Git* repository which will be parsed from the command line. In +the PHYTEC BSP, it is called phy²octo. In this repository, all information about +a software BSP release is stored in the form of a *Repo* XML manifest. This data +structure defines URLs of *Git* servers (called "remotes") and *Git* +repositories and their states (called "projects"). The *Git* repositories can be +seen in different states. The revision field can be a branch, tag, or commit id +of a repository. This means the state of the software is not necessarily unique +and can change over time. That is the reason we use only tags or commit ids for +our releases. The state of the working directory is then unique and does not +change. + +The manifests for the releases have the same name as the release itself. It is a +unique identifier for the complete BSP. The releases are sorted by the SoC +platform. The selected SoC will define the branch of the phy²octo *Git* +repository which will be used for the manifest selection. + +BSP Metadata +............ + +We include several third-party layers in our BSP to get a complete *Linux* +distribution up and running without the need to integrate external projects. All +used repositories are described in the following section. + +Poky +~~~~ + +The PHYTEC BSP is built on top of *Poky*. It comes with a specific version, +defined in the *Repo* manifest. *Poky* comes with a specific version of +*Bitbake*. The OpenEmbedded-core layer "meta" is used as a base for our *Linux* +system. + +meta-openembedded +~~~~~~~~~~~~~~~~~ + +OpenEmbedded is a collection of different layers containing the meta description +for many open-source software projects. We ship all OpenEmbedded layers with our +BSP, but not all of them are activated. Our example images pull several software +packages generated from OpenEmbedded recipes. + +meta-qt6 +~~~~~~~~ + +This layer provides an integration of *Qt6* in the *Poky*-based root filesystem +and is integrated into our BSP. + +meta-nodejs +~~~~~~~~~~~ + +This is an application layer to add recent Node.js versions. + +meta-gstreamer1.0 +~~~~~~~~~~~~~~~~~ + +This is an application layer to add recent GStreamer versions. + +meta-rauc +~~~~~~~~~ + +This layer contains the tools required to build an updated infrastructure with +`RAUC `_. A comparison with +other update systems can be found here: `Yocto update tools +`_. + +meta-phytec +~~~~~~~~~~~ + +This layer contains all machines and common features for all our BSPs. It is +PHYTEC's `Yocto Board Support Package +`_ for all supported +hardware (since *fido*) and is designed to be standalone with *Poky*. Only these +two parts are required if you want to integrate the PHYTEC's hardware into your +existing *Yocto* workflow. The features are: + +- Bootloaders in ``recipes-bsp/barebox/`` and ``recipes-bsp/u-boot/`` +- Kernels in ``recipes-kernel/linux/`` and + ``dynamic-layers/fsl-bsp-release/recipes-kernel/linux/`` +- Many machines in ``conf/machine/`` +- Proprietary *OpenGL ES/EGL* user space libraries for AM335x and i.MX 6 + platforms +- Proprietary *OpenCL* libraries for i.MX 6 platforms + +meta-ampliphy +~~~~~~~~~~~~~ + +This is our example distribution and BSP layer. It extends the basic +configuration of *Poky* with software projects described by all the other BSP +components. It provides a base for your specific development scenarios. The +current features are: + +- `systemd `_ init system +- Images: ``phytec-headless-image`` for non-graphics applications +- Camera integration with OpenCV and GStreamer examples for the i.MX 6 platform + bundled in a ``phytec-vision-image`` +- RAUC integration: we set up basic support for an A/B system image update, + which is possible locally and over-the-air + +meta-qt6-phytec +~~~~~~~~~~~~~~~ + +This is our layer for Qt6 board integration and examples. The features are: + +- `Qt6 with eglfs backend `_ for + PHYTEC's AM335x, i.MX 6 and RK3288 platforms +- Images: ``phytec-qt6demo-image`` for *Qt6* and video applications +- A *Qt6* demo application demonstrating how to create a *Qt6* project using + *QML* widgets and a *Bitbake* recipe for the *Yocto* and *systemd* + integration. It can be found in + ``sources/meta-qt6-phytec/recipes-qt/examples/phytec-qtdemo_git.bb`` + +meta-virtualization +~~~~~~~~~~~~~~~~~~~ + +- This layer provides support for building Xen, KVM, Libvirt, and associated + packages necessary for constructing OE-based virtualized solutions. + +meta-security +~~~~~~~~~~~~~ + +- This layer provides security tools, hardening tools for Linux kernels, and + libraries for implementing security mechanisms. + +meta-selinux +~~~~~~~~~~~~ + +- This layer's purpose is to enable SE Linux support. The majority of this + layer's work is accomplished in *bbappend* files, used to enable SE Linux + support in existing recipes. + +meta-browser +~~~~~~~~~~~~ + +- This is an application layer to add recent web browsers (Chromium, Firefox, + etc.). + +meta-rust +~~~~~~~~~ + +- Includes the Rust compiler and the Cargo package manager for Rust. + +meta-timesys +~~~~~~~~~~~~ + +- Timesys layer for Vigiles Yocto CVE monitoring, security notifications, and + image manifest generation. + +meta-freescale +~~~~~~~~~~~~~~ + +- This layer provides support for the i.MX, Layerscape, and QorIQ product + lines. + +meta-freescale-3rdparty +~~~~~~~~~~~~~~~~~~~~~~~ + +- Provides support for boards from various vendors. + +meta-freescale-distro +~~~~~~~~~~~~~~~~~~~~~ + +- This layer provides support for Freescale's Demonstration images for use with + OpenEmbedded and/or Yocto Freescale's BSP layer. + +base (fsl-community-bsp-base) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- This layer provides BSP base files of NXP. + +meta-fsl-bsp-release +~~~~~~~~~~~~~~~~~~~~ + +- This is the i.MX Yocto Project Release Layer. + +BSP Content +........... + +The BSP content gets pulled from different online sources when you first start +using *Bitbake*. All files will be downloaded and cloned in a local directory +configured as ``DL_DIR`` in *Yocto*. If you backup your BSP with the complete +content, those sources have to be backed up, too. How you can do this will be +explained in the chapter :ref:`scarthgap_gen-source-mirrors`. + +Build Configuration +------------------- + +The BSP initializes a build folder that will contain all files you +create by running *Bitbake* commands. It contains a ``conf`` folder +that handles build input variables. + +- ``bblayers.conf`` defines activated meta-layers, +- ``local.conf`` defines build input variables specific to your build +- ``site.conf`` defines build input variables specific to the development host + +The two topmost build input variables are ``DISTRO`` and ``MACHINE``. They are +preconfigured ``local.conf`` when you check out the BSP using phyLinux. + +We use "*Ampliphy*" as ``DISTRO`` with our BSP. This distribution will be +preselected and give you a starting point for implementing your own +configuration. + +A ``MACHINE`` defines a binary image that supports specific hardware +combinations of module and baseboard. Check the ``machine.conf`` file or our +webpage for a description of the hardware. + +Pre-built Images +================ + +For each BSP we provide pre-built target images that can be downloaded from the +PHYTEC FTP server: https://download.phytec.de/Software/Linux/ + +These images are also used for the BSP tests, which are flashed to the boards +during production. You can use the provided ``.wic`` images to create a bootable +SD card at any time. Identify your hardware and flash the downloaded image file +to an empty SD card using ``dd``. Please see section Images for information +about the correct usage of the command. + +BSP Workspace Installation +========================== + +Setting Up the Host +------------------- + +You can set up the host or use one of our build-container to run a Yocto build. +You need to have a running *Linux* distribution. It should be running on a +powerful machine since a lot of compiling will need to be done. + +If you want to use a build-container, you only need to install following +packages on your host + +.. code-block:: console + + host:~$ sudo apt install wget git + +Continue with the next step :ref:`scarthgap_git-config` after that. The documentation for +using build-container can be found in this manual after +:ref:`scarthgap_phylinux-advanced-usage` of phyLinux. + +Else *Yocto* needs a handful of additional packages on your host. For *Ubuntu* you need + +.. code-block:: console + + host:~$ sudo apt install gawk wget git diffstat unzip texinfo \ + gcc build-essential chrpath socat cpio python3 python3-pip \ + python3-pexpect xz-utils debianutils iputils-ping python3-git \ + python3-jinja2 libegl1-mesa libsdl1.2-dev \ + python3-subunit mesa-common-dev zstd liblz4-tool file locales + + +For other distributions you can find information in the *Yocto* Quick Build: +https://docs.yoctoproject.org/dev/brief-yoctoprojectqs/index.html + +.. _scarthgap_git-config: + +Git Configuration +----------------- + +The BSP heavily utilizes *Git*. *Git* needs some information from +you as a user to identify who made changes. Create a ``~/.gitconfig`` with the +following content, if you do not have one + +.. code-block:: kconfig + + [user] + name = + email = + [core] + editor = vim + [merge] + tool = vimdiff + [alias] + co = checkout + br = branch + ci = commit + st = status + unstage = reset HEAD -- + last = log -1 HEAD + [push] + default = current + [color] + ui = auto + +You should set ``name`` and ``email`` in your *Git* configuration, otherwise, +*Bitbake* will complain during the first build. You can use the two commands to +set them directly without editing ``~/.gitconfig`` manually + +.. code-block:: console + + host:~$ git config --global user.email "your_email@example.com" + host:~$ git config --global user.name "name surname" + +site.conf Setup +--------------- + +Before starting the *Yocto* build, it is advisable to configure the development +setup. Two things are most important: the download directory and the cache +directory. PHYTEC strongly recommends configuring the setup as it will reduce +the compile time of consequent builds. + +A download directory is a place where *Yocto* stores all sources fetched from +the internet. It can contain tar.gz, *Git* mirror, etc. It is very useful to set +this to a common shared location on the machine. Create this directory with 777 +access rights. To share this directory with different users, all files need to +have group write access. This will most probably be in conflict with default +*umask* settings. One possible solution would be to use ACLs for this +directory + +.. code-block:: console + + host:~$ sudo apt-get install acl + host:~$ sudo setfacl -R -d -m g::rwx + +If you have already created a download directory and want to fix the permissions +afterward, you can do so with + +.. code-block:: console + + host:~$ sudo find /home/share/ -perm /u=r ! -perm /g=r -exec chmod g+r \{\} \; + host:~$ sudo find /home/share/ -perm /u=w ! -perm /g=w -exec chmod g+w \{\} \; + host:~$ sudo find /home/share/ -perm /u=x ! -perm /g=x -exec chmod g+x \{\} \; + +The cache directory stores all stages of the build process. *Poky* has quite an +involved caching infrastructure. It is advisable to create a shared directory, +as all builds can access this cache directory, called the shared state cache. + +Create the two directories on a drive where you have approximately 50 GB of +space and assign the two variables in your ``build/conf/local.conf``:: + + DL_DIR ?= "/yocto_downloads" + SSTATE_DIR ?= "/yocto_sstate" + +If you want to know more about configuring your build, see the documented +example settings + +.. code-block:: + + sources/poky/meta-yocto/conf/local.conf.sample + sources/poky/meta-yocto/conf/local.conf.sample.extended + +phyLinux Documentation +====================== + +The phyLinux script is a basic management tool for PHYTEC *Yocto* BSP releases +written in *Python*. It is mainly a helper to get started with the BSP +structure. You can get all the BSP sources without the need of interacting with +*Repo* or *Git*. + +The phyLinux script has only one real dependency. It requires the *wget* tool +installed on your host. It will also install the `Repo tool +`_ in a global path +(/usr/local/bin) on your host PC. You can install it in a different location +manually. *Repo* will be automatically detected by phyLinux if it is found in +the PATH. The *Repo* tool will be used to manage the different *Git* +repositories of the *Yocto* BSP. + +Get phyLinux +------------ + +The phyLinux script can be found on the PHYTEC download server: +https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux + +Basic Usage +----------- + +For the basic usage of phyLinux, type + +.. code-block:: console + + host:~$ ./phyLinux --help + +which will result in + +.. code-block:: + + usage: phyLinux [-h] [-v] [--verbose] {init,info,clean} ... + + This Programs sets up an environment to work with The Yocto Project on Phytecs + Development Kits. Use phyLinx -h to display the help text for the + available commands. + + positional arguments: + {init,info,clean} commands + init init the phytec bsp in the current directory + info print info about the phytec bsp in the current directory + clean Clean up the current working directory + + optional arguments: + -h, --help show this help message and exit + -v, --version show program's version number and exit + --verbose + +Initialization +-------------- + +Create a fresh project folder + +.. code-block:: console + + host:~$ mkdir ~/yocto + +Calling phyLinux will use the default Python version. Starting with Ubuntu 20.04 +it will be Python3. If you want to initiate a BSP, which is not compatible with +Python3, you need to set Python2 as default (temporarily) before running +phyLinux + +.. code-block:: console + + host:~$ ln -s \`which python2\` python && export PATH=`pwd`:$PATH + +Now run phyLinux from the new folder + +.. code-block:: console + + host:~$ ./phyLinux init + +A clean folder is important because phyLinux will clean its working directory. +Calling phyLinux from a directory that isn't empty will result in the following +**warning**:: + + This current directory is not empty. It could lead to errors in the BSP configuration + process if you continue from here. At the very least, you have to check your build directory + for settings in bblayers.conf and local.conf, which will not be handled correctly in + all cases. It is advisable to start from an empty directory of call: + $ ./phyLinux clean + Do you really want to continue from here? + [yes/no]: + +On the first initialization, the phyLinux script will ask you to install the +*Repo* tool in your */usr/local/bin* directory. During the execution of the +*init* command, you need to choose your processor platform (SoC), PHYTEC's BSP +release number, and the hardware you are working on + +.. code-block:: + + *************************************************** + * Please choose one of the available SoC Platforms: + * + * 1: am335x + * 2: am57x + * 3: am62ax + * 4: am62x + * 5: am64x + * 6: am68x + * 7: imx6 + * 8: imx6ul + * 9: imx7 + * 10: imx8 + * 11: imx8m + * 12: imx8mm + * 13: imx8mp + * 14: imx8x + * 15: imx93 + * 16: nightly + * 17: rk3288 + * 18: stm32mp13x + * 19: stm32mp15x + * 20: topic + + # Exemplary output for chosen imx8mp + *************************************************** + * Please choose one of the available Releases: + * + * 1: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1-rc1 + * 2: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1-rc2 + * 3: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.0 + * 4: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 + * 5: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2-rc1 + * 6: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 + * 7: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.y + * 8: BSP-Yocto-Ampliphy-i.MX8MP-master + * 9: BSP-Yocto-FSL-i.MX8MP-ALPHA1 + * 10: BSP-Yocto-FSL-i.MX8MP-ALPHA2 + * 11: BSP-Yocto-FSL-i.MX8MP-PD21.1-rc1 + * 12: BSP-Yocto-FSL-i.MX8MP-PD21.1-rc2 + * 13: BSP-Yocto-FSL-i.MX8MP-PD21.1.0 + * 14: BSP-Yocto-FSL-i.MX8MP-PD21.1.1-rc1 + * 15: BSP-Yocto-FSL-i.MX8MP-PD21.1.1-rc2 + * 16: BSP-Yocto-FSL-i.MX8MP-PD21.1.1 + * 17: BSP-Yocto-FSL-i.MX8MP-PD21.1.2-rc1 + * 18: BSP-Yocto-FSL-i.MX8MP-PD21.1.2-rc2 + * 19: BSP-Yocto-FSL-i.MX8MP-PD21.1.2 + * 20: BSP-Yocto-FSL-i.MX8MP-PD21.1.3-rc1 + * 21: BSP-Yocto-FSL-i.MX8MP-PD21.1.3 + * 22: BSP-Yocto-NXP-i.MX8MP-PD22.1-rc1 + * 23: BSP-Yocto-NXP-i.MX8MP-PD22.1-rc2 + * 24: BSP-Yocto-NXP-i.MX8MP-PD22.1-rc3 + * 25: BSP-Yocto-NXP-i.MX8MP-PD22.1-rc4 + * 26: BSP-Yocto-NXP-i.MX8MP-PD22.1.0 + * 27: BSP-Yocto-NXP-i.MX8MP-PD22.1.1-rc1 + * 28: BSP-Yocto-NXP-i.MX8MP-PD22.1.1-rc2 + * 29: BSP-Yocto-NXP-i.MX8MP-PD22.1.1-rc3 + * 30: BSP-Yocto-NXP-i.MX8MP-PD22.1.1-rc4 + * 31: BSP-Yocto-NXP-i.MX8MP-PD22.1.1 + * 32: BSP-Yocto-NXP-i.MX8MP-PD22.1.2-rc1 + * 33: BSP-Yocto-NXP-i.MX8MP-PD22.1.2-rc2 + * 34: BSP-Yocto-NXP-i.MX8MP-PD22.1.2 + * 35: BSP-Yocto-NXP-i.MX8MP-PD22.1.y + * 36: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc1 + * 37: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc2 + * 38: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc3 + * 39: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc4 + * 40: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc5 + * 41: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc6 + * 42: BSP-Yocto-NXP-i.MX8MP-PD23.1.0 + * 43: BSP-Yocto-NXP-i.MX8MP-PD23.1.y + * 44: BSP-Yocto-NXP-i.MX8MP-PD24.1-rc1 + * 45: BSP-Yocto-NXP-i.MX8MP-PD24.1-rc2 + * 46: BSP-Yocto-NXP-i.MX8MP-PD24.1-rc3 + * 47: BSP-Yocto-NXP-i.MX8MP-PD24.1.0 + * 48: BSP-Yocto-NXP-i.MX8MP-PD24.1.y + + # Exemplary output for chosen BSP-Yocto-NXP-i.MX8MP-PD24.1.0 + ********************************************************************* + * Please choose one of the available builds: + * + no: machine: description and article number + distro: supported yocto distribution + target: supported build target + + 1: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM + Pollux PL1552.2 + PB-03123-001.A3 + distro: ampliphy-vendor + target: phytec-headless-image + 2: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM + Pollux PL1552.2 + PB-03123-001.A3 + distro: ampliphy-vendor-rauc + target: phytec-headless-bundle + target: phytec-headless-image + 3: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM + Pollux PL1552.2 + PB-03123-001.A3 + distro: ampliphy-vendor-xwayland + target: -c populate_sdk phytec-qt6demo-image + target: phytec-qt6demo-image + target: phytec-vision-image + 4: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM + Pollux PL1552.2 + PB-03123-001.A3 + distro: securiphy-vendor + target: phytec-securiphy-bundle + target: phytec-securiphy-image + 5: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM + Pollux PL1552.2 + PB-03123-001.A3 + distro: securiphy-vendor-provisioning + target: phytec-provisioning-image + + +If you cannot identify your board with the information given in the selector, +have a look at the invoice for the product. After the configuration is done, +you can always run + +.. code-block:: console + + host:~$ ./phyLinux info + + # Exemplary output + ********************************************** + * The current BSP configuration is: + * + * SoC: refs/heads/imx8mp + * Release: BSP-Yocto-NXP-i.MX8MP-PD24.1.0 + * + ********************************************** + +to see which SoC and Release are selected in the current workspace. If +you do not want to use the selector, phyLinux also supports command-line +arguments for several settings + +.. code-block:: console + + host:~$ MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.0 + +or view the help command for more information + +.. code-block:: console + + host:~$ ./phyLinux init --help + + usage: phyLinux init [-h] [--verbose] [--no-init] [-o REPOREPO] [-b REPOREPO_BRANCH] [-x XML] [-u URL] [-p PLATFORM] [-r RELEASE] + + options: + -h, --help show this help message and exit + --verbose + --no-init dont execute init after fetch + -o REPOREPO Use repo tool from another url + -b REPOREPO_BRANCH Checkout different branch of repo tool + -x XML Use a local XML manifest + -u URL Manifest git url + -p PLATFORM Processor platform + -r RELEASE Release version + +After the execution of the *init* command, phyLinux will print a few important +notes as well as information for the next steps in the build process. + +.. _scarthgap_phylinux-advanced-usage: + +Advanced Usage +-------------- + +phyLinux can be used to transport software states over any medium. The state of +the software is uniquely identified by *manifest.xml*. You can create a +manifest, send it to another place and recover the software state with + +.. code-block:: console + + host:~$ ./phyLinux init -x manifest.xml + +You can also create a *Git* repository containing your software states. The +*Git* repository needs to have branches other than master, as we reserved the +master branch for different usage. Use phyLinux to check out the states + +.. code-block:: console + + host:~$ ./phyLinux -u + +Using build-container +===================== + +.. warning:: + Currently, it is not possible to run the phyLinux script inside of a container. + After a complete init with the phyLinux script on your host machine, you can use a container for the build. + If you do not have phyLinux script running on your machine, please see phyLinux Documentation. + +There are various possibilities to run a build-container. Commonly used is +docker and podman, though we prefer podman as it does not need root privileges +to run. + +Installation +------------ + +How to install podman: https://podman.io +How to install docker: https://docs.docker.com/engine/install/ + +Available container +------------------- + +Right now we provide 4 different container based on Ubuntu LTS versions: +https://hub.docker.com/u/phybuilder + +- yocto-ubuntu-16.04 +- yocto-ubuntu-18.04 +- yocto-ubuntu-20.04 +- yocto-ubuntu-22.04 + +These containers can be run with podman or docker. With Yocto Project branch |yocto-codename| the container "yocto-ubuntu-20.04" is preferred. + +Download/Pull container +----------------------- + +.. code-block:: console + + host:~$ podman pull docker.io/phybuilder/yocto-ubuntu-20.04 + + OR + + host:~$ docker pull docker.io/phybuilder/yocto-ubuntu-20.04 + +By adding a tag at the end separated by a colon, you can also pull or run a special tagged container. + + podman pull docker.io/phybuilder/yocto-ubuntu-20.04:phy2 + +You can find all available tags in our duckerhub space: + +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-16.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-18.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-20.04/tags +- https://hub.docker.com/r/phybuilder/yocto-ubuntu-22.04/tags + +If you try to run a container, which is not pulled/downloaded, it will be pulled/downloaded automatically. + +You can have a look at all downloaded/pulled container with: + +.. code-block:: console + + $USERNAME@$HOSTNAME:~$ podman images + REPOSITORY TAG IMAGE ID CREATED SIZE + docker.io/phybuilder/yocto-ubuntu-22.04 latest d626178e448d 4 months ago 935 MB + docker.io/phybuilder/yocto-ubuntu-22.04 phy2 d626178e448d 4 months ago 935 MB + docker.io/phybuilder/yocto-ubuntu-20.04 phy2 e29a88b7172a 4 months ago 900 MB + docker.io/phybuilder/yocto-ubuntu-20.04 latest e29a88b7172a 4 months ago 900 MB + docker.io/phybuilder/yocto-ubuntu-18.04 phy1 14c9c3e477d4 7 months ago 567 MB + docker.io/phybuilder/yocto-ubuntu-18.04 latest 14c9c3e477d4 7 months ago 567 MB + docker.io/phybuilder/yocto-ubuntu-16.04 phy1 28c73e13ab4f 7 months ago 599 MB + docker.io/phybuilder/yocto-ubuntu-16.04 latest 28c73e13ab4f 7 months ago 599 MB + docker.io/phybuilder/yocto-ubuntu-22.04 phy1 5a0ef4b41935 8 months ago 627 MB + docker.io/phybuilder/yocto-ubuntu-20.04 phy1 b5a26a86c39f 8 months ago 680 MB + +Run container +------------- + +To run and use container for a Yocto build, first enter to your folder, where +you run phyLinux init before. Then start the container + +.. code-block:: console + + host:~$ podman run --rm=true -v /home:/home --userns=keep-id --workdir=$PWD -it docker.io/phybuilder/yocto-ubuntu-20.04 bash + +.. note:: + To run and use a container with docker, it is not that simple like with podman. + Therefore the container-user has to be defined and configured. + Furthermore forwarding of credentials is not given per default and has to be configured as well. + +Now your commandline should look something like that (where $USERNAME is the +user, who called "podman run" and the char/number code diffs every time a +container is started) + +.. code-block:: console + + $USERNAME@6593e2c7b8f6:~$ + +.. warning:: + If the given username is "root" you will not be able to run bitbake at all. + Please be sure, you run the container with your own user. + +Now you are ready to go on and starting the build. +To stop/close the container, just call + +.. code-block:: console + + $USERNAME@6593e2c7b8f6:~$ exit + +Working with Poky and Bitbake +============================= + +Start the Build +--------------- + +After you download all the metadata with phyLinux init, you have to set up the +shell environment variables. This needs to be done every time you open a new +shell for starting builds. We use the shell script provided by *Poky* in its +default configuration. From the root of your project directory type + +.. code-block:: console + + host:~$ source sources/poky/oe-init-build-env + +The abbreviation for the source command is a single dot + +.. code-block:: console + + host:~$ . sources/poky/oe-init-build-env + +The current working directory of the shell should change to *build/*. Before +building for the first time, you should take a look at the main configuration +file + +.. code-block:: console + + host:~$ vim conf/local.conf + +Your local modifications for the current build are stored here. Depending on +the SoC, you might need to accept license agreements. For example, to build the +image for Freescale/NXP processors you need to accept the GPU and VPU binary +license agreements. You have to uncomment the corresponding line + +.. code-block:: kconfig + + # Uncomment to accept NXP EULA # EULA can be found under + ../sources/meta-freescale/EULA ACCEPT_FSL_EULA = "1" + +Now you are ready to build your first image. We suggest starting with our +smaller non-graphical image *phytec-headless-image* to see if everything is +working correctly + +.. code-block:: console + + host:~$ bitbake phytec-headless-image + +The first compile process takes about 40 minutes on a modern Intel Core i7. All +subsequent builds will use the filled caches and should take about 3 minutes. + +Images +------ + +If everything worked, the images can be found under + +.. code-block:: console + + host:~$ cd deploy/images/ + +The easiest way to test your image is to configure your board for SD card boot +and to flash the build image to the SD card + +.. code-block:: console + + host:~$ sudo dd if=phytec-headless-image-.wic of=/dev/ bs=1M conv=fsync + +Here could be "sde", for example, depending on your system. Be +very careful when selecting the right drive! Selecting the wrong drive can +erase your hard drive! The parameter conv=fsync forces a data buffer to write +to the device before dd returns. + +After booting you can log in using a serial cable or over *ssh*. There is no +root password. That is because of the debug settings in *conf/local.conf*. If +you uncomment the line + +.. code-block:: kconfig + + #EXTRA_IMAGE_FEATURES = "debug-tweaks" + +the debug settings, like setting an empty root password, will not be applied. + +Accessing the Development States between Releases +------------------------------------------------- + +Special release manifests exist to give you access to the current development +states of the *Yocto* BSP. They will be displayed in the phyLinux selection +menu with the ending *PDXX.X.y* + +.. code-block:: console + + host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.y + +This will initialize a BSP that will track the latest development state. + +Inspect your Build Configuration +-------------------------------- + +*Poky* includes several tools to inspect your build layout. You can inspect the +commands of the layer tool + +.. code-block:: console + + host:~$ bitbake-layers + +It can, for example, be used to view in which layer a specific recipe gets +modified + +.. code-block:: console + + host:~$ bitbake-layers show-appends + +Before running a build you can also launch *Toaster* to be able to inspect the +build details with the Toaster web GUI + +.. code-block:: console + + host:~$ source toaster start + +Maybe you need to install some requirements, first + +.. code-block:: console + + host:~$ pip3 install -r + ../sources/poky/bitbake/toaster-requirements.txt + +You can then point your browser to *http://0.0.0.0:8000/* and continue working +with *Bitbake*. All build activity can be monitored and analyzed from this web +server. If you want to learn more about *Toaster*, look at +https://docs.yoctoproject.org/dev/toaster-manual/index.html. +To shut down the *Toaster* web GUI again, execute + +.. code-block:: console + + host:~$ source toaster stop + +BSP Features of meta-phytec and meta-ampliphy +--------------------------------------------- + +*Buildinfo* +........... + +The *buildinfo* task is a feature in our recipes that prints instructions to +fetch the source code from the public repositories. So you do not have to look +into the recipes yourself. To see the instructions, e.g. for the *barebox* +package, execute + +.. code-block:: console + + host:~$ bitbake barebox -c buildinfo + +in your shell. This will print something like + +.. code-block:: + + (mini) HOWTO: Use a local git repository to build barebox: + + To get source code for this package and version (barebox-2022.02.0-phy1), execute + + $ mkdir -p ~/git + $ cd ~/git + $ git clone git://git.phytec.de/barebox barebox + $ cd ~/git/barebox + $ git checkout -b v2022.02.0-phy1-local-development 7fe12e65d770f7e657e683849681f339a996418b + + You now have two possible workflows for your changes: + + 1. Work inside the git repository: + Copy and paste the following snippet to your "local.conf": + + SRC_URI:pn-barebox = "git://${HOME}/git/barebox;branch=${BRANCH}" + SRCREV:pn-barebox = "${AUTOREV}" + BRANCH:pn-barebox = "v2022.02.0-phy1-local-development" + + After that you can recompile and deploy the package with + + $ bitbake barebox -c compile + $ bitbake barebox -c deploy + + Note: You have to commit all your changes. Otherwise yocto doesn't pick them up! + + 2. Work and compile from the local working directory + To work and compile in an external source directory we provide the + externalsrc.bbclass. To use it, copy and paste the following snippet to your + "local.conf": + + INHERIT += "externalsrc" + EXTERNALSRC:pn-barebox = "${HOME}/git/barebox" + EXTERNALSRC_BUILD:pn-barebox = "${HOME}/git/barebox" + + Note: All the compiling is done in the EXTERNALSRC directory. Every time + you build an Image, the package will be recompiled and build. + + NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded. + NOTE: Writing buildhistory + +As you can see, everything is explained in the output. + +.. warning:: + + Using *externalsrc* breaks a lot of *Yocto's* internal dependency + mechanisms. It is not guaranteed that any changes to the source + directory are automatically picked up by the build process and + incorporated into the root filesystem or SD card image. You have to + always use *--force*. E.g. to compile *barebox* and redeploy it to + *deploy/images/* execute + + .. code-block:: console + + host:~$ bitbake barebox -c compile --force + host:~$ bitbake barebox -c deploy + +To update the SD card image with a new kernel or image first force the +compilation of it and then force a rebuild of the root filesystem. Use + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image -c rootfs --force + +Note that the build system is not modifying the external source directory. If +you want to apply all patches the *Yocto* recipe is carrying to the external +source directory, run the line + +.. code-block:: kconfig + + SRCTREECOVEREDTASKS="" BB_ENV_PASSTHROUGH_ADDITIONS="$BB_ENV_PASSTHROUGH_ADDITIONS SRCTREECOVEREDTASKS" bitbake -c patch + +.. _scarthgap_bsp-customization: + +BSP Customization +----------------- + +To get you started with the BSP, we have summarized some basic tasks from the +*Yocto* official documentation. It describes how to add additional software to +the image, change the kernel and bootloader configuration, and integrate +patches for the kernel and bootloader. + +Minor modifications, such as adding software, are done in the file +*build/conf/local.conf*. There you can overwrite global configuration variables +and make small modifications to recipes. + +There are 2 ways to make major changes: + +1. Either create your own layer and use *bbappend* files. +2. Add everything to PHYTEC's Distro layer *meta-ampliphy*. + +Creating your own layer is described in the section Create your own Layer. + +Disable Qt Demo +............... + +By default, the BSP image *phytec-qt6demo-image* starts a Qt6 Demo application +on the attached display or monitor. If you want to stop the demo and use the +*Linux* framebuffer console behind it, connect to the target via serial cable +or *ssh* and execute the shell command + +.. code-block:: console + + target:~$ systemctl stop phytec-qtdemo.service + +This command stops the demo temporarily. To start it again, reboot the +board or execute + +.. code-block:: console + + target:~$ systemctl start phytec-qtdemo.service + +You can disable the service permanently, so it does not start on boot + +.. code-block:: console + + target:~$ systemctl disable phytec-qtdemo.service + +.. tip:: + + The last command only disables the service. It does not *stop* immediately. + To see the current status execute + + .. code-block:: console + + target:~$ systemctl status phytec-qtdemo.service + +If you want to disable the service by default, edit the file +*build/conf/local.conf* and add the following line + +.. code-block:: kconfig + + # file build/conf/local.conf + SYSTEMD_AUTO_ENABLE:pn-phytec-qtdemo = "disable" + +After that, rebuild the image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +Framebuffer Console +................... + +On boards with a display interface, the framebuffer console is enabled per +default. You can attach a USB keyboard and log in. To change the keyboard +layout from the English default to German, type + +.. code-block:: console + + target:~$ loadkeys /usr/share/keymaps/i386/qwertz/de-latin1.map.gz + +To detach the framebuffer console, run + +.. code-block:: console + + target:~$ echo 0 > sys/class/vtconsole/vtcon1/bind + +To completely deactivate the framebuffer console, disable the following kernel +configuration option + +.. code-block:: + + Device Drivers->Graphics Support->Support for framebuffer devices->Framebuffer Console Support + +More information can be found at: +https://www.kernel.org/doc/Documentation/fb/fbcon.txt + +Tools Provided in the Prebuild Image +.................................... + +RAM Benchmark +~~~~~~~~~~~~~ + +Performing RAM and cache performance tests can best be done by using *pmbw* +(Parallel Memory Bandwidth Benchmark/Measurement Tool). *Pmbw* runs several +assembly routines which all use different access patterns to the caches and RAM +of the SoC. Before running the test, make sure that you have about 2 MiB of +space left on the device for the log files. We also lower the level of the +benchmark to ask the kernel more aggressively for resources. The benchmark test +will take several hours. + +To start the test type + +.. code-block:: console + + target:~$ nice -n -2 pmbw + +Upon completion of the test run, the log file can be converted to a *gnuplot* +script with + +.. code-block:: console + + target:~$ stats2gnuplot stats.txt > run1.gnuplot + +Now you can transfer the file to the host machine and install any version of +*gnuplot* + +.. code-block:: console + + host:~$ sudo apt-get install gnuplot host:~$ gnuplot run1.gnuplot + +The generated *plots-.pdf* file contains all plots. To render single +plots as *png* files for any web output you can use *Ghostscript* + +.. code-block:: console + + host:~$ sudo apt-get install ghostscript + host:~$ gs -dNOPAUSE -dBATCH -sDEVICE=png16m -r150 -sOutputFile='page-%00d.png' plots-phyboard-wega-am335x-1.pdf + +Add Additional Software for the BSP Image +......................................... + +To add additional software to the image, look at the OpenEmbedded layer index: +https://layers.openembedded.org/layerindex/branch/scarthgap/layers/ + +First, select the *Yocto* version of the BSP you have from the drop-down list in +the top left corner and click **Recipes**. Now you can search for a software +project name and find which layer it is in. In some cases, the program is in +*meta-openembedded*, *openembedded-core*, or *Poky* which means that the recipe +is already in your build tree. This section describes how to add additional +software when this is the case. If the package is in another layer, see the next +section. + +You can also search the list of available recipes + +.. code-block:: console + + host:~$ bitbake -s | grep # fill in program name, like in + host:~$ bitbake -s | grep lsof + +When the recipe for the program is already in the *Yocto* build, you can simply +add it by appending a configuration option to your file *build/conf/local.conf*. +The general syntax to add additional software to an image is + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " " + +For example, the line + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " ldd strace file lsof" + +installs some helper programs on the target image. + +.. warning:: + + The leading whitespace is essential for the append command. + +All configuration options in local.conf apply to all images. Consequently, the +tools are now included in both images phytec-headless-image and +phytec-qt6demo-image. + +Notes about Packages and Recipes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You are adding packages to the IMAGE_INSTALL variable. Those are not necessarily +equivalent to the recipes in your meta-layers. A recipe defines per default a +package with the same name. But a recipe can set the PACKAGES variable to +something different and is able to generate packages with arbitrary names. +Whenever you look for software, you have to search for the package name and, +strictly speaking, not for the recipe. In the worst case, you have to look at +all PACKAGES variables. A tool such as *Toaster* can be helpful in some cases. + +If you can not find your software in the layers provided in the folder +*sources*, see the next section to include another layer into the *Yocto* +build. + +References: `Yocto dev Documentation - Customizing Yocto builds +`_ + +Add an Additional Layer +....................... + +This is a step-by-step guide on how to add another layer to your *Yocto* build +and install additional software from it. As an example, we include the network +security scanner *nmap* in the layer *meta-security*. First, you must locate the +layer on which the software is hosted. Check out the `OpenEmbedded MetaData +Index `_ +and guess a little bit. The network scanner *nmap* is in the *meta-security* +layer. See `meta-security on layers.openembedded.org +`_. +To integrate it into the *Yocto* build, you have to check out the repository and +then switch to the correct stable branch. Since the BSP is based on the *Yocto* +|yocto-codename| build, you should try to use the |yocto-codename| branch in the layer, too. + +.. code-block:: console + + host:~$ cd sources + host:~$ git clone git://git.yoctoproject.org/meta-security + host:~$ cd meta-security + host:~$ git branch -r + +All available remote branches will show up. Usually there should be 'sumo', +'warrior', 'zeus', 'dunfell', 'hardnkott', 'kirkstone', 'mickledore', 'master'... + +.. code-block:: console + + host:~$ git checkout scarthgap + +Now we add the directory of the layer to the file *build/conf/bblayers.conf* by +appending the line + +.. code-block:: kconfig + + # file build/conf/bblayers.conf + BBLAYERS += "${BSPDIR}/sources/meta-security" + +to the end of the file. After that, you can check if the layer is available in +the build configuration by executing + +.. code-block:: console + + host:~$ bitbake-layers show-layers + +If there is an error like + +.. code-block:: + + ERROR: Layer 'security' depends on layer 'perl-layer', but this layer is not enabled in your configuration + +the layer that you want to add (here *meta-security*), depends on another layer, +which you need to enable first. E.g. the dependency required here is a layer in +*meta-openembedded* (in the PHYTEC BSP it is in the path +*sources/meta-openembedded/meta-perl/*). To enable it, add the following line to +*build/conf/bblayers.conf* + +.. code-block:: kconfig + + # file build/conf/bblayers.conf + BBLAYERS += "${BSPDIR}/sources/meta-openembedded/meta-perl" + +Now the command *bitbake-layers show-layers* should print a list of all layers +enabled including *meta-security* and *meta-perl*. After the layer is included, +you can install additional software from it as already described above. The +easiest way is to add the following line (here is the package *nmap*) + +.. code-block:: kconfig + + # file build/conf/local.conf + IMAGE_INSTALL:append = " nmap" + +to your *build/conf/local.conf*. Do not forget to rebuild the image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +Create your own layer +.................................. + +Creating your layer should be one of the first tasks when customizing the BSP. +You have two basic options. You can either copy and rename our *meta-ampliphy*, +or you can create a new layer that will contain your changes. The better option +depends on your use case. *meta-ampliphy* is our example of how to create a +custom *Linux* distribution that will be updated in the future. If you want to +benefit from those changes and are, in general, satisfied with the userspace +configuration, it could be the best solution to create your own layer on top of +*Ampliphy*. If you need to rework a lot of information and only need the basic +hardware support from PHYTEC, it would be better to copy *meta-ampliphy*, rename +it, and adapt it to your needs. You can also have a look at the OpenEmbedded +layer index to find different distribution layers. If you just need to add your +own application to the image, create your own layer. + +In the following chapter, we have an embedded project called "racer" which we +will implement using our *Ampliphy Linux* distribution. First, we need to create +a new layer. + +*Yocto* provides a script for that. If you set up the BSP and the shell is +ready, type + +.. code-block:: console + + host:~$ bitbake-layers create-layer meta-racer + +Default options are fine for now. Move the layer to the source directory + +.. code-block:: console + + host:~$ mv meta-racer ../sources/ + +Create a *Git* repository in this layer to track your changes + +.. code-block:: console + + host:~$ cd ../sources/meta-racer + host:~$ git init && git add . && git commit -s + +Now you can add the layer directly to your build/conf/bblayers.conf + +.. code-block:: kconfig + + BBLAYERS += "${BSPDIR}/sources/meta-racer" + +or with a script provided by *Yocto* + +.. code-block:: console + + host:~$ bitbake-layers add-layer meta-racer + +Kernel and Bootloader Recipe and Version +........................................ + +First, you need to know which kernel and version are used for your target +machine. PHYTEC provides multiple kernel recipes *linux-mainline*, *linux-ti* +and *linux-imx*. The first one provides support for PHYTEC's i.MX 6 and AM335x +modules and is based on the *Linux* kernel stable releases from `kernel.org +`_. +The *Git* repositories URLs are: + +- *linux-mainline*: git://git.phytec.de/linux-mainline +- *linux-ti*: git://git.phytec.de/linux-ti +- *linux-imx:* git://git.phytec.de/linux-imx +- *barebox*: git://git.phytec.de/barebox +- *u-boot-imx*: git://git.phytec.de/u-boot-imx + +To find your kernel provider, execute the following command + +.. code-block:: console + + host:~$ bitbake virtual/kernel -e | grep "PREFERRED_PROVIDER_virtual/kernel" + +The command prints the value of the variable +*PREFERRED_PROVIDER_virtual/kernel*. The variable is used in the internal +*Yocto* build process to select the kernel recipe to use. The following lines +are different outputs you might see + +.. code-block:: kconfig + + PREFERRED_PROVIDER_virtual/kernel="linux-mainline" + PREFERRED_PROVIDER_virtual/kernel="linux-ti" + PREFERRED_PROVIDER_virtual/kernel="linux-imx" + +To see which version is used, execute *bitbake -s*. For example + +.. code-block:: console + + host:~$ bitbake -s | egrep -e "linux-mainline|linux-ti|linux-imx|barebox|u-boot-imx" + +The parameter *-s* prints the version of all recipes. The output contains the +recipe name on the left and the version on the right + +.. code-block:: + + barebox :2022.02.0-phy1-r7.0 + barebox-hosttools-native :2022.02.0-phy1-r7.0 + barebox-targettools :2022.02.0-phy1-r7.0 + linux-mainline :5.15.102-phy1-r0.0 + +As you can see, the recipe *linux-mainline* has version *5.15.102-phy1*. In +the PHYTEC's *linux-mainline* *Git* repository, you will find a corresponding +tag *v5.15.102-phy1*. The version of the *barebox* recipe is 2022.02.0-phy1. +On i.MX8M\* modules the output will contain *linux-imx* and *u-boot-imx*. + +.. _yocto-man-scarthgap-kernel-and-bootloader-conf: + +Kernel and Bootloader Configuration +................................... + +The bootloader used by PHYTEC, *barebox*, uses the same build system as the +*Linux* kernel. Therefore, all commands in this section can be used to configure +the kernel and bootloader. To configure the kernel or bootloader, execute one of +the following commands + +.. code-block:: console + + host:~$ bitbake -c menuconfig virtual/kernel # Using the virtual provider name + host:~$ bitbake -c menuconfig linux-ti # Or use the recipe name directly + host:~$ bitbake -c menuconfig linux-mainline # Or use the recipe name directly (If you use an i.MX 6 or RK3288 Module) + host:~$ bitbake -c menuconfig linux-imx # Or use the recipe name directly (If you use an i.MX 8M*) + host:~$ bitbake -c menuconfig barebox # Or change the configuration of the bootloader + host:~$ bitbake -c menuconfig u-boot-imx # Or change the configuration of the bootloader (If you use an i.MX 8M*) + +After that, you can recompile and redeploy the kernel or bootloader + +.. code-block:: console + + host:~$ bitbake virtual/kernel -c compile # Or 'barebox' for the bootloader + host:~$ bitbake virtual/kernel -c deploy # Or 'barebox' for the bootloader + +Instead, you can also just rebuild the complete build output with + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # To update the kernel/bootloader, modules and the images + +In the last command, you can replace the image name with the name of an image of +your choice. The new images and binaries are in +*build/deploy/images//*. + +.. warning:: + + The build configuration is not permanent yet. Executing *bitbake + virtual/kernel -c clean* will remove everything. + +To make your changes permanent in the build system, you have to integrate your +configuration modifications into a layer. For the configuration you have two +options: + +- Include only a configuration fragment (a minimal *diff* between the + old and new configuration) +- Complete default configuration (*defconfig*) after your + modifications. + +Having a set of configuration fragments makes what was changed at which stage +more transparent. You can turn on and off the changes, you can manage +configurations for different situations and it helps when porting changes to new +kernel versions. You can also group changes together to reflect specific use +cases. A fully assembled kernel configuration will be deployed in the directory +*build/deploy/images/*. If you do not have any of those requirements, +it might be simpler to just manage a separate *defconfig* file. + +Add a Configuration Fragment to a Recipe +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The following steps can be used for both kernel and bootloader. Just replace the +recipe name *linux-mainline* in the commands with *linux-ti*, or *barebox* for +the bootloader. If you did not already take care of this, start with a clean +build. Otherwise, the diff of the configuration may be wrong + +.. code-block:: console + + host:~$ bitbake linux-mainline -c clean + host:~$ bitbake linux-mainline -c menuconfig + +Make your configuration changes in the menu and generate a config +fragment + +.. code-block:: console + + host:~$ bitbake linux-mainline -c diffconfig + +which prints the path of the written file + +.. code-block:: + + Config fragment has been dumped into: + /home//build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg + +All config changes are in the file *fragment.cfg* which should consist of only +some lines. The following example shows how to create a *bbappend* file and how +to add the necessary lines for the config fragment. You just have to adjust the +directories and names for the specific recipe: *linux-mainline*, *linux-ti*, +linux-imx, u-boot-imx, or *barebox*. + +.. code-block:: + + sources//recipes-kernel/linux/linux-mainline_%.bbappend # For the recipe linux-mainline + sources//recipes-kernel/linux/linux-ti_%.bbappend # For the recipe linux-ti + sources//recipes-kernel/linux/linux-imx_%.bbappend # For the recipe linux-imx + sources//recipes-bsp/barebox/barebox_%.bbappend # For the recipe barebox + sources//recipes-bsp/u-boot/u-boot-imx_%.bbappend # For the recipe u-boot-imx + +Replace the string *layer* with your own layer created as shown above (e.g. +*meta-racer*), or just use *meta-ampliphy*. To use *meta-ampliphy*, first, +create the directory for the config fragment and give it a new name (here +*enable-r8169.cfg*) and move the fragment to the layer. + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features + # copy the path from the output of *diffconfig* + host:~$ cp /home//build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg \ + sources/meta-ampliphy/recipes-kernel/linux/features/enable-r8169.cfg + +Then open the *bbappend* file (in this case +*sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend* ) with +your favorite editor and add the following lines + +.. code-block:: kconfig + + # contents of the file linux-mainline_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://enable-r8169.cfg \ + " + +.. warning:: + + Do not forget to use the correct *bbappend* filenames: *linux-ti_%.bbappend* + for the linux-ti recipe and *barebox_%.bbappend* for the bootloader in the + folder *recipes-bsp/barebox/* ! + +After saving the *bbappend* file, you have to rebuild the image. *Yocto* should +pick up the recipe changes automatically and generate a new image + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +Add a Complete Default Configuration (*defconfig*) to a Recipe +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This approach is similar to the one above, but instead of adding a fragment, a +*defconfig* is used. First, create the necessary folders in the layer you want +to use, either your own layer or *meta-ampliphy* + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features/ # For both linux-mainline and linux-ti + host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features/ # Or for the bootloader + +Then you have to create a suitable *defconfig* file. Make your configuration +changes using *menuconfig* and then save the *defconfig* file to the layer + +.. code-block:: console + + host:~$ bitbake linux-mainline -c menuconfig # Or use recipe name linux-ti or barebox + host:~$ bitbake linux-mainline -c savedefconfig # Create file 'defconfig.temp' in the work directory + +This will print the path to the generated file + +.. code-block:: + + Saving defconfig to ..../defconfig.temp + +Then, as above, copy the generated file to your layer, rename it to *defconfig*, +and add the following lines to the *bbappend* file (here +*sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend*) + +.. code-block:: kconfig + + # contents of the file linux-mainline_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://defconfig \ + " + +.. tip:: + + Do not forget to use the correct bbappend filenames: *linux-ti_%.bbappend* + for the linux-ti recipe and *barebox_%.bbappend* for the bootloader in the + folder *recipes-bsp/barebox/* ! + +After that, rebuild your image as the changes are picked up automatically + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +Patch the Kernel or Bootloader with *devtool* +............................................. + +*Apart from using the standard versions of kernel and bootloader which are +provided in the recipes, you can modify the source code or use our own +repositories to build your customized kernel.* + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| Standard workflow of the | Uses additional hard drive space | +| official *Yocto* documentation | as the sources get duplicated | ++----------------------------------+----------------------------------+ +| Toolchain does not have to | No optimal cache usage, build | +| recompile everything | overhead | ++----------------------------------+----------------------------------+ + +*Devtool* is a set of helper scripts to enhance the user workflow of *Yocto*. It +was integrated with version 1.8. It is available as soon as you set up your +shell environment. *Devtool* can be used to: + +- modify existing sources +- integrate software projects into your build setup +- build software and deploy software modifications to your target + +Here we will use *devtool* to patch the kernel. We use *linux-mainline* as an +example for the AM335x Kernel. The first command we use is *devtool modify - x + * + +.. code-block:: console + + host:~$ devtool modify -x linux-mainline linux-mainline + +*Devtool* will create a layer in *build/workspace* where you can see all +modifications done by *devtool* . It will extract the sources corresponding to +the recipe to the specified directory. A *bbappend* will be created in the +workspace directing the SRC_URI to this directory. Building an image with +*Bitbake* will now use the sources in this directory. Now you can modify lines +in the kernel + +.. code-block:: console + + host:~$ vim linux-mainline/arch/arm/boot/dts/am335x-phycore-som.dtsi + -> make a change + host:~$ bitbake phytec-qt6demo-image + +Your changes will now be recompiled and added to the image. If you want to store +your changes permanently, it is advisable to create a patch from the changes, +then store and backup only the patch. You can go into the *linux-mainline* +directory and create a patch using *Git*. How to create a patch is described in +:ref:`scarthgap_temporary-method` and is the same for all methods. + +If you want to learn more about *devtool*, visit: + +`Yocto dev - Devtool +`_ +or `Devtool Quick Reference +`_ + +.. _scarthgap_temporary-method: + +Patch the Kernel or Bootloader using the "Temporary Method" +........................................................... + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| No overhead, no extra | Changes are easily overwritten | +| configuration | by *Yocto* (Everything is | +| | lost!!). | ++----------------------------------+----------------------------------+ +| Toolchain does not have to | | +| recompile everything | | ++----------------------------------+----------------------------------+ + +It is possible to alter the source code before *Bitbake* configures and compiles +the recipe. Use *Bitbake'* s *devshell* command to jump into the source +directory of the recipe. Here is the *barebox* recipe + +.. code-block:: console + + host:~$ bitbake barebox -c devshell # or linux-mainline, linux-ti, linux-imx, u-boot-imx + +After executing the command, a shell window opens. The current working directory +of the shell will be changed to the source directory of the recipe inside the +*tmp* folder. Here you can use your favorite editor, e.g. *vim*, *emacs*, or any +other graphical editor, to alter the source code. When you are finished, exit +the *devshell* by typing *exit* or hitting **CTRL-D**. + +After leaving the *devshell* you can recompile the package + +.. code-block:: console + + host:~$ bitbake barebox -c compile --force # or linux-mainline, linux-ti, linux-imx, u-boot-imx + +The extra argument '--force' is important because *Yocto* does not recognize +that the source code was changed. + +.. tip:: + + You cannot execute the *bitbake* command in the *devshell* . You have + to leave it first. + +If the build fails, execute the devshell command again and fix it. If the build +is successful, you can deploy the package and create a new SD card image + +.. code-block:: console + + host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox.bin + host:~$ bitbake phytec-headless-image # new WIC image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic + +.. warning:: + + If you execute a clean e.g *bitbake barebox -c clean* , or if *Yocto* fetches + the source code again, all your changes are lost!!! + + To avoid this, you can create a patch and add it to a *bbappend* file. It is + the same workflow as described in the section about changing the + configuration. + + You have to create the patch in the *devshell* if you use the temporary + method and in the subdirectory created by *devtool* if you used *devtool*. + +.. code-block:: console + + host:~$ bitbake barebox -c devshell # Or linux-mainline, linux-ti + host(devshell):~$ git status # Show changes files + host(devshell):~$ git add # Add a special file to the staging area + host(devshell):~$ git commit -m "important modification" # Creates a commit with a not so useful commit message + host(devshell):~$ git format-patch -1 -o ~/ # Creates a patch of the last commit and saves it in your home folder + /home//0001-important-modification.patch # Git prints the path of the written patch file + host(devshell):~$ exit + +After you have created the patch, you must create a *bbappend* file for it. The +locations for the three different recipes - *linux-mainline* , *linux-ti* , and +*barebox* - are + +.. code-block:: + + sources//recipes-kernel/linux/linux-mainline_%.bbappend # For the recipe linux-mainline + sources//recipes-kernel/linux/linux-ti_%.bbappend # For the recipe linux-ti + sources//recipes-kernel/linux/linux-imx_%.bbappend # For the recipe linux-imx + sources//recipes-bsp/barebox/barebox_%.bbappend # For the recipe barebox + sources//recipes-bsp/u-boot/u-boot-imx_%.bbappend # For the recipe u-boot-imx + +The following example is for the recipe *barebox*. You have to adjust the paths. +First, create the folders and move the patch into them. Then create the +*bbappend* file + +.. code-block:: console + + host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features # Or use your own layer instead of *meta-ampliphy* + host:~$ cp ~/0001-important-modification.patch sources/meta-ampliphy/recipes-bsp/barebox/features # copy patch + host:~$ touch sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend + +.. tip:: + + Pay attention to your current work directory. You have to execute the + commands in the BSP top-level directory. Not in the *build* directory! + +After that use your favorite editor to add the following snipped into the +*bbappend* file (here +*sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend*) + +.. code-block:: kconfig + + # contents of the file barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://0001-important-modification.patch \ + " + +Save the file and rebuild the *barebox* recipe with + +.. code-block:: console + + host:~$ bitbake barebox -c clean # Or linux-ti, linux-mainline, linux-imx, u-boot-imx + host:~$ bitbake barebox + +If the build is successful, you can rebuild the final image with + +.. code-block:: console + + host:~$ bitbake phytec-headless-image # Or another image name + +**Further Resources:** + +The *Yocto* Project has some documentation for software developers. Check the +'Kernel Development Manual' for more information about how to configure the +kernel. Please note that not all of the information from the *Yocto* manual can +be applied to the PHYTEC BSP as we use the classic kernel approach of *Yocto* +and most of the documentation assumes the *Yocto* kernel approach. + +- `Yocto - Kernel Development Manual + `_ +- `Yocto - Development Manual + `_ + +Working with the Kernel and Bootloader using SRC_URI in *local.conf* +.................................................................... + +*Here we present a third option to make kernel and bootloader changes. You have +external checkouts of the linux-mainline, linux-ti, or barebox Git +repositories. You will overwrite the URL of the source code fetcher, the +variable SRC_URI, to point to your local checkout instead of the remote +repositories.* + ++----------------------------------+----------------------------------+ +| PRO | CON | ++----------------------------------+----------------------------------+ +| All changes are saved with | Many working directories in | +| *Git* | *build/tmp-\ | +| | glibc/work///* | ++----------------------------------+----------------------------------+ +| | You have to commit every change | +| | before recompiling | ++----------------------------------+----------------------------------+ +| | For each change, the toolchain | +| | compiles everything from scratch | +| | (avoidable with *ccache*) | ++----------------------------------+----------------------------------+ + +First, you need a local clone of the *Git* repository *barebox* or +kernel. If you do not have one, use the commands + +.. code-block:: console + + host:~$ mkdir ~/git + host:~$ cd ~/git + host:~$ git clone git://git.phytec.de/barebox + host:~$ cd barebox + host:~$ git checkout -b v2022.02.0-phy remotes/origin/v2022.02.0-phy + +Add the following snippet to the file build/conf/local.conf + +.. code-block:: kconfig + + # Use your own path to the git repository + # NOTE: Branch name in variable "BRANCH_pn-barebox" should be the same as the + # branch which is used in the repository folder. Otherwise your commits won't be recognized later. + BRANCH:pn-barebox = "v2022.02.0-phy" + SRC_URI:pn-barebox = "git:///${HOME}/git/barebox;branch=${BRANCH}" + SRCREV:pn-barebox = "${AUTOREV}" + +You also have to set the correct BRANCH name in the file. Either you create your +own branch in the *Git* repository, or you use the default (here +"v2015.02.0-phy"). Now you should recompile *barebox* from your own source + +.. code-block:: console + + host:~$ bitbake barebox -c clean + host:~$ bitbake barebox -c compile + +The build should be successful because the source was not changed yet. + +You can alter the source in *~/git/barebox* or the default *defconfig* (e.g. +*~/git/barebox/arch/arm/configs/imx_v7_defconfig*). After you are satisfied with +your changes, you have to make a dummy commit for *Yocto*. If you do not, +*Yocto* will not notice that the source code was modified in your repository +folder (e.g. ~/git/barebox/) + +.. code-block:: console + + host:~$ git status # show modified files + host:~$ git diff # show changed lines + host:~$ git commit -a -m "dummy commit for yocto" # This command is important! + +Try to compile your new changes. *Yocto* will automatically notice that the +source code was changed and fetches and configures everything from scratch. + +.. code-block:: console + + host:~$ bitbake barebox -c compile + +If the build fails, go back to the source directory, fix the problem, and +recommit your changes. If the build was successful, you can deploy *barebox* and +even create a new SD card image. + +.. code-block:: console + + host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox-phyflex-imx6-2.bin + host:~$ bitbake phytec-headless-image # new sd-card image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic + +If you want to make additional changes, just make another commit in the +repository and rebuild *barebox* again. + +Add Existing Software with "Sustainable Method" +............................................... + +Now that you have created your own layer, you have a second option to add +existing software to existing image definitions. Our standard image is defined +in meta-ampliphy + +.. code-block:: + + meta-ampliphy/recipes-images/images/phytec-headless-image.bb + +In your layer, you can now modify the recipe with a *bbappend* without modifying +any BSP code + +.. code-block:: + + meta-racer/recipes-images/images/phytec-headless-image.bbappend + +The append will be parsed together with the base recipe. As a result, you can +easily overwrite all variables set in the base recipe, which is not always what +you want. If we want to include additional software, we need to append it to the +IMAGE_INSTALL variable + +.. code-block:: kconfig + + IMAGE_INSTALL:append = " rsync" + +Add Linux Firmware Files to the Root Filesystem +............................................... + +It is a common task to add an extra firmware file to your root filesystem into +*/lib/firmware/*. For example, WiFi adapters or PCIe Ethernet cards might need +proprietary firmware. As a solution, we use a *bbappend* in our layer. To create +the necessary folders, *bbappend* and copy the firmware file type + +.. code-block:: console + + host:~$ cd meta-racer # go into your layer + host:~$ mkdir -p recipes-kernel/linux-firmware/linux-firmware/ + host:~$ touch recipes-kernel/linux-firmware/linux-firmware_%.bbappend + host:~$ cp ~/example-firmware.bin recipes-kernel/linux-firmware/linux-firmware/ # adapt filename + +Then add the following content to the *bbappend* file and replace every +occurrence of *example-firmware.bin* with your firmware file name. + +.. code-block:: kconfig + + # file recipes-kernel/linux-firmware/linux-firmware_%.bbappend + + FILESEXTRAPATHS:prepend := "${THISDIR}/linux-firmware:" + SRC_URI += "file://example-firmware.bin" + + do_install:append () { + install -m 0644 ${WORKDIR}/example-firmware.bin ${D}/lib/firmware/example-firmware.bin + } + + # NOTE: Use "=+" instead of "+=". Otherwise file is placed into the linux-firmware package. + PACKAGES =+ "${PN}-example" + FILES:${PN}-example = "/lib/firmware/example-firmware.bin" + +Now try to build the linux-firmware recipe + +.. code-block:: console + + host:~$ . sources/poky/oe-init-build-env + host:~$ bitbake linux-firmware + +This should generate a new package *deploy/ipk/all/linux-firmware-example*. + +As the final step, you have to install the firmware package to your image. You +can do that in your *local.conf* or image recipe via + +.. code-block:: kconfig + + # file local.conf or image recipe + IMAGE_INSTALL += "linux-firmware-example" + +.. warning:: + + Ensure that you have adapted the package name *linux-firmware-example* with + the name you assigned in *linux-firmware_%.bbappend*. + +Change the *u-boot* Environment via *bbappend* Files +.................................................... + +All i.MX8M\* products use the u-boot bootloader. The u-boot environment can be +modified using the Temporary Method. In the *u-boot-imx* sources modify the +header file corresponding to the processor located in +*include/configs/phycore_imx8m\**. New environment variables should be added at +the end of *CONFIG_EXTRA_ENV_SETTINGS* + +.. code-block:: kconfig + + #define CONFIG_EXTRA_ENV_SETTINGS \ + [...] + PHYCORE_FITIMAGE_ENV_BOOTLOGIC \ + "newvariable=1\0" + +Commit the changes and and create the file *u-boot-imx_%.bbappend* in your layer +at */recipes-bsp/u-boot/u-boot-imx_%.bbappend* + +.. code-block:: kconfig + + # contents of the file u-boot-imx_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/features:" + SRC_URI:append = " \ + file://0001-environment-addition.patch \ + " + +Change the *barebox* Environment via *bbappend* Files +..................................................... + +Since *BSP-Yocto-AM335x-16.2.0* and *BSP-Yocto-i.MX6-PD16.1.0*, the *barebox* +environment handling in *meta-phytec* has changed. Now it is possible to add, +change, and remove files in the *barebox* environment via the *Python* bitbake +task *do_env*. There are two *Python* functions to change the environment. Their +signatures are: + +- *env_add(d, *\ **filename as string**\ *, *\ **file content as string**\ *)*: + to add a new file or overwrite an existing file +- *env_rm(d, *\ **filename as string**\ *)*: to remove a file + +The first example of a *bbappend* file in the custom layer *meta-racer* shows +how to add a new non-volatile variable *linux.bootargs.fb* in the *barebox* +environment folder */env/nv/* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_add(d, "nv/linux.bootargs.fb", "imxdrm.legacyfb_depth=32\n") + } + +The next example shows how to replace the network configuration file +*/env/network/eth0* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_add(d, "network/eth0", + """#!/bin/sh + + # ip setting (static/dhcp) + ip=static + global.dhcp.vendor_id=barebox-${global.hostname} + + # static setup used if ip=static + ipaddr=192.168.178.5 + netmask=255.255.255.0 + gateway=192.168.178.1 + serverip=192.168.178.1 + """) + } + +In the above example, the *Python* multiline string syntax **""" text """** is +used to avoid adding multiple newline characters *\\n* into the recipe *Python* +code. The *Python* function *env_add* can add and overwrite environment files. + +The next example shows how to remove an already added environment file, for +example *,* */env/boot/mmc* + +.. code-block:: kconfig + + # file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append() { + env_rm(d, "boot/mmc") + } + +Debugging the Environment +~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you want to see all environment files that are added in the build process, +you can enable a debug flag in the *local.conf* + +.. code-block:: kconfig + + # file local.conf + ENV_VERBOSE = "1" + +After that, you have to rebuild the *barebox* recipe to see the debugging +output + +.. code-block:: console + + host:~$ bitbake barebox -c clean + host:~$ bitbake barebox -c configure + +The output of the last command looks like this + +.. code-block:: + + [...] + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/allow_color' content "false" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.base' content "consoleblank=0" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.fb' content "imxdrm.legacyfb_depth=32" + WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.rootfs' content "rootwait ro fsck.repair=yes" + +Changing the Environment (depending on Machines) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you need to apply some *barebox* environment modifications only to a single +or only a few machines, you can use *Bitbake'* s machine overwrite syntax. For +the machine overwrite syntax, you append a machine name or SoC name (such as +*mx6* , *ti33x,* or *rk3288* ) with an underscore to a variable or task + +.. code-block:: kconfig + + DEPENDS:remove:mx6 = "virtual/libgl" or + python do_env_append_phyboard-mira-imx6-4(). + +The next example adds the environment variables only if the MACHINE is set to +*phyboard-mira-imx6-4* + +.. code-block:: kconfig + + # file meta-phytec/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend + python do_env:append:phyboard-mira-imx6-4() { + env_add(d, "nv/linux.bootargs.cma", "cma=64M\n") + } + +*Bitbake's* override syntax for variables is explained in more detail at: +https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-metadata.html#conditional-metadata + +Upgrading the *barebox* Environment from Previous BSP Releases +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Prior to BSP version *BSP-Yocto-AM335x-16.2.0* and *BSP-Yocto-i.MX6-PD16.1.0* , +*barebox* environment changes via *bbappend* file were done differently. For +example, the directory structure in your meta layer (here *meta-skeleton* ) may +have looked like this + +.. code-block:: console + + host:~$ tree -a sources/meta-skeleton/recipes-bsp/barebox/ + sources/meta-skeleton/recipes-bsp/barebox + ├── barebox + │ └── phyboard-wega-am335x-3 + │ ├── boardenv + │ │ └── .gitignore + │ └── machineenv + │ └── nv + │ └── linux.bootargs.cma + └── barebox_%.bbappend + +and the file *barebox_%.bbappend* contained + +.. code-block:: kconfig + + # file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:" + +In this example, all environment changes from the directory *boardenv* in the +layer *meta-phytec* are ignored and the file *nv/linux.bootargs.cma* is added. +For the new handling of the *barebox* environment, you use the *Python* +functions *env_add* and *env_rm* in the *Python* task *do_env*. Now the above +example translates to a single *Python* function in the file +*barebox_%.bbappend* that looks like + +.. code-block:: kconfig + + # file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend + FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:" + python do_env:append() { + # Removing files (previously boardenv) + env_rm(d, "config-expansions") + # Adding new files (previously machineenv) + env_add(d, "nv/linux.bootargs.cma", "cma=64M\n") + } + +.. _scarthgap_changing-net-config: + +Changing the Network Configuration +.................................. + +To tweak IP addresses, routes, and gateways at runtime you can use the tools +*ifconfig* and *ip* . Some examples + +.. code-block:: console + + target:~$ ip addr # Show all network interfaces + target:~$ ip route # Show all routes + target:~$ ip addr add 192.168.178.11/24 dev eth0 # Add static ip and route to interface eth0 + target:~$ ip route add default via 192.168.178.1 dev eth0 # Add default gateway 192.168.178.1 + target:~$ ip addr del 192.168.178.11/24 dev eth0 # Remove static ip address from interface eth0 + +The network configuration is managed by *systemd-networkd* . To query the +current status use + +.. code-block:: console + + target:~$ networkctl status + target:~$ networkctl list + +The network daemon reads its configuration from the directories +*/etc/systemd/network/* , */run/systemd/network/* , and */lib/systemd/network/* +(from higher to lower priority). A sample configuration in +*/lib/systemd/network/10-eth0.network* looks like this + +.. code-block:: kconfig + + # file /lib/systemd/network/10-eth0.network + [Match] + Name=eth0 + + [Network] + Address=192.168.3.11/24 + Gateway=192.168.3.10 + +These files *\*.network* replace */etc/network/interfaces* from other +distributions. You can either edit the file *10-eth0.network* in-place or copy +it to */etc/systemd/network/* and make your changes there. After changing a file +you must restart the daemon to apply your changes + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +To see the syslog message of the network daemon, use + +.. code-block:: console + + target:~$ journalctl --unit=systemd-networkd.service + +To modify the network configuration at build time, look at the recipe +*sources/meta-ampliphy/recipes-core/systemd/systemd-machine-units.bb* +and the interface files in the folder +*meta-ampliphy/recipes-core/systemd/systemd-machine-units/* where the static IP +address configuration for *eth0* (and optionally *eth1*) is done. + +For more information, see https://wiki.archlinux.org/title/Systemd-networkd +and https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html. + +Changing the Wireless Network Configuration +........................................... + +Connecting to a WLAN Network +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- First set the correct regulatory domain for your country + +.. code-block:: console + + target:~$ iw reg set DE + target:~$ iw reg get + +You will see + +.. code-block:: + + country DE: DFS-ETSI + (2400 - 2483 @ 40), (N/A, 20), (N/A) + (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR + (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS + (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS + (57000 - 66000 @ 2160), (N/A, 40), (N/A) + +- Set up the wireless interface + +.. code-block:: console + + target:~$ ip link # list all interfaces. Search for wlan* + target:~$ ip link set up dev wlan0 + +- Now you can scan for available networks + +.. code-block:: console + + target:~$ iw wlan0 scan | grep SSID + +You can use a cross-platform supplicant with support for *WEP*, *WPA*, and +*WPA2* called *wpa_supplicant* for an encrypted connection. + +- To do so, add the network credentials to the file + */etc/wpa_supplicant.conf* + +.. code-block:: kconfig + + Confluence country=DE network={ ssid="" proto=WPA2 psk="" } + +- Now a connection can be established + +.. code-block:: console + + target:~$ wpa_supplicant -Dnl80211 -c/etc/wpa_supplicant.conf -iwlan0 -B + +This should result in the following output + +.. code-block:: kconfig + + ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=] + +To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see the section :ref:`scarthgap_changing-net-config`. + +- First, create the directory + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + +- Then add the following configuration snippet in + */etc/systemd/network/10-wlan0.network* + +.. code-block:: kconfig + + # file /etc/systemd/network/10-wlan0.network + [Match] + Name=wlan0 + + [Network] + DHCP=yes + +- Now, restart the network daemon so that the configuration takes effect + +.. code-block:: console + + target:~$ systemctl restart systemd-networkd + +Creating a WLAN Access Point +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This section provides a basic access point (AP) configuration for a +secured *WPA2* network. + +Find the name of the WLAN interface with + +.. code-block:: console + + target:~$ ip link + +Edit the configuration in */etc/hostapd.conf*. It is strongly dependent on +the use case. The following shows an example + +.. code-block:: kconfig + + # file /etc/hostapd.conf + interface=wlan0 + driver=nl80211 + ieee80211d=1 + country_code=DE + hw_mode=g + ieee80211n=1 + ssid=Test-Wifi + channel=2 + wpa=2 + wpa_passphrase=12345678 + wpa_key_mgmt=WPA-PSK + wpa_pairwise=CCMP + +Set up and start the DHCP server for the network interface *wlan0* via +*systemd-networkd* + +.. code-block:: console + + target:~$ mkdir -p /etc/systemd/network/ + target:~$ vi /etc/systemd/network/10-wlan0.network + +Insert the following text into the file + +.. code-block:: kconfig + + [Match] + Name=wlan0 + + [Network] + Address=192.168.0.1/24 + DHCPServer=yes + + [DHCPServer] + EmitDNS=yes + target:~$ systemctl restart systemd-networkd + target:~$ systemctl status systemd-networkd -l # check status and see errors + +Start the userspace daemon *hostapd* + +.. code-block:: console + + target:~$ systemctl start hostapd + target:~$ systemctl status hostapd -l # check for errors + +Now, you should see the WLAN network *Test-Wifi* on your terminal device +(laptop, smartphone, etc.). + +If there are problems with the access point, you can either check the log +messages with + +.. code-block:: console + + target:~$ journalctl --unit=hostapd + +or start the daemon in debugging mode from the command line + +.. code-block:: console + + target:~$ systemctl stop hostapd + target:~$ hostapd -d /etc/hostapd.conf -P /var/run/hostapd.pid + +You should see + +.. code-block:: + + ... + wlan0: interface state UNINITIALIZED->ENABLED + wlan0: AP-ENABLED + +Further information about AP settings and the userspace daemon +*hostapd* can be found at + +.. code-block:: + + https://wireless.wiki.kernel.org/en/users/documentation/hostapd + https://w1.fi/hostapd/ + +phyCORE-i.MX 6UL/ULL Bluetooth +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Special consideration must be paid when working with any Bluetooth on a +phyCORE-i.MX 6UL/ULL. For further information, please check `L-844e.A5 i.MX +6UL/ULL BSP Manual - Bluetooth +`_. + +Add OpenCV Libraries and Examples +................................. + +*OpenCV* (Opensource Computer Vision https://opencv.org/) is an open-source +library for computer vision applications. + +To install the libraries and examples edit the file *conf/local.conf* in the +*Yocto* build system and add + +.. code-block:: kconfig + + # file conf/local.conf + # Installing OpenCV libraries and examples + LICENSE_FLAGS_ACCEPTED += "commercial_libav" + LICENSE_FLAGS_ACCEPTED += "commercial_x264" + IMAGE_INSTALL:append = " \ + opencv \ + opencv-samples \ + libopencv-calib3d2.4 \ + libopencv-contrib2.4 \ + libopencv-core2.4 \ + libopencv-flann2.4 \ + libopencv-gpu2.4 \ + libopencv-highgui2.4 \ + libopencv-imgproc2.4 \ + libopencv-legacy2.4 \ + libopencv-ml2.4 \ + libopencv-nonfree2.4 \ + libopencv-objdetect2.4 \ + libopencv-ocl2.4 \ + libopencv-photo2.4 \ + libopencv-stitching2.4 \ + libopencv-superres2.4 \ + libopencv-video2.4 \ + libopencv-videostab2.4 \ + " + +Then rebuild your image + +.. code-block:: console + + host:~$ bitbake phytec-qt6demo-image + +.. tip:: + + Most examples do not work out of the box, because they depend on the *GTK* + graphics library. The BSP only supports *Qt6* . + +Add Minimal PHP web runtime with *lightpd* +.......................................... + +This is one example of how to add a small runtime for PHP applications and a web +server on your target. Lighttpd can be used together with the PHP command line +tool over cgi. This solution weights only 5.5 MiB of disk storage. It is already +preconfigured in meta-ampliphy. Just modify the build configuration to install +it on the image + +.. code-block:: kconfig + + # file conf/local.conf + # install lighttpd with php cgi module + IMAGE_INSTALL:append = " lighttpd" + +After booting the image, you should find the example web content in */www/pages* +. For testing php, you can delete the *index.html* and replace it with a +*index.php* file + +.. code-block:: html + + + + PHP-Test + + + + + + +On your host, you can point your browser to the board's IP, (e.g. 192.168.3.11) +and the phpinfo should show up. + +Common Tasks +------------ + +Debugging a User Space Application +.................................. + +The phytec-qt6demo-image can be cross-debugged without any change. For +cross-debugging, you just have to match the host sysroot with the image in use. +So you need to create a toolchain for your image + +.. code-block:: console + + host:~$ bitbake -c populate_sdk phytec-qt6demo-image + +Additionally, if you want to have full debug and backtrace capabilities for all +programs and libraries in the image, you could add + +.. code-block:: kconfig + + DEBUG_BUILD = "1" + +to the ``conf/local.conf``. This is not necessary in all cases. The compiler +options will then be switched from FULL_OPTIMIZATION to DEBUG_OPTIMIZATION. Look +at the *Poky* source code for the default assignment of DEBUG_OPTIMIZATION. + +To start a cross debug session, install the SDK as mentioned previously, source +the SDK environment, and run *Qt Creator* in the same shell. If you do not use +*Qt Creator*, you can directly call the arm-<..>-gdb debugger instead which +should be in your path after sourcing the environment script. + +If you work with *Qt Creator*, have a look at the appropriate documentation +delivered with your product (either QuickStart or Application Guide) for +information on how to set up the toolchain. + +When starting the debugger with your userspace application you will get a +SIGILL, an illegal instruction from the *libcrypto*. *Openssl* probes for the +system capabilities by trapping illegal instructions, which will trigger *GDB*. +You can ignore this and hit **Continue** (c command). You can permanently ignore +this stop by adding + +.. code-block:: kconfig + + handle SIGILL nostop + +to your *GDB* startup script or in the *Qt Creator GDB* configuration panel. +Secondly, you might need to disable a security feature by adding + +.. code-block:: kconfig + + set auto-load safe-path / + +to the same startup script, which will enable the automatic loading of libraries +from any location. + +If you need to have native debugging, you might want to install the debug +symbols on the target. You can do this by adding the following line to your +*conf/local.conf* + +.. code-block:: kconfig + + EXTRA_IMAGE_FEATURES += "dbg-pkgs" + +For cross-debugging, this is not required as the debug symbols will be loaded +from the host side and the dbg-pkgs are included in the SDK of your image +anyway. + +.. _scarthgap_gen-source-mirrors: + +Generating Source Mirrors, working Offline +.......................................... + +Modify your *site.conf* (or *local.conf* if you do not use a *site.conf* ) as +follows + +.. code-block:: kconfig + + #DL_DIR ?= "" don't set it! It will default to a directory inside /build + SOURCE_MIRROR_URL = "file:///home/share/yocto_downloads/" + INHERIT += "own-mirrors" + BB_GENERATE_MIRROR_TARBALLS = "1" + +Now run + +.. code-block:: console + + host:~$ bitbake --runall=fetch + +for all images and for all machines you want to provide sources for. This will +create all the necessary *tar* archives. We can remove all SCM subfolders, as +they are duplicated with the tarballs + +.. code-block:: console + + host:~$ rm -rf build/download/git2/ + etc... + +Please consider that we used a local source mirror for generating the dl_dir. +Because of that, some archives will be linked locally. + +First, we need to copy all files, resolving symbolic links into the new mirror +directory + +.. code-block:: console + + host:~$ rsync -vaL ${TOPDIR}/../src_mirror/ + +Now we clean the */build* directory by deleting everything except */build/conf/* +but including */build/conf/sanity*. We change *site.conf* as follows + +.. code-block:: kconfig + + SOURCE_MIRROR_URL = "file://${TOPDIR}/../src_mirror" + INHERIT += "own-mirrors" + BB_NO_NETWORK = "1" + SCONF_VERSION = "1" + +The BSP directory can now be compressed with + +.. code-block:: console + + host:~$ tar cfJ .tar.xz + +where filename and folder should be the full BSP Name. + +Compiling on the Target +....................... + +To your *local.conf* add + +.. code-block:: kconfig + + IMAGE_FEATURES:append = " tools-sdk dev-pkgs" + +Different Toolchains +.................... + +There are several ways to create a toolchain installer in *Poky*. One option is +to run + +.. code-block:: console + + host:~$ bitbake meta-toolchain + +This will generate a toolchain installer in *build/deploy/sdk* which can be used +for cross-compiling of target applications. However, the installer does not +include libraries added to your image, so it is a bare *GCC* compiler only. This +is suited for bootloader and kernel development. + +Another you can run is + +.. code-block:: console + + host:~$ bitbake -c populate_sdk + +This will generate a toolchain installer containing all necessary development +packages of the software installed on the root filesystem of the target. This +installer can be handed over to the user space application development team and +includes all necessary parts to develop an application. If the image contains +the *QT* libraries, all of those will be available in the installer too. + +The third option is to create the ADT (Application Development Toolkit) +installer. It will contain the cross-toolchain and some tools to aid the +software developers, for example, an *Eclipse* plugin and a *QEMU* target +simulator. + +.. code-block:: console + + host:~$ bitbake adt-installer + +The ADT is untested for our BSP at the moment. + +Using the SDK +~~~~~~~~~~~~~ + +After generating the SDK with + +.. code-block:: console + + host:~$ source sources/poky/oe-init-build-env + host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image + +run the generated binary with + +.. code-block:: console + + host:~$ deploy/sdk/ampliphy-glibc-x86_64-phytec-qt6demo-image-cortexa9hf-vfp-neon-toolchain-i.MX6-PD15.3-rc.sh + Enter target directory for SDK (default: /opt/ampliphy/i.MX6-PD15.3-rc): + You are about to install the SDK to "/opt/ampliphy/i.MX6-PD15.3-rc". Proceed[Y/n]? + Extracting SDK...done + Setting it up...done + SDK has been successfully set up and is ready to be used. + +You can activate the toolchain for your shell by sourcing the file +*environment-setup* in the toolchain directory + +.. code-block:: console + + host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + +.. note:: + + To be able to build a Qt6 application with the SDK and the Meson Build system, the following has to be done, *after* the SDK has been sourced: + + .. code-block:: console + + host:~$ export PATH=$OECORE_NATIVE_SYSROOT/usr/libexec:$PATH + + +Then the necessary tools like the cross compiler and linker are in your PATH. To +compile a simple *C* program, use + +.. code-block:: console + + host:~$ $CC main.c -o main + +The environment variable $CC contains the path to the ARM cross compiler and +other compiler arguments needed like *-march* , *-sysroot* and *--mfloat-abi*. + +.. tip:: + + You cannot compile programs only with the compiler name like + + .. code-block:: console + + host:~$ arm-phytec-linux-gnueabi-gcc main.c -o main + + It will fail in many cases. Always use *CC*, CFLAGS, LDFLAGS, and so on. + +For convenience, the *environment-setup* exports other environment variables +like CXX, LD, SDKTARGETSYSROOT. + +A simple makefile compiling a *C* and *C++* program may look like this + +.. code-block:: kconfig + + # Makefile + TARGETS=c-program cpp-program + + all: $(TARGETS) + + c-program: c-program.c + $(CC) $(CFLAGS) $(LDFLAGS) $< -o $@ + + cpp-program: cpp-program.cpp + $(CXX) $(CXXFLAGS) $(LDFLAGS) $< -o $@ + + .PHONY: clean + clean: + rm -f $(TARGETS) + +To compile for the target, just source the toolchain in your shell before +executing make + +.. code-block:: console + + host:~$ make # Compiling with host CC, CXX for host architecture + host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + host:~$ make # Compiling with target CC, CXX for target architecture + +If you need to specify additionally included directories in the sysroot of the +toolchain, you can use an '=' sign in the *-I* argument like + +.. code-block:: kconfig + + -I=/usr/include/SDL + +*GCC* replaces it by the sysroot path (here +*/opt/ampliphy/i.MX6-PD15.3-rc/sysroots/cortexa9hf-vfp-neon-phytec-linux-gnueabi/*). +See the main page of *GCC* for more information. + +.. tip:: + + The variables $CFLAGS and $CXXFLAGS contain the compiler debug flag '-g' by + default. This includes debugging information in the binary and making it + bigger. Those should be removed from the production image. If you create a + *Bitbake* recipe, the default behavior is to turn on '-g' too. The debugging + symbols are used in the SDK rootfs to be able to get debugging information + when invoking *GDB* from the host. Before installing the package to the + target rootfs, *Bitbake* will invoke *strip* on the program which removes the + debugging symbols. By default, they are not found nor required on the target + root filesystem + +Using the SDK with GNU Autotools +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +*Yocto* SDK is a straightforward tool for a project that uses the *GNU +Autotools*. The traditional compile steps for the host are usually + +.. code-block:: console + + host:~$ ./autogen.sh # maybe not needed + host:~$ ./configure + host:~$ make + host:~$ make install DESTDIR=$PWD/build/ + +The commands to compile for the target machine with the *Yocto* SDK are quite +similar. The following commands assume that the SDK was unpacked to the +directory */opt/phytec-ampliphy/i.MX6-PD15.3.0/* (adapt the path as needed) + +.. code-block:: console + + host:~$ source /opt/phytec-ampliphy/i.MX6-PD15.3.0/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi + host:~$ ./autogen.sh # maybe not needed + host:~$ ./configure ${CONFIGURE_FLAGS} + host:~$ make + host:~$ make install DESTDIR=$PWD/build/ + +Refer to the official *Yocto* documentation for more information: +https://docs.yoctoproject.org/dev/singleindex.html#autotools-based-projects + +Working with Kernel Modules +........................... + +You will come to the point where you either need to set some options for a +kernel module or you want to blacklist a module. Those things are handled by +*udev* and go into *\*.conf* files in + +.. code-block:: + + /etc/modprobe.d/\*.conf. + +If you want to specify an option at build time, there are three relevant +variables. If you just want to autoload a module that has no autoload +capabilities, add it to + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + +either in the kernel recipe or in the global variable scope. If you need to +specify options for a module, you can do so with + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + KERNEL_MODULE_PROBECONF += "your-module" + module_conf_your-module = "options your-module parametername=parametervalue" + +if you want to blacklist a module from autoloading, you can do it intuitively +with + +.. code-block:: kconfig + + KERNEL_MODULE_AUTOLOAD += "your-module" + KERNEL_MODULE_PROBECONF += "your-module" + module_conf_your-module = "blacklist your-module" + +Working with *udev* +................... + +Udev (Linux dynamic device management) is a system daemon that handles dynamic +device management in /dev. It is controlled by *udev* \ rules that are located +in */etc/udev/rules.d* (sysadmin configuration space) and\ */lib/udev/rules.d/* +(vendor-provided). Here is an example of an *udev* \ rule file + +.. code-block:: kconfig + + # file /etc/udev/rules.d/touchscreen.rules + # Create a symlink to any touchscreen input device + SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="input:*-e0*,3,*a0,1,*18,*", SYMLINK+="input/touchscreen0" + SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="ads7846", SYMLINK+="input/touchscreen0" + +See https://www.freedesktop.org/software/systemd/man/latest/udev.html for more details +about the syntax and usage. To get the list of attributes for a specific device +that can be used in an *udev* rule you can use the *udevadm info* tool. It +prints all existing attributes of the device node and its parents. The key-value +pairs from the output can be copied and pasted into a rule file. Some examples + +.. code-block:: console + + target:~$ udevadm info -a /dev/mmcblk0 + target:~$ udevadm info -a /dev/v4l-subdev25 + target:~$ udevadm info -a -p /sys/class/net/eth0 + +After changing an *udev* rule, you have to notify the daemon. Otherwise, your +changes are not reflected. Use the following command + +.. code-block:: console + + target:~$ udevadm control --reload-rules + +While developing *udev* rules you should monitor the events in order to see when +devices are attached or unattached to the system. Use + +.. code-block:: console + + target:~$ udevadm monitor + +Furthermore, it is very useful to monitor the system log in another shell, +especially if the rule executes external scripts. Execute + +.. code-block:: console + + target:~$ journalctl -f + +.. tip:: + + You cannot start daemons or heavy scripts in a *RUN* attribute. See + https://www.freedesktop.org/software/systemd/man/latest/udev.html#RUN%7Btype%7D . + + This can only be used for very short-running foreground tasks. Running an + event process for a long period of time may block all further events for this + or a dependent device. Starting daemons or other long-running processes is + not appropriate for *udev*; the forked processes, detached or not, will be + unconditionally killed after the event handling has finished. You can use the + special attribute *ENV{SYSTEMD_WANTS}="service-name.service"* and a + *systemd*\ service instead. + + See + https://unix.stackexchange.com/questions/63232/what-is-the-correct-way-to-write-a-udev-rule-to-stop-a-service-under-systemd. + +Troubleshooting +=============== + +Setscene Task Warning +--------------------- + +This warning occurs when the Yocto cache is in a dirty state. + +.. code-block:: + + WARNING: Setscene task X ([...]) failed with exit code '1' - real task + +You should avoid canceling the build process or if you have to, press Ctrl-C +once and wait until the build process has stopped. To remove all these warnings +just clean the sstate cache and remove the build folders. + +.. code-block:: console + + host:~$ bitbake phytec-headless-image -c cleansstate && rm -rf tmp deploy/ipk + +Yocto Documentation +=================== + +The most important piece of documentation for a BSP user is probably the +developer manual. +https://docs.yoctoproject.org/dev/dev-manual/index.html + +The chapter about common tasks is a good starting point. +https://docs.yoctoproject.org/dev/dev-manual/layers.html#understanding-and-creating-layers + +The complete documentation is available on one single HTML page, which is good +for searching for a feature or a variable name. +https://docs.yoctoproject.org/dev/singleindex.html diff --git a/previews/271/zh_CN/_static/_sphinx_javascript_frameworks_compat.js b/previews/271/zh_CN/_static/_sphinx_javascript_frameworks_compat.js new file mode 100644 index 000000000..81415803e --- /dev/null +++ b/previews/271/zh_CN/_static/_sphinx_javascript_frameworks_compat.js @@ -0,0 +1,123 @@ +/* Compatability shim for jQuery and underscores.js. + * + * Copyright Sphinx contributors + * Released under the two clause BSD licence + */ + +/** + * small helper function to urldecode strings + * + * See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/decodeURIComponent#Decoding_query_parameters_from_a_URL + */ +jQuery.urldecode = function(x) { + if (!x) { + return x + } + return decodeURIComponent(x.replace(/\+/g, ' ')); +}; + +/** + * small helper function to urlencode strings + */ +jQuery.urlencode = encodeURIComponent; + +/** + * This function returns the parsed url parameters of the + * current request. Multiple values per key are supported, + * it will always return arrays of strings for the value parts. + */ +jQuery.getQueryParameters = function(s) { + if (typeof s === 'undefined') + s = document.location.search; + var parts = s.substr(s.indexOf('?') + 1).split('&'); + var result = {}; + for (var i = 0; i < parts.length; i++) { + var tmp = parts[i].split('=', 2); + var key = jQuery.urldecode(tmp[0]); + var value = jQuery.urldecode(tmp[1]); + if (key in result) + result[key].push(value); + else + result[key] = [value]; + } + return result; +}; + +/** + * highlight a given string on a jquery object by wrapping it in + * span elements with the given class name. + */ +jQuery.fn.highlightText = function(text, className) { + function highlight(node, addItems) { + if (node.nodeType === 3) { + var val = node.nodeValue; + var pos = val.toLowerCase().indexOf(text); + if (pos >= 0 && + !jQuery(node.parentNode).hasClass(className) && + !jQuery(node.parentNode).hasClass("nohighlight")) { + var span; + var isInSVG = jQuery(node).closest("body, svg, foreignObject").is("svg"); + if (isInSVG) { + span = document.createElementNS("http://www.w3.org/2000/svg", "tspan"); + } else { + span = document.createElement("span"); + span.className = className; + } + span.appendChild(document.createTextNode(val.substr(pos, text.length))); + node.parentNode.insertBefore(span, node.parentNode.insertBefore( + document.createTextNode(val.substr(pos + text.length)), + node.nextSibling)); + node.nodeValue = val.substr(0, pos); + if (isInSVG) { + var rect = document.createElementNS("http://www.w3.org/2000/svg", "rect"); + var bbox = node.parentElement.getBBox(); + rect.x.baseVal.value = bbox.x; + rect.y.baseVal.value = bbox.y; + rect.width.baseVal.value = bbox.width; + rect.height.baseVal.value = bbox.height; + rect.setAttribute('class', className); + addItems.push({ + "parent": node.parentNode, + "target": rect}); + } + } + } + else if (!jQuery(node).is("button, select, textarea")) { + jQuery.each(node.childNodes, function() { + highlight(this, addItems); + }); + } + } + var addItems = []; + var result = this.each(function() { + highlight(this, addItems); + }); + for (var i = 0; i < addItems.length; ++i) { + jQuery(addItems[i].parent).before(addItems[i].target); + } + return result; +}; + +/* + * backward compatibility for jQuery.browser + * This will be supported until firefox bug is fixed. + */ +if (!jQuery.browser) { + jQuery.uaMatch = function(ua) { + ua = ua.toLowerCase(); + + var match = /(chrome)[ \/]([\w.]+)/.exec(ua) || + /(webkit)[ \/]([\w.]+)/.exec(ua) || + /(opera)(?:.*version|)[ \/]([\w.]+)/.exec(ua) || + /(msie) ([\w.]+)/.exec(ua) || + ua.indexOf("compatible") < 0 && /(mozilla)(?:.*? rv:([\w.]+)|)/.exec(ua) || + []; + + return { + browser: match[ 1 ] || "", + version: match[ 2 ] || "0" + }; + }; + jQuery.browser = {}; + jQuery.browser[jQuery.uaMatch(navigator.userAgent).browser] = true; +} diff --git a/previews/271/zh_CN/_static/basic.css b/previews/271/zh_CN/_static/basic.css new file mode 100644 index 000000000..7ebbd6d07 --- /dev/null +++ b/previews/271/zh_CN/_static/basic.css @@ -0,0 +1,914 @@ +/* + * Sphinx stylesheet -- basic theme. + */ + +/* -- main layout ----------------------------------------------------------- */ + +div.clearer { + clear: both; +} + +div.section::after { + display: block; + content: ''; + clear: left; +} + +/* -- relbar ---------------------------------------------------------------- */ + +div.related { + width: 100%; + font-size: 90%; +} + +div.related h3 { + display: none; +} + +div.related ul { + margin: 0; + padding: 0 0 0 10px; + list-style: none; +} + +div.related li { + display: inline; +} + +div.related li.right { + float: right; + margin-right: 5px; +} + +/* -- sidebar --------------------------------------------------------------- */ + +div.sphinxsidebarwrapper { + padding: 10px 5px 0 10px; +} + +div.sphinxsidebar { + float: left; + width: 230px; + margin-left: -100%; + font-size: 90%; + word-wrap: break-word; + overflow-wrap : break-word; +} + +div.sphinxsidebar ul { + list-style: none; +} + +div.sphinxsidebar ul ul, +div.sphinxsidebar ul.want-points { + margin-left: 20px; + list-style: square; +} + +div.sphinxsidebar ul ul { + margin-top: 0; + margin-bottom: 0; +} + +div.sphinxsidebar form { + margin-top: 10px; +} + +div.sphinxsidebar input { + border: 1px solid #98dbcc; + font-family: sans-serif; + font-size: 1em; +} + +div.sphinxsidebar #searchbox form.search { + overflow: hidden; +} + +div.sphinxsidebar #searchbox input[type="text"] { + float: left; + width: 80%; + padding: 0.25em; + box-sizing: border-box; +} + +div.sphinxsidebar #searchbox input[type="submit"] { + float: left; + width: 20%; + border-left: none; + padding: 0.25em; + box-sizing: border-box; +} + + +img { + border: 0; + max-width: 100%; +} + +/* -- search page ----------------------------------------------------------- */ + +ul.search { + margin-top: 10px; +} + +ul.search li { + padding: 5px 0; +} + +ul.search li a { + font-weight: bold; +} + +ul.search li p.context { + color: #888; + margin: 2px 0 0 30px; + text-align: left; +} + +ul.keywordmatches li.goodmatch a { + font-weight: bold; +} + +/* -- index page ------------------------------------------------------------ */ + +table.contentstable { + width: 90%; + margin-left: auto; + margin-right: auto; +} + +table.contentstable p.biglink { + line-height: 150%; +} + +a.biglink { + font-size: 1.3em; +} + +span.linkdescr { + font-style: italic; + padding-top: 5px; + font-size: 90%; +} + +/* -- general index --------------------------------------------------------- */ + +table.indextable { + width: 100%; +} + +table.indextable td { + text-align: left; + vertical-align: top; +} + +table.indextable ul { + margin-top: 0; + margin-bottom: 0; + list-style-type: none; +} + +table.indextable > tbody > tr > td > ul { + padding-left: 0em; +} + +table.indextable tr.pcap { + height: 10px; +} + +table.indextable tr.cap { + margin-top: 10px; + background-color: #f2f2f2; +} + +img.toggler { + margin-right: 3px; + margin-top: 3px; + cursor: pointer; +} + +div.modindex-jumpbox { + border-top: 1px solid #ddd; + border-bottom: 1px solid #ddd; + margin: 1em 0 1em 0; + padding: 0.4em; +} + +div.genindex-jumpbox { + border-top: 1px solid #ddd; + border-bottom: 1px solid #ddd; + margin: 1em 0 1em 0; + padding: 0.4em; +} + +/* -- domain module index --------------------------------------------------- */ + +table.modindextable td { + padding: 2px; + border-collapse: collapse; +} + +/* -- general body styles --------------------------------------------------- */ + +div.body { + min-width: 360px; + max-width: 800px; +} + +div.body p, div.body dd, div.body li, div.body blockquote { + -moz-hyphens: auto; + -ms-hyphens: auto; + -webkit-hyphens: auto; + hyphens: auto; +} + +a.headerlink { + visibility: hidden; +} + +a:visited { + color: #551A8B; +} + +h1:hover > a.headerlink, +h2:hover > a.headerlink, +h3:hover > a.headerlink, +h4:hover > a.headerlink, +h5:hover > a.headerlink, +h6:hover > a.headerlink, +dt:hover > a.headerlink, +caption:hover > a.headerlink, +p.caption:hover > a.headerlink, +div.code-block-caption:hover > a.headerlink { + visibility: visible; +} + +div.body p.caption { + text-align: inherit; +} + +div.body td { + text-align: left; +} + +.first { + margin-top: 0 !important; +} + +p.rubric { + margin-top: 30px; + font-weight: bold; +} + +img.align-left, figure.align-left, .figure.align-left, object.align-left { + clear: left; + float: left; + margin-right: 1em; +} + +img.align-right, figure.align-right, .figure.align-right, object.align-right { + clear: right; + float: right; + margin-left: 1em; +} + +img.align-center, figure.align-center, .figure.align-center, object.align-center { + display: block; + margin-left: auto; + margin-right: auto; +} + +img.align-default, figure.align-default, .figure.align-default { + display: block; + margin-left: auto; + margin-right: auto; +} + +.align-left { + text-align: left; +} + +.align-center { + text-align: center; +} + +.align-default { + text-align: center; +} + +.align-right { + text-align: right; +} + +/* -- sidebars -------------------------------------------------------------- */ + +div.sidebar, +aside.sidebar { + margin: 0 0 0.5em 1em; + border: 1px solid #ddb; + padding: 7px; + background-color: #ffe; + width: 40%; + float: right; + clear: right; + overflow-x: auto; +} + +p.sidebar-title { + font-weight: bold; +} + +nav.contents, +aside.topic, +div.admonition, div.topic, blockquote { + clear: left; +} + +/* -- topics ---------------------------------------------------------------- */ + +nav.contents, +aside.topic, +div.topic { + border: 1px solid #ccc; + padding: 7px; + margin: 10px 0 10px 0; +} + +p.topic-title { + font-size: 1.1em; + font-weight: bold; + margin-top: 10px; +} + +/* -- admonitions ----------------------------------------------------------- */ + +div.admonition { + margin-top: 10px; + margin-bottom: 10px; + padding: 7px; +} + +div.admonition dt { + font-weight: bold; +} + +p.admonition-title { + margin: 0px 10px 5px 0px; + font-weight: bold; +} + +div.body p.centered { + text-align: center; + margin-top: 25px; +} + +/* -- content of sidebars/topics/admonitions -------------------------------- */ + +div.sidebar > :last-child, +aside.sidebar > :last-child, +nav.contents > :last-child, +aside.topic > :last-child, +div.topic > :last-child, +div.admonition > :last-child { + margin-bottom: 0; +} + +div.sidebar::after, +aside.sidebar::after, +nav.contents::after, +aside.topic::after, +div.topic::after, +div.admonition::after, +blockquote::after { + display: block; + content: ''; + clear: both; +} + +/* -- tables ---------------------------------------------------------------- */ + +table.docutils { + margin-top: 10px; + margin-bottom: 10px; + border: 0; + border-collapse: collapse; +} + +table.align-center { + margin-left: auto; + margin-right: auto; +} + +table.align-default { + margin-left: auto; + margin-right: auto; +} + +table caption span.caption-number { + font-style: italic; +} + +table caption span.caption-text { +} + +table.docutils td, table.docutils th { + padding: 1px 8px 1px 5px; + border-top: 0; + border-left: 0; + border-right: 0; + border-bottom: 1px solid #aaa; +} + +th { + text-align: left; + padding-right: 5px; +} + +table.citation { + border-left: solid 1px gray; + margin-left: 1px; +} + +table.citation td { + border-bottom: none; +} + +th > :first-child, +td > :first-child { + margin-top: 0px; +} + +th > :last-child, +td > :last-child { + margin-bottom: 0px; +} + +/* -- figures --------------------------------------------------------------- */ + +div.figure, figure { + margin: 0.5em; + padding: 0.5em; +} + +div.figure p.caption, figcaption { + padding: 0.3em; +} + +div.figure p.caption span.caption-number, +figcaption span.caption-number { + font-style: italic; +} + +div.figure p.caption span.caption-text, +figcaption span.caption-text { +} + +/* -- field list styles ----------------------------------------------------- */ + +table.field-list td, table.field-list th { + border: 0 !important; +} + +.field-list ul { + margin: 0; + padding-left: 1em; +} + +.field-list p { + margin: 0; +} + +.field-name { + -moz-hyphens: manual; + -ms-hyphens: manual; + -webkit-hyphens: manual; + hyphens: manual; +} + +/* -- hlist styles ---------------------------------------------------------- */ + +table.hlist { + margin: 1em 0; +} + +table.hlist td { + vertical-align: top; +} + +/* -- object description styles --------------------------------------------- */ + +.sig { + font-family: 'Consolas', 'Menlo', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', monospace; +} + +.sig-name, code.descname { + background-color: transparent; + font-weight: bold; +} + +.sig-name { + font-size: 1.1em; +} + +code.descname { + font-size: 1.2em; +} + +.sig-prename, code.descclassname { + background-color: transparent; +} + +.optional { + font-size: 1.3em; +} + +.sig-paren { + font-size: larger; +} + +.sig-param.n { + font-style: italic; +} + +/* C++ specific styling */ + +.sig-inline.c-texpr, +.sig-inline.cpp-texpr { + font-family: unset; +} + +.sig.c .k, .sig.c .kt, +.sig.cpp .k, .sig.cpp .kt { + color: #0033B3; +} + +.sig.c .m, +.sig.cpp .m { + color: #1750EB; +} + +.sig.c .s, .sig.c .sc, +.sig.cpp .s, .sig.cpp .sc { + color: #067D17; +} + + +/* -- other body styles ----------------------------------------------------- */ + +ol.arabic { + list-style: decimal; +} + +ol.loweralpha { + list-style: lower-alpha; +} + +ol.upperalpha { + list-style: upper-alpha; +} + +ol.lowerroman { + list-style: lower-roman; +} + +ol.upperroman { + list-style: upper-roman; +} + +:not(li) > ol > li:first-child > :first-child, +:not(li) > ul > li:first-child > :first-child { + margin-top: 0px; +} + +:not(li) > ol > li:last-child > :last-child, +:not(li) > ul > li:last-child > :last-child { + margin-bottom: 0px; +} + +ol.simple ol p, +ol.simple ul p, +ul.simple ol p, +ul.simple ul p { + margin-top: 0; +} + +ol.simple > li:not(:first-child) > p, +ul.simple > li:not(:first-child) > p { + margin-top: 0; +} + +ol.simple p, +ul.simple p { + margin-bottom: 0; +} + +aside.footnote > span, +div.citation > span { + float: left; +} +aside.footnote > span:last-of-type, +div.citation > span:last-of-type { + padding-right: 0.5em; +} +aside.footnote > p { + margin-left: 2em; +} +div.citation > p { + margin-left: 4em; +} +aside.footnote > p:last-of-type, +div.citation > p:last-of-type { + margin-bottom: 0em; +} +aside.footnote > p:last-of-type:after, +div.citation > p:last-of-type:after { + content: ""; + clear: both; +} + +dl.field-list { + display: grid; + grid-template-columns: fit-content(30%) auto; +} + +dl.field-list > dt { + font-weight: bold; + word-break: break-word; + padding-left: 0.5em; + padding-right: 5px; +} + +dl.field-list > dd { + padding-left: 0.5em; + margin-top: 0em; + margin-left: 0em; + margin-bottom: 0em; +} + +dl { + margin-bottom: 15px; +} + +dd > :first-child { + margin-top: 0px; +} + +dd ul, dd table { + margin-bottom: 10px; +} + +dd { + margin-top: 3px; + margin-bottom: 10px; + margin-left: 30px; +} + +.sig dd { + margin-top: 0px; + margin-bottom: 0px; +} + +.sig dl { + margin-top: 0px; + margin-bottom: 0px; +} + +dl > dd:last-child, +dl > dd:last-child > :last-child { + margin-bottom: 0; +} + +dt:target, span.highlighted { + background-color: #fbe54e; +} + +rect.highlighted { + fill: #fbe54e; +} + +dl.glossary dt { + font-weight: bold; + font-size: 1.1em; +} + +.versionmodified { + font-style: italic; +} + +.system-message { + background-color: #fda; + padding: 5px; + border: 3px solid red; +} + +.footnote:target { + background-color: #ffa; +} + +.line-block { + display: block; + margin-top: 1em; + margin-bottom: 1em; +} + +.line-block .line-block { + margin-top: 0; + margin-bottom: 0; + margin-left: 1.5em; +} + +.guilabel, .menuselection { + font-family: sans-serif; +} + +.accelerator { + text-decoration: underline; +} + +.classifier { + font-style: oblique; +} + +.classifier:before { + font-style: normal; + margin: 0 0.5em; + content: ":"; + display: inline-block; +} + +abbr, acronym { + border-bottom: dotted 1px; + cursor: help; +} + +.translated { + background-color: rgba(207, 255, 207, 0.2) +} + +.untranslated { + background-color: rgba(255, 207, 207, 0.2) +} + +/* -- code displays --------------------------------------------------------- */ + +pre { + overflow: auto; + overflow-y: hidden; /* fixes display issues on Chrome browsers */ +} + +pre, div[class*="highlight-"] { + clear: both; +} + +span.pre { + -moz-hyphens: none; + -ms-hyphens: none; + -webkit-hyphens: none; + hyphens: none; + white-space: nowrap; +} + +div[class*="highlight-"] { + margin: 1em 0; +} + +td.linenos pre { + border: 0; + background-color: transparent; + color: #aaa; +} + +table.highlighttable { + display: block; +} + +table.highlighttable tbody { + display: block; +} + +table.highlighttable tr { + display: flex; +} + +table.highlighttable td { + margin: 0; + padding: 0; +} + +table.highlighttable td.linenos { + padding-right: 0.5em; +} + +table.highlighttable td.code { + flex: 1; + overflow: hidden; +} + +.highlight .hll { + display: block; +} + +div.highlight pre, +table.highlighttable pre { + margin: 0; +} + +div.code-block-caption + div { + margin-top: 0; +} + +div.code-block-caption { + margin-top: 1em; + padding: 2px 5px; + font-size: small; +} + +div.code-block-caption code { + background-color: transparent; +} + +table.highlighttable td.linenos, +span.linenos, +div.highlight span.gp { /* gp: Generic.Prompt */ + user-select: none; + -webkit-user-select: text; /* Safari fallback only */ + -webkit-user-select: none; /* Chrome/Safari */ + -moz-user-select: none; /* Firefox */ + -ms-user-select: none; /* IE10+ */ +} + +div.code-block-caption span.caption-number { + padding: 0.1em 0.3em; + font-style: italic; +} + +div.code-block-caption span.caption-text { +} + +div.literal-block-wrapper { + margin: 1em 0; +} + +code.xref, a code { + background-color: transparent; + font-weight: bold; +} + +h1 code, h2 code, h3 code, h4 code, h5 code, h6 code { + background-color: transparent; +} + +.viewcode-link { + float: right; +} + +.viewcode-back { + float: right; + font-family: sans-serif; +} + +div.viewcode-block:target { + margin: -1px -10px; + padding: 0 10px; +} + +/* -- math display ---------------------------------------------------------- */ + +img.math { + vertical-align: middle; +} + +div.body div.math p { + text-align: center; +} + +span.eqno { + float: right; +} + +span.eqno a.headerlink { + position: absolute; + z-index: 1; +} + +div.math:hover a.headerlink { + visibility: visible; +} + +/* -- printout stylesheet --------------------------------------------------- */ + +@media print { + div.document, + div.documentwrapper, + div.bodywrapper { + margin: 0 !important; + width: 100%; + } + + div.sphinxsidebar, + div.related, + div.footer, + #top-link { + display: none; + } +} \ No newline at end of file diff --git a/previews/271/zh_CN/_static/css/badge_only.css b/previews/271/zh_CN/_static/css/badge_only.css new file mode 100644 index 000000000..88ba55b96 --- /dev/null +++ b/previews/271/zh_CN/_static/css/badge_only.css @@ -0,0 +1 @@ +.clearfix{*zoom:1}.clearfix:after,.clearfix:before{display:table;content:""}.clearfix:after{clear:both}@font-face{font-family:FontAwesome;font-style:normal;font-weight:400;src:url(fonts/fontawesome-webfont.eot?674f50d287a8c48dc19ba404d20fe713?#iefix) format("embedded-opentype"),url(fonts/fontawesome-webfont.woff2?af7ae505a9eed503f8b8e6982036873e) format("woff2"),url(fonts/fontawesome-webfont.woff?fee66e712a8a08eef5805a46892932ad) format("woff"),url(fonts/fontawesome-webfont.ttf?b06871f281fee6b241d60582ae9369b9) format("truetype"),url(fonts/fontawesome-webfont.svg?912ec66d7572ff821749319396470bde#FontAwesome) format("svg")}.fa:before{font-family:FontAwesome;font-style:normal;font-weight:400;line-height:1}.fa:before,a .fa{text-decoration:inherit}.fa:before,a .fa,li .fa{display:inline-block}li .fa-large:before{width:1.875em}ul.fas{list-style-type:none;margin-left:2em;text-indent:-.8em}ul.fas li .fa{width:.8em}ul.fas li .fa-large:before{vertical-align:baseline}.fa-book:before,.icon-book:before{content:"\f02d"}.fa-caret-down:before,.icon-caret-down:before{content:"\f0d7"}.fa-caret-up:before,.icon-caret-up:before{content:"\f0d8"}.fa-caret-left:before,.icon-caret-left:before{content:"\f0d9"}.fa-caret-right:before,.icon-caret-right:before{content:"\f0da"}.rst-versions{position:fixed;bottom:0;left:0;width:300px;color:#fcfcfc;background:#1f1d1d;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;z-index:400}.rst-versions a{color:#2980b9;text-decoration:none}.rst-versions .rst-badge-small{display:none}.rst-versions .rst-current-version{padding:12px;background-color:#272525;display:block;text-align:right;font-size:90%;cursor:pointer;color:#27ae60}.rst-versions .rst-current-version:after{clear:both;content:"";display:block}.rst-versions .rst-current-version .fa{color:#fcfcfc}.rst-versions .rst-current-version .fa-book,.rst-versions .rst-current-version .icon-book{float:left}.rst-versions .rst-current-version.rst-out-of-date{background-color:#e74c3c;color:#fff}.rst-versions .rst-current-version.rst-active-old-version{background-color:#f1c40f;color:#000}.rst-versions.shift-up{height:auto;max-height:100%;overflow-y:scroll}.rst-versions.shift-up .rst-other-versions{display:block}.rst-versions .rst-other-versions{font-size:90%;padding:12px;color:grey;display:none}.rst-versions .rst-other-versions hr{display:block;height:1px;border:0;margin:20px 0;padding:0;border-top:1px solid #413d3d}.rst-versions .rst-other-versions dd{display:inline-block;margin:0}.rst-versions .rst-other-versions dd a{display:inline-block;padding:6px;color:#fcfcfc}.rst-versions .rst-other-versions .rtd-current-item{font-weight:700}.rst-versions.rst-badge{width:auto;bottom:20px;right:20px;left:auto;border:none;max-width:300px;max-height:90%}.rst-versions.rst-badge .fa-book,.rst-versions.rst-badge .icon-book{float:none;line-height:30px}.rst-versions.rst-badge.shift-up .rst-current-version{text-align:right}.rst-versions.rst-badge.shift-up .rst-current-version .fa-book,.rst-versions.rst-badge.shift-up .rst-current-version .icon-book{float:left}.rst-versions.rst-badge>.rst-current-version{width:auto;height:30px;line-height:30px;padding:0 6px;display:block;text-align:center}@media screen and (max-width:768px){.rst-versions{width:85%;display:none}.rst-versions.shift{display:block}}#flyout-search-form{padding:6px} \ No newline at end of file diff --git a/previews/271/zh_CN/_static/css/code-block.css b/previews/271/zh_CN/_static/css/code-block.css new file mode 100644 index 000000000..213d52d45 --- /dev/null +++ b/previews/271/zh_CN/_static/css/code-block.css @@ -0,0 +1,9 @@ +.rst-content .code-block-caption { + font-style: normal; + font-weight: bold; + padding: 10px 12px; + text-align: inherit; + border: 1px solid #e1e4e5; + border-bottom: 0px; + margin-bottom: -1px; +} diff --git a/previews/271/zh_CN/_static/css/fonts/Roboto-Slab-Bold.woff b/previews/271/zh_CN/_static/css/fonts/Roboto-Slab-Bold.woff new file mode 100644 index 000000000..6cb600001 Binary files /dev/null and b/previews/271/zh_CN/_static/css/fonts/Roboto-Slab-Bold.woff differ diff --git a/previews/271/zh_CN/_static/css/fonts/Roboto-Slab-Bold.woff2 b/previews/271/zh_CN/_static/css/fonts/Roboto-Slab-Bold.woff2 new file mode 100644 index 000000000..7059e2314 Binary files /dev/null and b/previews/271/zh_CN/_static/css/fonts/Roboto-Slab-Bold.woff2 differ diff --git a/previews/271/zh_CN/_static/css/fonts/Roboto-Slab-Regular.woff b/previews/271/zh_CN/_static/css/fonts/Roboto-Slab-Regular.woff new file mode 100644 index 000000000..f815f63f9 Binary files /dev/null and b/previews/271/zh_CN/_static/css/fonts/Roboto-Slab-Regular.woff differ diff --git a/previews/271/zh_CN/_static/css/fonts/Roboto-Slab-Regular.woff2 b/previews/271/zh_CN/_static/css/fonts/Roboto-Slab-Regular.woff2 new file mode 100644 index 000000000..f2c76e5bd Binary files /dev/null and b/previews/271/zh_CN/_static/css/fonts/Roboto-Slab-Regular.woff2 differ diff --git a/previews/271/zh_CN/_static/css/fonts/fontawesome-webfont.eot b/previews/271/zh_CN/_static/css/fonts/fontawesome-webfont.eot new file mode 100644 index 000000000..e9f60ca95 Binary files /dev/null and b/previews/271/zh_CN/_static/css/fonts/fontawesome-webfont.eot differ diff --git a/previews/271/zh_CN/_static/css/fonts/fontawesome-webfont.svg b/previews/271/zh_CN/_static/css/fonts/fontawesome-webfont.svg new file mode 100644 index 000000000..855c845e5 --- /dev/null +++ b/previews/271/zh_CN/_static/css/fonts/fontawesome-webfont.svg @@ -0,0 +1,2671 @@ + + + + +Created by FontForge 20120731 at Mon Oct 24 17:37:40 2016 + By ,,, +Copyright Dave Gandy 2016. All rights reserved. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/previews/271/zh_CN/_static/css/fonts/fontawesome-webfont.ttf b/previews/271/zh_CN/_static/css/fonts/fontawesome-webfont.ttf new file mode 100644 index 000000000..35acda2fa Binary files /dev/null and b/previews/271/zh_CN/_static/css/fonts/fontawesome-webfont.ttf differ diff --git a/previews/271/zh_CN/_static/css/fonts/fontawesome-webfont.woff b/previews/271/zh_CN/_static/css/fonts/fontawesome-webfont.woff new file mode 100644 index 000000000..400014a4b Binary files /dev/null and b/previews/271/zh_CN/_static/css/fonts/fontawesome-webfont.woff differ diff --git a/previews/271/zh_CN/_static/css/fonts/fontawesome-webfont.woff2 b/previews/271/zh_CN/_static/css/fonts/fontawesome-webfont.woff2 new file mode 100644 index 000000000..4d13fc604 Binary files /dev/null and b/previews/271/zh_CN/_static/css/fonts/fontawesome-webfont.woff2 differ diff --git a/previews/271/zh_CN/_static/css/fonts/lato-bold-italic.woff b/previews/271/zh_CN/_static/css/fonts/lato-bold-italic.woff new file mode 100644 index 000000000..88ad05b9f Binary files /dev/null and b/previews/271/zh_CN/_static/css/fonts/lato-bold-italic.woff differ diff --git a/previews/271/zh_CN/_static/css/fonts/lato-bold-italic.woff2 b/previews/271/zh_CN/_static/css/fonts/lato-bold-italic.woff2 new file mode 100644 index 000000000..c4e3d804b Binary files /dev/null and b/previews/271/zh_CN/_static/css/fonts/lato-bold-italic.woff2 differ diff --git a/previews/271/zh_CN/_static/css/fonts/lato-bold.woff b/previews/271/zh_CN/_static/css/fonts/lato-bold.woff new file mode 100644 index 000000000..c6dff51f0 Binary files /dev/null and b/previews/271/zh_CN/_static/css/fonts/lato-bold.woff differ diff --git a/previews/271/zh_CN/_static/css/fonts/lato-bold.woff2 b/previews/271/zh_CN/_static/css/fonts/lato-bold.woff2 new file mode 100644 index 000000000..bb195043c Binary files /dev/null and b/previews/271/zh_CN/_static/css/fonts/lato-bold.woff2 differ diff --git a/previews/271/zh_CN/_static/css/fonts/lato-normal-italic.woff b/previews/271/zh_CN/_static/css/fonts/lato-normal-italic.woff new file mode 100644 index 000000000..76114bc03 Binary files /dev/null and b/previews/271/zh_CN/_static/css/fonts/lato-normal-italic.woff differ diff --git a/previews/271/zh_CN/_static/css/fonts/lato-normal-italic.woff2 b/previews/271/zh_CN/_static/css/fonts/lato-normal-italic.woff2 new file mode 100644 index 000000000..3404f37e2 Binary files /dev/null and b/previews/271/zh_CN/_static/css/fonts/lato-normal-italic.woff2 differ diff --git a/previews/271/zh_CN/_static/css/fonts/lato-normal.woff b/previews/271/zh_CN/_static/css/fonts/lato-normal.woff new file mode 100644 index 000000000..ae1307ff5 Binary files /dev/null and b/previews/271/zh_CN/_static/css/fonts/lato-normal.woff differ diff --git a/previews/271/zh_CN/_static/css/fonts/lato-normal.woff2 b/previews/271/zh_CN/_static/css/fonts/lato-normal.woff2 new file mode 100644 index 000000000..3bf984332 Binary files /dev/null and b/previews/271/zh_CN/_static/css/fonts/lato-normal.woff2 differ diff --git a/previews/271/zh_CN/_static/css/phytec-theme.css b/previews/271/zh_CN/_static/css/phytec-theme.css new file mode 100644 index 000000000..c46cf7bca --- /dev/null +++ b/previews/271/zh_CN/_static/css/phytec-theme.css @@ -0,0 +1,45 @@ +/* Definitions for Colorscheme from the Phytec Website */ +:root { + --blue: #007bff; + --indigo: #6610f2; + --purple: #6f42c1; + --pink: #e83e8c; + --red: #dc3545; + --teal: #20c997; + --cyan: #17a2b8; + --gray: #6c757d; + --gray-dark: #343a40; + --primary: #006e73; + --secondary: #6c757d; + --success: #28a745; + --info: #17a2b8; + --warning: #ffc107; + --danger: #dc3545; + --light: #f8f9fa; + --dark: #343a40; + --black: #000; + --white: #fff; + --gray1: #f5f5f5; + --gray2: #d0d2d3; + --gray3: #95989a; + --gray4: #707070; + --teal1: #03c9d6; + --teal2: #02a6b1; + --teal3: #16969e; + --teal4: #006e73; + --orange: #ff9708; + --green: #c5d900; + --yellow: #f1bf00; +} + +.wy-menu-vertical header, +.wy-menu-vertical p.caption { + color: var(--teal4); + + /* Improves the appearance of uppercase text */ + letter-spacing: 0.75px; +} + +.wy-side-nav-search { + background-color: var(--teal4); +} diff --git a/previews/271/zh_CN/_static/css/theme.css b/previews/271/zh_CN/_static/css/theme.css new file mode 100644 index 000000000..0f14f1064 --- /dev/null +++ b/previews/271/zh_CN/_static/css/theme.css @@ -0,0 +1,4 @@ +html{box-sizing:border-box}*,:after,:before{box-sizing:inherit}article,aside,details,figcaption,figure,footer,header,hgroup,nav,section{display:block}audio,canvas,video{display:inline-block;*display:inline;*zoom:1}[hidden],audio:not([controls]){display:none}*{-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}html{font-size:100%;-webkit-text-size-adjust:100%;-ms-text-size-adjust:100%}body{margin:0}a:active,a:hover{outline:0}abbr[title]{border-bottom:1px dotted}b,strong{font-weight:700}blockquote{margin:0}dfn{font-style:italic}ins{background:#ff9;text-decoration:none}ins,mark{color:#000}mark{background:#ff0;font-style:italic;font-weight:700}.rst-content code,.rst-content tt,code,kbd,pre,samp{font-family:monospace,serif;_font-family:courier new,monospace;font-size:1em}pre{white-space:pre}q{quotes:none}q:after,q:before{content:"";content:none}small{font-size:85%}sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline}sup{top:-.5em}sub{bottom:-.25em}dl,ol,ul{margin:0;padding:0;list-style:none;list-style-image:none}li{list-style:none}dd{margin:0}img{border:0;-ms-interpolation-mode:bicubic;vertical-align:middle;max-width:100%}svg:not(:root){overflow:hidden}figure,form{margin:0}label{cursor:pointer}button,input,select,textarea{font-size:100%;margin:0;vertical-align:baseline;*vertical-align:middle}button,input{line-height:normal}button,input[type=button],input[type=reset],input[type=submit]{cursor:pointer;-webkit-appearance:button;*overflow:visible}button[disabled],input[disabled]{cursor:default}input[type=search]{-webkit-appearance:textfield;-moz-box-sizing:content-box;-webkit-box-sizing:content-box;box-sizing:content-box}textarea{resize:vertical}table{border-collapse:collapse;border-spacing:0}td{vertical-align:top}.chromeframe{margin:.2em 0;background:#ccc;color:#000;padding:.2em 0}.ir{display:block;border:0;text-indent:-999em;overflow:hidden;background-color:transparent;background-repeat:no-repeat;text-align:left;direction:ltr;*line-height:0}.ir br{display:none}.hidden{display:none!important;visibility:hidden}.visuallyhidden{border:0;clip:rect(0 0 0 0);height:1px;margin:-1px;overflow:hidden;padding:0;position:absolute;width:1px}.visuallyhidden.focusable:active,.visuallyhidden.focusable:focus{clip:auto;height:auto;margin:0;overflow:visible;position:static;width:auto}.invisible{visibility:hidden}.relative{position:relative}big,small{font-size:100%}@media print{body,html,section{background:none!important}*{box-shadow:none!important;text-shadow:none!important;filter:none!important;-ms-filter:none!important}a,a:visited{text-decoration:underline}.ir a:after,a[href^="#"]:after,a[href^="javascript:"]:after{content:""}blockquote,pre{page-break-inside:avoid}thead{display:table-header-group}img,tr{page-break-inside:avoid}img{max-width:100%!important}@page{margin:.5cm}.rst-content .toctree-wrapper>p.caption,h2,h3,p{orphans:3;widows:3}.rst-content .toctree-wrapper>p.caption,h2,h3{page-break-after:avoid}}.btn,.fa:before,.icon:before,.rst-content .admonition,.rst-content .admonition-title:before,.rst-content .admonition-todo,.rst-content .attention,.rst-content .caution,.rst-content .code-block-caption .headerlink:before,.rst-content .danger,.rst-content .eqno .headerlink:before,.rst-content .error,.rst-content .hint,.rst-content .important,.rst-content .note,.rst-content .seealso,.rst-content .tip,.rst-content .warning,.rst-content code.download span:first-child:before,.rst-content dl dt .headerlink:before,.rst-content h1 .headerlink:before,.rst-content h2 .headerlink:before,.rst-content h3 .headerlink:before,.rst-content h4 .headerlink:before,.rst-content h5 .headerlink:before,.rst-content h6 .headerlink:before,.rst-content p.caption .headerlink:before,.rst-content p .headerlink:before,.rst-content table>caption .headerlink:before,.rst-content tt.download span:first-child:before,.wy-alert,.wy-dropdown .caret:before,.wy-inline-validate.wy-inline-validate-danger .wy-input-context:before,.wy-inline-validate.wy-inline-validate-info .wy-input-context:before,.wy-inline-validate.wy-inline-validate-success .wy-input-context:before,.wy-inline-validate.wy-inline-validate-warning .wy-input-context:before,.wy-menu-vertical li.current>a button.toctree-expand:before,.wy-menu-vertical li.on a button.toctree-expand:before,.wy-menu-vertical li button.toctree-expand:before,input[type=color],input[type=date],input[type=datetime-local],input[type=datetime],input[type=email],input[type=month],input[type=number],input[type=password],input[type=search],input[type=tel],input[type=text],input[type=time],input[type=url],input[type=week],select,textarea{-webkit-font-smoothing:antialiased}.clearfix{*zoom:1}.clearfix:after,.clearfix:before{display:table;content:""}.clearfix:after{clear:both}/*! + * Font Awesome 4.7.0 by @davegandy - http://fontawesome.io - @fontawesome + * License - http://fontawesome.io/license (Font: SIL OFL 1.1, CSS: MIT License) + */@font-face{font-family:FontAwesome;src:url(fonts/fontawesome-webfont.eot?674f50d287a8c48dc19ba404d20fe713);src:url(fonts/fontawesome-webfont.eot?674f50d287a8c48dc19ba404d20fe713?#iefix&v=4.7.0) format("embedded-opentype"),url(fonts/fontawesome-webfont.woff2?af7ae505a9eed503f8b8e6982036873e) format("woff2"),url(fonts/fontawesome-webfont.woff?fee66e712a8a08eef5805a46892932ad) format("woff"),url(fonts/fontawesome-webfont.ttf?b06871f281fee6b241d60582ae9369b9) format("truetype"),url(fonts/fontawesome-webfont.svg?912ec66d7572ff821749319396470bde#fontawesomeregular) format("svg");font-weight:400;font-style:normal}.fa,.icon,.rst-content .admonition-title,.rst-content .code-block-caption .headerlink,.rst-content .eqno .headerlink,.rst-content code.download span:first-child,.rst-content dl dt .headerlink,.rst-content h1 .headerlink,.rst-content h2 .headerlink,.rst-content h3 .headerlink,.rst-content h4 .headerlink,.rst-content h5 .headerlink,.rst-content h6 .headerlink,.rst-content p.caption .headerlink,.rst-content p .headerlink,.rst-content table>caption .headerlink,.rst-content tt.download span:first-child,.wy-menu-vertical li.current>a button.toctree-expand,.wy-menu-vertical li.on a button.toctree-expand,.wy-menu-vertical li button.toctree-expand{display:inline-block;font:normal normal normal 14px/1 FontAwesome;font-size:inherit;text-rendering:auto;-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale}.fa-lg{font-size:1.33333em;line-height:.75em;vertical-align:-15%}.fa-2x{font-size:2em}.fa-3x{font-size:3em}.fa-4x{font-size:4em}.fa-5x{font-size:5em}.fa-fw{width:1.28571em;text-align:center}.fa-ul{padding-left:0;margin-left:2.14286em;list-style-type:none}.fa-ul>li{position:relative}.fa-li{position:absolute;left:-2.14286em;width:2.14286em;top:.14286em;text-align:center}.fa-li.fa-lg{left:-1.85714em}.fa-border{padding:.2em .25em .15em;border:.08em solid #eee;border-radius:.1em}.fa-pull-left{float:left}.fa-pull-right{float:right}.fa-pull-left.icon,.fa.fa-pull-left,.rst-content .code-block-caption .fa-pull-left.headerlink,.rst-content .eqno .fa-pull-left.headerlink,.rst-content .fa-pull-left.admonition-title,.rst-content code.download span.fa-pull-left:first-child,.rst-content dl dt .fa-pull-left.headerlink,.rst-content h1 .fa-pull-left.headerlink,.rst-content h2 .fa-pull-left.headerlink,.rst-content h3 .fa-pull-left.headerlink,.rst-content h4 .fa-pull-left.headerlink,.rst-content h5 .fa-pull-left.headerlink,.rst-content h6 .fa-pull-left.headerlink,.rst-content p .fa-pull-left.headerlink,.rst-content table>caption .fa-pull-left.headerlink,.rst-content tt.download span.fa-pull-left:first-child,.wy-menu-vertical li.current>a button.fa-pull-left.toctree-expand,.wy-menu-vertical li.on a button.fa-pull-left.toctree-expand,.wy-menu-vertical li button.fa-pull-left.toctree-expand{margin-right:.3em}.fa-pull-right.icon,.fa.fa-pull-right,.rst-content .code-block-caption .fa-pull-right.headerlink,.rst-content .eqno .fa-pull-right.headerlink,.rst-content .fa-pull-right.admonition-title,.rst-content code.download span.fa-pull-right:first-child,.rst-content dl dt .fa-pull-right.headerlink,.rst-content h1 .fa-pull-right.headerlink,.rst-content h2 .fa-pull-right.headerlink,.rst-content h3 .fa-pull-right.headerlink,.rst-content h4 .fa-pull-right.headerlink,.rst-content h5 .fa-pull-right.headerlink,.rst-content h6 .fa-pull-right.headerlink,.rst-content p .fa-pull-right.headerlink,.rst-content table>caption .fa-pull-right.headerlink,.rst-content tt.download span.fa-pull-right:first-child,.wy-menu-vertical li.current>a button.fa-pull-right.toctree-expand,.wy-menu-vertical li.on a button.fa-pull-right.toctree-expand,.wy-menu-vertical li button.fa-pull-right.toctree-expand{margin-left:.3em}.pull-right{float:right}.pull-left{float:left}.fa.pull-left,.pull-left.icon,.rst-content .code-block-caption .pull-left.headerlink,.rst-content .eqno .pull-left.headerlink,.rst-content .pull-left.admonition-title,.rst-content code.download span.pull-left:first-child,.rst-content dl dt .pull-left.headerlink,.rst-content h1 .pull-left.headerlink,.rst-content h2 .pull-left.headerlink,.rst-content h3 .pull-left.headerlink,.rst-content h4 .pull-left.headerlink,.rst-content h5 .pull-left.headerlink,.rst-content h6 .pull-left.headerlink,.rst-content p .pull-left.headerlink,.rst-content table>caption .pull-left.headerlink,.rst-content tt.download span.pull-left:first-child,.wy-menu-vertical li.current>a button.pull-left.toctree-expand,.wy-menu-vertical li.on a button.pull-left.toctree-expand,.wy-menu-vertical li button.pull-left.toctree-expand{margin-right:.3em}.fa.pull-right,.pull-right.icon,.rst-content .code-block-caption .pull-right.headerlink,.rst-content .eqno .pull-right.headerlink,.rst-content .pull-right.admonition-title,.rst-content code.download span.pull-right:first-child,.rst-content dl dt .pull-right.headerlink,.rst-content h1 .pull-right.headerlink,.rst-content h2 .pull-right.headerlink,.rst-content h3 .pull-right.headerlink,.rst-content h4 .pull-right.headerlink,.rst-content h5 .pull-right.headerlink,.rst-content h6 .pull-right.headerlink,.rst-content p .pull-right.headerlink,.rst-content table>caption .pull-right.headerlink,.rst-content tt.download span.pull-right:first-child,.wy-menu-vertical li.current>a button.pull-right.toctree-expand,.wy-menu-vertical li.on a button.pull-right.toctree-expand,.wy-menu-vertical li button.pull-right.toctree-expand{margin-left:.3em}.fa-spin{-webkit-animation:fa-spin 2s linear infinite;animation:fa-spin 2s linear infinite}.fa-pulse{-webkit-animation:fa-spin 1s steps(8) infinite;animation:fa-spin 1s steps(8) infinite}@-webkit-keyframes fa-spin{0%{-webkit-transform:rotate(0deg);transform:rotate(0deg)}to{-webkit-transform:rotate(359deg);transform:rotate(359deg)}}@keyframes fa-spin{0%{-webkit-transform:rotate(0deg);transform:rotate(0deg)}to{-webkit-transform:rotate(359deg);transform:rotate(359deg)}}.fa-rotate-90{-ms-filter:"progid:DXImageTransform.Microsoft.BasicImage(rotation=1)";-webkit-transform:rotate(90deg);-ms-transform:rotate(90deg);transform:rotate(90deg)}.fa-rotate-180{-ms-filter:"progid:DXImageTransform.Microsoft.BasicImage(rotation=2)";-webkit-transform:rotate(180deg);-ms-transform:rotate(180deg);transform:rotate(180deg)}.fa-rotate-270{-ms-filter:"progid:DXImageTransform.Microsoft.BasicImage(rotation=3)";-webkit-transform:rotate(270deg);-ms-transform:rotate(270deg);transform:rotate(270deg)}.fa-flip-horizontal{-ms-filter:"progid:DXImageTransform.Microsoft.BasicImage(rotation=0, mirror=1)";-webkit-transform:scaleX(-1);-ms-transform:scaleX(-1);transform:scaleX(-1)}.fa-flip-vertical{-ms-filter:"progid:DXImageTransform.Microsoft.BasicImage(rotation=2, mirror=1)";-webkit-transform:scaleY(-1);-ms-transform:scaleY(-1);transform:scaleY(-1)}:root .fa-flip-horizontal,:root .fa-flip-vertical,:root .fa-rotate-90,:root .fa-rotate-180,:root .fa-rotate-270{filter:none}.fa-stack{position:relative;display:inline-block;width:2em;height:2em;line-height:2em;vertical-align:middle}.fa-stack-1x,.fa-stack-2x{position:absolute;left:0;width:100%;text-align:center}.fa-stack-1x{line-height:inherit}.fa-stack-2x{font-size:2em}.fa-inverse{color:#fff}.fa-glass:before{content:""}.fa-music:before{content:""}.fa-search:before,.icon-search:before{content:""}.fa-envelope-o:before{content:""}.fa-heart:before{content:""}.fa-star:before{content:""}.fa-star-o:before{content:""}.fa-user:before{content:""}.fa-film:before{content:""}.fa-th-large:before{content:""}.fa-th:before{content:""}.fa-th-list:before{content:""}.fa-check:before{content:""}.fa-close:before,.fa-remove:before,.fa-times:before{content:""}.fa-search-plus:before{content:""}.fa-search-minus:before{content:""}.fa-power-off:before{content:""}.fa-signal:before{content:""}.fa-cog:before,.fa-gear:before{content:""}.fa-trash-o:before{content:""}.fa-home:before,.icon-home:before{content:""}.fa-file-o:before{content:""}.fa-clock-o:before{content:""}.fa-road:before{content:""}.fa-download:before,.rst-content code.download span:first-child:before,.rst-content tt.download span:first-child:before{content:""}.fa-arrow-circle-o-down:before{content:""}.fa-arrow-circle-o-up:before{content:""}.fa-inbox:before{content:""}.fa-play-circle-o:before{content:""}.fa-repeat:before,.fa-rotate-right:before{content:""}.fa-refresh:before{content:""}.fa-list-alt:before{content:""}.fa-lock:before{content:""}.fa-flag:before{content:""}.fa-headphones:before{content:""}.fa-volume-off:before{content:""}.fa-volume-down:before{content:""}.fa-volume-up:before{content:""}.fa-qrcode:before{content:""}.fa-barcode:before{content:""}.fa-tag:before{content:""}.fa-tags:before{content:""}.fa-book:before,.icon-book:before{content:""}.fa-bookmark:before{content:""}.fa-print:before{content:""}.fa-camera:before{content:""}.fa-font:before{content:""}.fa-bold:before{content:""}.fa-italic:before{content:""}.fa-text-height:before{content:""}.fa-text-width:before{content:""}.fa-align-left:before{content:""}.fa-align-center:before{content:""}.fa-align-right:before{content:""}.fa-align-justify:before{content:""}.fa-list:before{content:""}.fa-dedent:before,.fa-outdent:before{content:""}.fa-indent:before{content:""}.fa-video-camera:before{content:""}.fa-image:before,.fa-photo:before,.fa-picture-o:before{content:""}.fa-pencil:before{content:""}.fa-map-marker:before{content:""}.fa-adjust:before{content:""}.fa-tint:before{content:""}.fa-edit:before,.fa-pencil-square-o:before{content:""}.fa-share-square-o:before{content:""}.fa-check-square-o:before{content:""}.fa-arrows:before{content:""}.fa-step-backward:before{content:""}.fa-fast-backward:before{content:""}.fa-backward:before{content:""}.fa-play:before{content:""}.fa-pause:before{content:""}.fa-stop:before{content:""}.fa-forward:before{content:""}.fa-fast-forward:before{content:""}.fa-step-forward:before{content:""}.fa-eject:before{content:""}.fa-chevron-left:before{content:""}.fa-chevron-right:before{content:""}.fa-plus-circle:before{content:""}.fa-minus-circle:before{content:""}.fa-times-circle:before,.wy-inline-validate.wy-inline-validate-danger .wy-input-context:before{content:""}.fa-check-circle:before,.wy-inline-validate.wy-inline-validate-success .wy-input-context:before{content:""}.fa-question-circle:before{content:""}.fa-info-circle:before{content:""}.fa-crosshairs:before{content:""}.fa-times-circle-o:before{content:""}.fa-check-circle-o:before{content:""}.fa-ban:before{content:""}.fa-arrow-left:before{content:""}.fa-arrow-right:before{content:""}.fa-arrow-up:before{content:""}.fa-arrow-down:before{content:""}.fa-mail-forward:before,.fa-share:before{content:""}.fa-expand:before{content:""}.fa-compress:before{content:""}.fa-plus:before{content:""}.fa-minus:before{content:""}.fa-asterisk:before{content:""}.fa-exclamation-circle:before,.rst-content .admonition-title:before,.wy-inline-validate.wy-inline-validate-info .wy-input-context:before,.wy-inline-validate.wy-inline-validate-warning .wy-input-context:before{content:""}.fa-gift:before{content:""}.fa-leaf:before{content:""}.fa-fire:before,.icon-fire:before{content:""}.fa-eye:before{content:""}.fa-eye-slash:before{content:""}.fa-exclamation-triangle:before,.fa-warning:before{content:""}.fa-plane:before{content:""}.fa-calendar:before{content:""}.fa-random:before{content:""}.fa-comment:before{content:""}.fa-magnet:before{content:""}.fa-chevron-up:before{content:""}.fa-chevron-down:before{content:""}.fa-retweet:before{content:""}.fa-shopping-cart:before{content:""}.fa-folder:before{content:""}.fa-folder-open:before{content:""}.fa-arrows-v:before{content:""}.fa-arrows-h:before{content:""}.fa-bar-chart-o:before,.fa-bar-chart:before{content:""}.fa-twitter-square:before{content:""}.fa-facebook-square:before{content:""}.fa-camera-retro:before{content:""}.fa-key:before{content:""}.fa-cogs:before,.fa-gears:before{content:""}.fa-comments:before{content:""}.fa-thumbs-o-up:before{content:""}.fa-thumbs-o-down:before{content:""}.fa-star-half:before{content:""}.fa-heart-o:before{content:""}.fa-sign-out:before{content:""}.fa-linkedin-square:before{content:""}.fa-thumb-tack:before{content:""}.fa-external-link:before{content:""}.fa-sign-in:before{content:""}.fa-trophy:before{content:""}.fa-github-square:before{content:""}.fa-upload:before{content:""}.fa-lemon-o:before{content:""}.fa-phone:before{content:""}.fa-square-o:before{content:""}.fa-bookmark-o:before{content:""}.fa-phone-square:before{content:""}.fa-twitter:before{content:""}.fa-facebook-f:before,.fa-facebook:before{content:""}.fa-github:before,.icon-github:before{content:""}.fa-unlock:before{content:""}.fa-credit-card:before{content:""}.fa-feed:before,.fa-rss:before{content:""}.fa-hdd-o:before{content:""}.fa-bullhorn:before{content:""}.fa-bell:before{content:""}.fa-certificate:before{content:""}.fa-hand-o-right:before{content:""}.fa-hand-o-left:before{content:""}.fa-hand-o-up:before{content:""}.fa-hand-o-down:before{content:""}.fa-arrow-circle-left:before,.icon-circle-arrow-left:before{content:""}.fa-arrow-circle-right:before,.icon-circle-arrow-right:before{content:""}.fa-arrow-circle-up:before{content:""}.fa-arrow-circle-down:before{content:""}.fa-globe:before{content:""}.fa-wrench:before{content:""}.fa-tasks:before{content:""}.fa-filter:before{content:""}.fa-briefcase:before{content:""}.fa-arrows-alt:before{content:""}.fa-group:before,.fa-users:before{content:""}.fa-chain:before,.fa-link:before,.icon-link:before{content:""}.fa-cloud:before{content:""}.fa-flask:before{content:""}.fa-cut:before,.fa-scissors:before{content:""}.fa-copy:before,.fa-files-o:before{content:""}.fa-paperclip:before{content:""}.fa-floppy-o:before,.fa-save:before{content:""}.fa-square:before{content:""}.fa-bars:before,.fa-navicon:before,.fa-reorder:before{content:""}.fa-list-ul:before{content:""}.fa-list-ol:before{content:""}.fa-strikethrough:before{content:""}.fa-underline:before{content:""}.fa-table:before{content:""}.fa-magic:before{content:""}.fa-truck:before{content:""}.fa-pinterest:before{content:""}.fa-pinterest-square:before{content:""}.fa-google-plus-square:before{content:""}.fa-google-plus:before{content:""}.fa-money:before{content:""}.fa-caret-down:before,.icon-caret-down:before,.wy-dropdown .caret:before{content:""}.fa-caret-up:before{content:""}.fa-caret-left:before{content:""}.fa-caret-right:before{content:""}.fa-columns:before{content:""}.fa-sort:before,.fa-unsorted:before{content:""}.fa-sort-desc:before,.fa-sort-down:before{content:""}.fa-sort-asc:before,.fa-sort-up:before{content:""}.fa-envelope:before{content:""}.fa-linkedin:before{content:""}.fa-rotate-left:before,.fa-undo:before{content:""}.fa-gavel:before,.fa-legal:before{content:""}.fa-dashboard:before,.fa-tachometer:before{content:""}.fa-comment-o:before{content:""}.fa-comments-o:before{content:""}.fa-bolt:before,.fa-flash:before{content:""}.fa-sitemap:before{content:""}.fa-umbrella:before{content:""}.fa-clipboard:before,.fa-paste:before{content:""}.fa-lightbulb-o:before{content:""}.fa-exchange:before{content:""}.fa-cloud-download:before{content:""}.fa-cloud-upload:before{content:""}.fa-user-md:before{content:""}.fa-stethoscope:before{content:""}.fa-suitcase:before{content:""}.fa-bell-o:before{content:""}.fa-coffee:before{content:""}.fa-cutlery:before{content:""}.fa-file-text-o:before{content:""}.fa-building-o:before{content:""}.fa-hospital-o:before{content:""}.fa-ambulance:before{content:""}.fa-medkit:before{content:""}.fa-fighter-jet:before{content:""}.fa-beer:before{content:""}.fa-h-square:before{content:""}.fa-plus-square:before{content:""}.fa-angle-double-left:before{content:""}.fa-angle-double-right:before{content:""}.fa-angle-double-up:before{content:""}.fa-angle-double-down:before{content:""}.fa-angle-left:before{content:""}.fa-angle-right:before{content:""}.fa-angle-up:before{content:""}.fa-angle-down:before{content:""}.fa-desktop:before{content:""}.fa-laptop:before{content:""}.fa-tablet:before{content:""}.fa-mobile-phone:before,.fa-mobile:before{content:""}.fa-circle-o:before{content:""}.fa-quote-left:before{content:""}.fa-quote-right:before{content:""}.fa-spinner:before{content:""}.fa-circle:before{content:""}.fa-mail-reply:before,.fa-reply:before{content:""}.fa-github-alt:before{content:""}.fa-folder-o:before{content:""}.fa-folder-open-o:before{content:""}.fa-smile-o:before{content:""}.fa-frown-o:before{content:""}.fa-meh-o:before{content:""}.fa-gamepad:before{content:""}.fa-keyboard-o:before{content:""}.fa-flag-o:before{content:""}.fa-flag-checkered:before{content:""}.fa-terminal:before{content:""}.fa-code:before{content:""}.fa-mail-reply-all:before,.fa-reply-all:before{content:""}.fa-star-half-empty:before,.fa-star-half-full:before,.fa-star-half-o:before{content:""}.fa-location-arrow:before{content:""}.fa-crop:before{content:""}.fa-code-fork:before{content:""}.fa-chain-broken:before,.fa-unlink:before{content:""}.fa-question:before{content:""}.fa-info:before{content:""}.fa-exclamation:before{content:""}.fa-superscript:before{content:""}.fa-subscript:before{content:""}.fa-eraser:before{content:""}.fa-puzzle-piece:before{content:""}.fa-microphone:before{content:""}.fa-microphone-slash:before{content:""}.fa-shield:before{content:""}.fa-calendar-o:before{content:""}.fa-fire-extinguisher:before{content:""}.fa-rocket:before{content:""}.fa-maxcdn:before{content:""}.fa-chevron-circle-left:before{content:""}.fa-chevron-circle-right:before{content:""}.fa-chevron-circle-up:before{content:""}.fa-chevron-circle-down:before{content:""}.fa-html5:before{content:""}.fa-css3:before{content:""}.fa-anchor:before{content:""}.fa-unlock-alt:before{content:""}.fa-bullseye:before{content:""}.fa-ellipsis-h:before{content:""}.fa-ellipsis-v:before{content:""}.fa-rss-square:before{content:""}.fa-play-circle:before{content:""}.fa-ticket:before{content:""}.fa-minus-square:before{content:""}.fa-minus-square-o:before,.wy-menu-vertical li.current>a button.toctree-expand:before,.wy-menu-vertical li.on a button.toctree-expand:before{content:""}.fa-level-up:before{content:""}.fa-level-down:before{content:""}.fa-check-square:before{content:""}.fa-pencil-square:before{content:""}.fa-external-link-square:before{content:""}.fa-share-square:before{content:""}.fa-compass:before{content:""}.fa-caret-square-o-down:before,.fa-toggle-down:before{content:""}.fa-caret-square-o-up:before,.fa-toggle-up:before{content:""}.fa-caret-square-o-right:before,.fa-toggle-right:before{content:""}.fa-eur:before,.fa-euro:before{content:""}.fa-gbp:before{content:""}.fa-dollar:before,.fa-usd:before{content:""}.fa-inr:before,.fa-rupee:before{content:""}.fa-cny:before,.fa-jpy:before,.fa-rmb:before,.fa-yen:before{content:""}.fa-rouble:before,.fa-rub:before,.fa-ruble:before{content:""}.fa-krw:before,.fa-won:before{content:""}.fa-bitcoin:before,.fa-btc:before{content:""}.fa-file:before{content:""}.fa-file-text:before{content:""}.fa-sort-alpha-asc:before{content:""}.fa-sort-alpha-desc:before{content:""}.fa-sort-amount-asc:before{content:""}.fa-sort-amount-desc:before{content:""}.fa-sort-numeric-asc:before{content:""}.fa-sort-numeric-desc:before{content:""}.fa-thumbs-up:before{content:""}.fa-thumbs-down:before{content:""}.fa-youtube-square:before{content:""}.fa-youtube:before{content:""}.fa-xing:before{content:""}.fa-xing-square:before{content:""}.fa-youtube-play:before{content:""}.fa-dropbox:before{content:""}.fa-stack-overflow:before{content:""}.fa-instagram:before{content:""}.fa-flickr:before{content:""}.fa-adn:before{content:""}.fa-bitbucket:before,.icon-bitbucket:before{content:""}.fa-bitbucket-square:before{content:""}.fa-tumblr:before{content:""}.fa-tumblr-square:before{content:""}.fa-long-arrow-down:before{content:""}.fa-long-arrow-up:before{content:""}.fa-long-arrow-left:before{content:""}.fa-long-arrow-right:before{content:""}.fa-apple:before{content:""}.fa-windows:before{content:""}.fa-android:before{content:""}.fa-linux:before{content:""}.fa-dribbble:before{content:""}.fa-skype:before{content:""}.fa-foursquare:before{content:""}.fa-trello:before{content:""}.fa-female:before{content:""}.fa-male:before{content:""}.fa-gittip:before,.fa-gratipay:before{content:""}.fa-sun-o:before{content:""}.fa-moon-o:before{content:""}.fa-archive:before{content:""}.fa-bug:before{content:""}.fa-vk:before{content:""}.fa-weibo:before{content:""}.fa-renren:before{content:""}.fa-pagelines:before{content:""}.fa-stack-exchange:before{content:""}.fa-arrow-circle-o-right:before{content:""}.fa-arrow-circle-o-left:before{content:""}.fa-caret-square-o-left:before,.fa-toggle-left:before{content:""}.fa-dot-circle-o:before{content:""}.fa-wheelchair:before{content:""}.fa-vimeo-square:before{content:""}.fa-try:before,.fa-turkish-lira:before{content:""}.fa-plus-square-o:before,.wy-menu-vertical li button.toctree-expand:before{content:""}.fa-space-shuttle:before{content:""}.fa-slack:before{content:""}.fa-envelope-square:before{content:""}.fa-wordpress:before{content:""}.fa-openid:before{content:""}.fa-bank:before,.fa-institution:before,.fa-university:before{content:""}.fa-graduation-cap:before,.fa-mortar-board:before{content:""}.fa-yahoo:before{content:""}.fa-google:before{content:""}.fa-reddit:before{content:""}.fa-reddit-square:before{content:""}.fa-stumbleupon-circle:before{content:""}.fa-stumbleupon:before{content:""}.fa-delicious:before{content:""}.fa-digg:before{content:""}.fa-pied-piper-pp:before{content:""}.fa-pied-piper-alt:before{content:""}.fa-drupal:before{content:""}.fa-joomla:before{content:""}.fa-language:before{content:""}.fa-fax:before{content:""}.fa-building:before{content:""}.fa-child:before{content:""}.fa-paw:before{content:""}.fa-spoon:before{content:""}.fa-cube:before{content:""}.fa-cubes:before{content:""}.fa-behance:before{content:""}.fa-behance-square:before{content:""}.fa-steam:before{content:""}.fa-steam-square:before{content:""}.fa-recycle:before{content:""}.fa-automobile:before,.fa-car:before{content:""}.fa-cab:before,.fa-taxi:before{content:""}.fa-tree:before{content:""}.fa-spotify:before{content:""}.fa-deviantart:before{content:""}.fa-soundcloud:before{content:""}.fa-database:before{content:""}.fa-file-pdf-o:before{content:""}.fa-file-word-o:before{content:""}.fa-file-excel-o:before{content:""}.fa-file-powerpoint-o:before{content:""}.fa-file-image-o:before,.fa-file-photo-o:before,.fa-file-picture-o:before{content:""}.fa-file-archive-o:before,.fa-file-zip-o:before{content:""}.fa-file-audio-o:before,.fa-file-sound-o:before{content:""}.fa-file-movie-o:before,.fa-file-video-o:before{content:""}.fa-file-code-o:before{content:""}.fa-vine:before{content:""}.fa-codepen:before{content:""}.fa-jsfiddle:before{content:""}.fa-life-bouy:before,.fa-life-buoy:before,.fa-life-ring:before,.fa-life-saver:before,.fa-support:before{content:""}.fa-circle-o-notch:before{content:""}.fa-ra:before,.fa-rebel:before,.fa-resistance:before{content:""}.fa-empire:before,.fa-ge:before{content:""}.fa-git-square:before{content:""}.fa-git:before{content:""}.fa-hacker-news:before,.fa-y-combinator-square:before,.fa-yc-square:before{content:""}.fa-tencent-weibo:before{content:""}.fa-qq:before{content:""}.fa-wechat:before,.fa-weixin:before{content:""}.fa-paper-plane:before,.fa-send:before{content:""}.fa-paper-plane-o:before,.fa-send-o:before{content:""}.fa-history:before{content:""}.fa-circle-thin:before{content:""}.fa-header:before{content:""}.fa-paragraph:before{content:""}.fa-sliders:before{content:""}.fa-share-alt:before{content:""}.fa-share-alt-square:before{content:""}.fa-bomb:before{content:""}.fa-futbol-o:before,.fa-soccer-ball-o:before{content:""}.fa-tty:before{content:""}.fa-binoculars:before{content:""}.fa-plug:before{content:""}.fa-slideshare:before{content:""}.fa-twitch:before{content:""}.fa-yelp:before{content:""}.fa-newspaper-o:before{content:""}.fa-wifi:before{content:""}.fa-calculator:before{content:""}.fa-paypal:before{content:""}.fa-google-wallet:before{content:""}.fa-cc-visa:before{content:""}.fa-cc-mastercard:before{content:""}.fa-cc-discover:before{content:""}.fa-cc-amex:before{content:""}.fa-cc-paypal:before{content:""}.fa-cc-stripe:before{content:""}.fa-bell-slash:before{content:""}.fa-bell-slash-o:before{content:""}.fa-trash:before{content:""}.fa-copyright:before{content:""}.fa-at:before{content:""}.fa-eyedropper:before{content:""}.fa-paint-brush:before{content:""}.fa-birthday-cake:before{content:""}.fa-area-chart:before{content:""}.fa-pie-chart:before{content:""}.fa-line-chart:before{content:""}.fa-lastfm:before{content:""}.fa-lastfm-square:before{content:""}.fa-toggle-off:before{content:""}.fa-toggle-on:before{content:""}.fa-bicycle:before{content:""}.fa-bus:before{content:""}.fa-ioxhost:before{content:""}.fa-angellist:before{content:""}.fa-cc:before{content:""}.fa-ils:before,.fa-shekel:before,.fa-sheqel:before{content:""}.fa-meanpath:before{content:""}.fa-buysellads:before{content:""}.fa-connectdevelop:before{content:""}.fa-dashcube:before{content:""}.fa-forumbee:before{content:""}.fa-leanpub:before{content:""}.fa-sellsy:before{content:""}.fa-shirtsinbulk:before{content:""}.fa-simplybuilt:before{content:""}.fa-skyatlas:before{content:""}.fa-cart-plus:before{content:""}.fa-cart-arrow-down:before{content:""}.fa-diamond:before{content:""}.fa-ship:before{content:""}.fa-user-secret:before{content:""}.fa-motorcycle:before{content:""}.fa-street-view:before{content:""}.fa-heartbeat:before{content:""}.fa-venus:before{content:""}.fa-mars:before{content:""}.fa-mercury:before{content:""}.fa-intersex:before,.fa-transgender:before{content:""}.fa-transgender-alt:before{content:""}.fa-venus-double:before{content:""}.fa-mars-double:before{content:""}.fa-venus-mars:before{content:""}.fa-mars-stroke:before{content:""}.fa-mars-stroke-v:before{content:""}.fa-mars-stroke-h:before{content:""}.fa-neuter:before{content:""}.fa-genderless:before{content:""}.fa-facebook-official:before{content:""}.fa-pinterest-p:before{content:""}.fa-whatsapp:before{content:""}.fa-server:before{content:""}.fa-user-plus:before{content:""}.fa-user-times:before{content:""}.fa-bed:before,.fa-hotel:before{content:""}.fa-viacoin:before{content:""}.fa-train:before{content:""}.fa-subway:before{content:""}.fa-medium:before{content:""}.fa-y-combinator:before,.fa-yc:before{content:""}.fa-optin-monster:before{content:""}.fa-opencart:before{content:""}.fa-expeditedssl:before{content:""}.fa-battery-4:before,.fa-battery-full:before,.fa-battery:before{content:""}.fa-battery-3:before,.fa-battery-three-quarters:before{content:""}.fa-battery-2:before,.fa-battery-half:before{content:""}.fa-battery-1:before,.fa-battery-quarter:before{content:""}.fa-battery-0:before,.fa-battery-empty:before{content:""}.fa-mouse-pointer:before{content:""}.fa-i-cursor:before{content:""}.fa-object-group:before{content:""}.fa-object-ungroup:before{content:""}.fa-sticky-note:before{content:""}.fa-sticky-note-o:before{content:""}.fa-cc-jcb:before{content:""}.fa-cc-diners-club:before{content:""}.fa-clone:before{content:""}.fa-balance-scale:before{content:""}.fa-hourglass-o:before{content:""}.fa-hourglass-1:before,.fa-hourglass-start:before{content:""}.fa-hourglass-2:before,.fa-hourglass-half:before{content:""}.fa-hourglass-3:before,.fa-hourglass-end:before{content:""}.fa-hourglass:before{content:""}.fa-hand-grab-o:before,.fa-hand-rock-o:before{content:""}.fa-hand-paper-o:before,.fa-hand-stop-o:before{content:""}.fa-hand-scissors-o:before{content:""}.fa-hand-lizard-o:before{content:""}.fa-hand-spock-o:before{content:""}.fa-hand-pointer-o:before{content:""}.fa-hand-peace-o:before{content:""}.fa-trademark:before{content:""}.fa-registered:before{content:""}.fa-creative-commons:before{content:""}.fa-gg:before{content:""}.fa-gg-circle:before{content:""}.fa-tripadvisor:before{content:""}.fa-odnoklassniki:before{content:""}.fa-odnoklassniki-square:before{content:""}.fa-get-pocket:before{content:""}.fa-wikipedia-w:before{content:""}.fa-safari:before{content:""}.fa-chrome:before{content:""}.fa-firefox:before{content:""}.fa-opera:before{content:""}.fa-internet-explorer:before{content:""}.fa-television:before,.fa-tv:before{content:""}.fa-contao:before{content:""}.fa-500px:before{content:""}.fa-amazon:before{content:""}.fa-calendar-plus-o:before{content:""}.fa-calendar-minus-o:before{content:""}.fa-calendar-times-o:before{content:""}.fa-calendar-check-o:before{content:""}.fa-industry:before{content:""}.fa-map-pin:before{content:""}.fa-map-signs:before{content:""}.fa-map-o:before{content:""}.fa-map:before{content:""}.fa-commenting:before{content:""}.fa-commenting-o:before{content:""}.fa-houzz:before{content:""}.fa-vimeo:before{content:""}.fa-black-tie:before{content:""}.fa-fonticons:before{content:""}.fa-reddit-alien:before{content:""}.fa-edge:before{content:""}.fa-credit-card-alt:before{content:""}.fa-codiepie:before{content:""}.fa-modx:before{content:""}.fa-fort-awesome:before{content:""}.fa-usb:before{content:""}.fa-product-hunt:before{content:""}.fa-mixcloud:before{content:""}.fa-scribd:before{content:""}.fa-pause-circle:before{content:""}.fa-pause-circle-o:before{content:""}.fa-stop-circle:before{content:""}.fa-stop-circle-o:before{content:""}.fa-shopping-bag:before{content:""}.fa-shopping-basket:before{content:""}.fa-hashtag:before{content:""}.fa-bluetooth:before{content:""}.fa-bluetooth-b:before{content:""}.fa-percent:before{content:""}.fa-gitlab:before,.icon-gitlab:before{content:""}.fa-wpbeginner:before{content:""}.fa-wpforms:before{content:""}.fa-envira:before{content:""}.fa-universal-access:before{content:""}.fa-wheelchair-alt:before{content:""}.fa-question-circle-o:before{content:""}.fa-blind:before{content:""}.fa-audio-description:before{content:""}.fa-volume-control-phone:before{content:""}.fa-braille:before{content:""}.fa-assistive-listening-systems:before{content:""}.fa-american-sign-language-interpreting:before,.fa-asl-interpreting:before{content:""}.fa-deaf:before,.fa-deafness:before,.fa-hard-of-hearing:before{content:""}.fa-glide:before{content:""}.fa-glide-g:before{content:""}.fa-sign-language:before,.fa-signing:before{content:""}.fa-low-vision:before{content:""}.fa-viadeo:before{content:""}.fa-viadeo-square:before{content:""}.fa-snapchat:before{content:""}.fa-snapchat-ghost:before{content:""}.fa-snapchat-square:before{content:""}.fa-pied-piper:before{content:""}.fa-first-order:before{content:""}.fa-yoast:before{content:""}.fa-themeisle:before{content:""}.fa-google-plus-circle:before,.fa-google-plus-official:before{content:""}.fa-fa:before,.fa-font-awesome:before{content:""}.fa-handshake-o:before{content:""}.fa-envelope-open:before{content:""}.fa-envelope-open-o:before{content:""}.fa-linode:before{content:""}.fa-address-book:before{content:""}.fa-address-book-o:before{content:""}.fa-address-card:before,.fa-vcard:before{content:""}.fa-address-card-o:before,.fa-vcard-o:before{content:""}.fa-user-circle:before{content:""}.fa-user-circle-o:before{content:""}.fa-user-o:before{content:""}.fa-id-badge:before{content:""}.fa-drivers-license:before,.fa-id-card:before{content:""}.fa-drivers-license-o:before,.fa-id-card-o:before{content:""}.fa-quora:before{content:""}.fa-free-code-camp:before{content:""}.fa-telegram:before{content:""}.fa-thermometer-4:before,.fa-thermometer-full:before,.fa-thermometer:before{content:""}.fa-thermometer-3:before,.fa-thermometer-three-quarters:before{content:""}.fa-thermometer-2:before,.fa-thermometer-half:before{content:""}.fa-thermometer-1:before,.fa-thermometer-quarter:before{content:""}.fa-thermometer-0:before,.fa-thermometer-empty:before{content:""}.fa-shower:before{content:""}.fa-bath:before,.fa-bathtub:before,.fa-s15:before{content:""}.fa-podcast:before{content:""}.fa-window-maximize:before{content:""}.fa-window-minimize:before{content:""}.fa-window-restore:before{content:""}.fa-times-rectangle:before,.fa-window-close:before{content:""}.fa-times-rectangle-o:before,.fa-window-close-o:before{content:""}.fa-bandcamp:before{content:""}.fa-grav:before{content:""}.fa-etsy:before{content:""}.fa-imdb:before{content:""}.fa-ravelry:before{content:""}.fa-eercast:before{content:""}.fa-microchip:before{content:""}.fa-snowflake-o:before{content:""}.fa-superpowers:before{content:""}.fa-wpexplorer:before{content:""}.fa-meetup:before{content:""}.sr-only{position:absolute;width:1px;height:1px;padding:0;margin:-1px;overflow:hidden;clip:rect(0,0,0,0);border:0}.sr-only-focusable:active,.sr-only-focusable:focus{position:static;width:auto;height:auto;margin:0;overflow:visible;clip:auto}.fa,.icon,.rst-content .admonition-title,.rst-content .code-block-caption .headerlink,.rst-content .eqno .headerlink,.rst-content code.download span:first-child,.rst-content dl dt .headerlink,.rst-content h1 .headerlink,.rst-content h2 .headerlink,.rst-content h3 .headerlink,.rst-content h4 .headerlink,.rst-content h5 .headerlink,.rst-content h6 .headerlink,.rst-content p.caption .headerlink,.rst-content p .headerlink,.rst-content table>caption .headerlink,.rst-content tt.download span:first-child,.wy-dropdown .caret,.wy-inline-validate.wy-inline-validate-danger .wy-input-context,.wy-inline-validate.wy-inline-validate-info .wy-input-context,.wy-inline-validate.wy-inline-validate-success .wy-input-context,.wy-inline-validate.wy-inline-validate-warning .wy-input-context,.wy-menu-vertical li.current>a button.toctree-expand,.wy-menu-vertical li.on a button.toctree-expand,.wy-menu-vertical li button.toctree-expand{font-family:inherit}.fa:before,.icon:before,.rst-content .admonition-title:before,.rst-content .code-block-caption .headerlink:before,.rst-content .eqno .headerlink:before,.rst-content code.download span:first-child:before,.rst-content dl dt .headerlink:before,.rst-content h1 .headerlink:before,.rst-content h2 .headerlink:before,.rst-content h3 .headerlink:before,.rst-content h4 .headerlink:before,.rst-content h5 .headerlink:before,.rst-content h6 .headerlink:before,.rst-content p.caption .headerlink:before,.rst-content p .headerlink:before,.rst-content table>caption .headerlink:before,.rst-content tt.download span:first-child:before,.wy-dropdown .caret:before,.wy-inline-validate.wy-inline-validate-danger .wy-input-context:before,.wy-inline-validate.wy-inline-validate-info .wy-input-context:before,.wy-inline-validate.wy-inline-validate-success .wy-input-context:before,.wy-inline-validate.wy-inline-validate-warning .wy-input-context:before,.wy-menu-vertical li.current>a button.toctree-expand:before,.wy-menu-vertical li.on a button.toctree-expand:before,.wy-menu-vertical li button.toctree-expand:before{font-family:FontAwesome;display:inline-block;font-style:normal;font-weight:400;line-height:1;text-decoration:inherit}.rst-content .code-block-caption a .headerlink,.rst-content .eqno a .headerlink,.rst-content a .admonition-title,.rst-content code.download a span:first-child,.rst-content dl dt a .headerlink,.rst-content h1 a .headerlink,.rst-content h2 a .headerlink,.rst-content h3 a .headerlink,.rst-content h4 a .headerlink,.rst-content h5 a .headerlink,.rst-content h6 a .headerlink,.rst-content p.caption a .headerlink,.rst-content p a .headerlink,.rst-content table>caption a .headerlink,.rst-content tt.download a span:first-child,.wy-menu-vertical li.current>a button.toctree-expand,.wy-menu-vertical li.on a button.toctree-expand,.wy-menu-vertical li a button.toctree-expand,a .fa,a .icon,a .rst-content .admonition-title,a .rst-content .code-block-caption .headerlink,a .rst-content .eqno .headerlink,a .rst-content code.download span:first-child,a .rst-content dl dt .headerlink,a .rst-content h1 .headerlink,a .rst-content h2 .headerlink,a .rst-content h3 .headerlink,a .rst-content h4 .headerlink,a .rst-content h5 .headerlink,a .rst-content h6 .headerlink,a .rst-content p.caption .headerlink,a .rst-content p .headerlink,a .rst-content table>caption .headerlink,a .rst-content tt.download span:first-child,a .wy-menu-vertical li button.toctree-expand{display:inline-block;text-decoration:inherit}.btn .fa,.btn .icon,.btn .rst-content .admonition-title,.btn .rst-content .code-block-caption .headerlink,.btn .rst-content .eqno .headerlink,.btn .rst-content code.download span:first-child,.btn .rst-content dl dt .headerlink,.btn .rst-content h1 .headerlink,.btn .rst-content h2 .headerlink,.btn .rst-content h3 .headerlink,.btn .rst-content h4 .headerlink,.btn .rst-content h5 .headerlink,.btn .rst-content h6 .headerlink,.btn .rst-content p .headerlink,.btn .rst-content table>caption .headerlink,.btn .rst-content tt.download span:first-child,.btn .wy-menu-vertical li.current>a button.toctree-expand,.btn .wy-menu-vertical li.on a button.toctree-expand,.btn .wy-menu-vertical li button.toctree-expand,.nav .fa,.nav .icon,.nav .rst-content .admonition-title,.nav .rst-content .code-block-caption .headerlink,.nav .rst-content .eqno .headerlink,.nav .rst-content code.download span:first-child,.nav .rst-content dl dt .headerlink,.nav .rst-content h1 .headerlink,.nav .rst-content h2 .headerlink,.nav .rst-content h3 .headerlink,.nav .rst-content h4 .headerlink,.nav .rst-content h5 .headerlink,.nav .rst-content h6 .headerlink,.nav .rst-content p .headerlink,.nav .rst-content table>caption .headerlink,.nav .rst-content tt.download span:first-child,.nav .wy-menu-vertical li.current>a button.toctree-expand,.nav .wy-menu-vertical li.on a button.toctree-expand,.nav .wy-menu-vertical li button.toctree-expand,.rst-content .btn .admonition-title,.rst-content .code-block-caption .btn .headerlink,.rst-content .code-block-caption .nav .headerlink,.rst-content .eqno .btn .headerlink,.rst-content .eqno .nav .headerlink,.rst-content .nav .admonition-title,.rst-content code.download .btn span:first-child,.rst-content code.download .nav span:first-child,.rst-content dl dt .btn .headerlink,.rst-content dl dt .nav .headerlink,.rst-content h1 .btn .headerlink,.rst-content h1 .nav .headerlink,.rst-content h2 .btn .headerlink,.rst-content h2 .nav .headerlink,.rst-content h3 .btn .headerlink,.rst-content h3 .nav .headerlink,.rst-content h4 .btn .headerlink,.rst-content h4 .nav .headerlink,.rst-content h5 .btn .headerlink,.rst-content h5 .nav .headerlink,.rst-content h6 .btn .headerlink,.rst-content h6 .nav .headerlink,.rst-content p .btn .headerlink,.rst-content p .nav .headerlink,.rst-content table>caption .btn .headerlink,.rst-content table>caption .nav .headerlink,.rst-content tt.download .btn span:first-child,.rst-content tt.download .nav span:first-child,.wy-menu-vertical li .btn button.toctree-expand,.wy-menu-vertical li.current>a .btn button.toctree-expand,.wy-menu-vertical li.current>a .nav button.toctree-expand,.wy-menu-vertical li .nav button.toctree-expand,.wy-menu-vertical li.on a .btn button.toctree-expand,.wy-menu-vertical li.on a .nav button.toctree-expand{display:inline}.btn .fa-large.icon,.btn .fa.fa-large,.btn .rst-content .code-block-caption .fa-large.headerlink,.btn .rst-content .eqno .fa-large.headerlink,.btn .rst-content .fa-large.admonition-title,.btn .rst-content code.download span.fa-large:first-child,.btn .rst-content dl dt .fa-large.headerlink,.btn .rst-content h1 .fa-large.headerlink,.btn .rst-content h2 .fa-large.headerlink,.btn .rst-content h3 .fa-large.headerlink,.btn .rst-content h4 .fa-large.headerlink,.btn .rst-content h5 .fa-large.headerlink,.btn .rst-content h6 .fa-large.headerlink,.btn .rst-content p .fa-large.headerlink,.btn .rst-content table>caption .fa-large.headerlink,.btn .rst-content tt.download span.fa-large:first-child,.btn .wy-menu-vertical li button.fa-large.toctree-expand,.nav .fa-large.icon,.nav .fa.fa-large,.nav .rst-content .code-block-caption .fa-large.headerlink,.nav .rst-content .eqno .fa-large.headerlink,.nav .rst-content .fa-large.admonition-title,.nav .rst-content code.download span.fa-large:first-child,.nav .rst-content dl dt .fa-large.headerlink,.nav .rst-content h1 .fa-large.headerlink,.nav .rst-content h2 .fa-large.headerlink,.nav .rst-content h3 .fa-large.headerlink,.nav .rst-content h4 .fa-large.headerlink,.nav .rst-content h5 .fa-large.headerlink,.nav .rst-content h6 .fa-large.headerlink,.nav .rst-content p .fa-large.headerlink,.nav .rst-content table>caption .fa-large.headerlink,.nav .rst-content tt.download span.fa-large:first-child,.nav .wy-menu-vertical li button.fa-large.toctree-expand,.rst-content .btn .fa-large.admonition-title,.rst-content .code-block-caption .btn .fa-large.headerlink,.rst-content .code-block-caption .nav .fa-large.headerlink,.rst-content .eqno .btn .fa-large.headerlink,.rst-content .eqno .nav .fa-large.headerlink,.rst-content .nav .fa-large.admonition-title,.rst-content code.download .btn span.fa-large:first-child,.rst-content code.download .nav span.fa-large:first-child,.rst-content dl dt .btn .fa-large.headerlink,.rst-content dl dt .nav .fa-large.headerlink,.rst-content h1 .btn .fa-large.headerlink,.rst-content h1 .nav .fa-large.headerlink,.rst-content h2 .btn .fa-large.headerlink,.rst-content h2 .nav .fa-large.headerlink,.rst-content h3 .btn .fa-large.headerlink,.rst-content h3 .nav .fa-large.headerlink,.rst-content h4 .btn .fa-large.headerlink,.rst-content h4 .nav .fa-large.headerlink,.rst-content h5 .btn .fa-large.headerlink,.rst-content h5 .nav .fa-large.headerlink,.rst-content h6 .btn .fa-large.headerlink,.rst-content h6 .nav .fa-large.headerlink,.rst-content p .btn .fa-large.headerlink,.rst-content p .nav .fa-large.headerlink,.rst-content table>caption .btn .fa-large.headerlink,.rst-content table>caption .nav .fa-large.headerlink,.rst-content tt.download .btn span.fa-large:first-child,.rst-content tt.download .nav span.fa-large:first-child,.wy-menu-vertical li .btn button.fa-large.toctree-expand,.wy-menu-vertical li .nav button.fa-large.toctree-expand{line-height:.9em}.btn .fa-spin.icon,.btn .fa.fa-spin,.btn .rst-content .code-block-caption .fa-spin.headerlink,.btn .rst-content .eqno .fa-spin.headerlink,.btn .rst-content .fa-spin.admonition-title,.btn .rst-content code.download span.fa-spin:first-child,.btn .rst-content dl dt .fa-spin.headerlink,.btn .rst-content h1 .fa-spin.headerlink,.btn .rst-content h2 .fa-spin.headerlink,.btn .rst-content h3 .fa-spin.headerlink,.btn .rst-content h4 .fa-spin.headerlink,.btn .rst-content h5 .fa-spin.headerlink,.btn .rst-content h6 .fa-spin.headerlink,.btn .rst-content p .fa-spin.headerlink,.btn .rst-content table>caption .fa-spin.headerlink,.btn .rst-content tt.download span.fa-spin:first-child,.btn .wy-menu-vertical li button.fa-spin.toctree-expand,.nav .fa-spin.icon,.nav .fa.fa-spin,.nav .rst-content .code-block-caption .fa-spin.headerlink,.nav .rst-content .eqno .fa-spin.headerlink,.nav .rst-content .fa-spin.admonition-title,.nav .rst-content code.download span.fa-spin:first-child,.nav .rst-content dl dt .fa-spin.headerlink,.nav .rst-content h1 .fa-spin.headerlink,.nav .rst-content h2 .fa-spin.headerlink,.nav .rst-content h3 .fa-spin.headerlink,.nav .rst-content h4 .fa-spin.headerlink,.nav .rst-content h5 .fa-spin.headerlink,.nav .rst-content h6 .fa-spin.headerlink,.nav .rst-content p .fa-spin.headerlink,.nav .rst-content table>caption .fa-spin.headerlink,.nav .rst-content tt.download span.fa-spin:first-child,.nav .wy-menu-vertical li button.fa-spin.toctree-expand,.rst-content .btn .fa-spin.admonition-title,.rst-content .code-block-caption .btn .fa-spin.headerlink,.rst-content .code-block-caption .nav .fa-spin.headerlink,.rst-content .eqno .btn .fa-spin.headerlink,.rst-content .eqno .nav .fa-spin.headerlink,.rst-content .nav .fa-spin.admonition-title,.rst-content code.download .btn span.fa-spin:first-child,.rst-content code.download .nav span.fa-spin:first-child,.rst-content dl dt .btn .fa-spin.headerlink,.rst-content dl dt .nav .fa-spin.headerlink,.rst-content h1 .btn .fa-spin.headerlink,.rst-content h1 .nav .fa-spin.headerlink,.rst-content h2 .btn .fa-spin.headerlink,.rst-content h2 .nav .fa-spin.headerlink,.rst-content h3 .btn .fa-spin.headerlink,.rst-content h3 .nav .fa-spin.headerlink,.rst-content h4 .btn .fa-spin.headerlink,.rst-content h4 .nav .fa-spin.headerlink,.rst-content h5 .btn .fa-spin.headerlink,.rst-content h5 .nav .fa-spin.headerlink,.rst-content h6 .btn .fa-spin.headerlink,.rst-content h6 .nav .fa-spin.headerlink,.rst-content p .btn .fa-spin.headerlink,.rst-content p .nav .fa-spin.headerlink,.rst-content table>caption .btn .fa-spin.headerlink,.rst-content table>caption .nav .fa-spin.headerlink,.rst-content tt.download .btn span.fa-spin:first-child,.rst-content tt.download .nav span.fa-spin:first-child,.wy-menu-vertical li .btn button.fa-spin.toctree-expand,.wy-menu-vertical li .nav button.fa-spin.toctree-expand{display:inline-block}.btn.fa:before,.btn.icon:before,.rst-content .btn.admonition-title:before,.rst-content .code-block-caption .btn.headerlink:before,.rst-content .eqno .btn.headerlink:before,.rst-content code.download span.btn:first-child:before,.rst-content dl dt .btn.headerlink:before,.rst-content h1 .btn.headerlink:before,.rst-content h2 .btn.headerlink:before,.rst-content h3 .btn.headerlink:before,.rst-content h4 .btn.headerlink:before,.rst-content h5 .btn.headerlink:before,.rst-content h6 .btn.headerlink:before,.rst-content p .btn.headerlink:before,.rst-content table>caption .btn.headerlink:before,.rst-content tt.download span.btn:first-child:before,.wy-menu-vertical li button.btn.toctree-expand:before{opacity:.5;-webkit-transition:opacity .05s ease-in;-moz-transition:opacity .05s ease-in;transition:opacity .05s ease-in}.btn.fa:hover:before,.btn.icon:hover:before,.rst-content .btn.admonition-title:hover:before,.rst-content .code-block-caption .btn.headerlink:hover:before,.rst-content .eqno .btn.headerlink:hover:before,.rst-content code.download span.btn:first-child:hover:before,.rst-content dl dt .btn.headerlink:hover:before,.rst-content h1 .btn.headerlink:hover:before,.rst-content h2 .btn.headerlink:hover:before,.rst-content h3 .btn.headerlink:hover:before,.rst-content h4 .btn.headerlink:hover:before,.rst-content h5 .btn.headerlink:hover:before,.rst-content h6 .btn.headerlink:hover:before,.rst-content p .btn.headerlink:hover:before,.rst-content table>caption .btn.headerlink:hover:before,.rst-content tt.download span.btn:first-child:hover:before,.wy-menu-vertical li button.btn.toctree-expand:hover:before{opacity:1}.btn-mini .fa:before,.btn-mini .icon:before,.btn-mini .rst-content .admonition-title:before,.btn-mini .rst-content .code-block-caption .headerlink:before,.btn-mini .rst-content .eqno .headerlink:before,.btn-mini .rst-content code.download span:first-child:before,.btn-mini .rst-content dl dt .headerlink:before,.btn-mini .rst-content h1 .headerlink:before,.btn-mini .rst-content h2 .headerlink:before,.btn-mini .rst-content h3 .headerlink:before,.btn-mini .rst-content h4 .headerlink:before,.btn-mini .rst-content h5 .headerlink:before,.btn-mini .rst-content h6 .headerlink:before,.btn-mini .rst-content p .headerlink:before,.btn-mini .rst-content table>caption .headerlink:before,.btn-mini .rst-content tt.download span:first-child:before,.btn-mini .wy-menu-vertical li button.toctree-expand:before,.rst-content .btn-mini .admonition-title:before,.rst-content .code-block-caption .btn-mini .headerlink:before,.rst-content .eqno .btn-mini .headerlink:before,.rst-content code.download .btn-mini span:first-child:before,.rst-content dl dt .btn-mini .headerlink:before,.rst-content h1 .btn-mini .headerlink:before,.rst-content h2 .btn-mini .headerlink:before,.rst-content h3 .btn-mini .headerlink:before,.rst-content h4 .btn-mini .headerlink:before,.rst-content h5 .btn-mini .headerlink:before,.rst-content h6 .btn-mini .headerlink:before,.rst-content p .btn-mini .headerlink:before,.rst-content table>caption .btn-mini .headerlink:before,.rst-content tt.download .btn-mini span:first-child:before,.wy-menu-vertical li .btn-mini button.toctree-expand:before{font-size:14px;vertical-align:-15%}.rst-content .admonition,.rst-content .admonition-todo,.rst-content .attention,.rst-content .caution,.rst-content .danger,.rst-content .error,.rst-content .hint,.rst-content .important,.rst-content .note,.rst-content .seealso,.rst-content .tip,.rst-content .warning,.wy-alert{padding:12px;line-height:24px;margin-bottom:24px;background:#e7f2fa}.rst-content .admonition-title,.wy-alert-title{font-weight:700;display:block;color:#fff;background:#6ab0de;padding:6px 12px;margin:-12px -12px 12px}.rst-content .danger,.rst-content .error,.rst-content .wy-alert-danger.admonition,.rst-content .wy-alert-danger.admonition-todo,.rst-content .wy-alert-danger.attention,.rst-content .wy-alert-danger.caution,.rst-content .wy-alert-danger.hint,.rst-content .wy-alert-danger.important,.rst-content .wy-alert-danger.note,.rst-content .wy-alert-danger.seealso,.rst-content .wy-alert-danger.tip,.rst-content .wy-alert-danger.warning,.wy-alert.wy-alert-danger{background:#fdf3f2}.rst-content .danger .admonition-title,.rst-content .danger .wy-alert-title,.rst-content .error .admonition-title,.rst-content .error .wy-alert-title,.rst-content .wy-alert-danger.admonition-todo .admonition-title,.rst-content .wy-alert-danger.admonition-todo .wy-alert-title,.rst-content .wy-alert-danger.admonition .admonition-title,.rst-content .wy-alert-danger.admonition .wy-alert-title,.rst-content .wy-alert-danger.attention .admonition-title,.rst-content .wy-alert-danger.attention .wy-alert-title,.rst-content .wy-alert-danger.caution .admonition-title,.rst-content .wy-alert-danger.caution .wy-alert-title,.rst-content .wy-alert-danger.hint .admonition-title,.rst-content .wy-alert-danger.hint .wy-alert-title,.rst-content .wy-alert-danger.important .admonition-title,.rst-content .wy-alert-danger.important .wy-alert-title,.rst-content .wy-alert-danger.note .admonition-title,.rst-content .wy-alert-danger.note .wy-alert-title,.rst-content .wy-alert-danger.seealso .admonition-title,.rst-content .wy-alert-danger.seealso .wy-alert-title,.rst-content .wy-alert-danger.tip .admonition-title,.rst-content .wy-alert-danger.tip .wy-alert-title,.rst-content .wy-alert-danger.warning .admonition-title,.rst-content .wy-alert-danger.warning .wy-alert-title,.rst-content .wy-alert.wy-alert-danger .admonition-title,.wy-alert.wy-alert-danger .rst-content .admonition-title,.wy-alert.wy-alert-danger .wy-alert-title{background:#f29f97}.rst-content .admonition-todo,.rst-content .attention,.rst-content .caution,.rst-content .warning,.rst-content .wy-alert-warning.admonition,.rst-content .wy-alert-warning.danger,.rst-content .wy-alert-warning.error,.rst-content .wy-alert-warning.hint,.rst-content .wy-alert-warning.important,.rst-content .wy-alert-warning.note,.rst-content .wy-alert-warning.seealso,.rst-content .wy-alert-warning.tip,.wy-alert.wy-alert-warning{background:#ffedcc}.rst-content .admonition-todo .admonition-title,.rst-content .admonition-todo .wy-alert-title,.rst-content .attention .admonition-title,.rst-content .attention .wy-alert-title,.rst-content .caution .admonition-title,.rst-content .caution .wy-alert-title,.rst-content .warning .admonition-title,.rst-content .warning .wy-alert-title,.rst-content .wy-alert-warning.admonition .admonition-title,.rst-content .wy-alert-warning.admonition .wy-alert-title,.rst-content .wy-alert-warning.danger .admonition-title,.rst-content .wy-alert-warning.danger .wy-alert-title,.rst-content .wy-alert-warning.error .admonition-title,.rst-content .wy-alert-warning.error .wy-alert-title,.rst-content .wy-alert-warning.hint .admonition-title,.rst-content .wy-alert-warning.hint .wy-alert-title,.rst-content .wy-alert-warning.important .admonition-title,.rst-content .wy-alert-warning.important .wy-alert-title,.rst-content .wy-alert-warning.note .admonition-title,.rst-content .wy-alert-warning.note .wy-alert-title,.rst-content .wy-alert-warning.seealso .admonition-title,.rst-content .wy-alert-warning.seealso .wy-alert-title,.rst-content .wy-alert-warning.tip .admonition-title,.rst-content .wy-alert-warning.tip .wy-alert-title,.rst-content .wy-alert.wy-alert-warning .admonition-title,.wy-alert.wy-alert-warning .rst-content .admonition-title,.wy-alert.wy-alert-warning .wy-alert-title{background:#f0b37e}.rst-content .note,.rst-content .seealso,.rst-content .wy-alert-info.admonition,.rst-content .wy-alert-info.admonition-todo,.rst-content .wy-alert-info.attention,.rst-content .wy-alert-info.caution,.rst-content .wy-alert-info.danger,.rst-content .wy-alert-info.error,.rst-content .wy-alert-info.hint,.rst-content .wy-alert-info.important,.rst-content .wy-alert-info.tip,.rst-content .wy-alert-info.warning,.wy-alert.wy-alert-info{background:#e7f2fa}.rst-content .note .admonition-title,.rst-content .note .wy-alert-title,.rst-content .seealso .admonition-title,.rst-content .seealso .wy-alert-title,.rst-content .wy-alert-info.admonition-todo .admonition-title,.rst-content .wy-alert-info.admonition-todo .wy-alert-title,.rst-content .wy-alert-info.admonition .admonition-title,.rst-content .wy-alert-info.admonition .wy-alert-title,.rst-content .wy-alert-info.attention .admonition-title,.rst-content .wy-alert-info.attention .wy-alert-title,.rst-content .wy-alert-info.caution .admonition-title,.rst-content .wy-alert-info.caution .wy-alert-title,.rst-content .wy-alert-info.danger .admonition-title,.rst-content .wy-alert-info.danger .wy-alert-title,.rst-content .wy-alert-info.error .admonition-title,.rst-content .wy-alert-info.error .wy-alert-title,.rst-content .wy-alert-info.hint .admonition-title,.rst-content .wy-alert-info.hint .wy-alert-title,.rst-content .wy-alert-info.important .admonition-title,.rst-content .wy-alert-info.important .wy-alert-title,.rst-content .wy-alert-info.tip .admonition-title,.rst-content .wy-alert-info.tip .wy-alert-title,.rst-content .wy-alert-info.warning .admonition-title,.rst-content .wy-alert-info.warning .wy-alert-title,.rst-content .wy-alert.wy-alert-info .admonition-title,.wy-alert.wy-alert-info .rst-content .admonition-title,.wy-alert.wy-alert-info .wy-alert-title{background:#6ab0de}.rst-content .hint,.rst-content .important,.rst-content .tip,.rst-content .wy-alert-success.admonition,.rst-content .wy-alert-success.admonition-todo,.rst-content .wy-alert-success.attention,.rst-content .wy-alert-success.caution,.rst-content .wy-alert-success.danger,.rst-content .wy-alert-success.error,.rst-content .wy-alert-success.note,.rst-content .wy-alert-success.seealso,.rst-content .wy-alert-success.warning,.wy-alert.wy-alert-success{background:#dbfaf4}.rst-content .hint .admonition-title,.rst-content .hint .wy-alert-title,.rst-content .important .admonition-title,.rst-content .important .wy-alert-title,.rst-content .tip .admonition-title,.rst-content .tip .wy-alert-title,.rst-content .wy-alert-success.admonition-todo .admonition-title,.rst-content .wy-alert-success.admonition-todo .wy-alert-title,.rst-content .wy-alert-success.admonition .admonition-title,.rst-content .wy-alert-success.admonition .wy-alert-title,.rst-content .wy-alert-success.attention .admonition-title,.rst-content .wy-alert-success.attention .wy-alert-title,.rst-content .wy-alert-success.caution .admonition-title,.rst-content .wy-alert-success.caution .wy-alert-title,.rst-content .wy-alert-success.danger .admonition-title,.rst-content .wy-alert-success.danger .wy-alert-title,.rst-content .wy-alert-success.error .admonition-title,.rst-content .wy-alert-success.error .wy-alert-title,.rst-content .wy-alert-success.note .admonition-title,.rst-content .wy-alert-success.note .wy-alert-title,.rst-content .wy-alert-success.seealso .admonition-title,.rst-content .wy-alert-success.seealso .wy-alert-title,.rst-content .wy-alert-success.warning .admonition-title,.rst-content .wy-alert-success.warning .wy-alert-title,.rst-content .wy-alert.wy-alert-success .admonition-title,.wy-alert.wy-alert-success .rst-content .admonition-title,.wy-alert.wy-alert-success .wy-alert-title{background:#1abc9c}.rst-content .wy-alert-neutral.admonition,.rst-content .wy-alert-neutral.admonition-todo,.rst-content .wy-alert-neutral.attention,.rst-content .wy-alert-neutral.caution,.rst-content .wy-alert-neutral.danger,.rst-content .wy-alert-neutral.error,.rst-content .wy-alert-neutral.hint,.rst-content .wy-alert-neutral.important,.rst-content .wy-alert-neutral.note,.rst-content .wy-alert-neutral.seealso,.rst-content .wy-alert-neutral.tip,.rst-content .wy-alert-neutral.warning,.wy-alert.wy-alert-neutral{background:#f3f6f6}.rst-content .wy-alert-neutral.admonition-todo .admonition-title,.rst-content .wy-alert-neutral.admonition-todo .wy-alert-title,.rst-content .wy-alert-neutral.admonition .admonition-title,.rst-content .wy-alert-neutral.admonition .wy-alert-title,.rst-content .wy-alert-neutral.attention .admonition-title,.rst-content .wy-alert-neutral.attention .wy-alert-title,.rst-content .wy-alert-neutral.caution .admonition-title,.rst-content .wy-alert-neutral.caution .wy-alert-title,.rst-content .wy-alert-neutral.danger .admonition-title,.rst-content .wy-alert-neutral.danger .wy-alert-title,.rst-content .wy-alert-neutral.error .admonition-title,.rst-content .wy-alert-neutral.error .wy-alert-title,.rst-content .wy-alert-neutral.hint .admonition-title,.rst-content .wy-alert-neutral.hint .wy-alert-title,.rst-content .wy-alert-neutral.important .admonition-title,.rst-content .wy-alert-neutral.important .wy-alert-title,.rst-content .wy-alert-neutral.note .admonition-title,.rst-content .wy-alert-neutral.note .wy-alert-title,.rst-content .wy-alert-neutral.seealso .admonition-title,.rst-content .wy-alert-neutral.seealso .wy-alert-title,.rst-content .wy-alert-neutral.tip .admonition-title,.rst-content .wy-alert-neutral.tip .wy-alert-title,.rst-content .wy-alert-neutral.warning .admonition-title,.rst-content .wy-alert-neutral.warning .wy-alert-title,.rst-content .wy-alert.wy-alert-neutral .admonition-title,.wy-alert.wy-alert-neutral .rst-content .admonition-title,.wy-alert.wy-alert-neutral .wy-alert-title{color:#404040;background:#e1e4e5}.rst-content .wy-alert-neutral.admonition-todo a,.rst-content .wy-alert-neutral.admonition a,.rst-content .wy-alert-neutral.attention a,.rst-content .wy-alert-neutral.caution a,.rst-content .wy-alert-neutral.danger a,.rst-content .wy-alert-neutral.error a,.rst-content .wy-alert-neutral.hint a,.rst-content .wy-alert-neutral.important a,.rst-content .wy-alert-neutral.note a,.rst-content .wy-alert-neutral.seealso a,.rst-content .wy-alert-neutral.tip a,.rst-content .wy-alert-neutral.warning a,.wy-alert.wy-alert-neutral a{color:#2980b9}.rst-content .admonition-todo p:last-child,.rst-content .admonition p:last-child,.rst-content .attention p:last-child,.rst-content .caution p:last-child,.rst-content .danger p:last-child,.rst-content .error p:last-child,.rst-content .hint p:last-child,.rst-content .important p:last-child,.rst-content .note p:last-child,.rst-content .seealso p:last-child,.rst-content .tip p:last-child,.rst-content .warning p:last-child,.wy-alert p:last-child{margin-bottom:0}.wy-tray-container{position:fixed;bottom:0;left:0;z-index:600}.wy-tray-container li{display:block;width:300px;background:transparent;color:#fff;text-align:center;box-shadow:0 5px 5px 0 rgba(0,0,0,.1);padding:0 24px;min-width:20%;opacity:0;height:0;line-height:56px;overflow:hidden;-webkit-transition:all .3s ease-in;-moz-transition:all .3s ease-in;transition:all .3s ease-in}.wy-tray-container li.wy-tray-item-success{background:#27ae60}.wy-tray-container li.wy-tray-item-info{background:#2980b9}.wy-tray-container li.wy-tray-item-warning{background:#e67e22}.wy-tray-container li.wy-tray-item-danger{background:#e74c3c}.wy-tray-container li.on{opacity:1;height:56px}@media screen and (max-width:768px){.wy-tray-container{bottom:auto;top:0;width:100%}.wy-tray-container li{width:100%}}button{font-size:100%;margin:0;vertical-align:baseline;*vertical-align:middle;cursor:pointer;line-height:normal;-webkit-appearance:button;*overflow:visible}button::-moz-focus-inner,input::-moz-focus-inner{border:0;padding:0}button[disabled]{cursor:default}.btn{display:inline-block;border-radius:2px;line-height:normal;white-space:nowrap;text-align:center;cursor:pointer;font-size:100%;padding:6px 12px 8px;color:#fff;border:1px solid rgba(0,0,0,.1);background-color:#27ae60;text-decoration:none;font-weight:400;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;box-shadow:inset 0 1px 2px -1px hsla(0,0%,100%,.5),inset 0 -2px 0 0 rgba(0,0,0,.1);outline-none:false;vertical-align:middle;*display:inline;zoom:1;-webkit-user-drag:none;-webkit-user-select:none;-moz-user-select:none;-ms-user-select:none;user-select:none;-webkit-transition:all .1s linear;-moz-transition:all .1s linear;transition:all .1s linear}.btn-hover{background:#2e8ece;color:#fff}.btn:hover{background:#2cc36b;color:#fff}.btn:focus{background:#2cc36b;outline:0}.btn:active{box-shadow:inset 0 -1px 0 0 rgba(0,0,0,.05),inset 0 2px 0 0 rgba(0,0,0,.1);padding:8px 12px 6px}.btn:visited{color:#fff}.btn-disabled,.btn-disabled:active,.btn-disabled:focus,.btn-disabled:hover,.btn:disabled{background-image:none;filter:progid:DXImageTransform.Microsoft.gradient(enabled = false);filter:alpha(opacity=40);opacity:.4;cursor:not-allowed;box-shadow:none}.btn::-moz-focus-inner{padding:0;border:0}.btn-small{font-size:80%}.btn-info{background-color:#2980b9!important}.btn-info:hover{background-color:#2e8ece!important}.btn-neutral{background-color:#f3f6f6!important;color:#404040!important}.btn-neutral:hover{background-color:#e5ebeb!important;color:#404040}.btn-neutral:visited{color:#404040!important}.btn-success{background-color:#27ae60!important}.btn-success:hover{background-color:#295!important}.btn-danger{background-color:#e74c3c!important}.btn-danger:hover{background-color:#ea6153!important}.btn-warning{background-color:#e67e22!important}.btn-warning:hover{background-color:#e98b39!important}.btn-invert{background-color:#222}.btn-invert:hover{background-color:#2f2f2f!important}.btn-link{background-color:transparent!important;color:#2980b9;box-shadow:none;border-color:transparent!important}.btn-link:active,.btn-link:hover{background-color:transparent!important;color:#409ad5!important;box-shadow:none}.btn-link:visited{color:#9b59b6}.wy-btn-group .btn,.wy-control .btn{vertical-align:middle}.wy-btn-group{margin-bottom:24px;*zoom:1}.wy-btn-group:after,.wy-btn-group:before{display:table;content:""}.wy-btn-group:after{clear:both}.wy-dropdown{position:relative;display:inline-block}.wy-dropdown-active .wy-dropdown-menu{display:block}.wy-dropdown-menu{position:absolute;left:0;display:none;float:left;top:100%;min-width:100%;background:#fcfcfc;z-index:100;border:1px solid #cfd7dd;box-shadow:0 2px 2px 0 rgba(0,0,0,.1);padding:12px}.wy-dropdown-menu>dd>a{display:block;clear:both;color:#404040;white-space:nowrap;font-size:90%;padding:0 12px;cursor:pointer}.wy-dropdown-menu>dd>a:hover{background:#2980b9;color:#fff}.wy-dropdown-menu>dd.divider{border-top:1px solid #cfd7dd;margin:6px 0}.wy-dropdown-menu>dd.search{padding-bottom:12px}.wy-dropdown-menu>dd.search input[type=search]{width:100%}.wy-dropdown-menu>dd.call-to-action{background:#e3e3e3;text-transform:uppercase;font-weight:500;font-size:80%}.wy-dropdown-menu>dd.call-to-action:hover{background:#e3e3e3}.wy-dropdown-menu>dd.call-to-action .btn{color:#fff}.wy-dropdown.wy-dropdown-up .wy-dropdown-menu{bottom:100%;top:auto;left:auto;right:0}.wy-dropdown.wy-dropdown-bubble .wy-dropdown-menu{background:#fcfcfc;margin-top:2px}.wy-dropdown.wy-dropdown-bubble .wy-dropdown-menu a{padding:6px 12px}.wy-dropdown.wy-dropdown-bubble .wy-dropdown-menu a:hover{background:#2980b9;color:#fff}.wy-dropdown.wy-dropdown-left .wy-dropdown-menu{right:0;left:auto;text-align:right}.wy-dropdown-arrow:before{content:" ";border-bottom:5px solid #f5f5f5;border-left:5px solid transparent;border-right:5px solid transparent;position:absolute;display:block;top:-4px;left:50%;margin-left:-3px}.wy-dropdown-arrow.wy-dropdown-arrow-left:before{left:11px}.wy-form-stacked select{display:block}.wy-form-aligned .wy-help-inline,.wy-form-aligned input,.wy-form-aligned label,.wy-form-aligned select,.wy-form-aligned textarea{display:inline-block;*display:inline;*zoom:1;vertical-align:middle}.wy-form-aligned .wy-control-group>label{display:inline-block;vertical-align:middle;width:10em;margin:6px 12px 0 0;float:left}.wy-form-aligned .wy-control{float:left}.wy-form-aligned .wy-control label{display:block}.wy-form-aligned .wy-control select{margin-top:6px}fieldset{margin:0}fieldset,legend{border:0;padding:0}legend{width:100%;white-space:normal;margin-bottom:24px;font-size:150%;*margin-left:-7px}label,legend{display:block}label{margin:0 0 .3125em;color:#333;font-size:90%}input,select,textarea{font-size:100%;margin:0;vertical-align:baseline;*vertical-align:middle}.wy-control-group{margin-bottom:24px;max-width:1200px;margin-left:auto;margin-right:auto;*zoom:1}.wy-control-group:after,.wy-control-group:before{display:table;content:""}.wy-control-group:after{clear:both}.wy-control-group.wy-control-group-required>label:after{content:" *";color:#e74c3c}.wy-control-group .wy-form-full,.wy-control-group .wy-form-halves,.wy-control-group .wy-form-thirds{padding-bottom:12px}.wy-control-group .wy-form-full input[type=color],.wy-control-group .wy-form-full input[type=date],.wy-control-group .wy-form-full input[type=datetime-local],.wy-control-group .wy-form-full input[type=datetime],.wy-control-group .wy-form-full input[type=email],.wy-control-group .wy-form-full input[type=month],.wy-control-group .wy-form-full input[type=number],.wy-control-group .wy-form-full input[type=password],.wy-control-group .wy-form-full input[type=search],.wy-control-group .wy-form-full input[type=tel],.wy-control-group .wy-form-full input[type=text],.wy-control-group .wy-form-full input[type=time],.wy-control-group .wy-form-full input[type=url],.wy-control-group .wy-form-full input[type=week],.wy-control-group .wy-form-full select,.wy-control-group .wy-form-halves input[type=color],.wy-control-group .wy-form-halves input[type=date],.wy-control-group .wy-form-halves input[type=datetime-local],.wy-control-group .wy-form-halves input[type=datetime],.wy-control-group .wy-form-halves input[type=email],.wy-control-group .wy-form-halves input[type=month],.wy-control-group .wy-form-halves input[type=number],.wy-control-group .wy-form-halves input[type=password],.wy-control-group .wy-form-halves input[type=search],.wy-control-group .wy-form-halves input[type=tel],.wy-control-group .wy-form-halves input[type=text],.wy-control-group .wy-form-halves input[type=time],.wy-control-group .wy-form-halves input[type=url],.wy-control-group .wy-form-halves input[type=week],.wy-control-group .wy-form-halves select,.wy-control-group .wy-form-thirds input[type=color],.wy-control-group .wy-form-thirds input[type=date],.wy-control-group .wy-form-thirds input[type=datetime-local],.wy-control-group .wy-form-thirds input[type=datetime],.wy-control-group .wy-form-thirds input[type=email],.wy-control-group .wy-form-thirds input[type=month],.wy-control-group .wy-form-thirds input[type=number],.wy-control-group .wy-form-thirds input[type=password],.wy-control-group .wy-form-thirds input[type=search],.wy-control-group .wy-form-thirds input[type=tel],.wy-control-group .wy-form-thirds input[type=text],.wy-control-group .wy-form-thirds input[type=time],.wy-control-group .wy-form-thirds input[type=url],.wy-control-group .wy-form-thirds input[type=week],.wy-control-group .wy-form-thirds select{width:100%}.wy-control-group .wy-form-full{float:left;display:block;width:100%;margin-right:0}.wy-control-group .wy-form-full:last-child{margin-right:0}.wy-control-group .wy-form-halves{float:left;display:block;margin-right:2.35765%;width:48.82117%}.wy-control-group .wy-form-halves:last-child,.wy-control-group .wy-form-halves:nth-of-type(2n){margin-right:0}.wy-control-group .wy-form-halves:nth-of-type(odd){clear:left}.wy-control-group .wy-form-thirds{float:left;display:block;margin-right:2.35765%;width:31.76157%}.wy-control-group .wy-form-thirds:last-child,.wy-control-group .wy-form-thirds:nth-of-type(3n){margin-right:0}.wy-control-group .wy-form-thirds:nth-of-type(3n+1){clear:left}.wy-control-group.wy-control-group-no-input .wy-control,.wy-control-no-input{margin:6px 0 0;font-size:90%}.wy-control-no-input{display:inline-block}.wy-control-group.fluid-input input[type=color],.wy-control-group.fluid-input input[type=date],.wy-control-group.fluid-input input[type=datetime-local],.wy-control-group.fluid-input input[type=datetime],.wy-control-group.fluid-input input[type=email],.wy-control-group.fluid-input input[type=month],.wy-control-group.fluid-input input[type=number],.wy-control-group.fluid-input input[type=password],.wy-control-group.fluid-input input[type=search],.wy-control-group.fluid-input input[type=tel],.wy-control-group.fluid-input input[type=text],.wy-control-group.fluid-input input[type=time],.wy-control-group.fluid-input input[type=url],.wy-control-group.fluid-input input[type=week]{width:100%}.wy-form-message-inline{padding-left:.3em;color:#666;font-size:90%}.wy-form-message{display:block;color:#999;font-size:70%;margin-top:.3125em;font-style:italic}.wy-form-message p{font-size:inherit;font-style:italic;margin-bottom:6px}.wy-form-message p:last-child{margin-bottom:0}input{line-height:normal}input[type=button],input[type=reset],input[type=submit]{-webkit-appearance:button;cursor:pointer;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;*overflow:visible}input[type=color],input[type=date],input[type=datetime-local],input[type=datetime],input[type=email],input[type=month],input[type=number],input[type=password],input[type=search],input[type=tel],input[type=text],input[type=time],input[type=url],input[type=week]{-webkit-appearance:none;padding:6px;display:inline-block;border:1px solid #ccc;font-size:80%;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;box-shadow:inset 0 1px 3px #ddd;border-radius:0;-webkit-transition:border .3s linear;-moz-transition:border .3s linear;transition:border .3s linear}input[type=datetime-local]{padding:.34375em .625em}input[disabled]{cursor:default}input[type=checkbox],input[type=radio]{padding:0;margin-right:.3125em;*height:13px;*width:13px}input[type=checkbox],input[type=radio],input[type=search]{-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}input[type=search]::-webkit-search-cancel-button,input[type=search]::-webkit-search-decoration{-webkit-appearance:none}input[type=color]:focus,input[type=date]:focus,input[type=datetime-local]:focus,input[type=datetime]:focus,input[type=email]:focus,input[type=month]:focus,input[type=number]:focus,input[type=password]:focus,input[type=search]:focus,input[type=tel]:focus,input[type=text]:focus,input[type=time]:focus,input[type=url]:focus,input[type=week]:focus{outline:0;outline:thin dotted\9;border-color:#333}input.no-focus:focus{border-color:#ccc!important}input[type=checkbox]:focus,input[type=file]:focus,input[type=radio]:focus{outline:thin dotted #333;outline:1px auto #129fea}input[type=color][disabled],input[type=date][disabled],input[type=datetime-local][disabled],input[type=datetime][disabled],input[type=email][disabled],input[type=month][disabled],input[type=number][disabled],input[type=password][disabled],input[type=search][disabled],input[type=tel][disabled],input[type=text][disabled],input[type=time][disabled],input[type=url][disabled],input[type=week][disabled]{cursor:not-allowed;background-color:#fafafa}input:focus:invalid,select:focus:invalid,textarea:focus:invalid{color:#e74c3c;border:1px solid #e74c3c}input:focus:invalid:focus,select:focus:invalid:focus,textarea:focus:invalid:focus{border-color:#e74c3c}input[type=checkbox]:focus:invalid:focus,input[type=file]:focus:invalid:focus,input[type=radio]:focus:invalid:focus{outline-color:#e74c3c}input.wy-input-large{padding:12px;font-size:100%}textarea{overflow:auto;vertical-align:top;width:100%;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif}select,textarea{padding:.5em .625em;display:inline-block;border:1px solid #ccc;font-size:80%;box-shadow:inset 0 1px 3px #ddd;-webkit-transition:border .3s linear;-moz-transition:border .3s linear;transition:border .3s linear}select{border:1px solid #ccc;background-color:#fff}select[multiple]{height:auto}select:focus,textarea:focus{outline:0}input[readonly],select[disabled],select[readonly],textarea[disabled],textarea[readonly]{cursor:not-allowed;background-color:#fafafa}input[type=checkbox][disabled],input[type=radio][disabled]{cursor:not-allowed}.wy-checkbox,.wy-radio{margin:6px 0;color:#404040;display:block}.wy-checkbox input,.wy-radio input{vertical-align:baseline}.wy-form-message-inline{display:inline-block;*display:inline;*zoom:1;vertical-align:middle}.wy-input-prefix,.wy-input-suffix{white-space:nowrap;padding:6px}.wy-input-prefix .wy-input-context,.wy-input-suffix .wy-input-context{line-height:27px;padding:0 8px;display:inline-block;font-size:80%;background-color:#f3f6f6;border:1px solid #ccc;color:#999}.wy-input-suffix .wy-input-context{border-left:0}.wy-input-prefix .wy-input-context{border-right:0}.wy-switch{position:relative;display:block;height:24px;margin-top:12px;cursor:pointer}.wy-switch:before{left:0;top:0;width:36px;height:12px;background:#ccc}.wy-switch:after,.wy-switch:before{position:absolute;content:"";display:block;border-radius:4px;-webkit-transition:all .2s ease-in-out;-moz-transition:all .2s ease-in-out;transition:all .2s ease-in-out}.wy-switch:after{width:18px;height:18px;background:#999;left:-3px;top:-3px}.wy-switch span{position:absolute;left:48px;display:block;font-size:12px;color:#ccc;line-height:1}.wy-switch.active:before{background:#1e8449}.wy-switch.active:after{left:24px;background:#27ae60}.wy-switch.disabled{cursor:not-allowed;opacity:.8}.wy-control-group.wy-control-group-error .wy-form-message,.wy-control-group.wy-control-group-error>label{color:#e74c3c}.wy-control-group.wy-control-group-error input[type=color],.wy-control-group.wy-control-group-error input[type=date],.wy-control-group.wy-control-group-error input[type=datetime-local],.wy-control-group.wy-control-group-error input[type=datetime],.wy-control-group.wy-control-group-error input[type=email],.wy-control-group.wy-control-group-error input[type=month],.wy-control-group.wy-control-group-error input[type=number],.wy-control-group.wy-control-group-error input[type=password],.wy-control-group.wy-control-group-error input[type=search],.wy-control-group.wy-control-group-error input[type=tel],.wy-control-group.wy-control-group-error input[type=text],.wy-control-group.wy-control-group-error input[type=time],.wy-control-group.wy-control-group-error input[type=url],.wy-control-group.wy-control-group-error input[type=week],.wy-control-group.wy-control-group-error textarea{border:1px solid #e74c3c}.wy-inline-validate{white-space:nowrap}.wy-inline-validate .wy-input-context{padding:.5em .625em;display:inline-block;font-size:80%}.wy-inline-validate.wy-inline-validate-success .wy-input-context{color:#27ae60}.wy-inline-validate.wy-inline-validate-danger .wy-input-context{color:#e74c3c}.wy-inline-validate.wy-inline-validate-warning .wy-input-context{color:#e67e22}.wy-inline-validate.wy-inline-validate-info .wy-input-context{color:#2980b9}.rotate-90{-webkit-transform:rotate(90deg);-moz-transform:rotate(90deg);-ms-transform:rotate(90deg);-o-transform:rotate(90deg);transform:rotate(90deg)}.rotate-180{-webkit-transform:rotate(180deg);-moz-transform:rotate(180deg);-ms-transform:rotate(180deg);-o-transform:rotate(180deg);transform:rotate(180deg)}.rotate-270{-webkit-transform:rotate(270deg);-moz-transform:rotate(270deg);-ms-transform:rotate(270deg);-o-transform:rotate(270deg);transform:rotate(270deg)}.mirror{-webkit-transform:scaleX(-1);-moz-transform:scaleX(-1);-ms-transform:scaleX(-1);-o-transform:scaleX(-1);transform:scaleX(-1)}.mirror.rotate-90{-webkit-transform:scaleX(-1) rotate(90deg);-moz-transform:scaleX(-1) rotate(90deg);-ms-transform:scaleX(-1) rotate(90deg);-o-transform:scaleX(-1) rotate(90deg);transform:scaleX(-1) rotate(90deg)}.mirror.rotate-180{-webkit-transform:scaleX(-1) rotate(180deg);-moz-transform:scaleX(-1) rotate(180deg);-ms-transform:scaleX(-1) rotate(180deg);-o-transform:scaleX(-1) rotate(180deg);transform:scaleX(-1) rotate(180deg)}.mirror.rotate-270{-webkit-transform:scaleX(-1) rotate(270deg);-moz-transform:scaleX(-1) rotate(270deg);-ms-transform:scaleX(-1) rotate(270deg);-o-transform:scaleX(-1) rotate(270deg);transform:scaleX(-1) rotate(270deg)}@media only screen and (max-width:480px){.wy-form button[type=submit]{margin:.7em 0 0}.wy-form input[type=color],.wy-form input[type=date],.wy-form input[type=datetime-local],.wy-form input[type=datetime],.wy-form input[type=email],.wy-form input[type=month],.wy-form input[type=number],.wy-form input[type=password],.wy-form input[type=search],.wy-form input[type=tel],.wy-form input[type=text],.wy-form input[type=time],.wy-form input[type=url],.wy-form input[type=week],.wy-form label{margin-bottom:.3em;display:block}.wy-form input[type=color],.wy-form input[type=date],.wy-form input[type=datetime-local],.wy-form input[type=datetime],.wy-form input[type=email],.wy-form input[type=month],.wy-form input[type=number],.wy-form input[type=password],.wy-form input[type=search],.wy-form input[type=tel],.wy-form input[type=time],.wy-form input[type=url],.wy-form input[type=week]{margin-bottom:0}.wy-form-aligned .wy-control-group label{margin-bottom:.3em;text-align:left;display:block;width:100%}.wy-form-aligned .wy-control{margin:1.5em 0 0}.wy-form-message,.wy-form-message-inline,.wy-form .wy-help-inline{display:block;font-size:80%;padding:6px 0}}@media screen and (max-width:768px){.tablet-hide{display:none}}@media screen and (max-width:480px){.mobile-hide{display:none}}.float-left{float:left}.float-right{float:right}.full-width{width:100%}.rst-content table.docutils,.rst-content table.field-list,.wy-table{border-collapse:collapse;border-spacing:0;empty-cells:show;margin-bottom:24px}.rst-content table.docutils caption,.rst-content table.field-list caption,.wy-table caption{color:#000;font:italic 85%/1 arial,sans-serif;padding:1em 0;text-align:center}.rst-content table.docutils td,.rst-content table.docutils th,.rst-content table.field-list td,.rst-content table.field-list th,.wy-table td,.wy-table th{font-size:90%;margin:0;overflow:visible;padding:8px 16px}.rst-content table.docutils td:first-child,.rst-content table.docutils th:first-child,.rst-content table.field-list td:first-child,.rst-content table.field-list th:first-child,.wy-table td:first-child,.wy-table th:first-child{border-left-width:0}.rst-content table.docutils thead,.rst-content table.field-list thead,.wy-table thead{color:#000;text-align:left;vertical-align:bottom;white-space:nowrap}.rst-content table.docutils thead th,.rst-content table.field-list thead th,.wy-table thead th{font-weight:700;border-bottom:2px solid #e1e4e5}.rst-content table.docutils td,.rst-content table.field-list td,.wy-table td{background-color:transparent;vertical-align:middle}.rst-content table.docutils td p,.rst-content table.field-list td p,.wy-table td p{line-height:18px}.rst-content table.docutils td p:last-child,.rst-content table.field-list td p:last-child,.wy-table td p:last-child{margin-bottom:0}.rst-content table.docutils .wy-table-cell-min,.rst-content table.field-list .wy-table-cell-min,.wy-table .wy-table-cell-min{width:1%;padding-right:0}.rst-content table.docutils .wy-table-cell-min input[type=checkbox],.rst-content table.field-list .wy-table-cell-min input[type=checkbox],.wy-table .wy-table-cell-min input[type=checkbox]{margin:0}.wy-table-secondary{color:grey;font-size:90%}.wy-table-tertiary{color:grey;font-size:80%}.rst-content table.docutils:not(.field-list) tr:nth-child(2n-1) td,.wy-table-backed,.wy-table-odd td,.wy-table-striped tr:nth-child(2n-1) td{background-color:#f3f6f6}.rst-content table.docutils,.wy-table-bordered-all{border:1px solid #e1e4e5}.rst-content table.docutils td,.wy-table-bordered-all td{border-bottom:1px solid #e1e4e5;border-left:1px solid #e1e4e5}.rst-content table.docutils tbody>tr:last-child td,.wy-table-bordered-all tbody>tr:last-child td{border-bottom-width:0}.wy-table-bordered{border:1px solid #e1e4e5}.wy-table-bordered-rows td{border-bottom:1px solid #e1e4e5}.wy-table-bordered-rows tbody>tr:last-child td{border-bottom-width:0}.wy-table-horizontal td,.wy-table-horizontal th{border-width:0 0 1px;border-bottom:1px solid #e1e4e5}.wy-table-horizontal tbody>tr:last-child td{border-bottom-width:0}.wy-table-responsive{margin-bottom:24px;max-width:100%;overflow:auto}.wy-table-responsive table{margin-bottom:0!important}.wy-table-responsive table td,.wy-table-responsive table th{white-space:nowrap}a{color:#2980b9;text-decoration:none;cursor:pointer}a:hover{color:#3091d1}a:visited{color:#9b59b6}html{height:100%}body,html{overflow-x:hidden}body{font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;font-weight:400;color:#404040;min-height:100%;background:#edf0f2}.wy-text-left{text-align:left}.wy-text-center{text-align:center}.wy-text-right{text-align:right}.wy-text-large{font-size:120%}.wy-text-normal{font-size:100%}.wy-text-small,small{font-size:80%}.wy-text-strike{text-decoration:line-through}.wy-text-warning{color:#e67e22!important}a.wy-text-warning:hover{color:#eb9950!important}.wy-text-info{color:#2980b9!important}a.wy-text-info:hover{color:#409ad5!important}.wy-text-success{color:#27ae60!important}a.wy-text-success:hover{color:#36d278!important}.wy-text-danger{color:#e74c3c!important}a.wy-text-danger:hover{color:#ed7669!important}.wy-text-neutral{color:#404040!important}a.wy-text-neutral:hover{color:#595959!important}.rst-content .toctree-wrapper>p.caption,h1,h2,h3,h4,h5,h6,legend{margin-top:0;font-weight:700;font-family:Roboto Slab,ff-tisa-web-pro,Georgia,Arial,sans-serif}p{line-height:24px;font-size:16px;margin:0 0 24px}h1{font-size:175%}.rst-content .toctree-wrapper>p.caption,h2{font-size:150%}h3{font-size:125%}h4{font-size:115%}h5{font-size:110%}h6{font-size:100%}hr{display:block;height:1px;border:0;border-top:1px solid #e1e4e5;margin:24px 0;padding:0}.rst-content code,.rst-content tt,code{white-space:nowrap;max-width:100%;background:#fff;border:1px solid #e1e4e5;font-size:75%;padding:0 5px;font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;color:#e74c3c;overflow-x:auto}.rst-content tt.code-large,code.code-large{font-size:90%}.rst-content .section ul,.rst-content .toctree-wrapper ul,.rst-content section ul,.wy-plain-list-disc,article ul{list-style:disc;line-height:24px;margin-bottom:24px}.rst-content .section ul li,.rst-content .toctree-wrapper ul li,.rst-content section ul li,.wy-plain-list-disc li,article ul li{list-style:disc;margin-left:24px}.rst-content .section ul li p:last-child,.rst-content .section ul li ul,.rst-content .toctree-wrapper ul li p:last-child,.rst-content .toctree-wrapper ul li ul,.rst-content section ul li p:last-child,.rst-content section ul li ul,.wy-plain-list-disc li p:last-child,.wy-plain-list-disc li ul,article ul li p:last-child,article ul li ul{margin-bottom:0}.rst-content .section ul li li,.rst-content .toctree-wrapper ul li li,.rst-content section ul li li,.wy-plain-list-disc li li,article ul li li{list-style:circle}.rst-content .section ul li li li,.rst-content .toctree-wrapper ul li li li,.rst-content section ul li li li,.wy-plain-list-disc li li li,article ul li li li{list-style:square}.rst-content .section ul li ol li,.rst-content .toctree-wrapper ul li ol li,.rst-content section ul li ol li,.wy-plain-list-disc li ol li,article ul li ol li{list-style:decimal}.rst-content .section ol,.rst-content .section ol.arabic,.rst-content .toctree-wrapper ol,.rst-content .toctree-wrapper ol.arabic,.rst-content section ol,.rst-content section ol.arabic,.wy-plain-list-decimal,article ol{list-style:decimal;line-height:24px;margin-bottom:24px}.rst-content .section ol.arabic li,.rst-content .section ol li,.rst-content .toctree-wrapper ol.arabic li,.rst-content .toctree-wrapper ol li,.rst-content section ol.arabic li,.rst-content section ol li,.wy-plain-list-decimal li,article ol li{list-style:decimal;margin-left:24px}.rst-content .section ol.arabic li ul,.rst-content .section ol li p:last-child,.rst-content .section ol li ul,.rst-content .toctree-wrapper ol.arabic li ul,.rst-content .toctree-wrapper ol li p:last-child,.rst-content .toctree-wrapper ol li ul,.rst-content section ol.arabic li ul,.rst-content section ol li p:last-child,.rst-content section ol li ul,.wy-plain-list-decimal li p:last-child,.wy-plain-list-decimal li ul,article ol li p:last-child,article ol li ul{margin-bottom:0}.rst-content .section ol.arabic li ul li,.rst-content .section ol li ul li,.rst-content .toctree-wrapper ol.arabic li ul li,.rst-content .toctree-wrapper ol li ul li,.rst-content section ol.arabic li ul li,.rst-content section ol li ul li,.wy-plain-list-decimal li ul li,article ol li ul li{list-style:disc}.wy-breadcrumbs{*zoom:1}.wy-breadcrumbs:after,.wy-breadcrumbs:before{display:table;content:""}.wy-breadcrumbs:after{clear:both}.wy-breadcrumbs>li{display:inline-block;padding-top:5px}.wy-breadcrumbs>li.wy-breadcrumbs-aside{float:right}.rst-content .wy-breadcrumbs>li code,.rst-content .wy-breadcrumbs>li tt,.wy-breadcrumbs>li .rst-content tt,.wy-breadcrumbs>li code{all:inherit;color:inherit}.breadcrumb-item:before{content:"/";color:#bbb;font-size:13px;padding:0 6px 0 3px}.wy-breadcrumbs-extra{margin-bottom:0;color:#b3b3b3;font-size:80%;display:inline-block}@media screen and (max-width:480px){.wy-breadcrumbs-extra,.wy-breadcrumbs li.wy-breadcrumbs-aside{display:none}}@media print{.wy-breadcrumbs li.wy-breadcrumbs-aside{display:none}}html{font-size:16px}.wy-affix{position:fixed;top:1.618em}.wy-menu a:hover{text-decoration:none}.wy-menu-horiz{*zoom:1}.wy-menu-horiz:after,.wy-menu-horiz:before{display:table;content:""}.wy-menu-horiz:after{clear:both}.wy-menu-horiz li,.wy-menu-horiz ul{display:inline-block}.wy-menu-horiz li:hover{background:hsla(0,0%,100%,.1)}.wy-menu-horiz li.divide-left{border-left:1px solid #404040}.wy-menu-horiz li.divide-right{border-right:1px solid #404040}.wy-menu-horiz a{height:32px;display:inline-block;line-height:32px;padding:0 16px}.wy-menu-vertical{width:300px}.wy-menu-vertical header,.wy-menu-vertical p.caption{color:#55a5d9;height:32px;line-height:32px;padding:0 1.618em;margin:12px 0 0;display:block;font-weight:700;text-transform:uppercase;font-size:85%;white-space:nowrap}.wy-menu-vertical ul{margin-bottom:0}.wy-menu-vertical li.divide-top{border-top:1px solid #404040}.wy-menu-vertical li.divide-bottom{border-bottom:1px solid #404040}.wy-menu-vertical li.current{background:#e3e3e3}.wy-menu-vertical li.current a{color:grey;border-right:1px solid #c9c9c9;padding:.4045em 2.427em}.wy-menu-vertical li.current a:hover{background:#d6d6d6}.rst-content .wy-menu-vertical li tt,.wy-menu-vertical li .rst-content tt,.wy-menu-vertical li code{border:none;background:inherit;color:inherit;padding-left:0;padding-right:0}.wy-menu-vertical li button.toctree-expand{display:block;float:left;margin-left:-1.2em;line-height:18px;color:#4d4d4d;border:none;background:none;padding:0}.wy-menu-vertical li.current>a,.wy-menu-vertical li.on a{color:#404040;font-weight:700;position:relative;background:#fcfcfc;border:none;padding:.4045em 1.618em}.wy-menu-vertical li.current>a:hover,.wy-menu-vertical li.on a:hover{background:#fcfcfc}.wy-menu-vertical li.current>a:hover button.toctree-expand,.wy-menu-vertical li.on a:hover button.toctree-expand{color:grey}.wy-menu-vertical li.current>a button.toctree-expand,.wy-menu-vertical li.on a button.toctree-expand{display:block;line-height:18px;color:#333}.wy-menu-vertical li.toctree-l1.current>a{border-bottom:1px solid #c9c9c9;border-top:1px solid #c9c9c9}.wy-menu-vertical .toctree-l1.current .toctree-l2>ul,.wy-menu-vertical .toctree-l2.current .toctree-l3>ul,.wy-menu-vertical .toctree-l3.current .toctree-l4>ul,.wy-menu-vertical .toctree-l4.current .toctree-l5>ul,.wy-menu-vertical .toctree-l5.current .toctree-l6>ul,.wy-menu-vertical .toctree-l6.current .toctree-l7>ul,.wy-menu-vertical .toctree-l7.current .toctree-l8>ul,.wy-menu-vertical .toctree-l8.current .toctree-l9>ul,.wy-menu-vertical .toctree-l9.current .toctree-l10>ul,.wy-menu-vertical .toctree-l10.current .toctree-l11>ul{display:none}.wy-menu-vertical .toctree-l1.current .current.toctree-l2>ul,.wy-menu-vertical .toctree-l2.current .current.toctree-l3>ul,.wy-menu-vertical .toctree-l3.current .current.toctree-l4>ul,.wy-menu-vertical .toctree-l4.current .current.toctree-l5>ul,.wy-menu-vertical .toctree-l5.current .current.toctree-l6>ul,.wy-menu-vertical .toctree-l6.current .current.toctree-l7>ul,.wy-menu-vertical .toctree-l7.current .current.toctree-l8>ul,.wy-menu-vertical .toctree-l8.current .current.toctree-l9>ul,.wy-menu-vertical .toctree-l9.current .current.toctree-l10>ul,.wy-menu-vertical .toctree-l10.current .current.toctree-l11>ul{display:block}.wy-menu-vertical li.toctree-l3,.wy-menu-vertical li.toctree-l4{font-size:.9em}.wy-menu-vertical li.toctree-l2 a,.wy-menu-vertical li.toctree-l3 a,.wy-menu-vertical li.toctree-l4 a,.wy-menu-vertical li.toctree-l5 a,.wy-menu-vertical li.toctree-l6 a,.wy-menu-vertical li.toctree-l7 a,.wy-menu-vertical li.toctree-l8 a,.wy-menu-vertical li.toctree-l9 a,.wy-menu-vertical li.toctree-l10 a{color:#404040}.wy-menu-vertical li.toctree-l2 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l3 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l4 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l5 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l6 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l7 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l8 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l9 a:hover button.toctree-expand,.wy-menu-vertical li.toctree-l10 a:hover button.toctree-expand{color:grey}.wy-menu-vertical li.toctree-l2.current li.toctree-l3>a,.wy-menu-vertical li.toctree-l3.current li.toctree-l4>a,.wy-menu-vertical li.toctree-l4.current li.toctree-l5>a,.wy-menu-vertical li.toctree-l5.current li.toctree-l6>a,.wy-menu-vertical li.toctree-l6.current li.toctree-l7>a,.wy-menu-vertical li.toctree-l7.current li.toctree-l8>a,.wy-menu-vertical li.toctree-l8.current li.toctree-l9>a,.wy-menu-vertical li.toctree-l9.current li.toctree-l10>a,.wy-menu-vertical li.toctree-l10.current li.toctree-l11>a{display:block}.wy-menu-vertical li.toctree-l2.current>a{padding:.4045em 2.427em}.wy-menu-vertical li.toctree-l2.current li.toctree-l3>a{padding:.4045em 1.618em .4045em 4.045em}.wy-menu-vertical li.toctree-l3.current>a{padding:.4045em 4.045em}.wy-menu-vertical li.toctree-l3.current li.toctree-l4>a{padding:.4045em 1.618em .4045em 5.663em}.wy-menu-vertical li.toctree-l4.current>a{padding:.4045em 5.663em}.wy-menu-vertical li.toctree-l4.current li.toctree-l5>a{padding:.4045em 1.618em .4045em 7.281em}.wy-menu-vertical li.toctree-l5.current>a{padding:.4045em 7.281em}.wy-menu-vertical li.toctree-l5.current li.toctree-l6>a{padding:.4045em 1.618em .4045em 8.899em}.wy-menu-vertical li.toctree-l6.current>a{padding:.4045em 8.899em}.wy-menu-vertical li.toctree-l6.current li.toctree-l7>a{padding:.4045em 1.618em .4045em 10.517em}.wy-menu-vertical li.toctree-l7.current>a{padding:.4045em 10.517em}.wy-menu-vertical li.toctree-l7.current li.toctree-l8>a{padding:.4045em 1.618em .4045em 12.135em}.wy-menu-vertical li.toctree-l8.current>a{padding:.4045em 12.135em}.wy-menu-vertical li.toctree-l8.current li.toctree-l9>a{padding:.4045em 1.618em .4045em 13.753em}.wy-menu-vertical li.toctree-l9.current>a{padding:.4045em 13.753em}.wy-menu-vertical li.toctree-l9.current li.toctree-l10>a{padding:.4045em 1.618em .4045em 15.371em}.wy-menu-vertical li.toctree-l10.current>a{padding:.4045em 15.371em}.wy-menu-vertical li.toctree-l10.current li.toctree-l11>a{padding:.4045em 1.618em .4045em 16.989em}.wy-menu-vertical li.toctree-l2.current>a,.wy-menu-vertical li.toctree-l2.current li.toctree-l3>a{background:#c9c9c9}.wy-menu-vertical li.toctree-l2 button.toctree-expand{color:#a3a3a3}.wy-menu-vertical li.toctree-l3.current>a,.wy-menu-vertical li.toctree-l3.current li.toctree-l4>a{background:#bdbdbd}.wy-menu-vertical li.toctree-l3 button.toctree-expand{color:#969696}.wy-menu-vertical li.current ul{display:block}.wy-menu-vertical li ul{margin-bottom:0;display:none}.wy-menu-vertical li ul li a{margin-bottom:0;color:#d9d9d9;font-weight:400}.wy-menu-vertical a{line-height:18px;padding:.4045em 1.618em;display:block;position:relative;font-size:90%;color:#d9d9d9}.wy-menu-vertical a:hover{background-color:#4e4a4a;cursor:pointer}.wy-menu-vertical a:hover button.toctree-expand{color:#d9d9d9}.wy-menu-vertical a:active{background-color:#2980b9;cursor:pointer;color:#fff}.wy-menu-vertical a:active button.toctree-expand{color:#fff}.wy-side-nav-search{display:block;width:300px;padding:.809em;margin-bottom:.809em;z-index:200;background-color:#2980b9;text-align:center;color:#fcfcfc}.wy-side-nav-search input[type=text]{width:100%;border-radius:50px;padding:6px 12px;border-color:#2472a4}.wy-side-nav-search img{display:block;margin:auto auto .809em;height:45px;width:45px;background-color:#2980b9;padding:5px;border-radius:100%}.wy-side-nav-search .wy-dropdown>a,.wy-side-nav-search>a{color:#fcfcfc;font-size:100%;font-weight:700;display:inline-block;padding:4px 6px;margin-bottom:.809em;max-width:100%}.wy-side-nav-search .wy-dropdown>a:hover,.wy-side-nav-search .wy-dropdown>aactive,.wy-side-nav-search .wy-dropdown>afocus,.wy-side-nav-search>a:hover,.wy-side-nav-search>aactive,.wy-side-nav-search>afocus{background:hsla(0,0%,100%,.1)}.wy-side-nav-search .wy-dropdown>a img.logo,.wy-side-nav-search>a img.logo{display:block;margin:0 auto;height:auto;width:auto;border-radius:0;max-width:100%;background:transparent}.wy-side-nav-search .wy-dropdown>a.icon,.wy-side-nav-search>a.icon{display:block}.wy-side-nav-search .wy-dropdown>a.icon img.logo,.wy-side-nav-search>a.icon img.logo{margin-top:.85em}.wy-side-nav-search>div.switch-menus{position:relative;display:block;margin-top:-.4045em;margin-bottom:.809em;font-weight:400;color:hsla(0,0%,100%,.3)}.wy-side-nav-search>div.switch-menus>div.language-switch,.wy-side-nav-search>div.switch-menus>div.version-switch{display:inline-block;padding:.2em}.wy-side-nav-search>div.switch-menus>div.language-switch select,.wy-side-nav-search>div.switch-menus>div.version-switch select{display:inline-block;margin-right:-2rem;padding-right:2rem;max-width:240px;text-align-last:center;background:none;border:none;border-radius:0;box-shadow:none;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;font-size:1em;font-weight:400;color:hsla(0,0%,100%,.3);cursor:pointer;appearance:none;-webkit-appearance:none;-moz-appearance:none}.wy-side-nav-search>div.switch-menus>div.language-switch select:active,.wy-side-nav-search>div.switch-menus>div.language-switch select:focus,.wy-side-nav-search>div.switch-menus>div.language-switch select:hover,.wy-side-nav-search>div.switch-menus>div.version-switch select:active,.wy-side-nav-search>div.switch-menus>div.version-switch select:focus,.wy-side-nav-search>div.switch-menus>div.version-switch select:hover{background:hsla(0,0%,100%,.1);color:hsla(0,0%,100%,.5)}.wy-side-nav-search>div.switch-menus>div.language-switch select option,.wy-side-nav-search>div.switch-menus>div.version-switch select option{color:#000}.wy-side-nav-search>div.switch-menus>div.language-switch:has(>select):after,.wy-side-nav-search>div.switch-menus>div.version-switch:has(>select):after{display:inline-block;width:1.5em;height:100%;padding:.1em;content:"\f0d7";font-size:1em;line-height:1.2em;font-family:FontAwesome;text-align:center;pointer-events:none;box-sizing:border-box}.wy-nav .wy-menu-vertical header{color:#2980b9}.wy-nav .wy-menu-vertical a{color:#b3b3b3}.wy-nav .wy-menu-vertical a:hover{background-color:#2980b9;color:#fff}[data-menu-wrap]{-webkit-transition:all .2s ease-in;-moz-transition:all .2s ease-in;transition:all .2s ease-in;position:absolute;opacity:1;width:100%;opacity:0}[data-menu-wrap].move-center{left:0;right:auto;opacity:1}[data-menu-wrap].move-left{right:auto;left:-100%;opacity:0}[data-menu-wrap].move-right{right:-100%;left:auto;opacity:0}.wy-body-for-nav{background:#fcfcfc}.wy-grid-for-nav{position:absolute;width:100%;height:100%}.wy-nav-side{position:fixed;top:0;bottom:0;left:0;padding-bottom:2em;width:300px;overflow-x:hidden;overflow-y:hidden;min-height:100%;color:#9b9b9b;background:#343131;z-index:200}.wy-side-scroll{width:320px;position:relative;overflow-x:hidden;overflow-y:scroll;height:100%}.wy-nav-top{display:none;background:#2980b9;color:#fff;padding:.4045em .809em;position:relative;line-height:50px;text-align:center;font-size:100%;*zoom:1}.wy-nav-top:after,.wy-nav-top:before{display:table;content:""}.wy-nav-top:after{clear:both}.wy-nav-top a{color:#fff;font-weight:700}.wy-nav-top img{margin-right:12px;height:45px;width:45px;background-color:#2980b9;padding:5px;border-radius:100%}.wy-nav-top i{font-size:30px;float:left;cursor:pointer;padding-top:inherit}.wy-nav-content-wrap{margin-left:300px;background:#fcfcfc;min-height:100%}.wy-nav-content{padding:1.618em 3.236em;height:100%;max-width:800px;margin:auto}.wy-body-mask{position:fixed;width:100%;height:100%;background:rgba(0,0,0,.2);display:none;z-index:499}.wy-body-mask.on{display:block}footer{color:grey}footer p{margin-bottom:12px}.rst-content footer span.commit tt,footer span.commit .rst-content tt,footer span.commit code{padding:0;font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;font-size:1em;background:none;border:none;color:grey}.rst-footer-buttons{*zoom:1}.rst-footer-buttons:after,.rst-footer-buttons:before{width:100%;display:table;content:""}.rst-footer-buttons:after{clear:both}.rst-breadcrumbs-buttons{margin-top:12px;*zoom:1}.rst-breadcrumbs-buttons:after,.rst-breadcrumbs-buttons:before{display:table;content:""}.rst-breadcrumbs-buttons:after{clear:both}#search-results .search li{margin-bottom:24px;border-bottom:1px solid #e1e4e5;padding-bottom:24px}#search-results .search li:first-child{border-top:1px solid #e1e4e5;padding-top:24px}#search-results .search li a{font-size:120%;margin-bottom:12px;display:inline-block}#search-results .context{color:grey;font-size:90%}.genindextable li>ul{margin-left:24px}@media screen and (max-width:768px){.wy-body-for-nav{background:#fcfcfc}.wy-nav-top{display:block}.wy-nav-side{left:-300px}.wy-nav-side.shift{width:85%;left:0}.wy-menu.wy-menu-vertical,.wy-side-nav-search,.wy-side-scroll{width:auto}.wy-nav-content-wrap{margin-left:0}.wy-nav-content-wrap .wy-nav-content{padding:1.618em}.wy-nav-content-wrap.shift{position:fixed;min-width:100%;left:85%;top:0;height:100%;overflow:hidden}}@media screen and (min-width:1100px){.wy-nav-content-wrap{background:rgba(0,0,0,.05)}.wy-nav-content{margin:0;background:#fcfcfc}}@media print{.rst-versions,.wy-nav-side,footer{display:none}.wy-nav-content-wrap{margin-left:0}}.rst-versions{position:fixed;bottom:0;left:0;width:300px;color:#fcfcfc;background:#1f1d1d;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;z-index:400}.rst-versions a{color:#2980b9;text-decoration:none}.rst-versions .rst-badge-small{display:none}.rst-versions .rst-current-version{padding:12px;background-color:#272525;display:block;text-align:right;font-size:90%;cursor:pointer;color:#27ae60;*zoom:1}.rst-versions .rst-current-version:after,.rst-versions .rst-current-version:before{display:table;content:""}.rst-versions .rst-current-version:after{clear:both}.rst-content .code-block-caption .rst-versions .rst-current-version .headerlink,.rst-content .eqno .rst-versions .rst-current-version .headerlink,.rst-content .rst-versions .rst-current-version .admonition-title,.rst-content code.download .rst-versions .rst-current-version span:first-child,.rst-content dl dt .rst-versions .rst-current-version .headerlink,.rst-content h1 .rst-versions .rst-current-version .headerlink,.rst-content h2 .rst-versions .rst-current-version .headerlink,.rst-content h3 .rst-versions .rst-current-version .headerlink,.rst-content h4 .rst-versions .rst-current-version .headerlink,.rst-content h5 .rst-versions .rst-current-version .headerlink,.rst-content h6 .rst-versions .rst-current-version .headerlink,.rst-content p .rst-versions .rst-current-version .headerlink,.rst-content table>caption .rst-versions .rst-current-version .headerlink,.rst-content tt.download .rst-versions .rst-current-version span:first-child,.rst-versions .rst-current-version .fa,.rst-versions .rst-current-version .icon,.rst-versions .rst-current-version .rst-content .admonition-title,.rst-versions .rst-current-version .rst-content .code-block-caption .headerlink,.rst-versions .rst-current-version .rst-content .eqno .headerlink,.rst-versions .rst-current-version .rst-content code.download span:first-child,.rst-versions .rst-current-version .rst-content dl dt .headerlink,.rst-versions .rst-current-version .rst-content h1 .headerlink,.rst-versions .rst-current-version .rst-content h2 .headerlink,.rst-versions .rst-current-version .rst-content h3 .headerlink,.rst-versions .rst-current-version .rst-content h4 .headerlink,.rst-versions .rst-current-version .rst-content h5 .headerlink,.rst-versions .rst-current-version .rst-content h6 .headerlink,.rst-versions .rst-current-version .rst-content p .headerlink,.rst-versions .rst-current-version .rst-content table>caption .headerlink,.rst-versions .rst-current-version .rst-content tt.download span:first-child,.rst-versions .rst-current-version .wy-menu-vertical li button.toctree-expand,.wy-menu-vertical li .rst-versions .rst-current-version button.toctree-expand{color:#fcfcfc}.rst-versions .rst-current-version .fa-book,.rst-versions .rst-current-version .icon-book{float:left}.rst-versions .rst-current-version.rst-out-of-date{background-color:#e74c3c;color:#fff}.rst-versions .rst-current-version.rst-active-old-version{background-color:#f1c40f;color:#000}.rst-versions.shift-up{height:auto;max-height:100%;overflow-y:scroll}.rst-versions.shift-up .rst-other-versions{display:block}.rst-versions .rst-other-versions{font-size:90%;padding:12px;color:grey;display:none}.rst-versions .rst-other-versions hr{display:block;height:1px;border:0;margin:20px 0;padding:0;border-top:1px solid #413d3d}.rst-versions .rst-other-versions dd{display:inline-block;margin:0}.rst-versions .rst-other-versions dd a{display:inline-block;padding:6px;color:#fcfcfc}.rst-versions .rst-other-versions .rtd-current-item{font-weight:700}.rst-versions.rst-badge{width:auto;bottom:20px;right:20px;left:auto;border:none;max-width:300px;max-height:90%}.rst-versions.rst-badge .fa-book,.rst-versions.rst-badge .icon-book{float:none;line-height:30px}.rst-versions.rst-badge.shift-up .rst-current-version{text-align:right}.rst-versions.rst-badge.shift-up .rst-current-version .fa-book,.rst-versions.rst-badge.shift-up .rst-current-version .icon-book{float:left}.rst-versions.rst-badge>.rst-current-version{width:auto;height:30px;line-height:30px;padding:0 6px;display:block;text-align:center}@media screen and (max-width:768px){.rst-versions{width:85%;display:none}.rst-versions.shift{display:block}}#flyout-search-form{padding:6px}.rst-content .toctree-wrapper>p.caption,.rst-content h1,.rst-content h2,.rst-content h3,.rst-content h4,.rst-content h5,.rst-content h6{margin-bottom:24px}.rst-content img{max-width:100%;height:auto}.rst-content div.figure,.rst-content figure{margin-bottom:24px}.rst-content div.figure .caption-text,.rst-content figure .caption-text{font-style:italic}.rst-content div.figure p:last-child.caption,.rst-content figure p:last-child.caption{margin-bottom:0}.rst-content div.figure.align-center,.rst-content figure.align-center{text-align:center}.rst-content .section>a>img,.rst-content .section>img,.rst-content section>a>img,.rst-content section>img{margin-bottom:24px}.rst-content abbr[title]{text-decoration:none}.rst-content.style-external-links a.reference.external:after{font-family:FontAwesome;content:"\f08e";color:#b3b3b3;vertical-align:super;font-size:60%;margin:0 .2em}.rst-content blockquote{margin-left:24px;line-height:24px;margin-bottom:24px}.rst-content pre.literal-block{white-space:pre;margin:0;padding:12px;font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;display:block;overflow:auto}.rst-content div[class^=highlight],.rst-content pre.literal-block{border:1px solid #e1e4e5;overflow-x:auto;margin:1px 0 24px}.rst-content div[class^=highlight] div[class^=highlight],.rst-content pre.literal-block div[class^=highlight]{padding:0;border:none;margin:0}.rst-content div[class^=highlight] td.code{width:100%}.rst-content .linenodiv pre{border-right:1px solid #e6e9ea;margin:0;padding:12px;font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;user-select:none;pointer-events:none}.rst-content div[class^=highlight] pre{white-space:pre;margin:0;padding:12px;display:block;overflow:auto}.rst-content div[class^=highlight] pre .hll{display:block;margin:0 -12px;padding:0 12px}.rst-content .linenodiv pre,.rst-content div[class^=highlight] pre,.rst-content pre.literal-block{font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;font-size:12px;line-height:1.4}.rst-content div.highlight .gp,.rst-content div.highlight span.linenos{user-select:none;pointer-events:none}.rst-content div.highlight span.linenos{display:inline-block;padding-left:0;padding-right:12px;margin-right:12px;border-right:1px solid #e6e9ea}.rst-content .code-block-caption{font-style:italic;font-size:85%;line-height:1;padding:1em 0;text-align:center}@media print{.rst-content .codeblock,.rst-content div[class^=highlight],.rst-content div[class^=highlight] pre{white-space:pre-wrap}}.rst-content .admonition,.rst-content .admonition-todo,.rst-content .attention,.rst-content .caution,.rst-content .danger,.rst-content .error,.rst-content .hint,.rst-content .important,.rst-content .note,.rst-content .seealso,.rst-content .tip,.rst-content .warning{clear:both}.rst-content .admonition-todo .last,.rst-content .admonition-todo>:last-child,.rst-content .admonition .last,.rst-content .admonition>:last-child,.rst-content .attention .last,.rst-content .attention>:last-child,.rst-content .caution .last,.rst-content .caution>:last-child,.rst-content .danger .last,.rst-content .danger>:last-child,.rst-content .error .last,.rst-content .error>:last-child,.rst-content .hint .last,.rst-content .hint>:last-child,.rst-content .important .last,.rst-content .important>:last-child,.rst-content .note .last,.rst-content .note>:last-child,.rst-content .seealso .last,.rst-content .seealso>:last-child,.rst-content .tip .last,.rst-content .tip>:last-child,.rst-content .warning .last,.rst-content .warning>:last-child{margin-bottom:0}.rst-content .admonition-title:before{margin-right:4px}.rst-content .admonition table{border-color:rgba(0,0,0,.1)}.rst-content .admonition table td,.rst-content .admonition table th{background:transparent!important;border-color:rgba(0,0,0,.1)!important}.rst-content .section ol.loweralpha,.rst-content .section ol.loweralpha>li,.rst-content .toctree-wrapper ol.loweralpha,.rst-content .toctree-wrapper ol.loweralpha>li,.rst-content section ol.loweralpha,.rst-content section ol.loweralpha>li{list-style:lower-alpha}.rst-content .section ol.upperalpha,.rst-content .section ol.upperalpha>li,.rst-content .toctree-wrapper ol.upperalpha,.rst-content .toctree-wrapper ol.upperalpha>li,.rst-content section ol.upperalpha,.rst-content section ol.upperalpha>li{list-style:upper-alpha}.rst-content .section ol li>*,.rst-content .section ul li>*,.rst-content .toctree-wrapper ol li>*,.rst-content .toctree-wrapper ul li>*,.rst-content section ol li>*,.rst-content section ul li>*{margin-top:12px;margin-bottom:12px}.rst-content .section ol li>:first-child,.rst-content .section ul li>:first-child,.rst-content .toctree-wrapper ol li>:first-child,.rst-content .toctree-wrapper ul li>:first-child,.rst-content section ol li>:first-child,.rst-content section ul li>:first-child{margin-top:0}.rst-content .section ol li>p,.rst-content .section ol li>p:last-child,.rst-content .section ul li>p,.rst-content .section ul li>p:last-child,.rst-content .toctree-wrapper ol li>p,.rst-content .toctree-wrapper ol li>p:last-child,.rst-content .toctree-wrapper ul li>p,.rst-content .toctree-wrapper ul li>p:last-child,.rst-content section ol li>p,.rst-content section ol li>p:last-child,.rst-content section ul li>p,.rst-content section ul li>p:last-child{margin-bottom:12px}.rst-content .section ol li>p:only-child,.rst-content .section ol li>p:only-child:last-child,.rst-content .section ul li>p:only-child,.rst-content .section ul li>p:only-child:last-child,.rst-content .toctree-wrapper ol li>p:only-child,.rst-content .toctree-wrapper ol li>p:only-child:last-child,.rst-content .toctree-wrapper ul li>p:only-child,.rst-content .toctree-wrapper ul li>p:only-child:last-child,.rst-content section ol li>p:only-child,.rst-content section ol li>p:only-child:last-child,.rst-content section ul li>p:only-child,.rst-content section ul li>p:only-child:last-child{margin-bottom:0}.rst-content .section ol li>ol,.rst-content .section ol li>ul,.rst-content .section ul li>ol,.rst-content .section ul li>ul,.rst-content .toctree-wrapper ol li>ol,.rst-content .toctree-wrapper ol li>ul,.rst-content .toctree-wrapper ul li>ol,.rst-content .toctree-wrapper ul li>ul,.rst-content section ol li>ol,.rst-content section ol li>ul,.rst-content section ul li>ol,.rst-content section ul li>ul{margin-bottom:12px}.rst-content .section ol.simple li>*,.rst-content .section ol.simple li ol,.rst-content .section ol.simple li ul,.rst-content .section ul.simple li>*,.rst-content .section ul.simple li ol,.rst-content .section ul.simple li ul,.rst-content .toctree-wrapper ol.simple li>*,.rst-content .toctree-wrapper ol.simple li ol,.rst-content .toctree-wrapper ol.simple li ul,.rst-content .toctree-wrapper ul.simple li>*,.rst-content .toctree-wrapper ul.simple li ol,.rst-content .toctree-wrapper ul.simple li ul,.rst-content section ol.simple li>*,.rst-content section ol.simple li ol,.rst-content section ol.simple li ul,.rst-content section ul.simple li>*,.rst-content section ul.simple li ol,.rst-content section ul.simple li ul{margin-top:0;margin-bottom:0}.rst-content .line-block{margin-left:0;margin-bottom:24px;line-height:24px}.rst-content .line-block .line-block{margin-left:24px;margin-bottom:0}.rst-content .topic-title{font-weight:700;margin-bottom:12px}.rst-content .toc-backref{color:#404040}.rst-content .align-right{float:right;margin:0 0 24px 24px}.rst-content .align-left{float:left;margin:0 24px 24px 0}.rst-content .align-center{margin:auto}.rst-content .align-center:not(table){display:block}.rst-content .code-block-caption .headerlink,.rst-content .eqno .headerlink,.rst-content .toctree-wrapper>p.caption .headerlink,.rst-content dl dt .headerlink,.rst-content h1 .headerlink,.rst-content h2 .headerlink,.rst-content h3 .headerlink,.rst-content h4 .headerlink,.rst-content h5 .headerlink,.rst-content h6 .headerlink,.rst-content p.caption .headerlink,.rst-content p .headerlink,.rst-content table>caption .headerlink{opacity:0;font-size:14px;font-family:FontAwesome;margin-left:.5em}.rst-content .code-block-caption .headerlink:focus,.rst-content .code-block-caption:hover .headerlink,.rst-content .eqno .headerlink:focus,.rst-content .eqno:hover .headerlink,.rst-content .toctree-wrapper>p.caption .headerlink:focus,.rst-content .toctree-wrapper>p.caption:hover .headerlink,.rst-content dl dt .headerlink:focus,.rst-content dl dt:hover .headerlink,.rst-content h1 .headerlink:focus,.rst-content h1:hover .headerlink,.rst-content h2 .headerlink:focus,.rst-content h2:hover .headerlink,.rst-content h3 .headerlink:focus,.rst-content h3:hover .headerlink,.rst-content h4 .headerlink:focus,.rst-content h4:hover .headerlink,.rst-content h5 .headerlink:focus,.rst-content h5:hover .headerlink,.rst-content h6 .headerlink:focus,.rst-content h6:hover .headerlink,.rst-content p.caption .headerlink:focus,.rst-content p.caption:hover .headerlink,.rst-content p .headerlink:focus,.rst-content p:hover .headerlink,.rst-content table>caption .headerlink:focus,.rst-content table>caption:hover .headerlink{opacity:1}.rst-content p a{overflow-wrap:anywhere}.rst-content .wy-table td p,.rst-content .wy-table td ul,.rst-content .wy-table th p,.rst-content .wy-table th ul,.rst-content table.docutils td p,.rst-content table.docutils td ul,.rst-content table.docutils th p,.rst-content table.docutils th ul,.rst-content table.field-list td p,.rst-content table.field-list td ul,.rst-content table.field-list th p,.rst-content table.field-list th ul{font-size:inherit}.rst-content .btn:focus{outline:2px solid}.rst-content table>caption .headerlink:after{font-size:12px}.rst-content .centered{text-align:center}.rst-content .sidebar{float:right;width:40%;display:block;margin:0 0 24px 24px;padding:24px;background:#f3f6f6;border:1px solid #e1e4e5}.rst-content .sidebar dl,.rst-content .sidebar p,.rst-content .sidebar ul{font-size:90%}.rst-content .sidebar .last,.rst-content .sidebar>:last-child{margin-bottom:0}.rst-content .sidebar .sidebar-title{display:block;font-family:Roboto Slab,ff-tisa-web-pro,Georgia,Arial,sans-serif;font-weight:700;background:#e1e4e5;padding:6px 12px;margin:-24px -24px 24px;font-size:100%}.rst-content .highlighted{background:#f1c40f;box-shadow:0 0 0 2px #f1c40f;display:inline;font-weight:700}.rst-content .citation-reference,.rst-content .footnote-reference{vertical-align:baseline;position:relative;top:-.4em;line-height:0;font-size:90%}.rst-content .citation-reference>span.fn-bracket,.rst-content .footnote-reference>span.fn-bracket{display:none}.rst-content .hlist{width:100%}.rst-content dl dt span.classifier:before{content:" : "}.rst-content dl dt span.classifier-delimiter{display:none!important}html.writer-html4 .rst-content table.docutils.citation,html.writer-html4 .rst-content table.docutils.footnote{background:none;border:none}html.writer-html4 .rst-content table.docutils.citation td,html.writer-html4 .rst-content table.docutils.citation tr,html.writer-html4 .rst-content table.docutils.footnote td,html.writer-html4 .rst-content table.docutils.footnote tr{border:none;background-color:transparent!important;white-space:normal}html.writer-html4 .rst-content table.docutils.citation td.label,html.writer-html4 .rst-content table.docutils.footnote td.label{padding-left:0;padding-right:0;vertical-align:top}html.writer-html5 .rst-content dl.citation,html.writer-html5 .rst-content dl.field-list,html.writer-html5 .rst-content dl.footnote{display:grid;grid-template-columns:auto minmax(80%,95%)}html.writer-html5 .rst-content dl.citation>dt,html.writer-html5 .rst-content dl.field-list>dt,html.writer-html5 .rst-content dl.footnote>dt{display:inline-grid;grid-template-columns:max-content auto}html.writer-html5 .rst-content aside.citation,html.writer-html5 .rst-content aside.footnote,html.writer-html5 .rst-content div.citation{display:grid;grid-template-columns:auto auto minmax(.65rem,auto) minmax(40%,95%)}html.writer-html5 .rst-content aside.citation>span.label,html.writer-html5 .rst-content aside.footnote>span.label,html.writer-html5 .rst-content div.citation>span.label{grid-column-start:1;grid-column-end:2}html.writer-html5 .rst-content aside.citation>span.backrefs,html.writer-html5 .rst-content aside.footnote>span.backrefs,html.writer-html5 .rst-content div.citation>span.backrefs{grid-column-start:2;grid-column-end:3;grid-row-start:1;grid-row-end:3}html.writer-html5 .rst-content aside.citation>p,html.writer-html5 .rst-content aside.footnote>p,html.writer-html5 .rst-content div.citation>p{grid-column-start:4;grid-column-end:5}html.writer-html5 .rst-content dl.citation,html.writer-html5 .rst-content dl.field-list,html.writer-html5 .rst-content dl.footnote{margin-bottom:24px}html.writer-html5 .rst-content dl.citation>dt,html.writer-html5 .rst-content dl.field-list>dt,html.writer-html5 .rst-content dl.footnote>dt{padding-left:1rem}html.writer-html5 .rst-content dl.citation>dd,html.writer-html5 .rst-content dl.citation>dt,html.writer-html5 .rst-content dl.field-list>dd,html.writer-html5 .rst-content dl.field-list>dt,html.writer-html5 .rst-content dl.footnote>dd,html.writer-html5 .rst-content dl.footnote>dt{margin-bottom:0}html.writer-html5 .rst-content dl.citation,html.writer-html5 .rst-content dl.footnote{font-size:.9rem}html.writer-html5 .rst-content dl.citation>dt,html.writer-html5 .rst-content dl.footnote>dt{margin:0 .5rem .5rem 0;line-height:1.2rem;word-break:break-all;font-weight:400}html.writer-html5 .rst-content dl.citation>dt>span.brackets:before,html.writer-html5 .rst-content dl.footnote>dt>span.brackets:before{content:"["}html.writer-html5 .rst-content dl.citation>dt>span.brackets:after,html.writer-html5 .rst-content dl.footnote>dt>span.brackets:after{content:"]"}html.writer-html5 .rst-content dl.citation>dt>span.fn-backref,html.writer-html5 .rst-content dl.footnote>dt>span.fn-backref{text-align:left;font-style:italic;margin-left:.65rem;word-break:break-word;word-spacing:-.1rem;max-width:5rem}html.writer-html5 .rst-content dl.citation>dt>span.fn-backref>a,html.writer-html5 .rst-content dl.footnote>dt>span.fn-backref>a{word-break:keep-all}html.writer-html5 .rst-content dl.citation>dt>span.fn-backref>a:not(:first-child):before,html.writer-html5 .rst-content dl.footnote>dt>span.fn-backref>a:not(:first-child):before{content:" "}html.writer-html5 .rst-content dl.citation>dd,html.writer-html5 .rst-content dl.footnote>dd{margin:0 0 .5rem;line-height:1.2rem}html.writer-html5 .rst-content dl.citation>dd p,html.writer-html5 .rst-content dl.footnote>dd p{font-size:.9rem}html.writer-html5 .rst-content aside.citation,html.writer-html5 .rst-content aside.footnote,html.writer-html5 .rst-content div.citation{padding-left:1rem;padding-right:1rem;font-size:.9rem;line-height:1.2rem}html.writer-html5 .rst-content aside.citation p,html.writer-html5 .rst-content aside.footnote p,html.writer-html5 .rst-content div.citation p{font-size:.9rem;line-height:1.2rem;margin-bottom:12px}html.writer-html5 .rst-content aside.citation span.backrefs,html.writer-html5 .rst-content aside.footnote span.backrefs,html.writer-html5 .rst-content div.citation span.backrefs{text-align:left;font-style:italic;margin-left:.65rem;word-break:break-word;word-spacing:-.1rem;max-width:5rem}html.writer-html5 .rst-content aside.citation span.backrefs>a,html.writer-html5 .rst-content aside.footnote span.backrefs>a,html.writer-html5 .rst-content div.citation span.backrefs>a{word-break:keep-all}html.writer-html5 .rst-content aside.citation span.backrefs>a:not(:first-child):before,html.writer-html5 .rst-content aside.footnote span.backrefs>a:not(:first-child):before,html.writer-html5 .rst-content div.citation span.backrefs>a:not(:first-child):before{content:" "}html.writer-html5 .rst-content aside.citation span.label,html.writer-html5 .rst-content aside.footnote span.label,html.writer-html5 .rst-content div.citation span.label{line-height:1.2rem}html.writer-html5 .rst-content aside.citation-list,html.writer-html5 .rst-content aside.footnote-list,html.writer-html5 .rst-content div.citation-list{margin-bottom:24px}html.writer-html5 .rst-content dl.option-list kbd{font-size:.9rem}.rst-content table.docutils.footnote,html.writer-html4 .rst-content table.docutils.citation,html.writer-html5 .rst-content aside.footnote,html.writer-html5 .rst-content aside.footnote-list aside.footnote,html.writer-html5 .rst-content div.citation-list>div.citation,html.writer-html5 .rst-content dl.citation,html.writer-html5 .rst-content dl.footnote{color:grey}.rst-content table.docutils.footnote code,.rst-content table.docutils.footnote tt,html.writer-html4 .rst-content table.docutils.citation code,html.writer-html4 .rst-content table.docutils.citation tt,html.writer-html5 .rst-content aside.footnote-list aside.footnote code,html.writer-html5 .rst-content aside.footnote-list aside.footnote tt,html.writer-html5 .rst-content aside.footnote code,html.writer-html5 .rst-content aside.footnote tt,html.writer-html5 .rst-content div.citation-list>div.citation code,html.writer-html5 .rst-content div.citation-list>div.citation tt,html.writer-html5 .rst-content dl.citation code,html.writer-html5 .rst-content dl.citation tt,html.writer-html5 .rst-content dl.footnote code,html.writer-html5 .rst-content dl.footnote tt{color:#555}.rst-content .wy-table-responsive.citation,.rst-content .wy-table-responsive.footnote{margin-bottom:0}.rst-content .wy-table-responsive.citation+:not(.citation),.rst-content .wy-table-responsive.footnote+:not(.footnote){margin-top:24px}.rst-content .wy-table-responsive.citation:last-child,.rst-content .wy-table-responsive.footnote:last-child{margin-bottom:24px}.rst-content table.docutils th{border-color:#e1e4e5}html.writer-html5 .rst-content table.docutils th{border:1px solid #e1e4e5}html.writer-html5 .rst-content table.docutils td>p,html.writer-html5 .rst-content table.docutils th>p{line-height:1rem;margin-bottom:0;font-size:.9rem}.rst-content table.docutils td .last,.rst-content table.docutils td .last>:last-child{margin-bottom:0}.rst-content table.field-list,.rst-content table.field-list td{border:none}.rst-content table.field-list td p{line-height:inherit}.rst-content table.field-list td>strong{display:inline-block}.rst-content table.field-list .field-name{padding-right:10px;text-align:left;white-space:nowrap}.rst-content table.field-list .field-body{text-align:left}.rst-content code,.rst-content tt{color:#000;font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;padding:2px 5px}.rst-content code big,.rst-content code em,.rst-content tt big,.rst-content tt em{font-size:100%!important;line-height:normal}.rst-content code.literal,.rst-content tt.literal{color:#e74c3c;white-space:normal}.rst-content code.xref,.rst-content tt.xref,a .rst-content code,a .rst-content tt{font-weight:700;color:#404040;overflow-wrap:normal}.rst-content kbd,.rst-content pre,.rst-content samp{font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace}.rst-content a code,.rst-content a tt{color:#2980b9}.rst-content dl{margin-bottom:24px}.rst-content dl dt{font-weight:700;margin-bottom:12px}.rst-content dl ol,.rst-content dl p,.rst-content dl table,.rst-content dl ul{margin-bottom:12px}.rst-content dl dd{margin:0 0 12px 24px;line-height:24px}.rst-content dl dd>ol:last-child,.rst-content dl dd>p:last-child,.rst-content dl dd>table:last-child,.rst-content dl dd>ul:last-child{margin-bottom:0}html.writer-html4 .rst-content dl:not(.docutils),html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple){margin-bottom:24px}html.writer-html4 .rst-content dl:not(.docutils)>dt,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt{display:table;margin:6px 0;font-size:90%;line-height:normal;background:#e7f2fa;color:#2980b9;border-top:3px solid #6ab0de;padding:6px;position:relative}html.writer-html4 .rst-content dl:not(.docutils)>dt:before,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt:before{color:#6ab0de}html.writer-html4 .rst-content dl:not(.docutils)>dt .headerlink,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt .headerlink{color:#404040;font-size:100%!important}html.writer-html4 .rst-content dl:not(.docutils) dl:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) dl:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt{margin-bottom:6px;border:none;border-left:3px solid #ccc;background:#f0f0f0;color:#555}html.writer-html4 .rst-content dl:not(.docutils) dl:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt .headerlink,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) dl:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt .headerlink{color:#404040;font-size:100%!important}html.writer-html4 .rst-content dl:not(.docutils)>dt:first-child,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple)>dt:first-child{margin-top:0}html.writer-html4 .rst-content dl:not(.docutils) code.descclassname,html.writer-html4 .rst-content dl:not(.docutils) code.descname,html.writer-html4 .rst-content dl:not(.docutils) tt.descclassname,html.writer-html4 .rst-content dl:not(.docutils) tt.descname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) code.descclassname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) code.descname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) tt.descclassname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) tt.descname{background-color:transparent;border:none;padding:0;font-size:100%!important}html.writer-html4 .rst-content dl:not(.docutils) code.descname,html.writer-html4 .rst-content dl:not(.docutils) tt.descname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) code.descname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) tt.descname{font-weight:700}html.writer-html4 .rst-content dl:not(.docutils) .optional,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .optional{display:inline-block;padding:0 4px;color:#000;font-weight:700}html.writer-html4 .rst-content dl:not(.docutils) .property,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .property{display:inline-block;padding-right:8px;max-width:100%}html.writer-html4 .rst-content dl:not(.docutils) .k,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .k{font-style:italic}html.writer-html4 .rst-content dl:not(.docutils) .descclassname,html.writer-html4 .rst-content dl:not(.docutils) .descname,html.writer-html4 .rst-content dl:not(.docutils) .sig-name,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .descclassname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .descname,html.writer-html5 .rst-content dl[class]:not(.option-list):not(.field-list):not(.footnote):not(.citation):not(.glossary):not(.simple) .sig-name{font-family:SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,Courier,monospace;color:#000}.rst-content .viewcode-back,.rst-content .viewcode-link{display:inline-block;color:#27ae60;font-size:80%;padding-left:24px}.rst-content .viewcode-back{display:block;float:right}.rst-content p.rubric{margin-bottom:12px;font-weight:700}.rst-content code.download,.rst-content tt.download{background:inherit;padding:inherit;font-weight:400;font-family:inherit;font-size:inherit;color:inherit;border:inherit;white-space:inherit}.rst-content code.download span:first-child,.rst-content tt.download span:first-child{-webkit-font-smoothing:subpixel-antialiased}.rst-content code.download span:first-child:before,.rst-content tt.download span:first-child:before{margin-right:4px}.rst-content .guilabel,.rst-content .menuselection{font-size:80%;font-weight:700;border-radius:4px;padding:2.4px 6px;margin:auto 2px}.rst-content .guilabel,.rst-content .menuselection{border:1px solid #7fbbe3;background:#e7f2fa}.rst-content :not(dl.option-list)>:not(dt):not(kbd):not(.kbd)>.kbd,.rst-content :not(dl.option-list)>:not(dt):not(kbd):not(.kbd)>kbd{color:inherit;font-size:80%;background-color:#fff;border:1px solid #a6a6a6;border-radius:4px;box-shadow:0 2px grey;padding:2.4px 6px;margin:auto 0}.rst-content .versionmodified{font-style:italic}@media screen and (max-width:480px){.rst-content .sidebar{width:100%}}span[id*=MathJax-Span]{color:#404040}.math{text-align:center}@font-face{font-family:Lato;src:url(fonts/lato-normal.woff2?bd03a2cc277bbbc338d464e679fe9942) format("woff2"),url(fonts/lato-normal.woff?27bd77b9162d388cb8d4c4217c7c5e2a) format("woff");font-weight:400;font-style:normal;font-display:block}@font-face{font-family:Lato;src:url(fonts/lato-bold.woff2?cccb897485813c7c256901dbca54ecf2) format("woff2"),url(fonts/lato-bold.woff?d878b6c29b10beca227e9eef4246111b) format("woff");font-weight:700;font-style:normal;font-display:block}@font-face{font-family:Lato;src:url(fonts/lato-bold-italic.woff2?0b6bb6725576b072c5d0b02ecdd1900d) format("woff2"),url(fonts/lato-bold-italic.woff?9c7e4e9eb485b4a121c760e61bc3707c) format("woff");font-weight:700;font-style:italic;font-display:block}@font-face{font-family:Lato;src:url(fonts/lato-normal-italic.woff2?4eb103b4d12be57cb1d040ed5e162e9d) format("woff2"),url(fonts/lato-normal-italic.woff?f28f2d6482446544ef1ea1ccc6dd5892) format("woff");font-weight:400;font-style:italic;font-display:block}@font-face{font-family:Roboto Slab;font-style:normal;font-weight:400;src:url(fonts/Roboto-Slab-Regular.woff2?7abf5b8d04d26a2cafea937019bca958) format("woff2"),url(fonts/Roboto-Slab-Regular.woff?c1be9284088d487c5e3ff0a10a92e58c) format("woff");font-display:block}@font-face{font-family:Roboto Slab;font-style:normal;font-weight:700;src:url(fonts/Roboto-Slab-Bold.woff2?9984f4a9bda09be08e83f2506954adbe) format("woff2"),url(fonts/Roboto-Slab-Bold.woff?bed5564a116b05148e3b3bea6fb1162a) format("woff");font-display:block} \ No newline at end of file diff --git a/previews/271/zh_CN/_static/doctools.js b/previews/271/zh_CN/_static/doctools.js new file mode 100644 index 000000000..0398ebb9f --- /dev/null +++ b/previews/271/zh_CN/_static/doctools.js @@ -0,0 +1,149 @@ +/* + * Base JavaScript utilities for all Sphinx HTML documentation. + */ +"use strict"; + +const BLACKLISTED_KEY_CONTROL_ELEMENTS = new Set([ + "TEXTAREA", + "INPUT", + "SELECT", + "BUTTON", +]); + +const _ready = (callback) => { + if (document.readyState !== "loading") { + callback(); + } else { + document.addEventListener("DOMContentLoaded", callback); + } +}; + +/** + * Small JavaScript module for the documentation. + */ +const Documentation = { + init: () => { + Documentation.initDomainIndexTable(); + Documentation.initOnKeyListeners(); + }, + + /** + * i18n support + */ + TRANSLATIONS: {}, + PLURAL_EXPR: (n) => (n === 1 ? 0 : 1), + LOCALE: "unknown", + + // gettext and ngettext don't access this so that the functions + // can safely bound to a different name (_ = Documentation.gettext) + gettext: (string) => { + const translated = Documentation.TRANSLATIONS[string]; + switch (typeof translated) { + case "undefined": + return string; // no translation + case "string": + return translated; // translation exists + default: + return translated[0]; // (singular, plural) translation tuple exists + } + }, + + ngettext: (singular, plural, n) => { + const translated = Documentation.TRANSLATIONS[singular]; + if (typeof translated !== "undefined") + return translated[Documentation.PLURAL_EXPR(n)]; + return n === 1 ? singular : plural; + }, + + addTranslations: (catalog) => { + Object.assign(Documentation.TRANSLATIONS, catalog.messages); + Documentation.PLURAL_EXPR = new Function( + "n", + `return (${catalog.plural_expr})` + ); + Documentation.LOCALE = catalog.locale; + }, + + /** + * helper function to focus on search bar + */ + focusSearchBar: () => { + document.querySelectorAll("input[name=q]")[0]?.focus(); + }, + + /** + * Initialise the domain index toggle buttons + */ + initDomainIndexTable: () => { + const toggler = (el) => { + const idNumber = el.id.substr(7); + const toggledRows = document.querySelectorAll(`tr.cg-${idNumber}`); + if (el.src.substr(-9) === "minus.png") { + el.src = `${el.src.substr(0, el.src.length - 9)}plus.png`; + toggledRows.forEach((el) => (el.style.display = "none")); + } else { + el.src = `${el.src.substr(0, el.src.length - 8)}minus.png`; + toggledRows.forEach((el) => (el.style.display = "")); + } + }; + + const togglerElements = document.querySelectorAll("img.toggler"); + togglerElements.forEach((el) => + el.addEventListener("click", (event) => toggler(event.currentTarget)) + ); + togglerElements.forEach((el) => (el.style.display = "")); + if (DOCUMENTATION_OPTIONS.COLLAPSE_INDEX) togglerElements.forEach(toggler); + }, + + initOnKeyListeners: () => { + // only install a listener if it is really needed + if ( + !DOCUMENTATION_OPTIONS.NAVIGATION_WITH_KEYS && + !DOCUMENTATION_OPTIONS.ENABLE_SEARCH_SHORTCUTS + ) + return; + + document.addEventListener("keydown", (event) => { + // bail for input elements + if (BLACKLISTED_KEY_CONTROL_ELEMENTS.has(document.activeElement.tagName)) return; + // bail with special keys + if (event.altKey || event.ctrlKey || event.metaKey) return; + + if (!event.shiftKey) { + switch (event.key) { + case "ArrowLeft": + if (!DOCUMENTATION_OPTIONS.NAVIGATION_WITH_KEYS) break; + + const prevLink = document.querySelector('link[rel="prev"]'); + if (prevLink && prevLink.href) { + window.location.href = prevLink.href; + event.preventDefault(); + } + break; + case "ArrowRight": + if (!DOCUMENTATION_OPTIONS.NAVIGATION_WITH_KEYS) break; + + const nextLink = document.querySelector('link[rel="next"]'); + if (nextLink && nextLink.href) { + window.location.href = nextLink.href; + event.preventDefault(); + } + break; + } + } + + // some keyboard layouts may need Shift to get / + switch (event.key) { + case "/": + if (!DOCUMENTATION_OPTIONS.ENABLE_SEARCH_SHORTCUTS) break; + Documentation.focusSearchBar(); + event.preventDefault(); + } + }); + }, +}; + +// quick alias for translations +const _ = Documentation.gettext; + +_ready(Documentation.init); diff --git a/previews/271/zh_CN/_static/documentation_options.js b/previews/271/zh_CN/_static/documentation_options.js new file mode 100644 index 000000000..c4a989aa4 --- /dev/null +++ b/previews/271/zh_CN/_static/documentation_options.js @@ -0,0 +1,13 @@ +const DOCUMENTATION_OPTIONS = { + VERSION: '', + LANGUAGE: 'zh-CN', + COLLAPSE_INDEX: false, + BUILDER: 'html', + FILE_SUFFIX: '.html', + LINK_SUFFIX: '.html', + HAS_SOURCE: true, + SOURCELINK_SUFFIX: '.txt', + NAVIGATION_WITH_KEYS: false, + SHOW_SEARCH_SUMMARY: true, + ENABLE_SEARCH_SHORTCUTS: true, +}; \ No newline at end of file diff --git a/previews/271/zh_CN/_static/favicon.ico b/previews/271/zh_CN/_static/favicon.ico new file mode 100644 index 000000000..a817310c8 Binary files /dev/null and b/previews/271/zh_CN/_static/favicon.ico differ diff --git a/previews/271/zh_CN/_static/file.png b/previews/271/zh_CN/_static/file.png new file mode 100644 index 000000000..a858a410e Binary files /dev/null and b/previews/271/zh_CN/_static/file.png differ diff --git a/previews/271/zh_CN/_static/fonts/Lato/lato-bold.eot b/previews/271/zh_CN/_static/fonts/Lato/lato-bold.eot new file mode 100644 index 000000000..3361183a4 Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/Lato/lato-bold.eot differ diff --git a/previews/271/zh_CN/_static/fonts/Lato/lato-bold.ttf b/previews/271/zh_CN/_static/fonts/Lato/lato-bold.ttf new file mode 100644 index 000000000..29f691d5e Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/Lato/lato-bold.ttf differ diff --git a/previews/271/zh_CN/_static/fonts/Lato/lato-bold.woff b/previews/271/zh_CN/_static/fonts/Lato/lato-bold.woff new file mode 100644 index 000000000..c6dff51f0 Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/Lato/lato-bold.woff differ diff --git a/previews/271/zh_CN/_static/fonts/Lato/lato-bold.woff2 b/previews/271/zh_CN/_static/fonts/Lato/lato-bold.woff2 new file mode 100644 index 000000000..bb195043c Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/Lato/lato-bold.woff2 differ diff --git a/previews/271/zh_CN/_static/fonts/Lato/lato-bolditalic.eot b/previews/271/zh_CN/_static/fonts/Lato/lato-bolditalic.eot new file mode 100644 index 000000000..3d4154936 Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/Lato/lato-bolditalic.eot differ diff --git a/previews/271/zh_CN/_static/fonts/Lato/lato-bolditalic.ttf b/previews/271/zh_CN/_static/fonts/Lato/lato-bolditalic.ttf new file mode 100644 index 000000000..f402040b3 Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/Lato/lato-bolditalic.ttf differ diff --git a/previews/271/zh_CN/_static/fonts/Lato/lato-bolditalic.woff b/previews/271/zh_CN/_static/fonts/Lato/lato-bolditalic.woff new file mode 100644 index 000000000..88ad05b9f Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/Lato/lato-bolditalic.woff differ diff --git a/previews/271/zh_CN/_static/fonts/Lato/lato-bolditalic.woff2 b/previews/271/zh_CN/_static/fonts/Lato/lato-bolditalic.woff2 new file mode 100644 index 000000000..c4e3d804b Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/Lato/lato-bolditalic.woff2 differ diff --git a/previews/271/zh_CN/_static/fonts/Lato/lato-italic.eot b/previews/271/zh_CN/_static/fonts/Lato/lato-italic.eot new file mode 100644 index 000000000..3f826421a Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/Lato/lato-italic.eot differ diff --git a/previews/271/zh_CN/_static/fonts/Lato/lato-italic.ttf b/previews/271/zh_CN/_static/fonts/Lato/lato-italic.ttf new file mode 100644 index 000000000..b4bfc9b24 Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/Lato/lato-italic.ttf differ diff --git a/previews/271/zh_CN/_static/fonts/Lato/lato-italic.woff b/previews/271/zh_CN/_static/fonts/Lato/lato-italic.woff new file mode 100644 index 000000000..76114bc03 Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/Lato/lato-italic.woff differ diff --git a/previews/271/zh_CN/_static/fonts/Lato/lato-italic.woff2 b/previews/271/zh_CN/_static/fonts/Lato/lato-italic.woff2 new file mode 100644 index 000000000..3404f37e2 Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/Lato/lato-italic.woff2 differ diff --git a/previews/271/zh_CN/_static/fonts/Lato/lato-regular.eot b/previews/271/zh_CN/_static/fonts/Lato/lato-regular.eot new file mode 100644 index 000000000..11e3f2a5f Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/Lato/lato-regular.eot differ diff --git a/previews/271/zh_CN/_static/fonts/Lato/lato-regular.ttf b/previews/271/zh_CN/_static/fonts/Lato/lato-regular.ttf new file mode 100644 index 000000000..74decd9eb Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/Lato/lato-regular.ttf differ diff --git a/previews/271/zh_CN/_static/fonts/Lato/lato-regular.woff b/previews/271/zh_CN/_static/fonts/Lato/lato-regular.woff new file mode 100644 index 000000000..ae1307ff5 Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/Lato/lato-regular.woff differ diff --git a/previews/271/zh_CN/_static/fonts/Lato/lato-regular.woff2 b/previews/271/zh_CN/_static/fonts/Lato/lato-regular.woff2 new file mode 100644 index 000000000..3bf984332 Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/Lato/lato-regular.woff2 differ diff --git a/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-bold.eot b/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-bold.eot new file mode 100644 index 000000000..79dc8efed Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-bold.eot differ diff --git a/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-bold.ttf b/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-bold.ttf new file mode 100644 index 000000000..df5d1df27 Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-bold.ttf differ diff --git a/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-bold.woff b/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-bold.woff new file mode 100644 index 000000000..6cb600001 Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-bold.woff differ diff --git a/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-bold.woff2 b/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-bold.woff2 new file mode 100644 index 000000000..7059e2314 Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-bold.woff2 differ diff --git a/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-regular.eot b/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-regular.eot new file mode 100644 index 000000000..2f7ca78a1 Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-regular.eot differ diff --git a/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-regular.ttf b/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-regular.ttf new file mode 100644 index 000000000..eb52a7907 Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-regular.ttf differ diff --git a/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-regular.woff b/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-regular.woff new file mode 100644 index 000000000..f815f63f9 Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-regular.woff differ diff --git a/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-regular.woff2 b/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-regular.woff2 new file mode 100644 index 000000000..f2c76e5bd Binary files /dev/null and b/previews/271/zh_CN/_static/fonts/RobotoSlab/roboto-slab-v7-regular.woff2 differ diff --git a/previews/271/zh_CN/_static/googledd12f2e41658d61e.html b/previews/271/zh_CN/_static/googledd12f2e41658d61e.html new file mode 100644 index 000000000..cb695ae9f --- /dev/null +++ b/previews/271/zh_CN/_static/googledd12f2e41658d61e.html @@ -0,0 +1 @@ +google-site-verification: googledd12f2e41658d61e.html \ No newline at end of file diff --git a/previews/271/zh_CN/_static/imx8mm-head.pdf b/previews/271/zh_CN/_static/imx8mm-head.pdf new file mode 100644 index 000000000..ce68d7c18 Binary files /dev/null and b/previews/271/zh_CN/_static/imx8mm-head.pdf differ diff --git a/previews/271/zh_CN/_static/imx8mm-pd22.1.1.pdf b/previews/271/zh_CN/_static/imx8mm-pd22.1.1.pdf new file mode 100644 index 000000000..eebbcba1b Binary files /dev/null and b/previews/271/zh_CN/_static/imx8mm-pd22.1.1.pdf differ diff --git a/previews/271/zh_CN/_static/imx8mm-pd23.1.0.pdf b/previews/271/zh_CN/_static/imx8mm-pd23.1.0.pdf new file mode 100644 index 000000000..f107d0d6e Binary files /dev/null and b/previews/271/zh_CN/_static/imx8mm-pd23.1.0.pdf differ diff --git a/previews/271/zh_CN/_static/imx8mn-head.pdf b/previews/271/zh_CN/_static/imx8mn-head.pdf new file mode 100644 index 000000000..6d0bdfe37 Binary files /dev/null and b/previews/271/zh_CN/_static/imx8mn-head.pdf differ diff --git a/previews/271/zh_CN/_static/imx8mn-pd22.1.1.pdf b/previews/271/zh_CN/_static/imx8mn-pd22.1.1.pdf new file mode 100644 index 000000000..b2af40914 Binary files /dev/null and b/previews/271/zh_CN/_static/imx8mn-pd22.1.1.pdf differ diff --git a/previews/271/zh_CN/_static/imx8mn-pd23.1.0.pdf b/previews/271/zh_CN/_static/imx8mn-pd23.1.0.pdf new file mode 100644 index 000000000..417a678ee Binary files /dev/null and b/previews/271/zh_CN/_static/imx8mn-pd23.1.0.pdf differ diff --git a/previews/271/zh_CN/_static/imx8mp-head.pdf b/previews/271/zh_CN/_static/imx8mp-head.pdf new file mode 100644 index 000000000..2ad88f82a Binary files /dev/null and b/previews/271/zh_CN/_static/imx8mp-head.pdf differ diff --git a/previews/271/zh_CN/_static/imx8mp-libra-fpsc-head.pdf b/previews/271/zh_CN/_static/imx8mp-libra-fpsc-head.pdf new file mode 100644 index 000000000..2b9c39aef Binary files /dev/null and b/previews/271/zh_CN/_static/imx8mp-libra-fpsc-head.pdf differ diff --git a/previews/271/zh_CN/_static/imx8mp-mainline-head.pdf b/previews/271/zh_CN/_static/imx8mp-mainline-head.pdf new file mode 100644 index 000000000..ed122a79e Binary files /dev/null and b/previews/271/zh_CN/_static/imx8mp-mainline-head.pdf differ diff --git a/previews/271/zh_CN/_static/imx8mp-pd22.1.1.pdf b/previews/271/zh_CN/_static/imx8mp-pd22.1.1.pdf new file mode 100644 index 000000000..2e3ceb64d Binary files /dev/null and b/previews/271/zh_CN/_static/imx8mp-pd22.1.1.pdf differ diff --git a/previews/271/zh_CN/_static/imx8mp-pd22.1.2.pdf b/previews/271/zh_CN/_static/imx8mp-pd22.1.2.pdf new file mode 100644 index 000000000..60fac0b3d Binary files /dev/null and b/previews/271/zh_CN/_static/imx8mp-pd22.1.2.pdf differ diff --git a/previews/271/zh_CN/_static/imx8mp-pd23.1.0.pdf b/previews/271/zh_CN/_static/imx8mp-pd23.1.0.pdf new file mode 100644 index 000000000..4f930c5df Binary files /dev/null and b/previews/271/zh_CN/_static/imx8mp-pd23.1.0.pdf differ diff --git a/previews/271/zh_CN/_static/imx8mp-pd24.1.0_nxp.pdf b/previews/271/zh_CN/_static/imx8mp-pd24.1.0_nxp.pdf new file mode 100644 index 000000000..2c7020662 Binary files /dev/null and b/previews/271/zh_CN/_static/imx8mp-pd24.1.0_nxp.pdf differ diff --git a/previews/271/zh_CN/_static/imx8mp-pd24.1.1.pdf b/previews/271/zh_CN/_static/imx8mp-pd24.1.1.pdf new file mode 100644 index 000000000..ed13e1967 Binary files /dev/null and b/previews/271/zh_CN/_static/imx8mp-pd24.1.1.pdf differ diff --git a/previews/271/zh_CN/_static/imx8mp-pd24.1.2.pdf b/previews/271/zh_CN/_static/imx8mp-pd24.1.2.pdf new file mode 100644 index 000000000..69e7cfceb Binary files /dev/null and b/previews/271/zh_CN/_static/imx8mp-pd24.1.2.pdf differ diff --git a/previews/271/zh_CN/_static/imx93-pd24.1.0.pdf b/previews/271/zh_CN/_static/imx93-pd24.1.0.pdf new file mode 100644 index 000000000..589771c07 Binary files /dev/null and b/previews/271/zh_CN/_static/imx93-pd24.1.0.pdf differ diff --git a/previews/271/zh_CN/_static/imx93-pd24.1.1.pdf b/previews/271/zh_CN/_static/imx93-pd24.1.1.pdf new file mode 100644 index 000000000..ac175da36 Binary files /dev/null and b/previews/271/zh_CN/_static/imx93-pd24.1.1.pdf differ diff --git a/previews/271/zh_CN/_static/imx93-pd24.2.0.pdf b/previews/271/zh_CN/_static/imx93-pd24.2.0.pdf new file mode 100644 index 000000000..0d0d737be Binary files /dev/null and b/previews/271/zh_CN/_static/imx93-pd24.2.0.pdf differ diff --git a/previews/271/zh_CN/_static/jquery.js b/previews/271/zh_CN/_static/jquery.js new file mode 100644 index 000000000..c4c6022f2 --- /dev/null +++ b/previews/271/zh_CN/_static/jquery.js @@ -0,0 +1,2 @@ +/*! jQuery v3.6.0 | (c) OpenJS Foundation and other contributors | jquery.org/license */ +!function(e,t){"use strict";"object"==typeof module&&"object"==typeof module.exports?module.exports=e.document?t(e,!0):function(e){if(!e.document)throw new Error("jQuery requires a window with a document");return t(e)}:t(e)}("undefined"!=typeof window?window:this,function(C,e){"use strict";var t=[],r=Object.getPrototypeOf,s=t.slice,g=t.flat?function(e){return t.flat.call(e)}:function(e){return t.concat.apply([],e)},u=t.push,i=t.indexOf,n={},o=n.toString,v=n.hasOwnProperty,a=v.toString,l=a.call(Object),y={},m=function(e){return"function"==typeof e&&"number"!=typeof e.nodeType&&"function"!=typeof e.item},x=function(e){return null!=e&&e===e.window},E=C.document,c={type:!0,src:!0,nonce:!0,noModule:!0};function b(e,t,n){var r,i,o=(n=n||E).createElement("script");if(o.text=e,t)for(r in c)(i=t[r]||t.getAttribute&&t.getAttribute(r))&&o.setAttribute(r,i);n.head.appendChild(o).parentNode.removeChild(o)}function w(e){return null==e?e+"":"object"==typeof e||"function"==typeof e?n[o.call(e)]||"object":typeof e}var f="3.6.0",S=function(e,t){return new S.fn.init(e,t)};function p(e){var t=!!e&&"length"in e&&e.length,n=w(e);return!m(e)&&!x(e)&&("array"===n||0===t||"number"==typeof t&&0+~]|"+M+")"+M+"*"),U=new RegExp(M+"|>"),X=new RegExp(F),V=new RegExp("^"+I+"$"),G={ID:new RegExp("^#("+I+")"),CLASS:new RegExp("^\\.("+I+")"),TAG:new RegExp("^("+I+"|[*])"),ATTR:new RegExp("^"+W),PSEUDO:new RegExp("^"+F),CHILD:new RegExp("^:(only|first|last|nth|nth-last)-(child|of-type)(?:\\("+M+"*(even|odd|(([+-]|)(\\d*)n|)"+M+"*(?:([+-]|)"+M+"*(\\d+)|))"+M+"*\\)|)","i"),bool:new RegExp("^(?:"+R+")$","i"),needsContext:new RegExp("^"+M+"*[>+~]|:(even|odd|eq|gt|lt|nth|first|last)(?:\\("+M+"*((?:-\\d)?\\d*)"+M+"*\\)|)(?=[^-]|$)","i")},Y=/HTML$/i,Q=/^(?:input|select|textarea|button)$/i,J=/^h\d$/i,K=/^[^{]+\{\s*\[native \w/,Z=/^(?:#([\w-]+)|(\w+)|\.([\w-]+))$/,ee=/[+~]/,te=new RegExp("\\\\[\\da-fA-F]{1,6}"+M+"?|\\\\([^\\r\\n\\f])","g"),ne=function(e,t){var n="0x"+e.slice(1)-65536;return t||(n<0?String.fromCharCode(n+65536):String.fromCharCode(n>>10|55296,1023&n|56320))},re=/([\0-\x1f\x7f]|^-?\d)|^-$|[^\0-\x1f\x7f-\uFFFF\w-]/g,ie=function(e,t){return t?"\0"===e?"\ufffd":e.slice(0,-1)+"\\"+e.charCodeAt(e.length-1).toString(16)+" ":"\\"+e},oe=function(){T()},ae=be(function(e){return!0===e.disabled&&"fieldset"===e.nodeName.toLowerCase()},{dir:"parentNode",next:"legend"});try{H.apply(t=O.call(p.childNodes),p.childNodes),t[p.childNodes.length].nodeType}catch(e){H={apply:t.length?function(e,t){L.apply(e,O.call(t))}:function(e,t){var n=e.length,r=0;while(e[n++]=t[r++]);e.length=n-1}}}function se(t,e,n,r){var i,o,a,s,u,l,c,f=e&&e.ownerDocument,p=e?e.nodeType:9;if(n=n||[],"string"!=typeof t||!t||1!==p&&9!==p&&11!==p)return n;if(!r&&(T(e),e=e||C,E)){if(11!==p&&(u=Z.exec(t)))if(i=u[1]){if(9===p){if(!(a=e.getElementById(i)))return n;if(a.id===i)return n.push(a),n}else if(f&&(a=f.getElementById(i))&&y(e,a)&&a.id===i)return n.push(a),n}else{if(u[2])return H.apply(n,e.getElementsByTagName(t)),n;if((i=u[3])&&d.getElementsByClassName&&e.getElementsByClassName)return H.apply(n,e.getElementsByClassName(i)),n}if(d.qsa&&!N[t+" "]&&(!v||!v.test(t))&&(1!==p||"object"!==e.nodeName.toLowerCase())){if(c=t,f=e,1===p&&(U.test(t)||z.test(t))){(f=ee.test(t)&&ye(e.parentNode)||e)===e&&d.scope||((s=e.getAttribute("id"))?s=s.replace(re,ie):e.setAttribute("id",s=S)),o=(l=h(t)).length;while(o--)l[o]=(s?"#"+s:":scope")+" "+xe(l[o]);c=l.join(",")}try{return H.apply(n,f.querySelectorAll(c)),n}catch(e){N(t,!0)}finally{s===S&&e.removeAttribute("id")}}}return g(t.replace($,"$1"),e,n,r)}function ue(){var r=[];return function e(t,n){return r.push(t+" ")>b.cacheLength&&delete e[r.shift()],e[t+" "]=n}}function le(e){return e[S]=!0,e}function ce(e){var t=C.createElement("fieldset");try{return!!e(t)}catch(e){return!1}finally{t.parentNode&&t.parentNode.removeChild(t),t=null}}function fe(e,t){var n=e.split("|"),r=n.length;while(r--)b.attrHandle[n[r]]=t}function pe(e,t){var n=t&&e,r=n&&1===e.nodeType&&1===t.nodeType&&e.sourceIndex-t.sourceIndex;if(r)return r;if(n)while(n=n.nextSibling)if(n===t)return-1;return e?1:-1}function de(t){return function(e){return"input"===e.nodeName.toLowerCase()&&e.type===t}}function he(n){return function(e){var t=e.nodeName.toLowerCase();return("input"===t||"button"===t)&&e.type===n}}function ge(t){return function(e){return"form"in e?e.parentNode&&!1===e.disabled?"label"in e?"label"in e.parentNode?e.parentNode.disabled===t:e.disabled===t:e.isDisabled===t||e.isDisabled!==!t&&ae(e)===t:e.disabled===t:"label"in e&&e.disabled===t}}function ve(a){return le(function(o){return o=+o,le(function(e,t){var n,r=a([],e.length,o),i=r.length;while(i--)e[n=r[i]]&&(e[n]=!(t[n]=e[n]))})})}function ye(e){return e&&"undefined"!=typeof e.getElementsByTagName&&e}for(e in d=se.support={},i=se.isXML=function(e){var t=e&&e.namespaceURI,n=e&&(e.ownerDocument||e).documentElement;return!Y.test(t||n&&n.nodeName||"HTML")},T=se.setDocument=function(e){var t,n,r=e?e.ownerDocument||e:p;return r!=C&&9===r.nodeType&&r.documentElement&&(a=(C=r).documentElement,E=!i(C),p!=C&&(n=C.defaultView)&&n.top!==n&&(n.addEventListener?n.addEventListener("unload",oe,!1):n.attachEvent&&n.attachEvent("onunload",oe)),d.scope=ce(function(e){return a.appendChild(e).appendChild(C.createElement("div")),"undefined"!=typeof e.querySelectorAll&&!e.querySelectorAll(":scope fieldset div").length}),d.attributes=ce(function(e){return e.className="i",!e.getAttribute("className")}),d.getElementsByTagName=ce(function(e){return e.appendChild(C.createComment("")),!e.getElementsByTagName("*").length}),d.getElementsByClassName=K.test(C.getElementsByClassName),d.getById=ce(function(e){return a.appendChild(e).id=S,!C.getElementsByName||!C.getElementsByName(S).length}),d.getById?(b.filter.ID=function(e){var t=e.replace(te,ne);return function(e){return e.getAttribute("id")===t}},b.find.ID=function(e,t){if("undefined"!=typeof t.getElementById&&E){var n=t.getElementById(e);return n?[n]:[]}}):(b.filter.ID=function(e){var n=e.replace(te,ne);return function(e){var t="undefined"!=typeof e.getAttributeNode&&e.getAttributeNode("id");return t&&t.value===n}},b.find.ID=function(e,t){if("undefined"!=typeof t.getElementById&&E){var n,r,i,o=t.getElementById(e);if(o){if((n=o.getAttributeNode("id"))&&n.value===e)return[o];i=t.getElementsByName(e),r=0;while(o=i[r++])if((n=o.getAttributeNode("id"))&&n.value===e)return[o]}return[]}}),b.find.TAG=d.getElementsByTagName?function(e,t){return"undefined"!=typeof t.getElementsByTagName?t.getElementsByTagName(e):d.qsa?t.querySelectorAll(e):void 0}:function(e,t){var n,r=[],i=0,o=t.getElementsByTagName(e);if("*"===e){while(n=o[i++])1===n.nodeType&&r.push(n);return r}return o},b.find.CLASS=d.getElementsByClassName&&function(e,t){if("undefined"!=typeof t.getElementsByClassName&&E)return t.getElementsByClassName(e)},s=[],v=[],(d.qsa=K.test(C.querySelectorAll))&&(ce(function(e){var t;a.appendChild(e).innerHTML="",e.querySelectorAll("[msallowcapture^='']").length&&v.push("[*^$]="+M+"*(?:''|\"\")"),e.querySelectorAll("[selected]").length||v.push("\\["+M+"*(?:value|"+R+")"),e.querySelectorAll("[id~="+S+"-]").length||v.push("~="),(t=C.createElement("input")).setAttribute("name",""),e.appendChild(t),e.querySelectorAll("[name='']").length||v.push("\\["+M+"*name"+M+"*="+M+"*(?:''|\"\")"),e.querySelectorAll(":checked").length||v.push(":checked"),e.querySelectorAll("a#"+S+"+*").length||v.push(".#.+[+~]"),e.querySelectorAll("\\\f"),v.push("[\\r\\n\\f]")}),ce(function(e){e.innerHTML="";var t=C.createElement("input");t.setAttribute("type","hidden"),e.appendChild(t).setAttribute("name","D"),e.querySelectorAll("[name=d]").length&&v.push("name"+M+"*[*^$|!~]?="),2!==e.querySelectorAll(":enabled").length&&v.push(":enabled",":disabled"),a.appendChild(e).disabled=!0,2!==e.querySelectorAll(":disabled").length&&v.push(":enabled",":disabled"),e.querySelectorAll("*,:x"),v.push(",.*:")})),(d.matchesSelector=K.test(c=a.matches||a.webkitMatchesSelector||a.mozMatchesSelector||a.oMatchesSelector||a.msMatchesSelector))&&ce(function(e){d.disconnectedMatch=c.call(e,"*"),c.call(e,"[s!='']:x"),s.push("!=",F)}),v=v.length&&new RegExp(v.join("|")),s=s.length&&new RegExp(s.join("|")),t=K.test(a.compareDocumentPosition),y=t||K.test(a.contains)?function(e,t){var n=9===e.nodeType?e.documentElement:e,r=t&&t.parentNode;return e===r||!(!r||1!==r.nodeType||!(n.contains?n.contains(r):e.compareDocumentPosition&&16&e.compareDocumentPosition(r)))}:function(e,t){if(t)while(t=t.parentNode)if(t===e)return!0;return!1},j=t?function(e,t){if(e===t)return l=!0,0;var n=!e.compareDocumentPosition-!t.compareDocumentPosition;return n||(1&(n=(e.ownerDocument||e)==(t.ownerDocument||t)?e.compareDocumentPosition(t):1)||!d.sortDetached&&t.compareDocumentPosition(e)===n?e==C||e.ownerDocument==p&&y(p,e)?-1:t==C||t.ownerDocument==p&&y(p,t)?1:u?P(u,e)-P(u,t):0:4&n?-1:1)}:function(e,t){if(e===t)return l=!0,0;var n,r=0,i=e.parentNode,o=t.parentNode,a=[e],s=[t];if(!i||!o)return e==C?-1:t==C?1:i?-1:o?1:u?P(u,e)-P(u,t):0;if(i===o)return pe(e,t);n=e;while(n=n.parentNode)a.unshift(n);n=t;while(n=n.parentNode)s.unshift(n);while(a[r]===s[r])r++;return r?pe(a[r],s[r]):a[r]==p?-1:s[r]==p?1:0}),C},se.matches=function(e,t){return se(e,null,null,t)},se.matchesSelector=function(e,t){if(T(e),d.matchesSelector&&E&&!N[t+" "]&&(!s||!s.test(t))&&(!v||!v.test(t)))try{var n=c.call(e,t);if(n||d.disconnectedMatch||e.document&&11!==e.document.nodeType)return n}catch(e){N(t,!0)}return 0":{dir:"parentNode",first:!0}," ":{dir:"parentNode"},"+":{dir:"previousSibling",first:!0},"~":{dir:"previousSibling"}},preFilter:{ATTR:function(e){return e[1]=e[1].replace(te,ne),e[3]=(e[3]||e[4]||e[5]||"").replace(te,ne),"~="===e[2]&&(e[3]=" "+e[3]+" "),e.slice(0,4)},CHILD:function(e){return e[1]=e[1].toLowerCase(),"nth"===e[1].slice(0,3)?(e[3]||se.error(e[0]),e[4]=+(e[4]?e[5]+(e[6]||1):2*("even"===e[3]||"odd"===e[3])),e[5]=+(e[7]+e[8]||"odd"===e[3])):e[3]&&se.error(e[0]),e},PSEUDO:function(e){var t,n=!e[6]&&e[2];return G.CHILD.test(e[0])?null:(e[3]?e[2]=e[4]||e[5]||"":n&&X.test(n)&&(t=h(n,!0))&&(t=n.indexOf(")",n.length-t)-n.length)&&(e[0]=e[0].slice(0,t),e[2]=n.slice(0,t)),e.slice(0,3))}},filter:{TAG:function(e){var t=e.replace(te,ne).toLowerCase();return"*"===e?function(){return!0}:function(e){return e.nodeName&&e.nodeName.toLowerCase()===t}},CLASS:function(e){var t=m[e+" "];return t||(t=new RegExp("(^|"+M+")"+e+"("+M+"|$)"))&&m(e,function(e){return t.test("string"==typeof e.className&&e.className||"undefined"!=typeof e.getAttribute&&e.getAttribute("class")||"")})},ATTR:function(n,r,i){return function(e){var t=se.attr(e,n);return null==t?"!="===r:!r||(t+="","="===r?t===i:"!="===r?t!==i:"^="===r?i&&0===t.indexOf(i):"*="===r?i&&-1:\x20\t\r\n\f]*)[\x20\t\r\n\f]*\/?>(?:<\/\1>|)$/i;function j(e,n,r){return m(n)?S.grep(e,function(e,t){return!!n.call(e,t,e)!==r}):n.nodeType?S.grep(e,function(e){return e===n!==r}):"string"!=typeof n?S.grep(e,function(e){return-1)[^>]*|#([\w-]+))$/;(S.fn.init=function(e,t,n){var r,i;if(!e)return this;if(n=n||D,"string"==typeof e){if(!(r="<"===e[0]&&">"===e[e.length-1]&&3<=e.length?[null,e,null]:q.exec(e))||!r[1]&&t)return!t||t.jquery?(t||n).find(e):this.constructor(t).find(e);if(r[1]){if(t=t instanceof S?t[0]:t,S.merge(this,S.parseHTML(r[1],t&&t.nodeType?t.ownerDocument||t:E,!0)),N.test(r[1])&&S.isPlainObject(t))for(r in t)m(this[r])?this[r](t[r]):this.attr(r,t[r]);return this}return(i=E.getElementById(r[2]))&&(this[0]=i,this.length=1),this}return e.nodeType?(this[0]=e,this.length=1,this):m(e)?void 0!==n.ready?n.ready(e):e(S):S.makeArray(e,this)}).prototype=S.fn,D=S(E);var L=/^(?:parents|prev(?:Until|All))/,H={children:!0,contents:!0,next:!0,prev:!0};function O(e,t){while((e=e[t])&&1!==e.nodeType);return e}S.fn.extend({has:function(e){var t=S(e,this),n=t.length;return this.filter(function(){for(var e=0;e\x20\t\r\n\f]*)/i,he=/^$|^module$|\/(?:java|ecma)script/i;ce=E.createDocumentFragment().appendChild(E.createElement("div")),(fe=E.createElement("input")).setAttribute("type","radio"),fe.setAttribute("checked","checked"),fe.setAttribute("name","t"),ce.appendChild(fe),y.checkClone=ce.cloneNode(!0).cloneNode(!0).lastChild.checked,ce.innerHTML="",y.noCloneChecked=!!ce.cloneNode(!0).lastChild.defaultValue,ce.innerHTML="",y.option=!!ce.lastChild;var ge={thead:[1,"","
"],col:[2,"","
"],tr:[2,"","
"],td:[3,"","
"],_default:[0,"",""]};function ve(e,t){var n;return n="undefined"!=typeof e.getElementsByTagName?e.getElementsByTagName(t||"*"):"undefined"!=typeof e.querySelectorAll?e.querySelectorAll(t||"*"):[],void 0===t||t&&A(e,t)?S.merge([e],n):n}function ye(e,t){for(var n=0,r=e.length;n",""]);var me=/<|&#?\w+;/;function xe(e,t,n,r,i){for(var o,a,s,u,l,c,f=t.createDocumentFragment(),p=[],d=0,h=e.length;d\s*$/g;function je(e,t){return A(e,"table")&&A(11!==t.nodeType?t:t.firstChild,"tr")&&S(e).children("tbody")[0]||e}function De(e){return e.type=(null!==e.getAttribute("type"))+"/"+e.type,e}function qe(e){return"true/"===(e.type||"").slice(0,5)?e.type=e.type.slice(5):e.removeAttribute("type"),e}function Le(e,t){var n,r,i,o,a,s;if(1===t.nodeType){if(Y.hasData(e)&&(s=Y.get(e).events))for(i in Y.remove(t,"handle events"),s)for(n=0,r=s[i].length;n").attr(n.scriptAttrs||{}).prop({charset:n.scriptCharset,src:n.url}).on("load error",i=function(e){r.remove(),i=null,e&&t("error"===e.type?404:200,e.type)}),E.head.appendChild(r[0])},abort:function(){i&&i()}}});var _t,zt=[],Ut=/(=)\?(?=&|$)|\?\?/;S.ajaxSetup({jsonp:"callback",jsonpCallback:function(){var e=zt.pop()||S.expando+"_"+wt.guid++;return this[e]=!0,e}}),S.ajaxPrefilter("json jsonp",function(e,t,n){var r,i,o,a=!1!==e.jsonp&&(Ut.test(e.url)?"url":"string"==typeof e.data&&0===(e.contentType||"").indexOf("application/x-www-form-urlencoded")&&Ut.test(e.data)&&"data");if(a||"jsonp"===e.dataTypes[0])return r=e.jsonpCallback=m(e.jsonpCallback)?e.jsonpCallback():e.jsonpCallback,a?e[a]=e[a].replace(Ut,"$1"+r):!1!==e.jsonp&&(e.url+=(Tt.test(e.url)?"&":"?")+e.jsonp+"="+r),e.converters["script json"]=function(){return o||S.error(r+" was not called"),o[0]},e.dataTypes[0]="json",i=C[r],C[r]=function(){o=arguments},n.always(function(){void 0===i?S(C).removeProp(r):C[r]=i,e[r]&&(e.jsonpCallback=t.jsonpCallback,zt.push(r)),o&&m(i)&&i(o[0]),o=i=void 0}),"script"}),y.createHTMLDocument=((_t=E.implementation.createHTMLDocument("").body).innerHTML="
",2===_t.childNodes.length),S.parseHTML=function(e,t,n){return"string"!=typeof e?[]:("boolean"==typeof t&&(n=t,t=!1),t||(y.createHTMLDocument?((r=(t=E.implementation.createHTMLDocument("")).createElement("base")).href=E.location.href,t.head.appendChild(r)):t=E),o=!n&&[],(i=N.exec(e))?[t.createElement(i[1])]:(i=xe([e],t,o),o&&o.length&&S(o).remove(),S.merge([],i.childNodes)));var r,i,o},S.fn.load=function(e,t,n){var r,i,o,a=this,s=e.indexOf(" ");return-1").append(S.parseHTML(e)).find(r):e)}).always(n&&function(e,t){a.each(function(){n.apply(this,o||[e.responseText,t,e])})}),this},S.expr.pseudos.animated=function(t){return S.grep(S.timers,function(e){return t===e.elem}).length},S.offset={setOffset:function(e,t,n){var r,i,o,a,s,u,l=S.css(e,"position"),c=S(e),f={};"static"===l&&(e.style.position="relative"),s=c.offset(),o=S.css(e,"top"),u=S.css(e,"left"),("absolute"===l||"fixed"===l)&&-1<(o+u).indexOf("auto")?(a=(r=c.position()).top,i=r.left):(a=parseFloat(o)||0,i=parseFloat(u)||0),m(t)&&(t=t.call(e,n,S.extend({},s))),null!=t.top&&(f.top=t.top-s.top+a),null!=t.left&&(f.left=t.left-s.left+i),"using"in t?t.using.call(e,f):c.css(f)}},S.fn.extend({offset:function(t){if(arguments.length)return void 0===t?this:this.each(function(e){S.offset.setOffset(this,t,e)});var e,n,r=this[0];return r?r.getClientRects().length?(e=r.getBoundingClientRect(),n=r.ownerDocument.defaultView,{top:e.top+n.pageYOffset,left:e.left+n.pageXOffset}):{top:0,left:0}:void 0},position:function(){if(this[0]){var e,t,n,r=this[0],i={top:0,left:0};if("fixed"===S.css(r,"position"))t=r.getBoundingClientRect();else{t=this.offset(),n=r.ownerDocument,e=r.offsetParent||n.documentElement;while(e&&(e===n.body||e===n.documentElement)&&"static"===S.css(e,"position"))e=e.parentNode;e&&e!==r&&1===e.nodeType&&((i=S(e).offset()).top+=S.css(e,"borderTopWidth",!0),i.left+=S.css(e,"borderLeftWidth",!0))}return{top:t.top-i.top-S.css(r,"marginTop",!0),left:t.left-i.left-S.css(r,"marginLeft",!0)}}},offsetParent:function(){return this.map(function(){var e=this.offsetParent;while(e&&"static"===S.css(e,"position"))e=e.offsetParent;return e||re})}}),S.each({scrollLeft:"pageXOffset",scrollTop:"pageYOffset"},function(t,i){var o="pageYOffset"===i;S.fn[t]=function(e){return $(this,function(e,t,n){var r;if(x(e)?r=e:9===e.nodeType&&(r=e.defaultView),void 0===n)return r?r[i]:e[t];r?r.scrollTo(o?r.pageXOffset:n,o?n:r.pageYOffset):e[t]=n},t,e,arguments.length)}}),S.each(["top","left"],function(e,n){S.cssHooks[n]=Fe(y.pixelPosition,function(e,t){if(t)return t=We(e,n),Pe.test(t)?S(e).position()[n]+"px":t})}),S.each({Height:"height",Width:"width"},function(a,s){S.each({padding:"inner"+a,content:s,"":"outer"+a},function(r,o){S.fn[o]=function(e,t){var n=arguments.length&&(r||"boolean"!=typeof e),i=r||(!0===e||!0===t?"margin":"border");return $(this,function(e,t,n){var r;return x(e)?0===o.indexOf("outer")?e["inner"+a]:e.document.documentElement["client"+a]:9===e.nodeType?(r=e.documentElement,Math.max(e.body["scroll"+a],r["scroll"+a],e.body["offset"+a],r["offset"+a],r["client"+a])):void 0===n?S.css(e,t,i):S.style(e,t,n,i)},s,n?e:void 0,n)}})}),S.each(["ajaxStart","ajaxStop","ajaxComplete","ajaxError","ajaxSuccess","ajaxSend"],function(e,t){S.fn[t]=function(e){return this.on(t,e)}}),S.fn.extend({bind:function(e,t,n){return this.on(e,null,t,n)},unbind:function(e,t){return this.off(e,null,t)},delegate:function(e,t,n,r){return this.on(t,e,n,r)},undelegate:function(e,t,n){return 1===arguments.length?this.off(e,"**"):this.off(t,e||"**",n)},hover:function(e,t){return this.mouseenter(e).mouseleave(t||e)}}),S.each("blur focus focusin focusout resize scroll click dblclick mousedown mouseup mousemove mouseover mouseout mouseenter mouseleave change select submit keydown keypress keyup contextmenu".split(" "),function(e,n){S.fn[n]=function(e,t){return 0
"),n("table.docutils.footnote").wrap("
"),n("table.docutils.citation").wrap("
"),n(".wy-menu-vertical ul").not(".simple").siblings("a").each((function(){var t=n(this);expand=n(''),expand.on("click",(function(n){return e.toggleCurrent(t),n.stopPropagation(),!1})),t.prepend(expand)}))},reset:function(){var n=encodeURI(window.location.hash)||"#";try{var e=$(".wy-menu-vertical"),t=e.find('[href="'+n+'"]');if(0===t.length){var i=$('.document [id="'+n.substring(1)+'"]').closest("div.section");0===(t=e.find('[href="#'+i.attr("id")+'"]')).length&&(t=e.find('[href="#"]'))}if(t.length>0){$(".wy-menu-vertical .current").removeClass("current").attr("aria-expanded","false"),t.addClass("current").attr("aria-expanded","true"),t.closest("li.toctree-l1").parent().addClass("current").attr("aria-expanded","true");for(let n=1;n<=10;n++)t.closest("li.toctree-l"+n).addClass("current").attr("aria-expanded","true");t[0].scrollIntoView()}}catch(n){console.log("Error expanding nav for anchor",n)}},onScroll:function(){this.winScroll=!1;var n=this.win.scrollTop(),e=n+this.winHeight,t=this.navBar.scrollTop()+(n-this.winPosition);n<0||e>this.docHeight||(this.navBar.scrollTop(t),this.winPosition=n)},onResize:function(){this.winResize=!1,this.winHeight=this.win.height(),this.docHeight=$(document).height()},hashChange:function(){this.linkScroll=!0,this.win.one("hashchange",(function(){this.linkScroll=!1}))},toggleCurrent:function(n){var e=n.closest("li");e.siblings("li.current").removeClass("current").attr("aria-expanded","false"),e.siblings().find("li.current").removeClass("current").attr("aria-expanded","false");var t=e.find("> ul li");t.length&&(t.removeClass("current").attr("aria-expanded","false"),e.toggleClass("current").attr("aria-expanded",(function(n,e){return"true"==e?"false":"true"})))}},"undefined"!=typeof window&&(window.SphinxRtdTheme={Navigation:n.exports.ThemeNav,StickyNav:n.exports.ThemeNav}),function(){for(var n=0,e=["ms","moz","webkit","o"],t=0;t +
语言
+ ${config.projects.translations + .map( + (translation) => ` +
+ ${translation.language.code} +
+ `, + ) + .join("\n")} + + `; + return languagesHTML; + } + + function renderVersions(config) { + if (!config.versions.active.length) { + return ""; + } + const versionsHTML = ` +
+
版本
+ ${config.versions.active + .map( + (version) => ` +
+ ${version.slug} +
+ `, + ) + .join("\n")} +
+ `; + return versionsHTML; + } + + function renderDownloads(config) { + if (!Object.keys(config.versions.current.downloads).length) { + return ""; + } + const downloadsNameDisplay = { + pdf: "PDF", + epub: "Epub", + htmlzip: "HTML", + }; + + const downloadsHTML = ` +
+
下载
+ ${Object.entries(config.versions.current.downloads) + .map( + ([name, url]) => ` +
+ ${downloadsNameDisplay[name]} +
+ `, + ) + .join("\n")} +
+ `; + return downloadsHTML; + } + + document.addEventListener("readthedocs-addons-data-ready", function (event) { + const config = event.detail.data(); + + const flyout = ` +
+ + Read the Docs + v: ${config.versions.current.slug} + + +
+
+ ${renderLanguages(config)} + ${renderVersions(config)} + ${renderDownloads(config)} +
+
托管于 Read the Docs
+
+ 项目主页 +
+
+ 构建 +
+
+ 下载 +
+
+
+
搜索
+
+
+ +
+
+
+
+ + Hosted by Read the Docs + +
+
+ `; + + // Inject the generated flyout into the body HTML element. + document.body.insertAdjacentHTML("beforeend", flyout); + + // Trigger the Read the Docs Addons Search modal when clicking on the "Search docs" input from inside the flyout. + document + .querySelector("#flyout-search-form") + .addEventListener("focusin", () => { + const event = new CustomEvent("readthedocs-search-show"); + document.dispatchEvent(event); + }); + }) +} + +if (themeLanguageSelector || themeVersionSelector) { + function onSelectorSwitch(event) { + const option = event.target.selectedIndex; + const item = event.target.options[option]; + window.location.href = item.dataset.url; + } + + document.addEventListener("readthedocs-addons-data-ready", function (event) { + const config = event.detail.data(); + + const versionSwitch = document.querySelector( + "div.switch-menus > div.version-switch", + ); + if (themeVersionSelector) { + let versions = config.versions.active; + if (config.versions.current.hidden || config.versions.current.type === "external") { + versions.unshift(config.versions.current); + } + const versionSelect = ` + + `; + + versionSwitch.innerHTML = versionSelect; + versionSwitch.firstElementChild.addEventListener("change", onSelectorSwitch); + } + + const languageSwitch = document.querySelector( + "div.switch-menus > div.language-switch", + ); + + if (themeLanguageSelector) { + if (config.projects.translations.length) { + // Add the current language to the options on the selector + let languages = config.projects.translations.concat( + config.projects.current, + ); + languages = languages.sort((a, b) => + a.language.name.localeCompare(b.language.name), + ); + + const languageSelect = ` + + `; + + languageSwitch.innerHTML = languageSelect; + languageSwitch.firstElementChild.addEventListener("change", onSelectorSwitch); + } + else { + languageSwitch.remove(); + } + } + }); +} + +document.addEventListener("readthedocs-addons-data-ready", function (event) { + // Trigger the Read the Docs Addons Search modal when clicking on "Search docs" input from the topnav. + document + .querySelector("[role='search'] input") + .addEventListener("focusin", () => { + const event = new CustomEvent("readthedocs-search-show"); + document.dispatchEvent(event); + }); +}); \ No newline at end of file diff --git a/previews/271/zh_CN/_static/kirkstone.pdf b/previews/271/zh_CN/_static/kirkstone.pdf new file mode 100644 index 000000000..ede48ca40 Binary files /dev/null and b/previews/271/zh_CN/_static/kirkstone.pdf differ diff --git a/previews/271/zh_CN/_static/language_data.js b/previews/271/zh_CN/_static/language_data.js new file mode 100644 index 000000000..c7fe6c6fa --- /dev/null +++ b/previews/271/zh_CN/_static/language_data.js @@ -0,0 +1,192 @@ +/* + * This script contains the language-specific data used by searchtools.js, + * namely the list of stopwords, stemmer, scorer and splitter. + */ + +var stopwords = ["a", "and", "are", "as", "at", "be", "but", "by", "for", "if", "in", "into", "is", "it", "near", "no", "not", "of", "on", "or", "such", "that", "the", "their", "then", "there", "these", "they", "this", "to", "was", "will", "with"]; + + +/* Non-minified version is copied as a separate JS file, if available */ + +/** + * Porter Stemmer + */ +var Stemmer = function() { + + var step2list = { + ational: 'ate', + tional: 'tion', + enci: 'ence', + anci: 'ance', + izer: 'ize', + bli: 'ble', + alli: 'al', + entli: 'ent', + eli: 'e', + ousli: 'ous', + ization: 'ize', + ation: 'ate', + ator: 'ate', + alism: 'al', + iveness: 'ive', + fulness: 'ful', + ousness: 'ous', + aliti: 'al', + iviti: 'ive', + biliti: 'ble', + logi: 'log' + }; + + var step3list = { + icate: 'ic', + ative: '', + alize: 'al', + iciti: 'ic', + ical: 'ic', + ful: '', + ness: '' + }; + + var c = "[^aeiou]"; // consonant + var v = "[aeiouy]"; // vowel + var C = c + "[^aeiouy]*"; // consonant sequence + var V = v + "[aeiou]*"; // vowel sequence + + var mgr0 = "^(" + C + ")?" + V + C; // [C]VC... is m>0 + var meq1 = "^(" + C + ")?" + V + C + "(" + V + ")?$"; // [C]VC[V] is m=1 + var mgr1 = "^(" + C + ")?" + V + C + V + C; // [C]VCVC... is m>1 + var s_v = "^(" + C + ")?" + v; // vowel in stem + + this.stemWord = function (w) { + var stem; + var suffix; + var firstch; + var origword = w; + + if (w.length < 3) + return w; + + var re; + var re2; + var re3; + var re4; + + firstch = w.substr(0,1); + if (firstch == "y") + w = firstch.toUpperCase() + w.substr(1); + + // Step 1a + re = /^(.+?)(ss|i)es$/; + re2 = /^(.+?)([^s])s$/; + + if (re.test(w)) + w = w.replace(re,"$1$2"); + else if (re2.test(w)) + w = w.replace(re2,"$1$2"); + + // Step 1b + re = /^(.+?)eed$/; + re2 = /^(.+?)(ed|ing)$/; + if (re.test(w)) { + var fp = re.exec(w); + re = new RegExp(mgr0); + if (re.test(fp[1])) { + re = /.$/; + w = w.replace(re,""); + } + } + else if (re2.test(w)) { + var fp = re2.exec(w); + stem = fp[1]; + re2 = new RegExp(s_v); + if (re2.test(stem)) { + w = stem; + re2 = /(at|bl|iz)$/; + re3 = new RegExp("([^aeiouylsz])\\1$"); + re4 = new RegExp("^" + C + v + "[^aeiouwxy]$"); + if (re2.test(w)) + w = w + "e"; + else if (re3.test(w)) { + re = /.$/; + w = w.replace(re,""); + } + else if (re4.test(w)) + w = w + "e"; + } + } + + // Step 1c + re = /^(.+?)y$/; + if (re.test(w)) { + var fp = re.exec(w); + stem = fp[1]; + re = new RegExp(s_v); + if (re.test(stem)) + w = stem + "i"; + } + + // Step 2 + re = /^(.+?)(ational|tional|enci|anci|izer|bli|alli|entli|eli|ousli|ization|ation|ator|alism|iveness|fulness|ousness|aliti|iviti|biliti|logi)$/; + if (re.test(w)) { + var fp = re.exec(w); + stem = fp[1]; + suffix = fp[2]; + re = new RegExp(mgr0); + if (re.test(stem)) + w = stem + step2list[suffix]; + } + + // Step 3 + re = /^(.+?)(icate|ative|alize|iciti|ical|ful|ness)$/; + if (re.test(w)) { + var fp = re.exec(w); + stem = fp[1]; + suffix = fp[2]; + re = new RegExp(mgr0); + if (re.test(stem)) + w = stem + step3list[suffix]; + } + + // Step 4 + re = /^(.+?)(al|ance|ence|er|ic|able|ible|ant|ement|ment|ent|ou|ism|ate|iti|ous|ive|ize)$/; + re2 = /^(.+?)(s|t)(ion)$/; + if (re.test(w)) { + var fp = re.exec(w); + stem = fp[1]; + re = new RegExp(mgr1); + if (re.test(stem)) + w = stem; + } + else if (re2.test(w)) { + var fp = re2.exec(w); + stem = fp[1] + fp[2]; + re2 = new RegExp(mgr1); + if (re2.test(stem)) + w = stem; + } + + // Step 5 + re = /^(.+?)e$/; + if (re.test(w)) { + var fp = re.exec(w); + stem = fp[1]; + re = new RegExp(mgr1); + re2 = new RegExp(meq1); + re3 = new RegExp("^" + C + v + "[^aeiouwxy]$"); + if (re.test(stem) || (re2.test(stem) && !(re3.test(stem)))) + w = stem; + } + re = /ll$/; + re2 = new RegExp(mgr1); + if (re.test(w) && re2.test(w)) { + re = /.$/; + w = w.replace(re,""); + } + + // and turn initial Y back to y + if (firstch == "y") + w = firstch.toLowerCase() + w.substr(1); + return w; + } +} + diff --git a/previews/271/zh_CN/_static/logo-phytec.svg b/previews/271/zh_CN/_static/logo-phytec.svg new file mode 100644 index 000000000..b385926a7 --- /dev/null +++ b/previews/271/zh_CN/_static/logo-phytec.svg @@ -0,0 +1,9 @@ + + + + + + + + + diff --git a/previews/271/zh_CN/_static/mickledore.pdf b/previews/271/zh_CN/_static/mickledore.pdf new file mode 100644 index 000000000..4fa30d1dc Binary files /dev/null and b/previews/271/zh_CN/_static/mickledore.pdf differ diff --git a/previews/271/zh_CN/_static/minus.png b/previews/271/zh_CN/_static/minus.png new file mode 100644 index 000000000..d96755fda Binary files /dev/null and b/previews/271/zh_CN/_static/minus.png differ diff --git a/previews/271/zh_CN/_static/plus.png b/previews/271/zh_CN/_static/plus.png new file mode 100644 index 000000000..7107cec93 Binary files /dev/null and b/previews/271/zh_CN/_static/plus.png differ diff --git a/previews/271/zh_CN/_static/pygments.css b/previews/271/zh_CN/_static/pygments.css new file mode 100644 index 000000000..6f8b210a1 --- /dev/null +++ b/previews/271/zh_CN/_static/pygments.css @@ -0,0 +1,75 @@ +pre { line-height: 125%; } +td.linenos .normal { color: inherit; background-color: transparent; padding-left: 5px; padding-right: 5px; } +span.linenos { color: inherit; background-color: transparent; padding-left: 5px; padding-right: 5px; } +td.linenos .special { color: #000000; background-color: #ffffc0; padding-left: 5px; padding-right: 5px; } +span.linenos.special { color: #000000; background-color: #ffffc0; padding-left: 5px; padding-right: 5px; } +.highlight .hll { background-color: #ffffcc } +.highlight { background: #f8f8f8; } +.highlight .c { color: #3D7B7B; font-style: italic } /* Comment */ +.highlight .err { border: 1px solid #F00 } /* Error */ +.highlight .k { color: #008000; font-weight: bold } /* Keyword */ +.highlight .o { color: #666 } /* Operator */ +.highlight .ch { color: #3D7B7B; font-style: italic } /* Comment.Hashbang */ +.highlight .cm { color: #3D7B7B; font-style: italic } /* Comment.Multiline */ +.highlight .cp { color: #9C6500 } /* Comment.Preproc */ +.highlight .cpf { color: #3D7B7B; font-style: italic } /* Comment.PreprocFile */ +.highlight .c1 { color: #3D7B7B; font-style: italic } /* Comment.Single */ +.highlight .cs { color: #3D7B7B; font-style: italic } /* Comment.Special */ +.highlight .gd { color: #A00000 } /* Generic.Deleted */ +.highlight .ge { font-style: italic } /* Generic.Emph */ +.highlight .ges { font-weight: bold; font-style: italic } /* Generic.EmphStrong */ +.highlight .gr { color: #E40000 } /* Generic.Error */ +.highlight .gh { color: #000080; font-weight: bold } /* Generic.Heading */ +.highlight .gi { color: #008400 } /* Generic.Inserted */ +.highlight .go { color: #717171 } /* Generic.Output */ +.highlight .gp { color: #000080; font-weight: bold } /* Generic.Prompt */ +.highlight .gs { font-weight: bold } /* Generic.Strong */ +.highlight .gu { color: #800080; font-weight: bold } /* Generic.Subheading */ +.highlight .gt { color: #04D } /* Generic.Traceback */ +.highlight .kc { color: #008000; font-weight: bold } /* Keyword.Constant */ +.highlight .kd { color: #008000; font-weight: bold } /* Keyword.Declaration */ +.highlight .kn { color: #008000; font-weight: bold } /* Keyword.Namespace */ +.highlight .kp { color: #008000 } /* Keyword.Pseudo */ +.highlight .kr { color: #008000; font-weight: bold } /* Keyword.Reserved */ +.highlight .kt { color: #B00040 } /* Keyword.Type */ +.highlight .m { color: #666 } /* Literal.Number */ +.highlight .s { color: #BA2121 } /* Literal.String */ +.highlight .na { color: #687822 } /* Name.Attribute */ +.highlight .nb { color: #008000 } /* Name.Builtin */ +.highlight .nc { color: #00F; font-weight: bold } /* Name.Class */ +.highlight .no { color: #800 } /* Name.Constant */ +.highlight .nd { color: #A2F } /* Name.Decorator */ +.highlight .ni { color: #717171; font-weight: bold } /* Name.Entity */ +.highlight .ne { color: #CB3F38; font-weight: bold } /* Name.Exception */ +.highlight .nf { color: #00F } /* Name.Function */ +.highlight .nl { color: #767600 } /* Name.Label */ +.highlight .nn { color: #00F; font-weight: bold } /* Name.Namespace */ +.highlight .nt { color: #008000; font-weight: bold } /* Name.Tag */ +.highlight .nv { color: #19177C } /* Name.Variable */ +.highlight .ow { color: #A2F; font-weight: bold } /* Operator.Word */ +.highlight .w { color: #BBB } /* Text.Whitespace */ +.highlight .mb { color: #666 } /* Literal.Number.Bin */ +.highlight .mf { color: #666 } /* Literal.Number.Float */ +.highlight .mh { color: #666 } /* Literal.Number.Hex */ +.highlight .mi { color: #666 } /* Literal.Number.Integer */ +.highlight .mo { color: #666 } /* Literal.Number.Oct */ +.highlight .sa { color: #BA2121 } /* Literal.String.Affix */ +.highlight .sb { color: #BA2121 } /* Literal.String.Backtick */ +.highlight .sc { color: #BA2121 } /* Literal.String.Char */ +.highlight .dl { color: #BA2121 } /* Literal.String.Delimiter */ +.highlight .sd { color: #BA2121; font-style: italic } /* Literal.String.Doc */ +.highlight .s2 { color: #BA2121 } /* Literal.String.Double */ +.highlight .se { color: #AA5D1F; font-weight: bold } /* Literal.String.Escape */ +.highlight .sh { color: #BA2121 } /* Literal.String.Heredoc */ +.highlight .si { color: #A45A77; font-weight: bold } /* Literal.String.Interpol */ +.highlight .sx { color: #008000 } /* Literal.String.Other */ +.highlight .sr { color: #A45A77 } /* Literal.String.Regex */ +.highlight .s1 { color: #BA2121 } /* Literal.String.Single */ +.highlight .ss { color: #19177C } /* Literal.String.Symbol */ +.highlight .bp { color: #008000 } /* Name.Builtin.Pseudo */ +.highlight .fm { color: #00F } /* Name.Function.Magic */ +.highlight .vc { color: #19177C } /* Name.Variable.Class */ +.highlight .vg { color: #19177C } /* Name.Variable.Global */ +.highlight .vi { color: #19177C } /* Name.Variable.Instance */ +.highlight .vm { color: #19177C } /* Name.Variable.Magic */ +.highlight .il { color: #666 } /* Literal.Number.Integer.Long */ \ No newline at end of file diff --git a/previews/271/zh_CN/_static/rauc-kirkstone.pdf b/previews/271/zh_CN/_static/rauc-kirkstone.pdf new file mode 100644 index 000000000..cc44393ac Binary files /dev/null and b/previews/271/zh_CN/_static/rauc-kirkstone.pdf differ diff --git a/previews/271/zh_CN/_static/rauc-mickledore.pdf b/previews/271/zh_CN/_static/rauc-mickledore.pdf new file mode 100644 index 000000000..f546e99c0 Binary files /dev/null and b/previews/271/zh_CN/_static/rauc-mickledore.pdf differ diff --git a/previews/271/zh_CN/_static/rauc-scarthgap.pdf b/previews/271/zh_CN/_static/rauc-scarthgap.pdf new file mode 100644 index 000000000..c286c0b7a Binary files /dev/null and b/previews/271/zh_CN/_static/rauc-scarthgap.pdf differ diff --git a/previews/271/zh_CN/_static/robots.txt b/previews/271/zh_CN/_static/robots.txt new file mode 100644 index 000000000..ea27bb96d --- /dev/null +++ b/previews/271/zh_CN/_static/robots.txt @@ -0,0 +1,3 @@ +User-agent: * + +Sitemap: https://phytec.github.io/doc-bsp-yocto/sitemap.xml diff --git a/previews/271/zh_CN/_static/scarthgap.pdf b/previews/271/zh_CN/_static/scarthgap.pdf new file mode 100644 index 000000000..9ac913e1c Binary files /dev/null and b/previews/271/zh_CN/_static/scarthgap.pdf differ diff --git a/previews/271/zh_CN/_static/searchtools.js b/previews/271/zh_CN/_static/searchtools.js new file mode 100644 index 000000000..2c774d17a --- /dev/null +++ b/previews/271/zh_CN/_static/searchtools.js @@ -0,0 +1,632 @@ +/* + * Sphinx JavaScript utilities for the full-text search. + */ +"use strict"; + +/** + * Simple result scoring code. + */ +if (typeof Scorer === "undefined") { + var Scorer = { + // Implement the following function to further tweak the score for each result + // The function takes a result array [docname, title, anchor, descr, score, filename] + // and returns the new score. + /* + score: result => { + const [docname, title, anchor, descr, score, filename, kind] = result + return score + }, + */ + + // query matches the full name of an object + objNameMatch: 11, + // or matches in the last dotted part of the object name + objPartialMatch: 6, + // Additive scores depending on the priority of the object + objPrio: { + 0: 15, // used to be importantResults + 1: 5, // used to be objectResults + 2: -5, // used to be unimportantResults + }, + // Used when the priority is not in the mapping. + objPrioDefault: 0, + + // query found in title + title: 15, + partialTitle: 7, + // query found in terms + term: 5, + partialTerm: 2, + }; +} + +// Global search result kind enum, used by themes to style search results. +class SearchResultKind { + static get index() { return "index"; } + static get object() { return "object"; } + static get text() { return "text"; } + static get title() { return "title"; } +} + +const _removeChildren = (element) => { + while (element && element.lastChild) element.removeChild(element.lastChild); +}; + +/** + * See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions#escaping + */ +const _escapeRegExp = (string) => + string.replace(/[.*+\-?^${}()|[\]\\]/g, "\\$&"); // $& means the whole matched string + +const _displayItem = (item, searchTerms, highlightTerms) => { + const docBuilder = DOCUMENTATION_OPTIONS.BUILDER; + const docFileSuffix = DOCUMENTATION_OPTIONS.FILE_SUFFIX; + const docLinkSuffix = DOCUMENTATION_OPTIONS.LINK_SUFFIX; + const showSearchSummary = DOCUMENTATION_OPTIONS.SHOW_SEARCH_SUMMARY; + const contentRoot = document.documentElement.dataset.content_root; + + const [docName, title, anchor, descr, score, _filename, kind] = item; + + let listItem = document.createElement("li"); + // Add a class representing the item's type: + // can be used by a theme's CSS selector for styling + // See SearchResultKind for the class names. + listItem.classList.add(`kind-${kind}`); + let requestUrl; + let linkUrl; + if (docBuilder === "dirhtml") { + // dirhtml builder + let dirname = docName + "/"; + if (dirname.match(/\/index\/$/)) + dirname = dirname.substring(0, dirname.length - 6); + else if (dirname === "index/") dirname = ""; + requestUrl = contentRoot + dirname; + linkUrl = requestUrl; + } else { + // normal html builders + requestUrl = contentRoot + docName + docFileSuffix; + linkUrl = docName + docLinkSuffix; + } + let linkEl = listItem.appendChild(document.createElement("a")); + linkEl.href = linkUrl + anchor; + linkEl.dataset.score = score; + linkEl.innerHTML = title; + if (descr) { + listItem.appendChild(document.createElement("span")).innerHTML = + " (" + descr + ")"; + // highlight search terms in the description + if (SPHINX_HIGHLIGHT_ENABLED) // set in sphinx_highlight.js + highlightTerms.forEach((term) => _highlightText(listItem, term, "highlighted")); + } + else if (showSearchSummary) + fetch(requestUrl) + .then((responseData) => responseData.text()) + .then((data) => { + if (data) + listItem.appendChild( + Search.makeSearchSummary(data, searchTerms, anchor) + ); + // highlight search terms in the summary + if (SPHINX_HIGHLIGHT_ENABLED) // set in sphinx_highlight.js + highlightTerms.forEach((term) => _highlightText(listItem, term, "highlighted")); + }); + Search.output.appendChild(listItem); +}; +const _finishSearch = (resultCount) => { + Search.stopPulse(); + Search.title.innerText = _("Search Results"); + if (!resultCount) + Search.status.innerText = Documentation.gettext( + "Your search did not match any documents. Please make sure that all words are spelled correctly and that you've selected enough categories." + ); + else + Search.status.innerText = Documentation.ngettext( + "Search finished, found one page matching the search query.", + "Search finished, found ${resultCount} pages matching the search query.", + resultCount, + ).replace('${resultCount}', resultCount); +}; +const _displayNextItem = ( + results, + resultCount, + searchTerms, + highlightTerms, +) => { + // results left, load the summary and display it + // this is intended to be dynamic (don't sub resultsCount) + if (results.length) { + _displayItem(results.pop(), searchTerms, highlightTerms); + setTimeout( + () => _displayNextItem(results, resultCount, searchTerms, highlightTerms), + 5 + ); + } + // search finished, update title and status message + else _finishSearch(resultCount); +}; +// Helper function used by query() to order search results. +// Each input is an array of [docname, title, anchor, descr, score, filename, kind]. +// Order the results by score (in opposite order of appearance, since the +// `_displayNextItem` function uses pop() to retrieve items) and then alphabetically. +const _orderResultsByScoreThenName = (a, b) => { + const leftScore = a[4]; + const rightScore = b[4]; + if (leftScore === rightScore) { + // same score: sort alphabetically + const leftTitle = a[1].toLowerCase(); + const rightTitle = b[1].toLowerCase(); + if (leftTitle === rightTitle) return 0; + return leftTitle > rightTitle ? -1 : 1; // inverted is intentional + } + return leftScore > rightScore ? 1 : -1; +}; + +/** + * Default splitQuery function. Can be overridden in ``sphinx.search`` with a + * custom function per language. + * + * The regular expression works by splitting the string on consecutive characters + * that are not Unicode letters, numbers, underscores, or emoji characters. + * This is the same as ``\W+`` in Python, preserving the surrogate pair area. + */ +if (typeof splitQuery === "undefined") { + var splitQuery = (query) => query + .split(/[^\p{Letter}\p{Number}_\p{Emoji_Presentation}]+/gu) + .filter(term => term) // remove remaining empty strings +} + +/** + * Search Module + */ +const Search = { + _index: null, + _queued_query: null, + _pulse_status: -1, + + htmlToText: (htmlString, anchor) => { + const htmlElement = new DOMParser().parseFromString(htmlString, 'text/html'); + for (const removalQuery of [".headerlink", "script", "style"]) { + htmlElement.querySelectorAll(removalQuery).forEach((el) => { el.remove() }); + } + if (anchor) { + const anchorContent = htmlElement.querySelector(`[role="main"] ${anchor}`); + if (anchorContent) return anchorContent.textContent; + + console.warn( + `Anchored content block not found. Sphinx search tries to obtain it via DOM query '[role=main] ${anchor}'. Check your theme or template.` + ); + } + + // if anchor not specified or not found, fall back to main content + const docContent = htmlElement.querySelector('[role="main"]'); + if (docContent) return docContent.textContent; + + console.warn( + "Content block not found. Sphinx search tries to obtain it via DOM query '[role=main]'. Check your theme or template." + ); + return ""; + }, + + init: () => { + const query = new URLSearchParams(window.location.search).get("q"); + document + .querySelectorAll('input[name="q"]') + .forEach((el) => (el.value = query)); + if (query) Search.performSearch(query); + }, + + loadIndex: (url) => + (document.body.appendChild(document.createElement("script")).src = url), + + setIndex: (index) => { + Search._index = index; + if (Search._queued_query !== null) { + const query = Search._queued_query; + Search._queued_query = null; + Search.query(query); + } + }, + + hasIndex: () => Search._index !== null, + + deferQuery: (query) => (Search._queued_query = query), + + stopPulse: () => (Search._pulse_status = -1), + + startPulse: () => { + if (Search._pulse_status >= 0) return; + + const pulse = () => { + Search._pulse_status = (Search._pulse_status + 1) % 4; + Search.dots.innerText = ".".repeat(Search._pulse_status); + if (Search._pulse_status >= 0) window.setTimeout(pulse, 500); + }; + pulse(); + }, + + /** + * perform a search for something (or wait until index is loaded) + */ + performSearch: (query) => { + // create the required interface elements + const searchText = document.createElement("h2"); + searchText.textContent = _("Searching"); + const searchSummary = document.createElement("p"); + searchSummary.classList.add("search-summary"); + searchSummary.innerText = ""; + const searchList = document.createElement("ul"); + searchList.setAttribute("role", "list"); + searchList.classList.add("search"); + + const out = document.getElementById("search-results"); + Search.title = out.appendChild(searchText); + Search.dots = Search.title.appendChild(document.createElement("span")); + Search.status = out.appendChild(searchSummary); + Search.output = out.appendChild(searchList); + + const searchProgress = document.getElementById("search-progress"); + // Some themes don't use the search progress node + if (searchProgress) { + searchProgress.innerText = _("Preparing search..."); + } + Search.startPulse(); + + // index already loaded, the browser was quick! + if (Search.hasIndex()) Search.query(query); + else Search.deferQuery(query); + }, + + _parseQuery: (query) => { + // stem the search terms and add them to the correct list + const stemmer = new Stemmer(); + const searchTerms = new Set(); + const excludedTerms = new Set(); + const highlightTerms = new Set(); + const objectTerms = new Set(splitQuery(query.toLowerCase().trim())); + splitQuery(query.trim()).forEach((queryTerm) => { + const queryTermLower = queryTerm.toLowerCase(); + + // maybe skip this "word" + // stopwords array is from language_data.js + if ( + stopwords.indexOf(queryTermLower) !== -1 || + queryTerm.match(/^\d+$/) + ) + return; + + // stem the word + let word = stemmer.stemWord(queryTermLower); + // select the correct list + if (word[0] === "-") excludedTerms.add(word.substr(1)); + else { + searchTerms.add(word); + highlightTerms.add(queryTermLower); + } + }); + + if (SPHINX_HIGHLIGHT_ENABLED) { // set in sphinx_highlight.js + localStorage.setItem("sphinx_highlight_terms", [...highlightTerms].join(" ")) + } + + // console.debug("SEARCH: searching for:"); + // console.info("required: ", [...searchTerms]); + // console.info("excluded: ", [...excludedTerms]); + + return [query, searchTerms, excludedTerms, highlightTerms, objectTerms]; + }, + + /** + * execute search (requires search index to be loaded) + */ + _performSearch: (query, searchTerms, excludedTerms, highlightTerms, objectTerms) => { + const filenames = Search._index.filenames; + const docNames = Search._index.docnames; + const titles = Search._index.titles; + const allTitles = Search._index.alltitles; + const indexEntries = Search._index.indexentries; + + // Collect multiple result groups to be sorted separately and then ordered. + // Each is an array of [docname, title, anchor, descr, score, filename, kind]. + const normalResults = []; + const nonMainIndexResults = []; + + _removeChildren(document.getElementById("search-progress")); + + const queryLower = query.toLowerCase().trim(); + for (const [title, foundTitles] of Object.entries(allTitles)) { + if (title.toLowerCase().trim().includes(queryLower) && (queryLower.length >= title.length/2)) { + for (const [file, id] of foundTitles) { + const score = Math.round(Scorer.title * queryLower.length / title.length); + const boost = titles[file] === title ? 1 : 0; // add a boost for document titles + normalResults.push([ + docNames[file], + titles[file] !== title ? `${titles[file]} > ${title}` : title, + id !== null ? "#" + id : "", + null, + score + boost, + filenames[file], + SearchResultKind.title, + ]); + } + } + } + + // search for explicit entries in index directives + for (const [entry, foundEntries] of Object.entries(indexEntries)) { + if (entry.includes(queryLower) && (queryLower.length >= entry.length/2)) { + for (const [file, id, isMain] of foundEntries) { + const score = Math.round(100 * queryLower.length / entry.length); + const result = [ + docNames[file], + titles[file], + id ? "#" + id : "", + null, + score, + filenames[file], + SearchResultKind.index, + ]; + if (isMain) { + normalResults.push(result); + } else { + nonMainIndexResults.push(result); + } + } + } + } + + // lookup as object + objectTerms.forEach((term) => + normalResults.push(...Search.performObjectSearch(term, objectTerms)) + ); + + // lookup as search terms in fulltext + normalResults.push(...Search.performTermsSearch(searchTerms, excludedTerms)); + + // let the scorer override scores with a custom scoring function + if (Scorer.score) { + normalResults.forEach((item) => (item[4] = Scorer.score(item))); + nonMainIndexResults.forEach((item) => (item[4] = Scorer.score(item))); + } + + // Sort each group of results by score and then alphabetically by name. + normalResults.sort(_orderResultsByScoreThenName); + nonMainIndexResults.sort(_orderResultsByScoreThenName); + + // Combine the result groups in (reverse) order. + // Non-main index entries are typically arbitrary cross-references, + // so display them after other results. + let results = [...nonMainIndexResults, ...normalResults]; + + // remove duplicate search results + // note the reversing of results, so that in the case of duplicates, the highest-scoring entry is kept + let seen = new Set(); + results = results.reverse().reduce((acc, result) => { + let resultStr = result.slice(0, 4).concat([result[5]]).map(v => String(v)).join(','); + if (!seen.has(resultStr)) { + acc.push(result); + seen.add(resultStr); + } + return acc; + }, []); + + return results.reverse(); + }, + + query: (query) => { + const [searchQuery, searchTerms, excludedTerms, highlightTerms, objectTerms] = Search._parseQuery(query); + const results = Search._performSearch(searchQuery, searchTerms, excludedTerms, highlightTerms, objectTerms); + + // for debugging + //Search.lastresults = results.slice(); // a copy + // console.info("search results:", Search.lastresults); + + // print the results + _displayNextItem(results, results.length, searchTerms, highlightTerms); + }, + + /** + * search for object names + */ + performObjectSearch: (object, objectTerms) => { + const filenames = Search._index.filenames; + const docNames = Search._index.docnames; + const objects = Search._index.objects; + const objNames = Search._index.objnames; + const titles = Search._index.titles; + + const results = []; + + const objectSearchCallback = (prefix, match) => { + const name = match[4] + const fullname = (prefix ? prefix + "." : "") + name; + const fullnameLower = fullname.toLowerCase(); + if (fullnameLower.indexOf(object) < 0) return; + + let score = 0; + const parts = fullnameLower.split("."); + + // check for different match types: exact matches of full name or + // "last name" (i.e. last dotted part) + if (fullnameLower === object || parts.slice(-1)[0] === object) + score += Scorer.objNameMatch; + else if (parts.slice(-1)[0].indexOf(object) > -1) + score += Scorer.objPartialMatch; // matches in last name + + const objName = objNames[match[1]][2]; + const title = titles[match[0]]; + + // If more than one term searched for, we require other words to be + // found in the name/title/description + const otherTerms = new Set(objectTerms); + otherTerms.delete(object); + if (otherTerms.size > 0) { + const haystack = `${prefix} ${name} ${objName} ${title}`.toLowerCase(); + if ( + [...otherTerms].some((otherTerm) => haystack.indexOf(otherTerm) < 0) + ) + return; + } + + let anchor = match[3]; + if (anchor === "") anchor = fullname; + else if (anchor === "-") anchor = objNames[match[1]][1] + "-" + fullname; + + const descr = objName + _(", in ") + title; + + // add custom score for some objects according to scorer + if (Scorer.objPrio.hasOwnProperty(match[2])) + score += Scorer.objPrio[match[2]]; + else score += Scorer.objPrioDefault; + + results.push([ + docNames[match[0]], + fullname, + "#" + anchor, + descr, + score, + filenames[match[0]], + SearchResultKind.object, + ]); + }; + Object.keys(objects).forEach((prefix) => + objects[prefix].forEach((array) => + objectSearchCallback(prefix, array) + ) + ); + return results; + }, + + /** + * search for full-text terms in the index + */ + performTermsSearch: (searchTerms, excludedTerms) => { + // prepare search + const terms = Search._index.terms; + const titleTerms = Search._index.titleterms; + const filenames = Search._index.filenames; + const docNames = Search._index.docnames; + const titles = Search._index.titles; + + const scoreMap = new Map(); + const fileMap = new Map(); + + // perform the search on the required terms + searchTerms.forEach((word) => { + const files = []; + const arr = [ + { files: terms[word], score: Scorer.term }, + { files: titleTerms[word], score: Scorer.title }, + ]; + // add support for partial matches + if (word.length > 2) { + const escapedWord = _escapeRegExp(word); + if (!terms.hasOwnProperty(word)) { + Object.keys(terms).forEach((term) => { + if (term.match(escapedWord)) + arr.push({ files: terms[term], score: Scorer.partialTerm }); + }); + } + if (!titleTerms.hasOwnProperty(word)) { + Object.keys(titleTerms).forEach((term) => { + if (term.match(escapedWord)) + arr.push({ files: titleTerms[term], score: Scorer.partialTitle }); + }); + } + } + + // no match but word was a required one + if (arr.every((record) => record.files === undefined)) return; + + // found search word in contents + arr.forEach((record) => { + if (record.files === undefined) return; + + let recordFiles = record.files; + if (recordFiles.length === undefined) recordFiles = [recordFiles]; + files.push(...recordFiles); + + // set score for the word in each file + recordFiles.forEach((file) => { + if (!scoreMap.has(file)) scoreMap.set(file, {}); + scoreMap.get(file)[word] = record.score; + }); + }); + + // create the mapping + files.forEach((file) => { + if (!fileMap.has(file)) fileMap.set(file, [word]); + else if (fileMap.get(file).indexOf(word) === -1) fileMap.get(file).push(word); + }); + }); + + // now check if the files don't contain excluded terms + const results = []; + for (const [file, wordList] of fileMap) { + // check if all requirements are matched + + // as search terms with length < 3 are discarded + const filteredTermCount = [...searchTerms].filter( + (term) => term.length > 2 + ).length; + if ( + wordList.length !== searchTerms.size && + wordList.length !== filteredTermCount + ) + continue; + + // ensure that none of the excluded terms is in the search result + if ( + [...excludedTerms].some( + (term) => + terms[term] === file || + titleTerms[term] === file || + (terms[term] || []).includes(file) || + (titleTerms[term] || []).includes(file) + ) + ) + break; + + // select one (max) score for the file. + const score = Math.max(...wordList.map((w) => scoreMap.get(file)[w])); + // add result to the result list + results.push([ + docNames[file], + titles[file], + "", + null, + score, + filenames[file], + SearchResultKind.text, + ]); + } + return results; + }, + + /** + * helper function to return a node containing the + * search summary for a given text. keywords is a list + * of stemmed words. + */ + makeSearchSummary: (htmlText, keywords, anchor) => { + const text = Search.htmlToText(htmlText, anchor); + if (text === "") return null; + + const textLower = text.toLowerCase(); + const actualStartPosition = [...keywords] + .map((k) => textLower.indexOf(k.toLowerCase())) + .filter((i) => i > -1) + .slice(-1)[0]; + const startWithContext = Math.max(actualStartPosition - 120, 0); + + const top = startWithContext === 0 ? "" : "..."; + const tail = startWithContext + 240 < text.length ? "..." : ""; + + let summary = document.createElement("p"); + summary.classList.add("context"); + summary.textContent = top + text.substr(startWithContext, 240).trim() + tail; + + return summary; + }, +}; + +_ready(Search.init); diff --git a/previews/271/zh_CN/_static/sphinx_highlight.js b/previews/271/zh_CN/_static/sphinx_highlight.js new file mode 100644 index 000000000..8a96c69a1 --- /dev/null +++ b/previews/271/zh_CN/_static/sphinx_highlight.js @@ -0,0 +1,154 @@ +/* Highlighting utilities for Sphinx HTML documentation. */ +"use strict"; + +const SPHINX_HIGHLIGHT_ENABLED = true + +/** + * highlight a given string on a node by wrapping it in + * span elements with the given class name. + */ +const _highlight = (node, addItems, text, className) => { + if (node.nodeType === Node.TEXT_NODE) { + const val = node.nodeValue; + const parent = node.parentNode; + const pos = val.toLowerCase().indexOf(text); + if ( + pos >= 0 && + !parent.classList.contains(className) && + !parent.classList.contains("nohighlight") + ) { + let span; + + const closestNode = parent.closest("body, svg, foreignObject"); + const isInSVG = closestNode && closestNode.matches("svg"); + if (isInSVG) { + span = document.createElementNS("http://www.w3.org/2000/svg", "tspan"); + } else { + span = document.createElement("span"); + span.classList.add(className); + } + + span.appendChild(document.createTextNode(val.substr(pos, text.length))); + const rest = document.createTextNode(val.substr(pos + text.length)); + parent.insertBefore( + span, + parent.insertBefore( + rest, + node.nextSibling + ) + ); + node.nodeValue = val.substr(0, pos); + /* There may be more occurrences of search term in this node. So call this + * function recursively on the remaining fragment. + */ + _highlight(rest, addItems, text, className); + + if (isInSVG) { + const rect = document.createElementNS( + "http://www.w3.org/2000/svg", + "rect" + ); + const bbox = parent.getBBox(); + rect.x.baseVal.value = bbox.x; + rect.y.baseVal.value = bbox.y; + rect.width.baseVal.value = bbox.width; + rect.height.baseVal.value = bbox.height; + rect.setAttribute("class", className); + addItems.push({ parent: parent, target: rect }); + } + } + } else if (node.matches && !node.matches("button, select, textarea")) { + node.childNodes.forEach((el) => _highlight(el, addItems, text, className)); + } +}; +const _highlightText = (thisNode, text, className) => { + let addItems = []; + _highlight(thisNode, addItems, text, className); + addItems.forEach((obj) => + obj.parent.insertAdjacentElement("beforebegin", obj.target) + ); +}; + +/** + * Small JavaScript module for the documentation. + */ +const SphinxHighlight = { + + /** + * highlight the search words provided in localstorage in the text + */ + highlightSearchWords: () => { + if (!SPHINX_HIGHLIGHT_ENABLED) return; // bail if no highlight + + // get and clear terms from localstorage + const url = new URL(window.location); + const highlight = + localStorage.getItem("sphinx_highlight_terms") + || url.searchParams.get("highlight") + || ""; + localStorage.removeItem("sphinx_highlight_terms") + url.searchParams.delete("highlight"); + window.history.replaceState({}, "", url); + + // get individual terms from highlight string + const terms = highlight.toLowerCase().split(/\s+/).filter(x => x); + if (terms.length === 0) return; // nothing to do + + // There should never be more than one element matching "div.body" + const divBody = document.querySelectorAll("div.body"); + const body = divBody.length ? divBody[0] : document.querySelector("body"); + window.setTimeout(() => { + terms.forEach((term) => _highlightText(body, term, "highlighted")); + }, 10); + + const searchBox = document.getElementById("searchbox"); + if (searchBox === null) return; + searchBox.appendChild( + document + .createRange() + .createContextualFragment( + '

' + + '' + + _("Hide Search Matches") + + "

" + ) + ); + }, + + /** + * helper function to hide the search marks again + */ + hideSearchWords: () => { + document + .querySelectorAll("#searchbox .highlight-link") + .forEach((el) => el.remove()); + document + .querySelectorAll("span.highlighted") + .forEach((el) => el.classList.remove("highlighted")); + localStorage.removeItem("sphinx_highlight_terms") + }, + + initEscapeListener: () => { + // only install a listener if it is really needed + if (!DOCUMENTATION_OPTIONS.ENABLE_SEARCH_SHORTCUTS) return; + + document.addEventListener("keydown", (event) => { + // bail for input elements + if (BLACKLISTED_KEY_CONTROL_ELEMENTS.has(document.activeElement.tagName)) return; + // bail with special keys + if (event.shiftKey || event.altKey || event.ctrlKey || event.metaKey) return; + if (DOCUMENTATION_OPTIONS.ENABLE_SEARCH_SHORTCUTS && (event.key === "Escape")) { + SphinxHighlight.hideSearchWords(); + event.preventDefault(); + } + }); + }, +}; + +_ready(() => { + /* Do not call highlightSearchWords() when we are on the search page. + * It will highlight words from the *previous* search query. + */ + if (typeof Search === "undefined") SphinxHighlight.highlightSearchWords(); + SphinxHighlight.initEscapeListener(); +}); diff --git a/previews/271/zh_CN/_static/translations.js b/previews/271/zh_CN/_static/translations.js new file mode 100644 index 000000000..59f9b0f55 --- /dev/null +++ b/previews/271/zh_CN/_static/translations.js @@ -0,0 +1,60 @@ +Documentation.addTranslations({ + "locale": "zh_Hans_CN", + "messages": { + "%(filename)s — %(docstitle)s": "%(filename)s — %(docstitle)s", + "© %(copyright_prefix)s %(copyright)s.": "© %(copyright_prefix)s %(copyright)s.", + ", in ": "\uff0c\u5728 ", + "About these documents": "\u5173\u4e8e\u6b64\u6587\u6863", + "Automatically generated list of changes in version %(version)s": "\u81ea\u52a8\u751f\u6210\u7684 %(version)s \u7248\u672c\u53d8\u66f4\u5217\u8868", + "C API changes": "C API \u7684\u53d8\u66f4", + "Changes in Version %(version)s — %(docstitle)s": "\u4e8e\u7248\u672c %(version)s— %(docstitle)s \u53d8\u66f4", + "Collapse sidebar": "\u6298\u53e0\u8fb9\u680f", + "Complete Table of Contents": "\u5b8c\u6574\u76ee\u5f55", + "Contents": "\u76ee\u5f55", + "Copyright": "\u7248\u6743\u6240\u6709", + "Created using Sphinx %(sphinx_version)s.": "\u7531 Sphinx %(sphinx_version)s\u521b\u5efa\u3002", + "Expand sidebar": "\u5c55\u5f00\u8fb9\u680f", + "Full index on one page": "\u5355\u9875\u5168\u7d22\u5f15", + "General Index": "\u603b\u7d22\u5f15", + "Global Module Index": "\u5168\u5c40\u6a21\u5757\u7d22\u5f15", + "Go": "\u63d0\u4ea4", + "Hide Search Matches": "\u9690\u85cf\u641c\u7d22\u7ed3\u679c", + "Index": "\u7d22\u5f15", + "Index – %(key)s": "\u7d22\u5f15 – %(key)s", + "Index pages by letter": "\u5b57\u6bcd\u7d22\u5f15", + "Indices and tables:": "\u7d22\u5f15\u548c\u8868\u683c\uff1a", + "Last updated on %(last_updated)s.": "\u6700\u540e\u66f4\u65b0\u4e8e %(last_updated)s.", + "Library changes": "\u5e93\u7684\u53d8\u66f4", + "Navigation": "\u5bfc\u822a", + "Next topic": "\u4e0b\u4e00\u4e3b\u9898", + "Other changes": "\u5176\u4ed6\u53d8\u66f4", + "Overview": "\u6982\u8ff0", + "Please activate JavaScript to enable the search\n functionality.": "\u8bf7\u6fc0\u6d3b JavaScript \u4ee5\u5f00\u542f\u641c\u7d22\u529f\u80fd\u3002", + "Preparing search...": "\u6b63\u5728\u51c6\u5907\u641c\u7d22\u2026\u2026", + "Previous topic": "\u4e0a\u4e00\u4e3b\u9898", + "Quick search": "\u5feb\u901f\u641c\u7d22", + "Search": "\u641c\u7d22", + "Search Page": "\u641c\u7d22\u9875\u9762", + "Search Results": "\u641c\u7d22\u7ed3\u679c", + "Search finished, found ${resultCount} page(s) matching the search query.": "\u641c\u7d22\u5b8c\u6210\uff0c\u5339\u914d\u5230 ${resultCount} \u9875\u3002", + "Search within %(docstitle)s": "\u5728 %(docstitle)s \u4e2d\u641c\u7d22", + "Searching": "\u6b63\u5728\u641c\u7d22\u4e2d", + "Searching for multiple words only shows matches that contain\n all words.": "\u5f53\u641c\u7d22\u591a\u4e2a\u5173\u952e\u8bcd\u65f6\uff0c\u53ea\u4f1a\u663e\u793a\u540c\u65f6\u5305\u542b\u6240\u6709\u5173\u952e\u8bcd\u7684\u5185\u5bb9\u3002", + "Show Source": "\u663e\u793a\u6e90\u4ee3\u7801", + "Table of Contents": "\u76ee\u5f55", + "This Page": "\u672c\u9875", + "Welcome! This is": "\u6b22\u8fce\uff01", + "Your search did not match any documents. Please make sure that all words are spelled correctly and that you've selected enough categories.": "\u60a8\u7684\u641c\u7d22\u6ca1\u6709\u5339\u914d\u5230\u6587\u6863\u3002\u8bf7\u786e\u4fdd\u5173\u952e\u8bcd\u62fc\u5199\u6b63\u786e\uff0c\u5e76\u4e14\u9009\u62e9\u4e86\u5408\u9002\u7684\u5206\u7c7b\u3002", + "all functions, classes, terms": "\u6240\u6709\u51fd\u6570\u3001\u7c7b\u3001\u672f\u8bed\u8bcd\u6c47", + "can be huge": "\u53ef\u80fd\u4f1a\u5927", + "last updated": "\u6700\u540e\u66f4\u65b0\u4e8e", + "lists all sections and subsections": "\u5217\u51fa\u6240\u6709\u7684\u7ae0\u8282\u548c\u90e8\u5206", + "next chapter": "\u4e0b\u4e00\u7ae0", + "previous chapter": "\u4e0a\u4e00\u7ae0", + "quick access to all modules": "\u5feb\u901f\u67e5\u770b\u6240\u6709\u7684\u6a21\u5757", + "search": "\u641c\u7d22", + "search this documentation": "\u641c\u7d22\u6587\u6863", + "the documentation for": "\u672c\u6587\u6863\u5c5e\u4e8e" + }, + "plural_expr": "0" +}); \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8.html b/previews/271/zh_CN/bsp/imx8/imx8.html new file mode 100644 index 000000000..01f0fe517 --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8.html @@ -0,0 +1,180 @@ + + + + + + + + + i.MX 8 手册 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+ +
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mm/head.html b/previews/271/zh_CN/bsp/imx8/imx8mm/head.html new file mode 100644 index 000000000..902b3656e --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mm/head.html @@ -0,0 +1,4021 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + + + + +

L-1002e.Ax i.MX 8M Mini BSP 手册模板

文档标题

L-1002e.Ax i.MX 8M Mini BSP 手册模板

文档类型

BSP 手册

型号

L-1002e.Ax

Yocto 手册

发布日期

XXXX/XX/XX

母文档

L-1002e.Ax i.MX 8M Mini BSP 手册模板

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP 发布日期

BSP 状态

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 phyCORE-i.MX8M Mini Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads 中找到。

+
+

1.1. 支持的硬件

+

支持配备 i.MX 8M Mini SoC 或 i.MX 8M Nano SoC 的 phyBOARD-Polis。

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-NXP-i.MX8MM-PD24.1.0 的所有Machine及其对应的Article Numbers(产品型号)： 网址. 如果您在该网页 Supported Machines 一节选择了特定的 Machine Name ，您可以查看被选中machine下的包含的 Article Number(产品型号) 以及简要的硬件描述。如果您只有 Article Number ，可以将 Machine Name 下拉菜单留空，仅选择您的 Article Number 。那么，它会显示您特定硬件所对应的 Machine Name

+
+

1.1.1. phyBOARD-Polis 器件

+ + + + + + +
+../../../_images/polis-front.jpg +
+

phyBOARD-Polis 器件（顶部）

+
+
+
+../../../_images/polis-back.jpg + +
+

phyBOARD-Polis 器件（底部）

+
+
+
+
+
+
+
+

2. 开始使用

+

该 phyCORE-i.MX8M Mini Kit 包含预先烧写好的SD卡。它包含 phytec-qt6demo-image 镜像，可以直接用作启动盘。默认情况下，核心板上的eMMC仅烧写了U-Boot。您可以从 PHYTEC下载服务器 获取所有镜像资源。本章将解释如何将BSP镜像烧写到SD卡以及如何启动开发板。

+

有几种方法可以将镜像写入SD卡或eMMC。最为人熟知的方式是使用Linux命令行工具 dd 进行简单的顺序写入。另一种方法是使用PHYTEC的自研程序 partup ，它可以让格式化复杂系统的过程变得简单。您可以从其发布页面获取 预编译的Linux partup 二进制文件 。请阅读 partup的readme文件 来获取安装指导。

+
+

2.1. 下载镜像

+

phytec-qt6demo-image 镜像包含完整系统所需的所有必要文件，您需确保镜像中各个分区以及裸数据都会被正确写入启动盘。可以从 PHYTEC 下载服务器 下载 partup 镜像文件或者是可以使用 dd 进行烧写的 WIC 镜像。

+

从下载服务器获取 partup 镜像文件或WIC镜像：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt6demo-image-phyboard-polis-imx8mm-5.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+
+
+
+

备注

+

针对eMMC，我们建议使用partup去烧写比较大的或者是有复杂分区配置的镜像，因为它在写入速度上比 dd 更快，并且可以对闪存设备进行更灵活的配置。

+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要创建SD卡启动盘，必须要拥有Linux PC上的root权限。在选择烧写设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+
+

2.2.1. 寻找正确的设备

+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行命令：

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+

卸载所有这些分区，例如：

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

现在，SD卡已经准备好可以使用 partup 、 dd 或 bmap-tools 来写入镜像。

+
+
+

2.2.2. 使用bmap-tools

+

烧写SD卡的其中一种方法是使用 bmap-tools 。Yocto会自动为WIC镜像创建一个block map文件（ <IMAGENAME>-<MACHINE>.wic.bmap ），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host:~$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-polis-imx8mm-5?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

将 <your_device> 替换为您之前找到的SD卡设备名称，并确保将文件 <IMAGENAME>-<MACHINE>.wic.bmap 与WIC镜像文件放在一起，以便bmaptool知道哪些块需要写入，哪些块需要跳过。

+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.2.3. 使用partup

+

使用partup烧写SD卡只需一个命令：

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-polis-imx8mm-5?(.rootfs).partup /dev/<your_device>
+
+
+

确保将 <your_device> 替换为您之前找到的设备名称。

+

关于partup的进一步使用说明，请参阅其 官方文档 。

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 release notes 。

+
+
+

备注

+

partup 具有清除eMMC user区域中特定区域的功能，我们提供的partup程序中用该功能擦除U-Boot环境变量。这是 bmaptool 工具所无法完成的一点，如前一部分所提到的。

+

partup相较于其他烧写工具的一个主要优势是，它可以配置MMC的特定部分，比如他可以直接写入eMMCboot分区，无需调用其他命令。

+
+
+
+

2.2.4. 使用 dd

+

在卸载所有SD卡的挂载分区后，您可以烧写SD卡。

+

一些PHYTEC BSP会生成未压缩的镜像（文件名扩展名为*.wic），而另一些则生成压缩的镜像（文件名扩展名为*.wic.xz）。

+

要写入未压缩的镜像（*.wic），请使用以下命令：

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-polis-imx8mm-5?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

或者要写入压缩后的镜像（*.wic.xz），请使用以下命令：

+
host:~$ xzcat phytec-qt6demo-image-phyboard-polis-imx8mm-5?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

再次确保将 <your_device> 替换为之前找到的设备名称。

+

参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

+
+
+
+

2.3. 首次启动

+ + + + + + + +
启动模式选择
+../../../_images/SD_Card_Boot.jpg +
+

Mini

+
+
+
+
    +

  • 插入SD卡

    • +

  • 使用 micro USB 线将开发板的 (X30) 调试USB口和主机连接起来

    • +

  • 给开发板通电

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 8M Mini BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (scarthgap).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (scarthgap).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-IMX8MM ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-vendor MACHINE=phyboard-polis-imx8mm-5 ./phyLinux init -p imx8mm -r BSP-Yocto-NXP-i.MX8MM-PD24.1.0
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 phyboard-polis-imx8mm-5 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx8mm.bin: ARM可信固件二进制文件

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY固件镜像

    • +

  • imx-boot：由imx-mkimage编译的bootloader镜像，包括SPL、U-Boot、ARM可信固件和DDR固件。这是最终的可引导bootloader镜像。

    • +

  • fitImage: Linux内核FIT镜像

    • +

  • fitImage-its*.its: FIT image configuration file

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx8mm-phyboard-polis-rdk*.dtb：内核设备树文件

    • +

  • imx8mm-phy*.dtbo: 内核设备树overlay文件

    • +

  • phytec-qt6demo-image*.tar.gz: 根文件系统

    • +

  • phytec-qt6demo-image*.rootfs.wic.xz: SD卡镜像

    • +
+
+
+
+
+

4. 安装操作系统

+
+

4.1. 启动模式开关 (S1)

+

该 phyBOARD-Polis 具有一个启动配置开关，带有六个可单独切换的开关，用于选择 phyCORE-i.MX 8M Mini 的默认启动源。

+
+

4.1.1. Mini

+ + + + + + + + + + +
启动模式选择
+../../../_images/eMMC.jpg +
+

eMMC（核心板的默认启动方式）

+
+
+
+../../../_images/SPI_NOR1.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download2.png +
+

USB

+
+
+
+../../../_images/SD_Card_Boot.jpg +
+

SD卡

+
+
+
+ + + + + + + +
切换UART1的RS485和RS232模式
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+
+
+

4.2. 烧写eMMC

+

为了保持文档的一致性和简洁性，假设已经配置好了TFTP服务器；所有生成的镜像（如上所列）都被复制到默认的/srv/tftp目录。如果您没有进行设置，您需要修改路径到包含镜像的目录。有关如何设置TFTP服务器和目录的说明，请参见 Setup Network Host 。

+

要从 eMMC 启动，请确保 BSP 镜像已正确烧写到 eMMC，并且 bootmode switch (S1) 设置为 eMMC。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行上述命令来检查系统启动在这种条件下是否会到影响。如果 mmcblk2p1 和 mmcblk1p1 具有相同的UUID，则会影响系统正确启动。

+
+
+

4.2.1. 从网络烧写 eMMC

+

i.MX 8M Mini 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

4.2.1.1. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

查看主机上可用的镜像文件：

+
host:~$ ls /srv/tftp
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.bmap
+
+
+

通过网络ssh协议使用 bmaptool 命令将镜像发送到开发板的eMMC：

+
host:~$ scp /srv/tftp/phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.xz /dev/mmcblk2"
+
+
+
+
+

4.2.1.2. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

使用以下命令，通过网络将压缩或未压缩的镜像和配套的 *.bmap 文件传送到核心板并写入 eMMC：

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.* /tmp && bmaptool copy /tmp/phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.xz /dev/mmcblk2
+
+
+
+
+

4.2.1.3. 在开发板的U-Boot中通过网络烧写eMMC

+

这些步骤将展示如何通过网络更新eMMC。

+
+

小技巧

+

此步骤仅在镜像文件小于1GB的情况下会被执行成功，因为在启用OPTEE后，Bootloader中可用的RAM大小有限，不足以加载超过1GB的镜像

+
+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

解压缩您的镜像

+
host:~$ unxz /srv/tftp/phytec-headless-image-phyboard-polis-imx8mm-5.rootfs.wic.xz
+
+
+

通过网络将您的镜像加载到内存中：

+
    +

  • 使用DHCP

    +
    u-boot=> dhcp phytec-headless-image-phyboard-polis-imx8mm-5.rootfs.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.1 (1 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.1
+Filename 'phytec-headless-image-phyboard-polis-imx8mm-5.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • 使用静态IP地址（必须先设置serverip和ipaddr）。

    +
    u-boot=> tftp ${loadaddr} phytec-headless-image-phyboard-polis-imx8mm-5.rootfs.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-phyboard-polis-imx8mm-5.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
+
+
+
+
+

4.2.2. 在运行的U-Boot中通过网络烧写eMMC U-Boot镜像

+

可以在U-Boot中更新U-Boot镜像imx-boot，eMMC上的U-Boot需要位于eMMC的user区域。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x42 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.3. 从USB大容量存储设备烧写eMMC

+
+

4.2.3.1. 在运行的Linux系统中从USB烧写eMMC

+

下面这些步骤展示如何在Linux系统上使用USB大容量存储设备烧写eMMC。您需要一个保存了完整镜像的U盘和一个可从SD卡启动的核心板。（例如： phytec-qt6demo-image-phyboard-polis-imx8mm-5.|yocto-imageext| ）。将 bootmode switch (S1) 设置为SD卡。

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ ls /mnt
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.bmap
+
    +
    +
    • +

  • 将镜像写入 phyCORE-i.MX 8M Mini eMMC（无分区的 MMC 设备 2）：

    +
    target:~$ bmaptool copy /mnt/phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.xz /dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    小技巧

    +

    在此之前，您需要将 bootmode switch (S1) 配置为 eMMC。

    +
    +
    • +
+
+
+

4.2.3.2. 在开发板上通过U-Boot从USB烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件小于1GB的情况下会被执行成功，因为在启用OPTEE后，Bootloader中可用的RAM大小有限，不足以加载超过1GB的镜像

+
+

下面这些步骤展示如何通过USB设备更新eMMC。将 bootmode switch (S1) 配置为SD卡并插入SD卡。给开发板上电并进入U-Boot环境。将已存储了未压缩WIC镜像的优盘插入开发板USB接口。

+

将镜像从USB设备加载到RAM中：

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 0x58000000 phytec-headless-image-|yocto-machinename|.rootfs.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write 0x58000000 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+
+

4.2.4. 从SD卡烧写eMMC

+

即使没有可用的网络，您也可以更新eMMC。为此，您需要一个位于SD卡上的镜像文件（ *.wic ）。由于镜像文件相当大，您需要在SD卡创建第三个分区。要创建新分区或扩展您的SD卡，请参见 Resizing ext4 Root Filesystem 。

+

或者，使用partup包烧写SD卡，如 Getting Started 中所述。这样就可使用SD卡的全部容量。

+
+

4.2.4.1. 在开发板的linux环境中通过SD卡烧写eMMC

+

您也可以在Linux系统中烧写eMMC。您只需要一个partup包或保存在SD卡上的WIC镜像。

+
    +

  • 检查在SD卡上保存的partup包或WIC镜像文件：

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.partup
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.bmap
+
    +
    +
    • +

  • 使用 partup 将镜像写入 phyCORE-i.MX 8M Mini 的 eMMC（MMC 设备 2 不带 分区字样）：

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.partup /dev/mmcblk2
+
    +
    +

    使用partup烧写的优点是可以充分利用eMMC设备的全部容量，会相应自动调整分区大小。

    +
    +

    备注

    +

    另外，也可以使用 bmaptool 工具：

    +
    target:~$ bmaptool copy phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic.xz /dev/mmcblk2
+
    +
    +

    请注意，在使用 bmaptool 烧写时，根文件系统分区并不会使用eMMC的最大容量。

    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    警告

    +

    在此之前，您需要将 bootmode switch (S1) 配置为 eMMC。

    +
    +
    • +
+
+
+

4.2.4.2. 在开发板的uboot环境中通过SD卡烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1GB的情况下有效，因为在启用OPTEE后，Bootloader中可用的RAM大小有限。如果镜像文件过大，请阅读 在开发板上通过SD卡更新eMMC 一节

+
+
    +

  • 将一个可用的镜像烧写到SD卡，并创建一个EXT4格式的第三分区。将WIC镜像（例如 phytec-qt6demo-image.rootfs.wic）复制到该分区。

    • +

  • 将 bootmode switch (S1) 配置为 SD 卡并插入 SD 卡。

    • +

  • 打开电源并进入U-Boot。

    • +

  • 加载镜像：

    +
    u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-phyboard-polis-imx8mm-5.rootfs.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • 将当前mmc设备切换到eMMC：

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • 将您的WIC镜像（例如 phytec-qt6demo-image.rootfs.wic）从SD卡烧写到eMMC。这将对emmc进行分区，并将imx-boot、Image、dtb、dtbo和根文件系统复制到eMMC。

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • 关闭电源并将 bootmode switch (S1) 更改为 eMMC。

    • +
+
+
+
+
+

4.3. 烧写 SPI NOR Flash

+

phyCORE-i.MX8MM 模块可选配SPI NOR Flash。要从SPI Flash启动，请将 bootmode switch (S1) 设置为 SPI NOR 。SPI Flash通常比较小。phyBOARD-Pollux-i.MX8MP开发套件仅配备32MB的SPI NOR Flash。只能存储bootloader及其环境变量。默认情况下，内核、设备树和文件系统会从eMMC加载。

+

SPI NOR Flash分区表在U-Boot环境变量中定义。可以通过以下命令打印：

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. 通过网络烧写SPI NOR Flash

+

SPI NOR可以包含bootloader及其环境变量。arm64的linux内核无法自行解压缩，内核镜像大小超出了phyCORE-i.MX 8M Mini 上的SPI NOR Flash的容量。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+
+

4.3.1.1. 在开发板linux环境中通过网络烧写SPI NOR Flash

+
    +

  • 将镜像从主机复制到开发板：

    +
    host:~$ scp imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • 查找要擦除的U-boot分区的块数：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除U-Boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.1.2. 在开发板的U-Boot环境中通过网络烧写SPI NOR

+

类似于通过网络更新eMMC，请确保正确设置主机PC。IP地址需要设置为192.168.3.10，子网掩码设置为255.255.255.0，并且需要有一个可用的TFTP服务。在进行读写之前，需要对SPI NOR Flash进行枚举：

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像。确保您使用了正确的镜像文件。通过tftp加载镜像，然后将bootloader写入Flash：

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+

4.3.2. 从SD卡烧写SPI NOR Flash

+

SPI NOR Flash上的bootloader也可以通过SD卡进行烧写。

+
+

4.3.2.1. 在开发板的linux环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi复制到SD卡的第一个分区。

    • +

  • 挂载SD卡：

    +
    target:~$ mount /dev/mmcblk1p1 /mnt
+
    +
    +
    • +

  • 查找要擦除的U-Boot分区的块数：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除u-boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.2.2. 在开发板的U-Boot环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi复制到SD卡的第一个分区。

    • +

  • 在进行读写操作之前，需要对SPI-NOR Flash进行枚举：

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像，请确保使用正确的镜像文件。从SD卡加载镜像，擦除并将bootloader写入flash：

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC： L-1006e.A6 RAUC Update & Device Management Manual 。

+
+
+

4.5. EFI Boot

+

Standardboot in U-Boot also supports booting distros over efi. By default the +U-Boot will search for a bootscript first, which is used to boot our Ampliphy +distro. If it does not find any bootscript, it will search for bootable efi +applications. So for booting over efi just make sure you don't have our distro +installed.

+
+

4.5.1. Disable booting with efi

+

To disable booting with efi you have to set the doefiboot variable to 0. +Also make sure you do not have efi or efi_mgr specified in the +bootmeths environment variable.

+
u-boot=> setenv doefiboot 0
+u-boot=> env save; env save;
+
+
+
+
+

4.5.2. Switch to only efi boot

+

If you want to only boot with efi, you can set the bootmeths environment +variable to efi. Also make sure you have the doefiboot environment variable +set to 1.

+
u-boot=> setenv bootmeths efi
+u-boot=> env save; env save;
+
+
+
+
+

4.5.3. Installing a distro

+

With efi you can install and boot different distros like openSUSE, Fedora or +Debian. First you have to get the iso Image from their website. For example:

+

https://cdimage.debian.org/debian-cd/current/arm64/iso-dvd/

+

Then copy the .iso file to a usb stick for example. Make sure you select the +correct device:

+
sudo dd if=file.iso of=/dev/sdx bs=1M conv=fsync status=progress
+
+
+

Insert the USB stick into the board and boot it. GRUB will then prompt you with +a menu where you can select what to do. Here select install. Then you have to +click through the installation menu. This is relatively straightforward and +differs a bit for every distro. You can install the distro for example to emmc +(mmc 2) or sdcard (mmc 1). Make sure you do not overwrite +your U-Boot during the install. Best to choose a different medium to install to +than the U-Boot is stored on. Otherwise manual partitioning will be required. +The automatic partitioning will start at the beginning of the disk. To not +overwrite the U-Boot, use an offset of 4MiB at the beginning of the disk.

+

During the Installation of Debian you will be asked, if you want to Force the +GRUB installation to the EFI removable media path. Select no. Also select no, +when you will be asked if you want to update the NVRAM variables. Otherwise the +grub-dummy installation step will fail and you will be sent back to the +"Force GRUB installation" prompt.

+

After the installation is complete, reboot the board and remove the +installation medium (USB-stick). The board should then boot the distro you +installed.

+

If that does not happen, check if there is a boot option set for the distro. +The easiest way is with the eficonfig command.

+
u-boot=> eficonfig
+
+
+

That will open a menu. Then you can select Edit Boot Option. It will show +you the current boot options. If this is empty or you don't find your distro, +select Add Boot Option to add a new one. For debian for example you only +need to set the description and the file. You can enter whatever you want into +the description field. When you select the file field, you can select the disc +you installed the distro on and partition number one. For example +"mmc 2:1" for emmc, or "mmc 1:1" for sdcard. The file you +need to select is at EFI/debian/grubaa64.efi. After that save, quit and +reset the board. The board should then boot into debian.

+
+
+
+
+

5. 开发

+

从这个版本开始，U-Boot中的启动行为发生了变化。之前，内核和设备树是作为单独的二进制文件提供的。现在，二者将被包含在一个单一的FIT镜像二进制文件中。此外，PHYTEC ampliphy发行版的启动逻辑被移到了一个启动脚本中，该脚本本身是一个单独的FIT镜像二进制文件的一部分。要恢复到旧的启动方式，您可以执行

+
u-boot=> run legacyboot
+
+
+
+

备注

+

这种启动方式已被弃用，并将在下一个版本中移除。默认情况下，通过此命令启动将返回错误，因为启动分区中缺少内核和设备树。

+
+
+

5.1. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone git://git.phytec.de/u-boot-imx）

+
+
+

5.1.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-imx 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    https://github.com/phytec/linux-phytec-imx
+
    +
    +
    • +

  • 我们的 i.MX 8M Mini 内核是基于 linux-phytec-imx 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.1.2. 获取SDK

+

您可以在此处下载SDK 这里，或者使用Yocto去编译生成SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

在成功编译后，SDK安装包保存在 build/deploy*/sdk。

+
+
+

5.1.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-vendor-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.x.sh
+host:~$ ./phytec-ampliphy-vendor-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.x.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor/5.0.x):
+You are about to install the SDK to "/opt/ampliphy-vendor/5.0.x". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.1.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-vendor/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.1.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.2. 单独编译U-Boot

+
+

5.2.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本中使用的**tag**称为 v2022.04_2.2.2-phy5

    • +

  • 查看所需的 U-Boot tag：

    +
    host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2022.04_2.2.2-phy5
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.2.2. 获取所需的二进制文件

+

要编译bootloader，您需要将这些文件复制到您的 u-boot-imx 编译目录，并将其重命名以适应 mkimage 脚本：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx8mm.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以在yocto工程目录中获取 bl31-imx8mm.bin、tee.bin和lpddr4_*.bin：BSP Images

+

或者你可以在这里下载文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/imx-boot-tools/

+
+

警告

+

确保您重命名所需的文件，以和 mkimage tool 兼容。

+
+
+
+

5.2.3. 编译bootloader

+
    +

  • 编译 flash.bin (imx-boot):

    +
    host:~/u-boot-imx$ make phycore-imx8mm_defconfig
+host:~/u-boot-imx$ make flash.bin
+
    +
    +
    • +
+
+
+

5.2.4. 将bootloader烧写到块设备上

+

flash.bin 文件可以在 u-boot-imx/ 目录下找到，现在可以进行烧写。需要指定芯片特定的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 8M Mini

33 kiB

33 kiB

/dev/mmcblk2

+

例如，烧写SD卡：

+
host:~/u-boot-imx$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=33 conv=sync
+
+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+

5.2.5. 使用固定内存大小编译U-Boot

+

如果您的系统因为EEPROM中的硬件信息损坏或丢失而无法启动，您可以创建一个具有固定RAM大小的flash.bin。但您仍应联系我们支持部门以烧写正确的EEPROM数据。

+

按照步骤获取U-boot源代码，并切换到 Build U-Boot 章节说明的分支。

+

Edit the file configs/phycore-imx8mm_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MM=y
+CONFIG_PHYCORE_IMX8MM_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_4GB=y
+
+
+

选择正确的RAM大小，确保与核心板上的贴装的器件一致，取消注释该RAM大小的行。保存更改后，按照 Build U-Boot 章节的剩余步骤进行操作。

+
+
+
+

5.3. 单独编译内核

+

内核与设备树一起打包在FIT镜像中。U-Boot已被配置为能够加载FIT镜像并引导其中包含的内核。因此，内核镜像必须打包在FIT镜像中。

+
+

5.3.1. 配置源代码

+
    +

  • 使用的 linux-phytec-imx 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v5.15.71_2.2.2-phy3

    • +

  • Check out 所需的 linux-phytec-imx 标签：

    +
    host:~$ git clone https://github.com/phytec/linux-phytec-imx
+host:~$ cd ~/linux-phytec-imx/
+host:~/linux-phytec-imx$ git fetch --all --tags
+host:~/linux-phytec-imx$ git checkout tags/v5.15.71_2.2.2-phy3
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-phytec-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-phytec-imx$ source /opt/ampliphy-vendor/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.3.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-phytec-imx$ make imx8_phytec_defconfig
+host:~/linux-phytec-imx$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-phytec-imx/arch/arm64/boot/Image.gz 找到

    • +

  • dtb文件可以在 ~/linux-phytec-imx/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-phytec-imx$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.3.3. 将内核打包成FIT镜像

+

要简单地替换内核，您需要一个 image tree source (.its)文件。如果您已经使用Yocto编译了我们的BSP，可以从此处提到的目录获取its文件： BSP Images 或者您可以在这里下载该文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/

+

将 .its 文件复制到当前工作目录，创建一个指向内核镜像的链接，并使用 mkimage 创建最终的 fitImage。

+
host:~/linux-phytec-imx$ cp /path/to/yocto/deploydir/fitimage-its*.its .
+                  && ln -s arch/arm64/boot/Image.gz linux.bin
+                  && uboot-mkimage -f fitImage-its*.its fitImage
+
+
+
+
+

5.3.4. 将FIT镜像和内核模块复制到SD卡

+

FIT镜像以及内核module可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-phytec-imx$ cp fitImage /path/to/sdcard/boot/
+host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.4. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.4.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.4.2. 获取镜像

+

从我们的服务器下载imx-boot，或者从您Yocto工程中的build/deploy-ampliphy-vendor/images/phyboard-polis-imx8mm-5/路径获取。要将wic镜像烧写到eMMC，你还需要 phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic。

+
+
+

5.4.3. 开发板准备

+

将 bootmode switch (S1) 设置为 USB串行下载。同时，将 USB 端口 X2 连接到主机。

+
+
+

5.4.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 (X30) 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.4.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.4.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.wic
+
+
+
+
+

5.4.7. 通过UUU工具烧写SPI NOR Flash

+

执行并给开发板上电：

+
host:~$ sudo uuu -b qspi imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi
+
+
+

这将更新SPI NOR Flash上的U-Boot，但不会更新环境。您可能需要擦除旧环境，以便加载新U-Boot的默认环境：

+
u-boot=> env erase
+u-boot=> reset
+
+
+
+
+
+

5.5. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.5.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.5.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.5.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.6. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.6.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核fitimage复制到您的tftp目录中：

    +
    host:~$ cp fitImage /srv/tftp
+
    +
    +
    • +

  • 将启动脚本复制到您的tftp目录中：

    +
    host:~$ cp boot.scr.uimg /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-polis-imx8mm-5.rootfs.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.6.2. 设置网络启动的bootenv.txt文件

+

在您的tftp目录中创建一个bootenv.txt文件，并将以下变量写入其中。

+
nfsroot=/srv/nfs
+overlays=<overlayconfignames>
+
+
+

<overlayconfignames> 替换为您想要使用的设备树overlay配置名称。用#号分隔配置名称。例如：

+
overlays=conf-example-overlay1.dtbo#conf-example-overlay2.dtbo
+
+
+
+

小技巧

+

所有支持的设备树overlay文件都在 device tree 章节中。或者可以通过以下命令打印：

+
host:~$ dumpimage -l fitImage
+
+
+
+
+
+

5.6.3. 开发板上的网络设置

+

如果要自定义开发板上的以太网配置，请按照此处的说明进行操作： Network Environment Customization

+
+
+

5.6.4. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> setenv boot_targets ethernet
+u-boot=> bootflow scan -lb
+
    +
    +
    • +
+
+
+
+

5.7. 获取BSP开发中版本

+
+

5.7.1. 当前release的开发中版本

+

这些release manifest文件是为了让您访问 Yocto BSP的开发版本。它们不会在phyLinux选择菜单中显示，需要手动选择。可以使用以下命令行来完成此操作：

+
host:~$ ./phyLinux init -p imx8mm -r BSP-Yocto-NXP-i.MX8MM-PD24.1.y
+
+
+

这将初始化一个BSP，用于跟踪当前版本（ BSP-Yocto-NXP-i.MX8MM-PD24.1.0 ）的最新开发版本。从现在开始，在此文件夹中执行 repo sync 将从我们的Git仓库中拉取所有最新的更改：

+
host:~$ repo sync
+
+
+
+
+

5.7.2. 即将发布版本的开发中版本

+

即将发布版本的开发中版本可以通过这种方式访问。请执行以下命令，并查找一个比最新版本（ BSP-Yocto-NXP-i.MX8MM-PD24.1.0 ）的PDXX.Y数字更高的版本，并且以 .y 结尾：

+
host:~$ ./phyLinux init -p imx8mm
+
+
+
+
+
+

5.8. 获取最新的Upstream支持

+

我们有一个使用Yocto主分支（不是NXP发布的）的manifest，他使用upstream的Linux和U-Boot。这可以用来测试最新的upstream kernel/U-Boot。

+
+

备注

+

master分支的manifest反映了最新的开发状态。有时会出现一些bug。我们会定期修复master分支。

+
+
host:~$ ./phyLinux init -p imx8mm -r BSP-Yocto-Ampliphy-i.MX8MM-master
+
+
+
+
+

5.9. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.9.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将 phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将 phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic 镜像复制到其中。然后卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+

5.10. Switch back to legacyboot

+
+

警告

+

As we switched to standardboot with fitimage as default, legacyboot is +deprecated. We kept the option to switch back to legacyboot for this +release, but it will be removed in the future.

+
+
+

5.10.1. Changes in Yocto

+

By default, the fitImage and bootscript will be deployed into the wic.xz Image. +To switch back to legacyboot, you need to replace the fitImage and bootscript +for the kernel image and the devicetrees. They are still in the deploy +folder from the Yocto build, so you can manually copy them to the boot +partition on your device. Otherwise you can do the following changes in Yocto +to get the kernel and devicetrees deployed in the Image again.

+

First create the variable KERNEL_DEVICETREE_DEPLOY. This can be done for +example in the local.conf file in your build directory conf/local.conf. +The variable is basically a copy of the KERNEL_DEVICETREE variable that is +set in conf/machine/phyboard-polis-imx8mm-5.conf in meta-phytec but the freescale +at the beginning needs to be removed, so that only the devicetree filename are +left. In the end it should look something like this:

+
KERNEL_DEVICETREE_DEPLOY = " \
+     imx8mp-phyboard-pollux-rdk.dtb \
+     imx8mp-phyboard-pollux-isp-csi1.dtbo \
+     imx8mp-phyboard-pollux-isp-csi2.dtbo \
+     imx8mp-phyboard-pollux-isi-csi1.dtbo \
+     imx8mp-phyboard-pollux-isi-csi2.dtbo \
+     imx8mp-phyboard-pollux-peb-av-10.dtbo \
+     imx8mp-phyboard-pollux-peb-wlbt-05.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2-fpdlink-port1.dtbo \
+     imx8mp-phycore-no-eth.dtbo \
+     imx8mp-phycore-no-rtc.dtbo \
+     imx8mp-phycore-no-spiflash.dtbo \
+     imx8mp-phycore-rpmsg.dtbo \
+"
+
+
+

Then add this line:

+
IMAGE_BOOT_FILES:mx8m-nxp-bsp:append = " Image oftree ${KERNEL_DEVICETREE_DEPLOY}"
+
+
+
+

备注

+

A clean might be required for this to work.

+
bitbake -c cleanall phytec-qt6demo-image
+
+
+
+

Then start the build:

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

5.10.2. Changes in U-Boot environment

+

To re-enable legacyboot set the following variable:

+
uboot=> setenv dolegacyboot 1
+uboot=> env save; env save;
+uboot=> boot
+
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 8M Mini BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 8M Mini 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Board.dts - 包含module dtsi 文件。从SoC i.MX 8M Mini 引出并在底板使用的设备也包含在此 dts 中。

    • +

  • Overlay.dtso - 根据核心板或底板上可选硬件（例如 SPI 闪存或 PEB-AV-10）的情况来启用/禁用一些功能。

    • +
+

在Linux内核的根目录下，我们的 i.MX 8 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。下面是扩展板的硬件描述。对比源码中的include，overlay通过覆盖的方式来生效。overlay也可以根据实际开发板的硬件配置来设置设备树节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/ 中。

+

phyboard-polis-imx8mm-5.conf 可用的overlay文件有：

+
imx8mm-phyboard-polis-peb-eval-01.dtbo
+|dtbo-peb-av-10|
+imx8mm-phycore-rpmsg.dtbo
+imx8mm-phycore-no-eth.dtbo
+imx8mm-phycore-no-spiflash.dtbo
+imx8mm-vm016.dtbo
+imx8mm-vm016-fpdlink.dtbo
+imx8mm-vm017.dtbo
+imx8mm-vm017-fpdlink.dtbo
+imx8mm-dual-vm017-fpdlink.dtbo
+
+
+

Otherwise you can show the content of a FIT image including all overlay +configs in the FIT image with this command in Linux:

+
host:~$ dumpimage -l /boot/fitImage
+
+
+

or in U-Boot:

+
u-boot=> load mmc ${mmcdev}:1 ${loadaddr} fitImage
+u-boot=> iminfo
+
+
+

可以在Linux或U-Boot环境下配置overlay。overlay是在引导命令调用后、内核加载之前生效。接下来的部分将更详细地解释配置方法。

+
+

6.2.2.1. 设置 ${overlays} 变量

+

The ${overlays} U-Boot environment variable contains a number-sign (#) +separated list of overlays that will be applied during boot. The overlays +listed in the overlays variable must be included in the FIT image. Overlays set +in the $KERNEL_DEVICETREE Yocto machine variable will automatically be added to +the FIT image.

+

The ${overlays} variable can either be set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +When desired to use the overlays variable as set manually in the U-Boot +environment, disable bootenv by setting env set no_bootenv 1 as the overlays +variable may be overwritten during the execution of the boot script. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=conf-imx8mm-phyboard-polis-rdk-peb-eval-01.dtbo#conf-imx8mm-phyboard-polis-peb-av-10.dtbo
+
+
+

更改将在下次重启后生效。如果没有可用的 bootenv.txt 文件，可以直接在U-Boot环境中设置overlay变量。

+
u-boot=> setenv overlays conf-imx8mm-phyboard-polis-peb-av-10.dtbo
+u-boot=> printenv overlays
+overlays=conf-imx8mm-phyboard-polis-peb-av-10.dtbo
+u-boot=> boot
+
+
+

如果用户定义了 ${overlays} 变量，同时存在 bootenv.txt 文件，则需要设置 ${no_bootenv} 变量：

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays conf-imx8mm-phyboard-polis-peb-av-10.dtbo
+u-boot=> boot
+
+
+

有关环境的更多信息，请参见 U-boot External Environment subsection of the +device tree overlay section。

+

We use the ${overlays} variable for overlays describing expansion boards and +cameras that can not be detected during run time. To prevent applying overlays +unset the overlays variable and set no_bootenv to anything other than 0.

+
u-boot=> env delete overlays
+u-boot=> env set no_bootenv 1
+
+
+

If desired to use the bootenv.txt file for setting U-Boot variables other than +overlays and having overlays disabled, remove the overlays definition line from +the bootenv.txt file instead of setting no_bootenv.

+
+
+

6.2.2.2. SoM Variants

+

Additional overlays are applied automatically to disable components that are not +populated on the SoM. The detection is done with the EEPROM data (EEPROM SoM +Detection) found on the SoM i2c EEPROM.

+

这取决于核心板型号是否会应用任何设备树overlay。要检查在U-Boot中运行的SoM是否会应用overlay，请运行：

+
u-boot=> env print fit_extensions
+
+
+

如果没有可用的EEPROM数据，则不加载任何设备树overlay。

+

To prevent application of the SoM variant related overlays the +${no_extensions} variable can be set to 1 in the bootloader environment:

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot外部环境

+

在Linux内核启动时，外部环境 bootenv.txt 文本文件将从MMC设备的boot分区或通过TFTP加载。该文件的主要目的是存储 ${overlays} 变量。这可以针对不同的machine在Yocto中预定义不同的overlay配置。文件的内容在meta-phytec中的Yocto recipe中的bootenv中定义： https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=scarthgap

+

该文件中也可以设置其他变量。这些变量将覆盖环境中现有的设置。但只有对boot命令后进行计算的变量生效，例如 ${nfsroot} 或 ${mmcargs}。在文件中更改其他变量将不会有作用。以网络启动的用法作为示例。

+

如果无法加载外部环境，启动过程将继续进行，并使用自带的环境变量值。

+
+
+

6.2.4. 在Linux环境下更改开发板上的U-boot环境变量

+

Libubootenv是我们镜像中包含的一个工具，用于在开发板linux上修改U-Boot环境。

+

使用以下命令打印U-Boot环境：

+
target:~$ fw_printenv
+
+
+

使用以下命令修改U-Boot环境：

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

小心

+

Libubootenv会读取配置文件中配置的环境变量。要修改的环境变量会被插入到该文件中，默认情况下使用eMMC中存储环境变量。

+

如果eMMC没有被烧写过或者eMMC环境被擦除，libubootenv将无法工作。您应该修改 /etc/fw_env.config 文件，以匹配您想要使用的环境源。

+
+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 8M Mini BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 8M Mini BSP设备树概念部分，以了解我们的 i.MX 8 BSP设备树模型。

+

以下部分概述了 i.MX 8 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 8M Mini 引脚复用

+

该 i.MX 8M Mini Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 8M Mini 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 8M Mini 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是 imx8mm-phyboard-polis-rdk.dts中UART1设备的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX     0x00
+                MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX      0x00
+                MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B  0x00
+                MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B  0x00
+        >;
+};
+
+
+

字符串的第一部分 MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX 指定了引脚（在这个例子中是 SAI2_RXFS）。字符串的第二部分（UART1_DCE_RX）是该引脚当前的复用选项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部上拉电阻是否被激活。在当前配置中，内部电阻是禁用的。

+
+
+

7.2. RS232/RS485

+

i.MX 8M Mini SoC 提供最多 4 个 UART 单元。PHYTEC 开发板支持不同数量 UART 单元。UART1 也可以用作 RS-485。为此，需要正确设置 bootmode switch (S1)：

+ + + + + + + +
切换UART1的RS485和RS232模式
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+

7.2.1. RS232

+
    +

  • 以人类可读的格式显示终端的当前设置：

    +
    target:~$ stty -a
+
    +
    +
    • +

  • UART接口的配置可以通过stty命令完成。例如：

    +
    target:~$ stty -F /dev/ttymxc0 115200 crtscts raw -echo
+
    +
    +
    • +

  • 通过简单的echo和cat，可以测试基本的通信。示例：

    +
    target:~$ echo 123 > /dev/ttymxc0
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

主机应打印出 "123"。

+
+
+

7.2.2. RS485

+
+

提示

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

为了方便测试，请查看linux-serial-test。这个工具会通过调用RS485的IOCTL，发送恒定的数据流。

+
target:~$ linux-serial-test -p /dev/ttymxc0 -b 115200 --rs485 0
+
+
+

有关linux-serial-test工具及其参数的更多信息，请访问此链接：linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Linux kernel文档描述了如何在C代码中调用IOCTL： https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection1.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see "test" printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final "count for this session". There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+

RS232和RS485的设备树表示：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n291

+
+
+
+
+

7.3. 网络

+

phyBOARD-Polis-i.MX 8M Mini 提供一个千兆以太网接口。

+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n59。

+

+
+

7.3.1. 网络配置

+
+

7.3.1.1. U-boot网络环境

+
    +

  • 要在bootloader中查找以太网设置：

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • 在将主机设置为IP 192.168.3.10和子网掩码255.255.255.0的情况下，开发板应该返回：

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • 如果您需要进行任何更改：

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> 应该是 ipaddr、netmask、gatewayip 或 serverip 中的一个。<value> 将是所选参数的设定值。

    +
    • +

  • 您所做的更改目前是临时的。要保存这些更改：

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

在这里，您也可以将IP地址更改为DHCP，而不是使用静态IP地址。

+
    +

  • 配置：

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • 设置 TFTP 和 NFS 的路径。修改可以如下所示：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+

小技巧

+

像nfsroot和netargs这样的变量可以被U-boot外部环境重新赋值。对于网络启动，外部环境将通过tftp加载。例如，要在 bootenv.txt 文件中设置nfsroot变量，请在tftproot目录修改：

+
nfsroot=/home/user/nfssrc
+
+
+

无需在开发板上存储这些信息。请注意，U-boot外部环境对于像 ipaddr 或 serveraddr 这样的变量不起作用，因为它们在加载外部环境之前已经被设置完成。

+
+
+
+

7.3.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. 无线局域网

+

为了支持WLAN和蓝牙，我们使用来自LSR的Sterling-LWB模块。该模块支持2.4 GHz，并且可以在多种模式下运行，如客户端模式、使用WEP、WPA、WPA2加密的接入点（AP）模式等。有关该模块的更多信息，请访问 https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. 连接到WLAN网络

+

首先设置您所在国家的正确监管域：

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

你将会看到：

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

设置无线接口：

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

现在您可以扫描可用的网络：

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

您可以使用一个跨平台的客户端，名为wpa_supplicant，支持WEP、WPA和WPA2，以建立加密连接。

+

为此，请将网络凭据添加到文件 /etc/wpa_supplicant.conf 中：

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

现在可以建立连接：

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

这会得到如下输出：

+
Successfully initialized wpa_supplicant
+
+
+

The ip address is automatically configured over DHCP. For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (scarthgap).

+
+
+
+

7.3.3. 蓝牙

+

Bluetooth is connected to UART2 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

现在您可以扫描环境中的可见蓝牙设备。在默认配置下，蓝牙是不可见的。

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. 可见性

+

要激活可见性：

+
target:~$ hciconfig hci0 piscan
+
+
+

要禁用可见性：

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. 连接

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

备注

+

如果连接失败并出现错误信息：“连接失败：org.bluez.Error.Failed”，请尝试使用以下命令重新启动PulseAudio：

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC 卡

+

该 i.MX 8M Mini 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

MMC（SD卡插槽）接口的DT配置可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n383

+

eMMC接口的DT配置可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n335

+
+
+

7.5. eMMC设备

+

PHYTEC模块如phyCORE-i.MX 8M Mini 配备了eMMC存储芯片作为主要存储。eMMC设备使用多层单元（MLC）或三层单元（TLC）技术来实现存储，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 8M Mini ，并在Linux内核中作为块设备表示，如SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.5.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），该层负责处理原始MLC或TLC的磨损均衡、块管理和错误更正码（ECC）。这需要定期执行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 通过以下命令使能BKOPS_EN：

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.5.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 8M Mini SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.5.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
+
+

7.5.5. 启用伪SLC模式

+

eMMC设备使用 MLC或TLC 来存储数据。与NAND Flash中使用的SLC相比，MLC或TLC在成本更低的情况下，可靠性较低且错误率较高。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. 擦除设备

+

可以直接擦除eMMC设备，而不是通过写零覆盖。eMMC块管理算法将擦除底层的MLC或TLC，或者将这些块标记为可丢弃。设备上的数据将丢失，并将被读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.5.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 8M Mini 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.5.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

下表是 i.MX 8M Mini SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 8M Mini

33 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.6. SPI主设备

+

i.MX 8M Mini 控制器包含一个 FlexSPI 和一个 ECSPI IP 核。FlexSPI 主控制器支持两个 SPI 通道，最多可连接 4 个设备。每个通道支持单通道/双通道/四通道/八通道模式的数据传输（1/2/4/8 条数据线）。ECSPI 控制器支持 3 个 SPI 接口，每个接口都有一个专用的CS（chip select）引脚。由于CS也可通过 GPIO 实现，因此每个通道上可以连接多个设备。

+
+

7.6.1. SPI NOR 烧写

+

phyCORE-i.MX 8M Mini 配备有一个 QSPI NOR Flash，该 Flash 连接到 i.MX 8M Mini 的 FlexSPI 接口。QSPI NOR Flash 可用于启动。有关烧写和启动模式设置的详细信息，请参见不同的章节。由于 SPI NOR Flash 的空间有限，因此仅可存储bootloader。默认情况下，内核、设备树和根文件系统来自 eMMC。

+

bootloader程序通过EEPROM数据检测是否安装了SPI Flash。如果没有安装SPI Flash，则在启动期间应用设备树overlay，通过扩展命令禁用SPI Flash设备树节点。如果没有可用的EEPROM数据，SPI NOR Flash节点将始终启用。有关更多信息，请参阅设备树overlay部分。

+

bootloader程序还可以通过内核的mtdparts启动参数修改设备树，将SPI MTD分区表传递给Linux。BSP中的默认分区布局设置为：

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

这是一个预定义的bootloader环境变量，可以在运行时更改。从Linux用户空间，可以通过/dev/mtd<N>设备访问NOR Flash分区，其中<N>是与要访问的NOR Flash分区相关联的MTD设备编号。要找到分区的正确MTD设备编号，请在目标上运行：

+
root@phyboard-polis-imx8mm-5:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

它列出了所有MTD设备及其对应的分区名称。闪存节点在模块DTS中的SPI主节点内定义。SPI节点包含连接到此SPI总线的所有设备，在这种情况下只有SPI NOR Flash。

+

设备树中SPI主节点的定义可以在这里找到：

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n87

+
+
+
+

7.7. GPIOs

+

phyBOARD-Polis 具有一组专门用于GPIO的引脚。这些引脚直接连接到 i.MX 8M Mini 引脚，并被复用为 GPIO。它们可以直接在 Linux 用户空间中使用。处理器将其 GPIO 组织为5个GPIO组（GPIO1 – GPIO5），每个组包含 32 个GPIO。gpiochip0、gpiochip32、gpiochip64、gpiochip96 和 gpiochip128 是这些内部 i.MX 8M Mini GPIO 组 GPIO1 – GPIO5 的 sysfs 表示。

+

GPIO被标识为GPIO<X>_<Y>（例如：GPIO5_07）。<X>表示GPIO Bank，从1计数到5，而<Y>表示该Bank内的GPIO。<Y>从0计数到31（每个bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo -c gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如从gpiochip0的GPIO 20）：

    +
    target:~$ gpioget -c gpiochip0 20
+
    +
    +
    • +

  • 将gpiochip0上的GPIO 20的值设置为0并退出工具：

    +
    target:~$ gpioset -z -c gpiochip0 20=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <line=value>...
+
+Set values of GPIO lines.
+
+Lines are specified by name, or optionally by offset if the chip option
+is provided.
+Values may be '1' or '0', or equivalently 'active'/'inactive' or 'on'/'off'.
+
+The line output state is maintained until the process exits, but after that
+is not guaranteed.
+
+Options:
+      --banner            display a banner on successful startup
+  -b, --bias <bias>       specify the line bias
+                  Possible values: 'pull-down', 'pull-up', 'disabled'.
+                  (default is to leave bias unchanged)
+      --by-name           treat lines as names even if they would parse as an offset
+  -c, --chip <chip>       restrict scope to a particular chip
+  -C, --consumer <name>   consumer name applied to requested lines (default is 'gpioset')
+  -d, --drive <drive>     specify the line drive mode
+                  Possible values: 'push-pull', 'open-drain', 'open-source'.
+                  (default is 'push-pull')
+  -h, --help              display this help and exit
+  -l, --active-low        treat the line as active low
+  -p, --hold-period <period>
+                  the minimum time period to hold lines at the requested values
+  -s, --strict            abort if requested line names are not unique
+  -t, --toggle <period>[,period]...
+                  toggle the line(s) after the specified period(s)
+                  If the last period is non-zero then the sequence repeats.
+      --unquoted  don't quote line names
+  -v, --version           output version information and exit
+  -z, --daemonize set values then detach from the controlling terminal
+
+Chips:
+    A GPIO chip may be identified by number, name, or path.
+    e.g. '0', 'gpiochip0', and '/dev/gpiochip0' all refer to the same chip.
+
+Periods:
+    Periods are taken as milliseconds unless units are specified. e.g. 10us.
+    Supported units are 's', 'ms', and 'us'.
+
+*Note*
+    The state of a GPIO line controlled over the character device reverts to default
+    when the last process referencing the file descriptor representing the device file exits.
+    This means that it's wrong to run gpioset, have it exit and expect the line to continue
+    being driven high or low. It may happen if given pin is floating but it must be interpreted
+    as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.7.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用 CONFIG_GPIO_SYSFS 后才能支持。要在menuconfig中使 CONFIG_GPIO_SYSFS 可见，必须首先启用选项 CONFIG_EXPERT 。

+

您也可以将此选项添加到您在 Linux 内核源代码 arch/arm64/configs/ 目录下使用的 defconfig 中。例如，我们基于 NXP 的BSP版本，这个defconfig可以是 imx8_phytec_distro.config

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+

设备树 imx8mm-phyboard-polis-rdk.dts 中一些GPIO引脚的管脚复用：

+
pinctrl_leds: leds1grp {
+        fsl,pins = <
+                MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1       0x16
+                MX8MM_IOMUXC_GPIO1_IO14_GPIO1_IO14      0x16
+                MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x16
+        >;
+};
+
+
+
+
+
+

7.8. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

这里的 LED 灯包括蓝色的 mmc、绿色的 心跳和红色的 emmc，它们都在 phyBOARD-Polis 上。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

用户输入/输出配置的设备树配置可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n36

+
+
+

7.9. I²C总线

+

该 i.MX 8M Mini 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 8M Mini 的I²C模块。 本节描述了我们 phyBOARD-Polis 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

通用 I²C1 总线配置（例如 imx8mm-phycore-som.dtsi）： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n119

+

通用 I²C4 总线配置（例如 imx8mm-phyboard-polis-rdk.dts）： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n244

+
+
+

7.10. EEPROM

+

在 phyCORE-i.MX8MM 上贴了一个 i2c 接口的 EEPROM 存储。它有两个地址。主 EEPROM 空间（总线：I2C-0 地址：0x51）可以通过 Linux 中的 sysfs 接口访问。主 EEPROM 的前 256 字节和 ID 页（总线：I2C-0 地址：0x59）用于板检测，不可修改。因此，ID 页不能通过 sysfs 接口访问。覆盖保留空间将导致启动问题。

+
+

备注

+

如果您删除了保留的EEPROM空间数据，请联系我们的支持团队！

+
+
+

7.10.1. phyCORE-i.MX8MM 上的I2C EEPROM

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

phyCORE-i.MX8MM SoM上的I2C EEPROM连接到I2C-0总线的I2C地址0x51。可以直接对该设备进行读写操作：

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

要用零填充4KiB的EEPROM（总线：I2C-0 地址：0x51），并保留EEPROM数据，请使用：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM 检测

+

在 phyCORE-i.MX8MM 上配置的I2C EEPROM具有一个可通过I2C地址0x59在i2c0上寻址的独立ID页面，以及一个可通过I2C地址0x51在i2c0上寻址的正常区域。PHYTEC使用这个32字节的数据区域来存储关于SoM的信息，包括PCB版本和配置。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果EEPROM ID页面数据和正常区域的前256个字节被删除，bootloader程序将回退到 phyCORE-i.MX8MM Kit RAM设置，即 2GiB RAM。

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

使用API修订版2数据格式烧写的核心板将在早期启动阶段打印出有关模块的信息。

+

DT 表示法，例如在 phyCORE-i.MX 8M Mini 文件 imx8mm-phycore-som.dtsi 中，可以在我们的 PHYTEC git 中找到： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n311

+
+
+
+

7.11. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC唤醒alarm

+

可以从实时时钟（RTC）发出中断以唤醒系统。该格式使用Unix纪元时间，即自1970年1月1日UTC午夜以来的秒数。要在从挂起到RAM状态后的4分钟唤醒系统，请输入：

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

备注

+

内部唤醒alarm时间将被向上舍入到下一个分钟，因为alarm功能不支持秒。

+
+
+
+

7.11.2. RTC参数

+

实时时钟（RTC）具有一些功能，可以通过 hwclock 工具进行读取和设置。

+
    +

  • 我们可以通过以下方式检查RTC支持的功能：

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    这个值的含义在内核中进行了编码，每个位的定义为：

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • 我们可以通过以下方式检查RTC BSM（Backup Switchover Mode 备份切换模式）：

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • 我们可以通过以下方式设置RTC BSM：

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    BSM位的定义为：

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    小技巧

    +

    您应该将BSM模式设置为DSM或LSM，以便在初始电源不可用时，RTC可以切换到备用电源。请查看 RV-3028 RTC的Datasheet，以了解LSM（电平切换模式）和DSM（直接切换模式）这两个定义的工作模式。

    +
    +
    • +
+

I²C RTCs的DT表示: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n319

+
+
+
+

7.12. USB主控制器

+

i.MX 8M Mini SoC的USB控制器为众多消费类便携设备提供了一种低成本的连接以及数据传输解决方案，传输速率最高可达480 Mbps（高速 'HS'）。USB子系统具有两个独立的USB控制器IP。两个IP都是即插即用（OTG）控制器IP，能够充当USB外设设备或USB主机。每个IP都连接到一个USB 2.0物理层（PHY）。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+

USB2（host）配置在内核设备树 imx8mm-phyboard-polis-rdk.dts 中：

+
&usbotg2 {
+        dr_mode = "host";
+        picophy,pre-emp-curr-control = <3>;
+        picophy,dc-vol-level-adjust = <7>;
+        status = "okay";
+};
+
+
+

USB主机的DT表示：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n347

+
+
+

7.13. USB OTG

+

大多数PHYTEC板提供USB OTG接口。USB OTG端口会自动作为USB设备或USB主机工作。模式取决于连接到USB OTG端口的USB硬件。例如，如果将USB大容量存储设备连接到USB OTG端口，该设备将显示为 /dev/sda 。

+
+

7.13.1. 作为USB设备

+

为了将开发板作为USB设备连接到USB主机（例如PC），您需要配置相应的USB gadget。通过USB configfs，您可以定义USB gadget的参数和功能。BSP包含作为kernel module 的USB configfs支持。

+
target:~$ modprobe libcomposite
+
+
+

例子:

+
    +

  • 首先，定义参数，例如USB Vendor和product ID，并为英语（0x409）设置信息字符串：

    • +
+
+

提示

+

为了节省时间，请复制这些命令并在脚本中执行它们

+
+
cd /sys/kernel/config/usb_gadget/
+mkdir g1
+cd g1/
+echo "0x1d6b" > idVendor
+echo "0x0104" > idProduct
+mkdir strings/0x409
+echo "0123456789" > strings/0x409/serialnumber
+echo "Foo Inc." > strings/0x409/manufacturer
+echo "Bar Gadget" > strings/0x409/product
+
+
+
    +

  • 接下来，为大容量存储 gadget 创建一个文件：

    • +
+
target:~$ dd if=/dev/zero of=/tmp/file.img bs=1M count=64
+
+
+
    +

  • 现在你可以创建你想要使用的功能：

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir functions/acm.GS0
+mkdir functions/ecm.usb0
+mkdir functions/mass_storage.0
+echo /tmp/file.img > functions/mass_storage.0/lun.0/file
+
+
+
    +

  • acm: 串行设备 gadget，创建类似 /dev/ttyGS0 的串行接口。

    • +

  • ecm: 以太网 gadget，创建以太网接口，例如 usb0

    • +

  • mass_storage: 主机可以像处理其他USB大容量存储设备一样，对设备的大容量存储进行分区、格式化和挂载。

    • +
+
    +

  • 将定义的功能绑定到配置：

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir configs/c.1
+mkdir configs/c.1/strings/0x409
+echo "CDC ACM+ECM+MS" > configs/c.1/strings/0x409/configuration
+ln -s functions/acm.GS0 configs/c.1/
+ln -s functions/ecm.usb0 configs/c.1/
+ln -s functions/mass_storage.0 configs/c.1/
+
+
+
    +

  • 最后，使用以下命令启动USB gadget：

    • +
+
target:~$ cd /sys/kernel/config/usb_gadget/g1
+target:~$ ls /sys/class/udc/
+ci_hdrc.0
+target:~$ echo "ci_hdrc.0" >UDC
+
+
+

如果您的系统有多个USB设备或OTG端口，您可以将正确的端口传递给USB设备控制器（UDC）。

+
    +

  • 要停止USB gadget 并解除绑定已使用的功能，请执行：

    • +
+
target:~$ echo "" > /sys/kernel/config/usb_gadget/g1/UDC
+
+
+

两个USB接口在内核设备树 imx8mm-phyboard-polis-rdk.dts 中被配置为主机。请参见： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n335

+
+
+
+

7.14. CAN FD

+

The phyBOARD-Polis has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
+

提示

+

phyBOARD-Polis 具有一个通过 SPI 连接的外部 CAN FD 芯片 MCP2518FD。由于使用了SPI，限制了 CAN FD 的数据传输速率上限。

+
+
+

提示

+

在phyBOARD-Polis-i.MX8MM上，如果需要，可以通过将S5设置为ON来启用端接电阻。

+
+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。两个CAN接口显示为can0和can1。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    can0的信息将如下所示：

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+
+

警告

+

mcp2518fd SPI到CAN FD只支持从125kB/s开始的波特率。可以选择更慢的速率，但可能无法正常工作。

+
+

imx8mm-phyboard-polis-rdk 的设备树CAN配置.dts: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n175

+
+
+

7.15. PCIe

+

phyCORE-i.MX 8M Mini 具有一个 Mini-PCIe 插槽。一般来说，PCIe 会自动检测总线上的新设备。在连接设备并启动系统后，您可以使用命令 lspci 查看所有被识别的 PCIe 设备。

+
    +

  • 输入：

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • 你将收到：

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

在这个例子中，PCIe设备是 英特尔 WiFi Link 5100 。

+

对于PCIe设备，您必须在内核配置中启用正确的驱动程序。例如，这款WLAN卡是由英特尔制造的。必须启用的驱动程序选项名为 CONFIG_IWLWIFI ，可以在内核配置中的 Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimate 下找到。

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • linux-imx的表示为：virtual/kernel

      • +
    +
    • +
+

对于某些设备，如WLAN卡，需要额外的二进制固件文件。这些固件文件必须放置在 /lib/firmware/ 目录中，才能使用该设备。

+
    +

  • 输入：

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • 例如，如果您尝试启动网络接口：

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • 您将在串口控制台上获得以下输出：

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

小技巧

+

某些PCIe设备，例如以太网卡，即使没有从 /lib/firmware/ 加载固件文件，也可能正常工作，而你收到了如上输出第一行所示的错误消息。这是因为一些制造商在板卡本身提供了固件作为后备。在这种情况下，设备的行为和输出在很大程度上依赖于制造商的固件。

+
+

Device Tree PCIe configuration of imx8mm-phyboard-polis-rdk.dts: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n257

+
+
+

7.16. 音频

+

PEB-AV-10-Connector有两个版本，其中1531.1版本配备了TI TLV320AIC3007音频编解码器（CODEC）。音频数据通过I2S传输，并通过I2C进行控制。

+

有一个符合OMTP标准的3.5mm耳机插孔和一个8针接口，用于连接带有AV连接器的音频设备。这个8针接口包含单声道扬声器、耳机和线路输入信号（line-in）。

+

要检查您的声卡驱动程序是否正确加载以及设备名称，请输入以下命令以查看播放设备：

+
target:~$ aplay -L
+
+
+

或输入录音设备：

+
target:~$ arecord -L
+
+
+
+

7.16.1. Alsamixer

+

要检查声卡的功能，请输入：

+
target:~$ alsamixer
+
+
+

您应该会看到很多选项，因为音频IC具有许多可以测试的功能。通过SSH打开alsamixer的图形界面比通过调试串口打开更易于使用。所有混音点都有单声道或立体声增益控制。"MM"表示该功能被静音（左右输出均为静音），可以通过按' m '切换。您还可以通过按' < ' 左和 ' > '切换右声道输出。使用 tab 键，您可以在播放和录音控制之间切换。

+
+
+

7.16.2. 恢复默认音量

+

一些默认设置存储在 /var/lib/alsa/asound.state 中。您可以使用以下命令保存当前的alsa设置：

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

您可以通过以下方式恢复已保存的alsa设置：

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.16.3. ALSA配置

+

我们的BSP附带一个ALSA配置文件 /etc/asound.conf 。

+

ALSA配置文件可以根据需要进行编辑或删除，它并不是ALSA正常工作所必需的。

+
target:~$ vi /etc/asound.conf
+
+
+

要将PEB-AV-10设置为输出，请将 playback.pcm 从 "dummy" 设置为 "pebav10":

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

如果听不到声音，请将播放设备更改为软件音量控制播放设备，将 playback.pcm 设置为相应的软音量播放设备，例如“softvol_pebav10”。使用alsamixer控制来调整音量级别。

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.16.4. PulseAudio 配置

+

对于使用 Pulseaudio 的应用程序，请检查可用的音频输出设备：

+
target:~$ pactl list short sinks
+
+
+

要选择输出设备，请输入：

+
target:~$ pactl set-default-sink <sink_number>
+
+
+
+
+

7.16.5. 播放

+

运行speaker-test以检查播放功能：

+
target:~$ speaker-test -c 2 -t wav
+
+
+

要播放简单的音频流，您可以使用aplay。例如，要播放ALSA测试音频：

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

要播放其他格式，例如mp3，您可以使用Gstreamer：

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.16.6. 录音

+

arecord 是一个命令行工具，用于录制音频流，默认输入源为线路输入。要选择不同的音频源，可以使用 alsamixer。例如，打开 右侧 PGA 混音器 Mic3R 和 左侧 PGA 混音器 Mic3R，以便通过 3.5mm 插孔录制来自 TLV320 编解码器的麦克风输入音频。

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

提示

+

由于播放和录音共享硬件接口，因此无法在同时进行播放和录音操作时使用不同的采样率和格式。

+
+

设备树音频配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mm-phyboard-polis-peb-av-010.dtsi?h=v5.15.71_2.2.2-phy3#n54

+
+
+
+

7.17. 视频

+
+

7.17.1. 视频与Gstreamer

+

默认情况下，BSP安装了一个示例视频，路径为 /usr/share/qtphy/videos/ 。可以使用以下命令之一开始视频播放：

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.18. 显示

+

10英寸显示屏始终处于使能状态。如果PEB-AV连接器未连接，启动时可能会出现错误信息。

+
+

7.18.1. Qt Demo

+

使用 phytec-qt6demo-image 时，Weston会在启动时启动。我们的Qt6 DEMO应用程序名为“qtphy”，可以通过以下方式停止：

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • 要重新开始Demo，请运行：

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • 要禁用Demo的自动启动，请运行：

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • 要启用Demo的自动启动，请运行：

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston可以通过以下方式停止：

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

备注

+

在关闭Weston之前，必须先关闭Qt Demo。

+
+
+
+

7.18.2. 背光控制

+

如果LCD连接到PHYTEC开发板，可以通过Linux内核的sysfs接口控制其背光。系统中所有可用的背光设备可以在文件夹/sys/class/backlight中找到。读取相应的文件并向其写入数据可以控制背光。

+
+

备注

+

一些具有多显示的开发板在 /sys/class/backlight 有多个背光控制。比如：backlight0和backlight1

+
+
    +

  • 例如，要获取最大亮度级别（max_brightness），请执行：

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    有效的亮度值范围是 0 到 <max_brightness>。

    +
    • +

  • 要获取当前亮度级别，请输入：

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • 写入文件brightness以更改亮度：

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    例如，关闭背光。

    +

    有关所有文件的文档，请参见 https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight。

    +
    • +
+

PEB-AV-10的设备树可以在这里找到: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mm-phyboard-polis-peb-av-010.dtsi?h=v5.15.71_2.2.2-phy3

+
+
+
+

7.19. 电源管理

+
+

7.19.1. CPU核心频率调节

+

i.MX 8M Mini SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。调整频率和电压被称为“动态电压和频率调整”（DVFS）。i.MX 8M Mini BSP支持DVFS功能。Linux内核提供了一个DVFS框架，允许每个CPU核心设置最小或最大频率和一个管理其运行的governor。根据使用的 i.MX 8 型号，支持几种不同的频率。

+
+

小技巧

+

尽管DVFS框架为每个CPU核心提供了频率设置，但一个CPU核心的频率更改会影响其他CPU核心。因此，所有CPU核心始终共享相同的DVFS设置。每个核心的单独DVFS设置是不可能的。

+
+
    +

  • 要获取完整列表，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    例如 i.MX 8MPlus CPU，最高可达约 1.6 GHz，则结果将是：

    +
    1200000 1600000
+
    +
    +
    • +

  • 要查询当前的频率输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

governor 会根据它们的目标自动选择这些频率中的一个。

+
    +

  • 列出所有可用的 governor，使用以下命令：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    结果是：

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative governor 与 ondemand governor 非常相似。只是它的行为有所不同，它会更保守地增减CPU速度，而不是在CPU有任何负载的瞬间就跳到最大速度。

    • +

  • ondemand （默认）根据当前系统负载在可能的CPU核心频率之间切换。当系统负载超过特定值时，它会立即提高CPU核心频率。

    • +

  • powersave 始终选择最低的CPU核心频率。

    • +

  • performance 始终选择最高的CPU核心频率。

    • +

  • userspace 允许以root身份运行的用户或用户空间程序设置特定频率（例如，设置为1600000）。输入：

    • +

  • 要查询当前的 governor，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    您通常会得到：

    +
    ondemand
+
    +
    +
    • +

  • 切换到另一个governor（例如，userspace）可以通过以下方式完成：

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • 现在你可以设置频率：

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

有关governor的更详细信息，请参阅Linux内核代码库中的Linux内核文档，路径为 Documentation/admin-guide/pm/cpufreq.rst 。

+
+
+

7.19.2. CPU核心管理

+

该 i.MX 8M Mini SoC 芯片上可以有多个处理器核心。例如，该 i.MX 8M Mini 具有 4 个 ARM 核心，可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    这里系统有四个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.19.3. 挂起到RAM

+

phyCORE-i.MX8MM 支持基本的挂起和恢复。可以使用不同的唤醒源。挂起/恢复可以通过以下方式实现：

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

要通过串行控制台唤醒，请运行

+
target:~$ echo enabled > /sys/class/tty/ttymxc2/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.20. 热管理

+
+

7.20.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.20.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 8M Mini SoC 平台上使用热管理内核 API。 i.MX 8 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个触发点。这些触发点根据CPU型号的不同而有所不同。主要区分工业版和商业版。

+ + + + + + + + + + + + + + + + + +

商业

工业

被动（警告）

85°C

95°C

严重（关机）

90°C

100°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并实施冷却措施。内核中可用的热政策（也称为thermal governor）包括：Step Wise、Fair Share、Bang Bang和Userspace。BSP中使用的默认策略是Step Wise。如果sysfs文件temp中的SoC温度值高于 trip_point_0 ，则CPU频率将设置为最低CPU频率。当SoC温度降到 trip_point_0 以下时，限制将被解除。

+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+

7.20.3. GPIO风扇

+
+

备注

+

Only GPIO fan supported.

+
+

一个GPIO控制的风扇可以连接到 phyBOARD-Polis-i.MX 8M Mini。该SoC包含一个温度传感器，该传感器被用于热频率调节。风扇无法通过内核进行控制。我们使用lmsensors和hwmon来实现这一点。lmsensors定期读取温度，并在可配置的阈值下启用或禁用风扇。对于 phyBOARD-Polis-i.MX 8M Mini，这个阈值是60°C。

+

设置可以在配置文件中进行配置：

+
/etc/fancontrol
+
+
+

风扇控制在启动时由systemd服务启动。可以通过以下方式禁用它：

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.21. 看门狗

+

PHYTEC i.MX 8M Mini 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.21.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.22. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 8M Mini 提供一次性可编程fuse，用于存储信息，例如 MAC 地址、启动配置和其他永久设置（在 i.MX 8M Mini reference manual中称为“片上 OTP 控制器 (OCOTP_CTRL)”）。以下列表摘自 i.MX 8M Mini reference manual，包括 OCOTP_CTRL 中的一些有用寄存器（基地址为0x30350000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为0x30350000

描述

OCOTP_MAC_ADDR0

9

0

0x640

包含ENET0 MAC地址的低32位

OCOTP_MAC_ADDR1

9

1

0x650

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

OCOTP_MAC_ADDR2

9

2

0x660

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 8M Mini Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.22.1. 在uBoot中读取fuse的值

+

您可以使用内存映射的shadow寄存器读取fuse寄存器。要计算内存地址，请使用以下公式计算：

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.22.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+
+

8. i.MX 8M Mini M4 Core

+

除了Cortex-A53核心外，SoC中还集成了一个Cortex-M4 Core 作为MCU。我们的Yocto-Linux-BSP在A53核心上运行，而 M4 Core 可以作为辅助CPU，用于使用裸机或RTOS固件执行额外任务。两种核心都可以访问相同的外设，因此外设的使用需要在 M4 Core 的固件或Linux操作系统的设备树中进行限制。本节将描述如何编译固件示例以及如何在 phyBOARD-Polis 上运行它们。

+

phyBOARD-Polis 目前由 NXP MCUXpresso SDK 和 Zephyr 项目支持。本节仅描述 NXP MCUXpresso SDK，因为目前 MCUXpresso SDK 支持的功能更多。

+

如果您想在Zephyr项目中使用 M4 Core ，请参考Zephyr项目文档：

+ +
+

8.1. 获取固件示例

+

固件可以使用NXP MCUxpresso SDK和兼容的编译工具链通过命令行工具进行编译。

+
+

8.1.1. 获取源代码

+

MCUX SDK以及 i.MX 8M Mini 的示例可以从PHYTEC的GitHub页面获取：

+ +
    +

  1. 通过west初始化MCUX SDK：

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    这将创建一个 mcuxsdk 目录，并在其中包含 mcux-sdk 仓库。mcux-sdk-phytec-examples 仓库将自动克隆到 mcuxsdk 目录中。给定的参数 <VERSION> 是 mcux-sdk 仓库的分支名称，代表 MCUX SDK 版本。要获取最新的测试版本，您可以使用 2.13.0。

    +
    +

    备注

    +

    west 是一个仓库管理工具，也是 Zephyr 项目的一部分。要安装 west，您可以使用 pip。在这个示例中，west 被安装在一个 Python 虚拟环境中:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. 更新依赖项：

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    目录 examples-phytec 包含了所有移植并测试过的示例，适用于 phyBOARD-Polis 和版本为 2.13.0 的 MCUX。

    +

    要编译固件，需要一个编译器工具链和make/cmake。GNU ARM 嵌入式工具链可能在您的主机linux发行版的仓库中可用，例如Ubuntu。

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    编译器工具链也可以直接从 https://developer.arm.com/ 获取。在解压缩文件后，必须将 ARMGCC_DIR 添加到环境变量中，例如，对于位于主目录中的 ARM toolchain 10-2020-q4-major 版本：

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. 编译固件

+

要编译PHYTEC示例，需要先设置环境

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

编译固件的脚本位于 <sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc。每个可运行的内存位置都有相应的编译脚本，例如：

+
host:~$ ./build_release.sh
+
+
+

要编译运行在 M4 Core 的 TCM 上的固件。输出将放置在 armgcc 目录下的 release/ 中。.bin 文件可以在 U-Boot 中运行，而 .elf 文件可以在 Linux 中运行。

+

要编译在DRAM上运行的固件，请运行脚本build_ddr_release。例如。

+
host:~$ ./build_ddr_release.sh
+
+
+

输出将放置在armgcc目录下的ddr_release/中。.bin文件可以在U-Boot中运行，而.elf文件可以在Linux中运行。

+
+
+
+

8.2. 运行 M4 Core 示例

+

有两种方法可以运行 M4 Core 的固件，在Linux中使用Remoteproc以及在U-Boot。

+

要接收调试信息，请在您的主机PC上启动您喜欢的终端软件（例如Minicom、Tio或Tera Term），并将其配置为115200波特率、8个数据位、无奇偶校验和1个停止位（8n1），且不使用握手。

+

一旦Micro USB电缆连接到 phyBOARD-Polis 上的USB调试端口，就会注册两个ttyUSB设备。一个打印来自A53核心的调试UART的消息，另一个打印来自 M4 Core 的调试UART的消息。

+
+

8.2.1. 从U-Boot运行示例

+

要使用bootloader U-Boot加载固件，可以使用bootaux命令：

+
    +

  1. 准备一张烧写了BSP镜像的SD卡

    2. +

  2. 将生成的 .bin 文件复制到 SD 卡的第一个分区

    3. +

  3. 通过按任意键停止自动启动

    4. +

  4. 根据固件类型输入命令：

    5. +
+

对于在 M4 Core 的TCM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

用于在DRAM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

程序的输出应显示在 M4 Core 的调试UART上。

+
+
+

8.2.2. 通过Remoteproc在Linux上运行示例

+

Remoteproc是一个模块，允许您在运行时从Linux控制 M4 Core 。可以加载为TCM编译的固件，并可以启动或停止执行。要使用Remoteproc，需要设置设备树Overlay：

+

在开发板的/boot目录中编辑bootenv.txt文件，添加 imx8mm-phycore-rpmsg.dtbo ：

+
overlays=imx8mm-phycore-rpmsg.dtbo
+
+
+

重启目标并在U-Boot中执行:

+
u-boot=> run prepare_mcore
+
+
+

M4 Core 的固件 .elf 文件可以在 /lib/firmware 下找到。要加载固件，请输入：

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

要加载不同的固件，M4 Core 需要停止：

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

备注

+

在开发板上找到的 /lib/firmware 中的例子来自NXP的Yocto层meta-imx。要使用您通过MCUX SDK自己编译的样本，请在编译后将它们复制到开发板的 /lib/firmware 中。

+
+
+ +
+
+
+

9. BSP扩展

+
+

9.1. Chromium

+

我们的BSP支持Chromium。您只需几个步骤即可将其包含在 phytec-qt6demo-image 中。

+
+

9.1.1. 将Chromium添加到您的local.conf文件中

+

要包含Chromium，您需要在您的local.conf中添加以下行。您可以在<yocto_dir>/build/conf/local.conf中找到这个配置文件。这将把Chromium添加到您下一个镜像编译中。:

+
IMAGE_INSTALL:append = " chromium-ozone-wayland"
+
+
+
+

备注

+

编译Chromium需要很长时间。

+
+
+
+

9.1.2. 在开发板上运行Chromium

+

要运行Chromium，需要一些参数来使用硬件图形加速：

+
target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox
+
+
+

如果您想通过SSH启动Chromium，您必须首先定义运行Chromium的显示器。例如：

+
target$ DISPLAY=:0
+
+
+

在您定义完这个之后，您可以通过上述所示的Weston虚拟终端启动它。

+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mm/imx8mm.html b/previews/271/zh_CN/bsp/imx8/imx8mm/imx8mm.html new file mode 100644 index 000000000..aa4180acf --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mm/imx8mm.html @@ -0,0 +1,432 @@ + + + + + + + + + i.MX 8M Mini 手册 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

i.MX 8M Mini 手册

+ +
+

BSP-Yocto-NXP-i.MX8MM-PD23.1.0

+
+

目录

+ +
+
+
+

BSP-Yocto-NXP-i.MX8MM-PD22.1.1

+
+

目录

+ +
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mm/pd22.1.1.html b/previews/271/zh_CN/bsp/imx8/imx8mm/pd22.1.1.html new file mode 100644 index 000000000..fd0e9b540 --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mm/pd22.1.1.html @@ -0,0 +1,3708 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 8M Mini BSP手册

文档标题

i.MX 8M Mini BSP手册

文档类型

BSP 手册

Yocto 手册

发布日期

2023/05/25

母文档

i.MX 8M Mini BSP手册

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP 发布日期

BSP 状态

BSP-Yocto-NXP-i.MX8MM-PD22.1.1

小更新

2023/05/23

已发布

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 phyCORE-i.MX8M Mini Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads 中找到。

+
+

1.1. 支持的硬件

+

支持配备 i.MX 8M Mini SoC 或 i.MX 8M Nano SoC 的 phyBOARD-Polis。

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-NXP-i.MX8MM-PD22.1.1 的所有Machine及其对应的Article Numbers(产品型号)： 网址. 如果您在该网页 Supported Machines 一节选择了特定的 Machine Name ，您可以查看被选中machine下的包含的 Article Number(产品型号) 以及简要的硬件描述。如果您只有 Article Number ，可以将 Machine Name 下拉菜单留空，仅选择您的 Article Number 。那么，它会显示您特定硬件所对应的 Machine Name

+
+

1.1.1. phyBOARD-Polis 器件

+ + + + + + +
+../../../_images/polis-front.jpg +
+

phyBOARD-Polis 器件（顶部）

+
+
+
+../../../_images/polis-back.jpg + +
+

phyBOARD-Polis 器件（底部）

+
+
+
+
+
+
+
+

2. 开始使用

+

该 phyCORE-i.MX8M Mini Kit 包含预先烧写好的SD卡。它包含 phytec-qt5demo-image ，可以直接用作启动盘。默认情况下，核心板的eMMC仅烧写了U-boot。您可以从 PHYTEC下载服务器 获取所有源代码。本章解释了如何将BSP镜像烧录到SD卡以及如何启动开发板。

+
+

2.1. 下载镜像

+

WIC镜像包含预先格式化的分区信息以及分区中包含的BSP文件，可以使用单个Linux命令 dd 轻松写入到SD卡上。WIC镜像可以通过Yocto编译或从PHYTEC下载服务器下载。

+

从下载服务器获取WIC文件：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic
+
+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要使用 dd 命令创建SD卡启动盘，您必须具有root权限。在使用 dd 指定目标设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行该命令：

    +
    host$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+
    +

  • 卸载所有分区，例如：

    +
    host$ sudo umount /dev/sde1
+
    +
    +
    • +

  • 在卸载所有分区后，您可以创建SD卡启动盘：

    +
    host$ sudo dd if=<IMAGENAME>-<MACHINE>.wic of=/dev/sdX bs=1M conv=fsync status=progress
+
    +
    +

    再次确保将 /dev/sdX 替换为之前找到的设备名称。

    +

    参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

    +
    • +
+

准备SD卡启动盘的另一种更快的方法是使用Intel的 bmap-tools 。Yocto会自动为WIC镜像创建一个block map文件（ <IMAGENAME>-<MACHINE>.wic.bmap ），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host$ bmaptool copy <IMAGENAME>-<MACHINE>.wic /dev/<your_device>
+
+
+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.3. 首次启动

+ + + + + + + +
启动模式选择
+../../../_images/SD_Card_Boot.jpg +
+

Mini

+
+
+
+
    +

  • 插入SD卡

    • +

  • 使用 micro USB 线将开发板的 (X30) 调试USB口和主机连接起来

    • +

  • 给开发板通电

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 8M Mini BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: L-813e.A13 Yocto Reference Manual (hardknott).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +L-813e.A13 Yocto Reference Manual (hardknott).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-IMX8MM ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-xwayland MACHINE=phyboard-polis-imx8mm-5 ./phyLinux init -p imx8mm -r BSP-Yocto-NXP-i.MX8MM-PD22.1.1
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-qt5demo-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 phyboard-polis-imx8mm-5 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx8mm.bin: ARM可信固件二进制文件

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY固件镜像

    • +

  • imx-boot：由imx-mkimage编译的bootloader镜像，包括SPL、U-Boot、ARM可信固件和DDR固件。这是最终的可引导bootloader镜像。

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx8mm-phyboard-polis-rdk*.dtb：内核设备树文件

    • +

  • imx8mm-phy*.dtbo: 内核设备树overlay文件

    • +

  • phytec-qt5demo-image*.tar.gz: 根文件系统

    • +

  • phytec-qt5demo-image*.wic: SD卡镜像

    • +
+
+
+
+
+

4. 安装操作系统

+
+

4.1. 启动模式开关 (S1)

+

该 phyBOARD-Polis 具有一个启动配置开关，带有六个可单独切换的开关，用于选择 phyCORE-i.MX 8M Mini 的默认启动源。

+
+

4.1.1. Mini

+ + + + + + + + + + +
启动模式选择
+../../../_images/eMMC.jpg +
+

eMMC（核心板的默认启动方式）

+
+
+
+../../../_images/SPI_NOR1.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download2.png +
+

USB

+
+
+
+../../../_images/SD_Card_Boot.jpg +
+

SD卡

+
+
+
+ + + + + + + +
切换UART1的RS485和RS232模式
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+
+
+

4.2. 烧写eMMC

+

要从eMMC启动，请确保BSP镜像已正确烧录到eMMC，并且 bootmode switch (S1) 设置为 默认SOM启动 。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行上述命令来检查系统启动在这种条件下是否会到影响。如果 mmcblk2p1 和 mmcblk1p1 具有相同的UUID，则会影响系统正确启动。

+
+
+

4.2.1. 从网络烧写 eMMC

+

i.MX 8M Mini 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

4.2.1.1. 在开发板的u-boot环境中从网络烧写eMMC

+

这些步骤将展示如何通过网络更新eMMC。然而，此步骤仅在镜像文件小于1GB的情况下会被执行成功。如果镜像文件更大，请转到“格式化SD卡”一节。配置 bootmode switch (S1) 以从SD卡启动，并插入一张SD卡。给开发板上电并进入U-Boot环境。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+
    +

  • 通过网络将您的镜像加载到内存中：

    +
    u-boot=> tftp ${loadaddr} phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • 将镜像写入eMMC：

    +
    u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +
+
+
+

4.2.1.2. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！设置主机网络。

+
+

使用一条命令，通过网络ssh协议将带有块映射的压缩或未压缩的镜像发送到开发板的eMMC上使用,执行：

+
target:~$ ssh <USER>@192.168.3.10 "dd if=<path_to_file>/phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic" | dd of=/dev/mmcblk2
+
+
+
+
+

4.2.1.3. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！设置主机网络。

+
+

查看主机上可用的镜像文件：

+
host:~$ ls
+phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic
+
+
+

通过网络使用ssh将镜像用dd命令发送到您设备的eMMC：

+
host:~$ dd if=phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2"
+
+
+
+
+
+

4.2.2. 在u-boot中通过网络烧写eMMC u-boot镜像

+

如果eMMC上的bootloader位于eMMC的User区，从u-boot中更新独立的u-boot镜像imx-boot也是可能的。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！设置主机网络。

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x42 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.3. 从USB烧写eMMC

+
+

4.2.3.1. 在u-boot上从USB烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1GB时有效，因为在启用OPTEE后，Bootloader中可用的RAM大小有限。

+
+

下面这些步骤展示如何通过USB设备更新eMMC。将启动模式开关配置为 bootmode switch (S1) 并插入SD卡。给开发板上电并进入U-Boot环境。将已存储了未压缩WIC镜像的优盘插入开发板USB接口。

+

将镜像从USB设备加载到RAM中：

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} *.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. 在运行的Linux系统中从USB烧写eMMC

+

下面这些步骤展示如何在Linux系统上使用USB大容量存储设备烧写eMMC。您需要一个保存了完整镜像的U盘和一个可从SD卡启动的核心板（例如 phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic）。将引导模式开关设置为 bootmode switch (S1)。

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ cd /mnt
+target:~$ ls
+phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic
+
    +
    +
    • +

  • 显示可用的MMC设备列表：

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • eMMC设备的特征是它包含两个boot分区：(mmcblk2boot0; mmcblk2boot1)

    • +

  • 将镜像写入 phyCORE-i.MX 8M Mini eMMC（无分区的 MMC 设备 2）：

    +
    target:~$ dd if=phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic of=/dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    • +
+
+

警告

+

在此之前，您需要将启动配置开关配置 bootmode switch (S1) 设置为 默认SOM启动。

+
+
+
+
+

4.2.4. 从SD卡烧写eMMC

+

即使没有可用的网络，您也可以更新eMMC。为此，您需要一个位于SD卡上的镜像文件（ *.wic ）。由于镜像文件相当大，您需要在SD卡创建第三个分区。要创建新分区或扩展您的SD卡，请参见 Resizing ext4 Root Filesystem 。

+
+

4.2.4.1. 在u-boot上从SD卡烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1GB的情况下有效，因为在启用OPTEE后，Bootloader中可用的RAM大小有限。如果镜像文件太大，请使用“在目标上使用Linux从SD卡更新eMMC”一节。

+
+
    +

  • 将一个可用的镜像烧写到SD卡，并创建一个FAT格式的第三分区。将WIC镜像（例如 phytec-qt5demo-image.wic）复制到该分区。

    • +

  • 将启动模式开关配置为从SD卡启动，并插入SD卡。

    • +

  • 给开发板上电并进入u-boot环境。

    • +

  • 将您的WIC镜像（例如 phytec-qt5demo-image.wic）从SD卡烧写到eMMC。这将对卡进行分区，并将imx-boot、Image、dtb、dtbo和根文件系统复制到eMMC。

    • +

  • 加载镜像：

    +
    u-boot=> fatload mmc 1:3 ${loadaddr} phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • 切换mmc设备：

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc0(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • 关闭电源，将启动模式开关切换到默认SOM启动，以从eMMC启动。

    • +
+
+
+

4.2.4.2. 在开发板的linux环境中通过SD卡烧写eMMC

+

您也可以在Linux上烧写eMMC。您只需在SD卡上保存一个完整的镜像（例如 phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic）。

+
    +

  • 查看您在SD卡上保存的镜像文件：

    +
    target:~$ ls
+phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic
+
    +
    +
    • +

  • 显示可用的MMC设备列表：

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • eMMC设备的特征是它包含两个boot分区：(mmcblk2 boot0; mmcblk2 boot1)

    • +

  • 将镜像写入 phyCORE-i.MX 8M Mini 的 eMMC (MMC 设备 2 不带 分区)：

    +
    target:~$ dd if=phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic of=/dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    • +
+
+

警告

+

在此之前，您需要将 bootmode switch (S1) 配置为默认SOM启动，以从eMMC启动。

+
+
+
+
+
+

4.3. 烧写 SPI NOR Flash

+

phyCORE-i.MX8MM 模块可选配SPI NOR Flash。要从SPI Flash启动，请将 bootmode switch (S1) 设置为 QSPI启动 以从QSPI启动。SPI Flash通常容量较小。phyBOARD-Pollux-i.MX8MP套件仅配备32MB SPI NOR Flash。只能存储bootloader及其环境。内核、设备树和文件系统默认保存在eMMC。

+

SPI NOR Flash分区表在U-Boot环境变量中定义。可以通过以下命令打印：

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. 通过网络烧写SPI NOR Flash

+

SPI NOR可以包含bootloader及其环境变量。arm64的linux内核无法自行解压缩，内核镜像大小超出了phyCORE-i.MX 8M Mini 上的SPI NOR Flash的容量。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！设置主机网络。

+
+
+

4.3.1.1. 在开发板的u-boot环境中从网络烧写SPI NOR

+

与通过网络更新eMMC类似，请确保正确设置开发主机。IP需要设置为192.168.3.10，子网掩码设置为255.255.255.0，并且需要有一个TFTP服务器。在进行读写操作之前，需要对SPI-NOR Flash进行probe：

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • 需要用特殊格式的SPI NOR Flash u-boot镜像。请确保使用正确的镜像文件。通过tftp加载镜像，擦除并将bootloader写入flash：

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+

警告

+

在写满后擦除整个SPI NOR Flash将需要相当长的时间。这可能会触发看门狗复位。因此，请在Linux中擦除整个闪存。

+
+
+
+

4.3.1.2. 在开发板linux环境中通过网络烧写SPI NOR Flash

+
    +

  • 将镜像从主机复制到开发板：

    +
    host:~$ scp imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • 找到U-boot分区的擦除块数量：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除u-boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+

4.3.2. 从SD卡烧写SPI NOR Flash

+

SPI NOR Flash上的bootloader也可以通过SD卡进行烧写。

+
+

4.3.2.1. 在开发板的u-boot环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi复制到SD卡的FAT分区。在进行读写操作之前，需要对SPI-NOR flash进行probe：

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像，请确保使用正确的镜像文件。从SD卡加载镜像，擦除并将bootloader写入flash：

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+

警告

+

在写满后擦除整个SPI NOR Flash将需要相当长的时间。这可能会触发看门狗复位。因此，请在Linux中擦除整个闪存。

+
+
+
+

4.3.2.2. 在开发板的linux环境中从SD卡烧写SPI NOR

+
    +

  • 挂载SD卡：

    +
    host:~$ mount /dev/mmcblkp1 /mnt
+
    +
    +
    • +

  • 查找u-boot分区的擦除块数量：

    +
    target:~$  mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除u-boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC：L-1006e.A3 RAUC 更新与设备管理手册。

+
+
+
+

5. 开发

+
+

5.1. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.1.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.2. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.2.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核镜像复制到您的tftp目录中：

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • 将设备树复制到您的tftp目录：

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • 将您想要使用的所有overlay文件复制到您的tftp目录中：

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-qt5demo-image-phyboard-polis-imx8mm-5.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.2.2. 设置网络启动的bootenv.txt文件

+

在您的tftp目录中创建一个bootenv.txt文件，并将以下变量写入其中。

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> 必须替换为您想要使用的overlay设备树文件名。用空格分隔文件名。例如：

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

小技巧

+

所有支持的设备树overlay在 device tree 章节中。

+
+
+
+

5.2.3. 开发板上的网络设置

+

如果要自定义开发板上的以太网配置，请按照此处的说明进行操作： Network Environment Customization

+
+
+

5.2.4. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.3.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. 获取镜像

+

可以从我们的服务器下载imx-boot，或者从Yocto编译目录中的build/deploy/images/phyboard-polis-imx8mm-5/获取它。要将wic镜像烧写到eMMC，你还需要 phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic。

+
+
+

5.3.3. 开发板准备

+

将 bootmode switch (S1) 设置为 USB串行下载。同时，将 USB 端口 X2 连接到主机。

+
+
+

5.3.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 (X30) 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.3.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic
+
+
+
+
+
+

5.4. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone git://git.phytec.de/u-boot-imx）

+
+
+

5.4.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-imx 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • 我们的 i.MX 8M Mini 内核是基于 linux-imx 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. 获取SDK

+

您可以在此处下载SDK 这里，或者使用Yocto去编译生成SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt5demo-image # or another image
+
    +
    +
    • +
+

在成功编译后，SDK安装包保存在 build/deploy*/sdk。

+
+
+

5.4.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt5demo-image-cortexa53-crypto-toolchain-BSP-Yocto-NXP-i.MX8MM-PD22.1.1.sh
+host:~$ ./phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt5demo-image-cortexa53-crypto-toolchain-BSP-Yocto-NXP-i.MX8MM-PD22.1.1.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MM-PD22.1.1):
+You are about to install the SDK to "/opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MM-PD22.1.1". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. 单独编译U-Boot

+
+

5.5.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本的 tag 称为 v2021.04_2.2.0-phy13

    • +

  • 查看所需的 U-Boot tag：

    • +
+
host:~$ cd ~/u-boot-imx/
+host:~$ git fetch --all --tags
+host:~$ git checkout tags/v2021.04_2.2.0-phy13
+
+
+
    +

  • 从技术上讲，您现在可以编译U-Boot，但实际上还需要一些进一步的步骤：

    +
      +

    • 创建您自己的开发分支：

      +
      host:~$ git switch --create <new-branch>
+
      +
      +
      +

      备注

      +

      您可以根据您的需要自行命名您的开发分支，这只是一个示例。

      +
      +
      • +
    +
    • +

  • 设置编译环境：

    +
    host:~$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +

  • 在编译镜像之前，请设置此环境变量：

    +
    host:~$ export ATF_LOAD_ADDR=0x920000
+
    +
    +
    • +
+
+
+

5.5.2. 获取所需的二进制文件

+

要编译bootloader，您需要将这些文件复制到您的 u-boot-imx 编译目录，并将其重命名以适应 mkimage 脚本：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx8mm.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以在yocto工程目录中获取 bl31-imx8mm.bin、tee.bin和lpddr4_*.bin：BSP Images

+

或者你可以在这里下载文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/imx-boot-tools/

+
+

警告

+

确保您重命名所需的文件，以和 mkimage tool 兼容。

+
+
+
+

5.5.3. 编译bootloader

+
    +

  • 编译 flash.bin (imx-boot):

    +
    host:~$ make phycore-imx8mm_defconfig
+host:~$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. 将bootloader烧写到块设备上

+

flash.bin 文件可以在 u-boot-imx/ 目录中找到。需要一个特定于芯片的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 8M Mini

33 kiB

33 kiB

/dev/mmcblk2

+

例如，烧写SD卡：

+
host:~$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=33 conv=sync
+
+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+

5.5.5. 使用固定内存大小编译U-Boot

+

如果您的系统因为EEPROM中的硬件信息损坏或丢失而无法启动，您可以创建一个具有固定RAM大小的flash.bin。但您仍应联系我们支持部门以烧写正确的EEPROM数据。

+

按照步骤获取U-boot源代码，并切换到 Build U-Boot 章节说明的分支。

+

Edit the file configs/phycore-imx8mm_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MM=y
+CONFIG_PHYCORE_IMX8MM_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_4GB=y
+
+
+

选择正确的RAM大小，确保与核心板上的贴装的器件一致，取消注释该RAM大小的行。保存更改后，按照 Build U-Boot 章节的剩余步骤进行操作。

+
+
+
+

5.6. 单独编译内核

+
+

5.6.1. 配置源代码

+
    +

  • 使用的 linux-imx 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v5.10.72_2.2.0-phy17

    • +

  • Check out 所需的 linux-imx 标签：

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v5.10.72_2.2.0-phy17
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-imx$ make imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-imx/arch/arm64/boot/Image 找到

    • +

  • dtb文件可以在 ~/linux-imx/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. 将内核复制到SD卡

+

内核及module和对应的设备树二进制文件可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. 获取BSP开发中版本

+
+

5.7.1. 当前release的开发中版本

+

这些release manifest文件是为了让您访问 Yocto BSP的开发版本。它们不会在phyLinux选择菜单中显示，需要手动选择。可以使用以下命令行来完成此操作：

+
host:~$ ./phyLinux init -p imx8mm -r BSP-Yocto-NXP-i.MX8MM-PD22.1.y
+
+
+

这将初始化一个BSP，用于跟踪当前版本（ BSP-Yocto-NXP-i.MX8MM-PD22.1.1 ）的最新开发版本。从现在开始，在此文件夹中执行 repo sync 将从我们的Git仓库中拉取所有最新的更改：

+
host:~$ repo sync
+
+
+
+
+

5.7.2. 即将发布版本的开发中版本

+

即将发布版本的开发中版本可以通过这种方式访问。请执行以下命令，并查找一个比最新版本（ BSP-Yocto-NXP-i.MX8MM-PD22.1.1 ）的PDXX.Y数字更高的版本，并且以 .y 结尾：

+
host:~$ ./phyLinux init -p imx8mm
+
+
+
+
+
+

5.8. 获取最新的Upstream支持

+

我们有一个使用Yocto主分支（不是NXP发布的）的manifest，他使用upstream的Linux和U-Boot。这可以用来测试最新的upstream kernel/U-Boot。

+
+

备注

+

master分支的manifest反映了最新的开发状态。有时会出现一些bug。我们会定期修复master分支。

+
+
host:~$ ./phyLinux init -p imx8mm -r BSP-Yocto-Ampliphy-i.MX8MM-master
+
+
+
+
+

5.9. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.9.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将 phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将 phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic 镜像复制到其中。然后卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt5demo-image-phyboard-polis-imx8mm-5.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 8M Mini BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 8M Mini 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Carrierboard.dtsi - 包括来自于 i.MX 8M Mini SoC 的外设，在底板上使用的外设的设备树配置包含在这个 dtsi 中。

    • +

  • Board.dts - 包含底板和核心板的dtsi文件。以及使能一些底板或核心板上的器件和配置。例如，phyCORE-i.MX 8M Mini 核心板可能安装MIPI DSI到LVDS的转换器也可能没有，则Board.dts文件会根据安装情况来对该转换器进行使能配置。而不是在Module.dtsi中配置

    • +
+

在Linux内核的根目录下，我们的 i.MX 8 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。例如扩展板的硬件描述。对比源码中的include，overlay是用覆盖的方式来生效。overlay也可以根据节点是否连接来设置节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/overlays 中。

+

phyboard-polis-imx8mm-5.conf 可用的overlay文件有：

+
imx8mm-phyboard-polis-peb-eval-01.dtbo
+imx8mm-phyboard-polis-peb-av-010.dtbo
+imx8mm-phycore-rpmsg.dtbo
+imx8mm-phycore-no-eth.dtbo
+imx8mm-phycore-no-spiflash.dtbo
+imx8mm-vm016.dtbo
+imx8mm-vm016-fpdlink.dtbo
+imx8mm-vm017.dtbo
+imx8mm-vm017-fpdlink.dtbo
+imx8mm-dual-vm017-fpdlink.dtbo
+
+
+

可以在Linux或U-Boot环境下配置overlay。overlay是在引导命令调用后、内核加载之前生效。接下来的部分将更详细地解释配置方法。

+
+

6.2.2.1. 设置 ${overlays} 变量

+

${overlays} U-Boot 环境变量包含一个以空格分隔的overlay文件列表，这些overlay文件将在启动过程中应用。根据启动源，overlay文件必须放置在 eMMC/SD 卡的启动分区中，或者通过 tftp 加载。在 $KERNEL_DEVICETREE 这个 Yocto machine 变量中设置的 overlay 文件将自动添加到最终 WIC 镜像的启动分区中。

+

${overlays} 变量可以直接在U-Boot环境中设置，也可以作为外部 bootenv.txt 环境文件的一部分。默认情况下， ${overlays} 变量来自位于启动分区的 bootenv.txt 文件。您可以在已启动的开发板上从Linux读取和写入该文件：

+
target:~$ cat /boot/bootenv.txt
+overlays=imx8mm-phyboard-polis-rdk-peb-eval-01.dtbo imx8mm-phyboard-polis-peb-av-010.dtbo
+
+
+

更改将在下次重启后生效。如果没有可用的 bootenv.txt 文件，可以直接在U-Boot环境中设置overlay变量。

+
u-boot=> setenv overlays imx8mm-phyboard-polis-peb-av-010.dtbo
+u-boot=> printenv overlays
+overlays=imx8mm-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

如果用户定义了 ${overlays} 变量，同时存在 bootenv.txt 文件，则需要设置 ${no_bootenv} 变量：

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx8mm-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

有关环境的更多信息，请参见 U-boot External Environment subsection of the +device tree overlay section。

+

我们使用 ${overlays} 变量来描述在运行时无法自动检测的扩展板和摄像头。如果想禁用 ${overlays} 变量中列出的overlay，可以在U-Boot的环境中将 ${no_overlays} 变量设置为 1。

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+

6.2.2.2. 扩展命令

+

使用U-Boot扩展命令能够轻松加载由回调函数 extension_board_scan() 检测并添加到列表中的overlay。以这种方式应用的overlay会禁用核心板上未贴装的组件。检测是通过读取出厂EEPROM数据（EEPROM SoM Detection）来实现的。

+

这取决于核心板型号是否会应用任何设备树overlay。要检查在U-Boot中运行的SoM是否会应用overlay，请运行：

+
u-boot=> extension scan
+Found 1 extension board(s).
+u-boot=> extension list
+Extension 0: phyCORE-i.MX8MM no SPI flash
+        Manufacturer:           PHYTEC
+        Version:
+        Devicetree overlay:     imx8mm-phycore-no-spiflash.dtbo
+        Other information:      SPI flash not populated on SoM
+
+
+

如果没有可用的EEPROM数据，则不加载任何设备树overlay。

+

为了禁止在启动时自动运行扩展命令，可以在bootloader环境中将 ${no_extensions} 变量设置为 1 ：

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot外部环境

+

在Linux内核启动时，外部环境 bootenv.txt 文本文件将从MMC设备的boot分区或通过TFTP加载。该文件的主要目的是存储 ${overlays} 变量。这可以针对不同的machine在Yocto中预定义不同的overlay配置。文件的内容在meta-phytec中的Yocto recipe中的bootenv中定义： https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=hardknott

+

该文件中也可以设置其他变量。这些变量将覆盖环境中现有的设置。但只有对boot命令后进行计算的变量生效，例如 ${nfsroot} 或 ${mmcargs}。在文件中更改其他变量将不会有作用。以网络启动的用法作为示例。

+

如果无法加载外部环境，启动过程将继续进行，并使用自带的环境变量值。

+
+
+

6.2.4. 在Linux环境下更改开发板上的U-boot环境变量

+

Libubootenv是我们镜像中包含的一个工具，用于在开发板linux上修改U-Boot环境。

+

使用以下命令打印U-Boot环境：

+
target:~$ fw_printenv
+
+
+

使用以下命令修改U-Boot环境：

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

小心

+

Libubootenv会读取配置文件中配置的环境变量。要修改的环境变量会被插入到该文件中，默认情况下使用eMMC中存储环境变量。

+

如果eMMC没有被烧写过或者eMMC环境被擦除，libubootenv将无法工作。您应该修改 /etc/fw_env.config 文件，以匹配您想要使用的环境源。

+
+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 8M Mini BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 8M Mini BSP设备树概念部分，以了解我们的 i.MX 8 BSP设备树模型。

+

以下部分概述了 i.MX 8 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 8M Mini 引脚复用

+

该 i.MX 8M Mini Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 8M Mini 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 8M Mini 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是imx8mm-phyboard-polis.dtsi中UART1设备的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX     0x00
+                MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX      0x00
+                MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B  0x00
+                MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B  0x00
+        >;
+};
+
+
+

字符串的第一部分 MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX 指定了引脚（在这个例子中是 SAI2_RXFS）。字符串的第二部分（UART1_DCE_RX）是该引脚当前的复用选项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部上拉电阻是否被激活。在当前配置中，内部电阻是禁用的。

+
+
+

7.2. RS232/RS485

+

i.MX 8M Mini SoC 提供最多 4 个 UART 单元。PHYTEC 开发板支持不同数量 UART 单元。UART1 也可以用作 RS-485。为此，需要正确设置 bootmode switch (S1)：

+ + + + + + + +
切换UART1的RS485和RS232模式
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+

7.2.1. RS232

+
    +

  • 以人类可读的格式显示终端的当前设置：

    +
    target:~$ stty -a
+
    +
    +
    • +

  • UART接口的配置可以通过stty命令完成。例如：

    +
    target:~$ stty -F /dev/ttymxc0 115200 crtscts raw -echo
+
    +
    +
    • +

  • 通过简单的echo和cat，可以测试基本的通信。示例：

    +
    target:~$ echo 123 > /dev/ttymxc0
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

主机应打印出 "123"。

+
+
+

7.2.2. RS485

+
+

提示

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

为了方便测试，请查看linux-serial-test。这个工具会通过调用RS485的IOCTL，发送恒定的数据流。

+
target:~$ linux-serial-test -p /dev/ttymxc0 -b 115200 --rs485 0
+
+
+

有关linux-serial-test工具及其参数的更多信息，请访问此链接：linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Linux kernel文档描述了如何在C代码中调用IOCTL： https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+

RS232和RS485的设备树表示：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n188

+
+
+
+

7.3. 网络

+

phyBOARD-Polis-i.MX 8M Mini 提供一个千兆以太网接口。

+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n53。

+

+
+

7.3.1. 网络配置

+
+

7.3.1.1. U-boot网络环境

+
    +

  • 要在bootloader中查找以太网设置：

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • 在将主机设置为IP 192.168.3.10和子网掩码255.255.255.0的情况下，开发板应该返回：

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • 如果您需要进行任何更改：

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> 应该是 ipaddr、netmask、gatewayip 或 serverip 中的一个。<value> 将是所选参数的设定值。

    +
    • +

  • 您所做的更改目前是临时的。要保存这些更改：

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

在这里，您也可以将IP地址更改为DHCP，而不是使用静态IP地址。

+
    +

  • 配置：

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • 设置 TFTP 和 NFS 的路径。修改可以如下所示：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+

小技巧

+

像nfsroot和netargs这样的变量可以被U-boot外部环境重新赋值。对于网络启动，外部环境将通过tftp加载。例如，要在 bootenv.txt 文件中设置nfsroot变量，请在tftproot目录修改：

+
nfsroot=/home/user/nfssrc
+
+
+

无需在开发板上存储这些信息。请注意，U-boot外部环境对于像 ipaddr 或 serveraddr 这样的变量不起作用，因为它们在加载外部环境之前已经被设置完成。

+
+
+
+

7.3.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. 无线局域网

+

为了支持WLAN和蓝牙，我们使用来自LSR的Sterling-LWB模块。该模块支持2.4 GHz，并且可以在多种模式下运行，如客户端模式、使用WEP、WPA、WPA2加密的接入点（AP）模式等。有关该模块的更多信息，请访问 https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. 连接到WLAN网络

+

首先设置您所在国家的正确监管域：

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

你将会看到：

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

设置无线接口：

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

现在您可以扫描可用的网络：

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

您可以使用一个跨平台的客户端，名为wpa_supplicant，支持WEP、WPA和WPA2，以建立加密连接。

+

为此，请将网络凭据添加到文件 /etc/wpa_supplicant.conf 中：

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

现在可以建立连接：

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

这会得到如下输出：

+
...
+ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

要完成配置，您可以配置DHCP以接收IP地址（大多数WLAN接入点都支持）。有关其他可能的IP配置，请参阅 L-813e.A13 Yocto Reference Manual (hardknott) 中的“更改网络配置”部分。

+

首先，创建目录：

+
target:~$ mkdir -p /etc/systemd/network/
+
+
+

然后在 /etc/systemd/network/10-wlan0.network 中添加以下配置片段：

+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+

现在，请重启网络守护进程以使配置生效：

+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+
+

7.3.3. 蓝牙

+

Bluetooth is connected to UART2 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

现在您可以扫描环境中的可见蓝牙设备。在默认配置下，蓝牙是不可见的。

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. 可见性

+

要激活可见性：

+
target:~$ hciconfig hci0 piscan
+
+
+

要禁用可见性：

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. 连接

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

备注

+

如果连接失败并出现错误信息：“连接失败：org.bluez.Error.Failed”，请尝试使用以下命令重新启动PulseAudio：

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC 卡

+

该 i.MX 8M Mini 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

MMC（SD卡插槽）接口的DT配置可以在这里找到： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n266

+

eMMC接口的DT配置可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n315

+
+
+

7.5. eMMC设备

+

PHYTEC模块，如phyCORE-i.MX 8M Mini，配备了一个eMMC存储芯片作为主要存储。eMMC设备包含MLC存储单元，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 8M Mini，并在Linux内核中被表示为块设备，类似于SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.5.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），负责处理原始MLC单元的磨损平衡、块管理和错误纠正码（ECC）。这需要定期进行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+

mmc这个linux工具目前不支持启用自动BKOPS功能。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops enable /dev/mmcblk2
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.5.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 8M Mini SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n> <partition> <device>
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.5.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
    +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+
+
+

7.5.5. 启用伪SLC模式

+

eMMC设备使用 多层单元内存（MLC） 来存储数据。与NAND Flash中使用的单层单元（SLC）内存单元相比，MLC内存单元具有更低的可靠性和更高的错误率，但成本更低。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. 擦除设备

+

可以直接擦除eMMC设备，而不是用零覆盖它。eMMC块管理算法将会擦除MLC存储单元或将这些块标记为丢弃。设备上的数据将丢失，并且读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.5.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 8M Mini 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.5.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

下表是 i.MX 8M Mini SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 8M Mini

33 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.6. SPI主设备

+

i.MX 8M Mini 控制器包含一个 FlexSPI 和一个 ECSPI IP 核。FlexSPI 主控制器支持两个 SPI 通道，最多可连接 4 个设备。每个通道支持单通道/双通道/四通道/八通道模式的数据传输（1/2/4/8 条数据线）。ECSPI 控制器支持 3 个 SPI 接口，每个接口都有一个专用的CS（chip select）引脚。由于CS也可通过 GPIO 实现，因此每个通道上可以连接多个设备。

+
+

7.6.1. SPI NOR 烧写

+

phyCORE-i.MX 8M Mini 配备有一个 QSPI NOR Flash，该 Flash 连接到 i.MX 8M Mini 的 FlexSPI 接口。QSPI NOR Flash 可用于启动。有关烧写和启动模式设置的详细信息，请参见不同的章节。由于 SPI NOR Flash 的空间有限，因此仅可存储bootloader。默认情况下，内核、设备树和根文件系统来自 eMMC。

+

bootloader程序通过EEPROM数据检测是否安装了SPI Flash。如果没有安装SPI Flash，则在启动期间应用设备树overlay，通过扩展命令禁用SPI Flash设备树节点。如果没有可用的EEPROM数据，SPI NOR Flash节点将始终启用。有关更多信息，请参阅设备树overlay部分。

+

bootloader程序还可以通过内核的mtdparts启动参数修改设备树，将SPI MTD分区表传递给Linux。BSP中的默认分区布局设置为：

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

这是一个预定义的bootloader环境变量，可以在运行时更改。从Linux用户空间，可以通过/dev/mtd<N>设备访问NOR Flash分区，其中<N>是与要访问的NOR Flash分区相关联的MTD设备编号。要找到分区的正确MTD设备编号，请在目标上运行：

+
root@phyboard-polis-imx8mm-5:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

它列出了所有MTD设备及其对应的分区名称。闪存节点在模块DTS中的SPI主节点内定义。SPI节点包含连接到此SPI总线的所有设备，在这种情况下只有SPI NOR Flash。

+

设备树中SPI主节点的定义可以在这里找到：

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy9#n71

+
+
+
+

7.7. GPIOs

+

phyBOARD-Polis 具有一组专门用于GPIO的引脚。这些引脚直接连接到 i.MX 8M Mini 引脚，并被复用为 GPIO。它们可以直接在 Linux 用户空间中使用。处理器将其 GPIO 组织为5个GPIO组（GPIO1 – GPIO5），每个组包含 32 个GPIO。gpiochip0、gpiochip32、gpiochip64、gpiochip96 和 gpiochip128 是这些内部 i.MX 8M Mini GPIO 组 GPIO1 – GPIO5 的 sysfs 表示。

+

GPIO被标识为GPIO<X>_<Y>（例如：GPIO5_07）。<X>表示GPIO Bank，从1计数到5，而<Y>表示该Bank内的GPIO。<Y>从0计数到31（每个bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如从gpiochip0的GPIO 20）：

    +
    target:~$ gpioget gpiochip0 20
+
    +
    +
    • +

  • 将gpiochip0上的GPIO 20的值设置为0并退出工具：

    +
    target:~$ gpioset --mode=exit gpiochip0 20=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.7.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用 CONFIG_GPIO_SYSFS 后才能支持。要在menuconfig中使 CONFIG_GPIO_SYSFS 可见，必须首先启用选项 CONFIG_EXPERT 。

+

您也可以将此选项添加到您在 Linux 内核源代码 arch/arm64/configs/ 目录下使用的 defconfig 中。例如，我们基于 NXP 的BSP版本，这个defconfig可以是 imx8_phytec_distro.config

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

您也可以创建一个新的config片段。有关详细信息，请参阅我们的《Yocto参考手册<yocto-ref-manual-kernel-and-bootloader-config>》。

+

设备树中的某些GPIO引脚的引脚复用 imx8mm-phyboard-polis-rdk.dtsi:

+
pinctrl_leds: leds1grp {
+        fsl,pins = <
+                MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1       0x16
+                MX8MM_IOMUXC_GPIO1_IO14_GPIO1_IO14      0x16
+                MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x16
+        >;
+};
+
+
+
+
+
+

7.8. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+mmc1::@    mmc2::@    user-led1@ user-led2@ user-led3@
+
+
+

这里的 LED 灯包括蓝色的 mmc、绿色的 心跳和红色的 emmc，它们都在 phyBOARD-Polis 上。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 255 > /sys/class/leds/user-led1/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/user-led1/brightness
+
    +
    +
    • +
+

GPIO的设备树配置可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n37

+
+
+

7.9. I²C总线

+

该 i.MX 8M Mini 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 8M Mini 的I²C模块。 本节描述了我们 phyBOARD-Polis 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

I²C1 总线配置（例如 imx8mm-phycore-som.dtsi）：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy#n102

+

I²C4总线配置（例如 imx8mm-phyboard-polis-rdk.dtsi）：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n149

+
+
+

7.10. EEPROM

+

在 phyCORE-i.MX8MM 上有一个i2c EEPROM闪存。它有两个地址。主EEPROM空间（总线：I2C-0 地址：0x51）和ID页（总线：I2C-0 地址：0x59）可以通过Linux中的sysfs接口进行访问。主EEPROM和ID页的前256个字节用于板检测，不可被覆盖。覆盖保留的空间将导致启动问题。

+
+

7.10.1. phyCORE-i.MX8MM 上的I2C EEPROM

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

phyCORE-i.MX8MM SoM上的I2C EEPROM连接到I2C-0总线的I2C地址0x51。可以直接对该设备进行读写操作：

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

要用零填充4KiB的EEPROM（总线：I2C-0 地址：0x51），并保留EEPROM数据，请使用：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM 检测

+

在 phyCORE-i.MX8MM 上配置的I2C EEPROM具有一个可通过I2C地址0x59在i2c0上寻址的独立ID页面，以及一个可通过I2C地址0x51在i2c0上寻址的正常区域。PHYTEC使用这个32字节的数据区域来存储关于SoM的信息，包括PCB版本和配置。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果EEPROM ID页面数据和正常区域的前256个字节被删除，bootloader程序将回退到 phyCORE-i.MX8MM Kit RAM设置，即 2GiB RAM。

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

使用API修订版2数据格式烧写的核心板将在早期启动阶段打印出有关模块的信息。

+
+
+

7.10.3. 恢复EEPROM数据

+

硬件数据已预先写入两个EEPROM数据空间。如果您不小心删除或覆盖了Normal区域，可以将ID区域的硬件检查数据复制到正常区域。

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1
+
+
+
+

备注

+

如果您删除了两个EEPROM空间，请联系我们的支持团队！

+
+

phyCORE-i.MX 8M Mini 文件 imx8mm-phycore-som.dtsi 可以在我们的PHYTEC git中找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n271

+
+
+
+

7.11. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC唤醒alarm

+

可以从实时时钟（RTC）发出中断以唤醒系统。该格式使用Unix纪元时间，即自1970年1月1日UTC午夜以来的秒数。要在从挂起到RAM状态后的4分钟唤醒系统，请输入：

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

备注

+

内部唤醒alarm时间将被向上舍入到下一个分钟，因为alarm功能不支持秒。

+
+

I²C RTC的DT：：imx-dt:imx8mm-phycore-som.dtsi?h=v5.10.72_2.2.0-phy9#n277

+
+
+
+

7.12. USB主控制器

+

i.MX 8M Mini SoC的USB控制器为众多消费类便携设备提供了一种低成本的连接以及数据传输解决方案，传输速率最高可达480 Mbps（高速 'HS'）。USB子系统具有两个独立的USB控制器IP。两个IP都是即插即用（OTG）控制器IP，能够充当USB外设设备或USB主机。每个IP都连接到一个USB 2.0物理层（PHY）。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+

USB2（host）配置在内核设备树 imx8mm.dtsi:

+
&usbotg2 {
+        dr_mode = "host";
+        picophy,pre-emp-curr-control = <3>;
+        picophy,dc-vol-level-adjust = <7>;
+        status = "okay";
+};
+
+
+

USB Host的DT：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy9#n240

+
+
+

7.13. USB OTG

+

大多数PHYTEC板提供USB OTG接口。USB OTG端口会自动作为USB设备或USB主机工作。模式取决于连接到USB OTG端口的USB硬件。例如，如果将USB大容量存储设备连接到USB OTG端口，该设备将显示为 /dev/sda 。

+
+

7.13.1. 作为USB设备

+

为了将开发板作为USB设备连接到USB主机（例如PC），您需要配置相应的USB gadget。通过USB configfs，您可以定义USB gadget的参数和功能。BSP包含作为kernel module 的USB configfs支持。

+
target:~$ modprobe libcomposite
+
+
+

例子:

+
    +

  • 首先，定义参数，例如USB Vendor和product ID，并为英语（0x409）设置信息字符串：

    • +
+
+

提示

+

为了节省时间，请复制这些命令并在脚本中执行它们

+
+
cd /sys/kernel/config/usb_gadget/
+mkdir g1
+cd g1/
+echo "0x1d6b" > idVendor
+echo "0x0104" > idProduct
+mkdir strings/0x409
+echo "0123456789" > strings/0x409/serialnumber
+echo "Foo Inc." > strings/0x409/manufacturer
+echo "Bar Gadget" > strings/0x409/product
+
+
+
    +

  • 接下来，为大容量存储 gadget 创建一个文件：

    • +
+
target:~$ dd if=/dev/zero of=/tmp/file.img bs=1M count=64
+
+
+
    +

  • 现在你可以创建你想要使用的功能：

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir functions/acm.GS0
+mkdir functions/ecm.usb0
+mkdir functions/mass_storage.0
+echo /tmp/file.img > functions/mass_storage.0/lun.0/file
+
+
+
    +

  • acm: 串行设备 gadget，创建类似 /dev/ttyGS0 的串行接口。

    • +

  • ecm: 以太网 gadget，创建以太网接口，例如 usb0

    • +

  • mass_storage: 主机可以像处理其他USB大容量存储设备一样，对设备的大容量存储进行分区、格式化和挂载。

    • +
+
    +

  • 将定义的功能绑定到配置：

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir configs/c.1
+mkdir configs/c.1/strings/0x409
+echo "CDC ACM+ECM+MS" > configs/c.1/strings/0x409/configuration
+ln -s functions/acm.GS0 configs/c.1/
+ln -s functions/ecm.usb0 configs/c.1/
+ln -s functions/mass_storage.0 configs/c.1/
+
+
+
    +

  • 最后，使用以下命令启动USB gadget：

    • +
+
target:~$ cd /sys/kernel/config/usb_gadget/g1
+target:~$ ls /sys/class/udc/
+ci_hdrc.0
+target:~$ echo "ci_hdrc.0" >UDC
+
+
+

如果您的系统有多个USB设备或OTG端口，您可以将正确的端口传递给USB设备控制器（UDC）。

+
    +

  • 要停止USB gadget 并解除绑定已使用的功能，请执行：

    • +
+
target:~$ echo "" > /sys/kernel/config/usb_gadget/g1/UDC
+
+
+

两个USB接口在内核设备树imx8mm-phyboard-polis.dtsi中配置为Host。请参见：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n228

+
+
+
+

7.14. CAN FD

+

The phyBOARD-Polis has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
+

提示

+

phyBOARD-Polis 具有一个通过 SPI 连接的外部 CAN FD 芯片 MCP2518FD。由于使用了SPI，限制了 CAN FD 的数据传输速率上限。

+
+
+

提示

+

在phyBOARD-Polis-i.MX8MM上，如果需要，可以通过将S5设置为ON来启用端接电阻。

+
+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。两个CAN接口显示为can0和can1。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    can0的信息将如下所示：

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+
+

警告

+

mcp2518fd SPI到CAN FD只支持从125kB/s开始的波特率。可以选择更慢的速率，但可能无法正常工作。

+
+

imx8mm-phyboard-polis.dtsi的设备树CAN配置： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n106

+
+
+

7.15. PCIe

+

phyCORE-i.MX 8M Mini 具有一个 Mini-PCIe 插槽。一般来说，PCIe 会自动检测总线上的新设备。在连接设备并启动系统后，您可以使用命令 lspci 查看所有被识别的 PCIe 设备。

+
    +

  • 输入：

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • 你将收到：

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

在这个例子中，PCIe设备是 英特尔 WiFi Link 5100 。

+

对于PCIe设备，您必须在内核配置中启用正确的驱动程序。例如，这款WLAN卡是由英特尔制造的。必须启用的驱动程序选项名为 CONFIG_IWLWIFI ，可以在内核配置中的 Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimate 下找到。

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • linux-imx的表示为：virtual/kernel

      • +
    +
    • +
+

对于某些设备，如WLAN卡，需要额外的二进制固件文件。这些固件文件必须放置在 /lib/firmware/ 目录中，才能使用该设备。

+
    +

  • 输入：

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • 例如，如果您尝试启动网络接口：

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • 您将在串口控制台上获得以下输出：

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

小技巧

+

某些PCIe设备，例如以太网卡，即使没有从 /lib/firmware/ 加载固件文件，也可能正常工作，而你收到了如上输出第一行所示的错误消息。这是因为一些制造商在板卡本身提供了固件作为后备。在这种情况下，设备的行为和输出在很大程度上依赖于制造商的固件。

+
+
+
+

7.16. 音频

+

PEB-AV-10-Connector有两个版本，其中1531.1版本配备了TI TLV320AIC3007音频编解码器（CODEC）。音频数据通过I2S传输，并通过I2C进行控制。

+

有一个符合OMTP标准的3.5mm耳机插孔和一个8针接口，用于连接带有AV连接器的音频设备。这个8针接口包含单声道扬声器、耳机和线路输入信号（line-in）。

+

要检查您的声卡驱动程序是否正确加载以及设备名称，请输入以下命令以查看播放设备：

+
target:~$ aplay -L
+
+
+

或输入录音设备：

+
target:~$ arecord -L
+
+
+
+

7.16.1. Alsamixer

+

要检查声卡的功能，请输入：

+
target:~$ alsamixer
+
+
+

您应该会看到很多选项，因为音频IC具有许多可以配置的功能选项。通过SSH打开alsamixer可能比通过串口控制台更好，因为控制台的图形效果更佳。您可以为所有混合点使用单声道或立体声增益控制。“MM”表示该功能被静音（左右输出均为静音），可以通过按 m 键切换。您还可以通过按'<'键切换左声道和'>'键切换右声道。使用 tab 键，您可以在播放和录音的控制之间切换。

+
+
+

7.16.2. ALSA配置

+

我们的BSP附带一个ALSA配置文件 /etc/asound.conf 。

+

ALSA配置文件可以根据需要进行编辑或删除，它并不是ALSA正常工作所必需的。

+
target:~$ vi /etc/asound.conf
+
+
+

要将PEB-AV-10设置为输出，请将playback.pcm从“dummy”设置为“pebav10”：

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

如果听不到声音，请将播放设备更改为软件音量控制播放设备，将 playback.pcm 设置为相应的软音量播放设备，例如“softvol_pebav10”。使用alsamixer控制来调整音量级别。

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.16.3. PulseAudio 配置

+

对于使用Pulseaudio的应用程序，请检查可用的输出设备：

+
target:~$ pactl list short sinks
+0   alsa_output.platform-snd_dummy.0.stereo-fallback    module-alsa-card.c  s16le 2ch 44100Hz   SUSPENDED
+1   alsa_output.platform-sound-peb-av-10.stereo-fallback    module-alsa-card.c  s16le 2ch 44100Hz   SUSPENDED
+
+
+

要选择PEB-AV-10，请输入：

+
target:~$ pactl set-default-sink 1
+
+
+
+
+

7.16.4. 播放

+

运行speaker-test以检查播放功能：

+
target:~$ speaker-test -c 2 -t wav
+
+
+

要播放简单的音频流，您可以使用aplay。例如，要播放ALSA测试音频：

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

要播放其他格式，例如mp3，您可以使用Gstreamer：

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.16.5. 录音

+

arecord 是一个命令行工具，用于录制音频流，默认输入源为线路输入。要选择不同的音频源，可以使用 alsamixer。例如，打开 右侧 PGA 混音器 Mic3R 和 左侧 PGA 混音器 Mic3R，以便通过 3.5mm 插孔录制来自 TLV320 编解码器的麦克风输入音频。

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

提示

+

由于播放和录音共享硬件接口，因此无法在同时进行播放和录音操作时使用不同的采样率和格式。

+
+

设备树音频配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mm-phyboard-polis-peb-av-010.dtso?h=v5.10.72_2.2.0-phy17#n56

+
+
+
+

7.17. 视频

+
+

7.17.1. 视频与Gstreamer

+

这个视频在BSP中默认安装：

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/phytec-qtdemo/videos/caminandes.webm
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=<video.mp4> \
+\! qtdemux  \! h264parse \! queue \! vpudec \! waylandsink async=false enable-last-sample=false \
+qos=false sync=false
+
+
+
    +

  • 或者：

    • +
+
target:~$ gplay-1.0 /usr/share/phytec-qtdemo/videos/caminandes.webm
+
+
+
+
+

7.17.2. kmssink 插件 ID 确认

+

kmssink插件需要一个连接器ID。要获取连接器ID，您可以使用工具modetest。

+
target:~$ modetest -c imx-drm
+
+
+

输出如：

+
Connectors:
+id  encoder status      name        size (mm)   modes   encoders
+35  34  connected   LVDS-1          216x135     1   34
+  modes:
+    index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
+  #0 1280x800 59.07 1280 1380 1399 1440 800 804 808 823 70000 flags: phsync, pvsync; type: preferred, driver
+  props:
+    1 EDID:
+        flags: immutable blob
+        blobs:
+
+        value:
+    2 DPMS:
+        flags: enum
+        enums: On=0 Standby=1 Suspend=2 Off=3
+        value: 0
+    5 link-status:
+        flags: enum
+        enums: Good=0 Bad=1
+        value: 0
+    6 non-desktop:
+        flags: immutable range
+        values: 0 1
+        value: 0
+    4 TILE:
+        flags: immutable blob
+        blobs:
+
+        value:
+
+
+
+
+
+

7.18. 显示

+

10英寸显示屏始终处于使能状态。如果PEB-AV连接器未连接，启动时可能会出现错误信息。

+
+

7.18.1. Qt Demo

+

使用phytec-qt5demo-image时，Weston会在启动时启动。可以通过以下命令停止phytec-qt5demo：

+
target:~$ systemctl stop phytec-qtdemo
+
+
+
    +

  • 要重新开始Demo，请运行：

    +
    target:~$ systemctl start phytec-qtdemo
+
    +
    +
    • +

  • 要禁用Demo的自动启动，请运行：

    +
    target:~$ systemctl disable phytec-qtdemo
+
    +
    +
    • +

  • 要启用Demo的自动启动，请运行：

    +
    target:~$ systemctl enable phytec-qtdemo
+
    +
    +
    • +

  • Weston可以通过以下方式停止：

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

备注

+

在关闭Weston之前，必须先关闭Qt Demo。

+
+
+
+

7.18.2. 背光控制

+

如果LCD连接到PHYTEC开发板，可以通过Linux内核的sysfs接口控制其背光。系统中所有可用的背光设备可以在文件夹/sys/class/backlight中找到。读取相应的文件并向其写入数据可以控制背光。

+
+

备注

+

一些具有多显示的开发板在 /sys/class/backlight 有多个背光控制。比如：backlight0和backlight1

+
+
    +

  • 例如，要获取最大亮度级别（max_brightness），请执行：

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    有效的亮度值范围是 0 到 <max_brightness>。

    +
    • +

  • 要获取当前亮度级别，请输入：

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • 写入文件brightness以更改亮度：

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    例如，关闭背光。

    +

    有关所有文件的文档，请参见 https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight。

    +
    • +
+

PEB-AV-10的设备树可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mm-phyboard-polis-peb-av-010.dtso?h=v5.10.72_2.2.0-phy17

+
+
+
+

7.19. 电源管理

+
+

7.19.1. CPU核心频率调节

+

i.MX 8M Mini SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。调整频率和电压被称为“动态电压和频率调整”（DVFS）。i.MX 8M Mini BSP支持DVFS功能。Linux内核提供了一个DVFS框架，允许每个CPU核心设置最小或最大频率和一个管理其运行的governor。根据使用的 i.MX 8 型号，支持几种不同的频率。

+
+

小技巧

+

尽管DVFS框架为每个CPU核心提供了频率设置，但一个CPU核心的频率更改会影响其他CPU核心。因此，所有CPU核心始终共享相同的DVFS设置。每个核心的单独DVFS设置是不可能的。

+
+
    +

  • 要获取完整列表，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    例如 i.MX 8MPlus CPU，最高可达约 1.6 GHz，则结果将是：

    +
    1200000 1600000
+
    +
    +
    • +

  • 要查询当前的频率输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

governor 会根据它们的目标自动选择这些频率中的一个。

+
    +

  • 列出所有可用的 governor，使用以下命令：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    结果是：

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative governor 与 ondemand governor 非常相似。只是它的行为有所不同，它会更保守地增减CPU速度，而不是在CPU有任何负载的瞬间就跳到最大速度。

    • +

  • ondemand （默认）根据当前系统负载在可能的CPU核心频率之间切换。当系统负载超过特定值时，它会立即提高CPU核心频率。

    • +

  • powersave 始终选择最低的CPU核心频率。

    • +

  • performance 始终选择最高的CPU核心频率。

    • +

  • userspace 允许以root身份运行的用户或用户空间程序设置特定频率（例如，设置为1600000）。输入：

    • +

  • 要查询当前的 governor，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    您通常会得到：

    +
    ondemand
+
    +
    +
    • +

  • 切换到另一个governor（例如，userspace）可以通过以下方式完成：

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • 现在你可以设置频率：

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

有关governor的更详细信息，请参阅Linux内核代码库中的Linux内核文档，路径为 Documentation/admin-guide/pm/cpufreq.rst 。

+
+
+

7.19.2. CPU核心管理

+

该 i.MX 8M Mini SoC 芯片上可以有多个处理器核心。例如，该 i.MX 8M Mini 具有 4 个 ARM 核心，可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    这里系统有四个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.19.3. 挂起到RAM

+

phyCORE-i.MX8MM 支持基本的挂起和恢复。可以使用不同的唤醒源。挂起/恢复可以通过以下方式实现：

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

要通过串行控制台唤醒，请运行

+
target:~$ echo enabled > /sys/class/tty/ttymxc2/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.20. 热管理

+
+

7.20.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.20.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 8M Mini SoC 平台上使用热管理内核 API。 i.MX 8 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个触发点。这些触发点根据CPU型号的不同而有所不同。主要区分工业版和商业版。

+ + + + + + + + + + + + + + + + + +

商业

工业

被动（警告）

85°C

95°C

严重（关机）

90°C

100°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并实施冷却措施。内核中可用的热政策（也称为thermal governor）包括：Step Wise、Fair Share、Bang Bang和Userspace。BSP中使用的默认策略是Step Wise。如果sysfs文件temp中的SoC温度值高于 trip_point_0 ，则CPU频率将设置为最低CPU频率。当SoC温度降到 trip_point_0 以下时，限制将被解除。

+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+

7.20.3. GPIO风扇

+
+

备注

+

Only GPIO fan supported.

+
+

一个GPIO控制的风扇可以连接到 phyBOARD-Polis-i.MX 8M Mini。该SoC包含一个温度传感器，该传感器被用于热频率调节。风扇无法通过内核进行控制。我们使用lmsensors和hwmon来实现这一点。lmsensors定期读取温度，并在可配置的阈值下启用或禁用风扇。对于 phyBOARD-Polis-i.MX 8M Mini，这个阈值是60°C。

+

设置可以在配置文件中进行配置：

+
/etc/fancontrol
+
+
+

风扇控制在启动时由systemd服务启动。可以通过以下方式禁用它：

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.21. 看门狗

+

PHYTEC i.MX 8M Mini 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.21.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.22. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 8M Mini 提供一次性可编程fuse，用于存储信息，例如 MAC 地址、启动配置和其他永久设置（在 i.MX 8M Mini reference manual中称为“片上 OTP 控制器 (OCOTP_CTRL)”）。以下列表摘自 i.MX 8M Mini reference manual，包括 OCOTP_CTRL 中的一些有用寄存器（基地址为0x30350000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为0x30350000

描述

OCOTP_MAC_ADDR0

9

0

0x640

包含ENET0 MAC地址的低32位

OCOTP_MAC_ADDR1

9

1

0x650

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

OCOTP_MAC_ADDR2

9

2

0x660

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 8M Mini Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.22.1. 在uBoot中读取fuse的值

+

您可以使用内存映射的shadow寄存器读取fuse寄存器。要计算内存地址，请使用以下公式计算：

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.22.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+
+

8. i.MX 8M Mini M4 Core

+

除了Cortex-A53核心外，SoC中还集成了一个Cortex-M4 Core 作为MCU。我们的Yocto-Linux-BSP在A53核心上运行，而 M4 Core 可以作为辅助CPU，用于使用裸机或RTOS固件执行额外任务。两种核心都可以访问相同的外设，因此外设的使用需要在 M4 Core 的固件或Linux操作系统的设备树中进行限制。本节将描述如何编译固件示例以及如何在 phyBOARD-Polis 上运行它们。

+

phyBOARD-Polis 目前由 NXP MCUXpresso SDK 和 Zephyr 项目支持。本节仅描述 NXP MCUXpresso SDK，因为目前 MCUXpresso SDK 支持的功能更多。

+

如果您想在Zephyr项目中使用 M4 Core ，请参考Zephyr项目文档：

+ +
+

8.1. 获取固件示例

+

固件可以使用NXP MCUxpresso SDK和兼容的编译工具链通过命令行工具进行编译。

+
+

8.1.1. 获取源代码

+

MCUX SDK以及 i.MX 8M Mini 的示例可以从PHYTEC的GitHub页面获取：

+ +
    +

  1. 通过west初始化MCUX SDK：

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    这将创建一个 mcuxsdk 目录，并在其中包含 mcux-sdk 仓库。mcux-sdk-phytec-examples 仓库将自动克隆到 mcuxsdk 目录中。给定的参数 <VERSION> 是 mcux-sdk 仓库的分支名称，代表 MCUX SDK 版本。要获取最新的测试版本，您可以使用 2.13.0。

    +
    +

    备注

    +

    west 是一个仓库管理工具，也是 Zephyr 项目的一部分。要安装 west，您可以使用 pip。在这个示例中，west 被安装在一个 Python 虚拟环境中:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. 更新依赖项：

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    目录 examples-phytec 包含了所有移植并测试过的示例，适用于 phyBOARD-Polis 和版本为 2.13.0 的 MCUX。

    +

    要编译固件，需要一个编译器工具链和make/cmake。GNU ARM 嵌入式工具链可能在您的主机linux发行版的仓库中可用，例如Ubuntu。

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    编译器工具链也可以直接从 https://developer.arm.com/ 获取。在解压缩文件后，必须将 ARMGCC_DIR 添加到环境变量中，例如，对于位于主目录中的 ARM toolchain 10-2020-q4-major 版本：

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. 编译固件

+

要编译PHYTEC示例，需要先设置环境

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

编译固件的脚本位于 <sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc。每个可运行的内存位置都有相应的编译脚本，例如：

+
host:~$ ./build_release.sh
+
+
+

要编译运行在 M4 Core 的 TCM 上的固件。输出将放置在 armgcc 目录下的 release/ 中。.bin 文件可以在 U-Boot 中运行，而 .elf 文件可以在 Linux 中运行。

+

要编译在DRAM上运行的固件，请运行脚本build_ddr_release。例如。

+
host:~$ ./build_ddr_release.sh
+
+
+

输出将放置在armgcc目录下的ddr_release/中。.bin文件可以在U-Boot中运行，而.elf文件可以在Linux中运行。

+
+
+
+

8.2. 运行 M4 Core 示例

+

有两种方法可以运行 M4 Core 的固件，在Linux中使用Remoteproc以及在U-Boot。

+

要接收调试信息，请在您的主机PC上启动您喜欢的终端软件（例如Minicom、Tio或Tera Term），并将其配置为115200波特率、8个数据位、无奇偶校验和1个停止位（8n1），且不使用握手。

+

一旦Micro USB电缆连接到 phyBOARD-Polis 上的USB调试端口，就会注册两个ttyUSB设备。一个打印来自A53核心的调试UART的消息，另一个打印来自 M4 Core 的调试UART的消息。

+
+

8.2.1. 从U-Boot运行示例

+

要使用bootloader U-Boot加载固件，可以使用bootaux命令：

+
    +

  1. 准备一张烧写了BSP镜像的SD卡

    2. +

  2. 将生成的 .bin 文件复制到 SD 卡的第一个分区

    3. +

  3. 通过按任意键停止自动启动

    4. +

  4. 根据固件类型输入命令：

    5. +
+

对于在 M4 Core 的TCM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

用于在DRAM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

程序的输出应显示在 M4 Core 的调试UART上。

+
+
+

8.2.2. 通过Remoteproc在Linux上运行示例

+

Remoteproc是一个模块，允许您在运行时从Linux控制 M4 Core 。可以加载为TCM编译的固件，并可以启动或停止执行。要使用Remoteproc，需要设置设备树Overlay：

+

在开发板的/boot目录中编辑bootenv.txt文件，添加 imx8mm-phycore-rpmsg.dtbo ：

+
overlays=imx8mm-phycore-rpmsg.dtbo
+
+
+

重启目标并在U-Boot中执行:

+
u-boot=> run prepare_mcore
+
+
+

M4 Core 的固件 .elf 文件可以在 /lib/firmware 下找到。要加载固件，请输入：

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

要加载不同的固件，M4 Core 需要停止：

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

备注

+

在开发板上找到的 /lib/firmware 中的例子来自NXP的Yocto层meta-imx。要使用您通过MCUX SDK自己编译的样本，请在编译后将它们复制到开发板的 /lib/firmware 中。

+
+
+ +
+
+
+

9. BSP扩展

+
+

9.1. Chromium

+

我们的BSP支持Chromium。您只需几个步骤即可将其包含在 phytec-qt5demo-image 中。

+
+

9.1.1. 将Chromium添加到您的local.conf文件中

+

要包含Chromium，您需要在您的local.conf中添加以下行。您可以在<yocto_dir>/build/conf/local.conf中找到这个配置文件。这将把Chromium添加到您下一个镜像编译中。:

+
IMAGE_INSTALL_append = " chromium-ozone-wayland"
+
+
+
+

备注

+

编译Chromium需要很长时间。

+
+
+
+

9.1.2. 在开发板上运行Chromium

+

要运行Chromium，需要一些参数来使用硬件图形加速：

+
target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox
+
+
+

如果您想通过SSH启动Chromium，您必须首先定义运行Chromium的显示器。例如：

+
target$ DISPLAY=:0
+
+
+

在您定义完这个之后，您可以通过上述所示的Weston虚拟终端启动它。

+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mm/pd23.1.0.html b/previews/271/zh_CN/bsp/imx8/imx8mm/pd23.1.0.html new file mode 100644 index 000000000..7d458d305 --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mm/pd23.1.0.html @@ -0,0 +1,3814 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 8M Mini BSP手册

文档标题

i.MX 8M Mini BSP手册

文档类型

BSP 手册

Yocto 手册

Kirkstone

发布日期

2024/01/10

母文档

i.MX 8M Mini BSP手册

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP发布日期

BSP 状态

BSP-Yocto-NXP-i.MX8MM-PD23.1.0

大版本

2023/12/12

已发布

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 phyCORE-i.MX8M Mini Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads 中找到。

+
+

1.1. 支持的硬件

+

支持配备 i.MX 8M Mini SoC 或 i.MX 8M Nano SoC 的 phyBOARD-Polis。

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-NXP-i.MX8MM-PD23.1.0 的所有Machine及其对应的Article Numbers(产品型号)： 网址. 如果您在该网页 Supported Machines 一节选择了特定的 Machine Name ，您可以查看被选中machine下的包含的 Article Number(产品型号) 以及简要的硬件描述。如果您只有 Article Number ，可以将 Machine Name 下拉菜单留空，仅选择您的 Article Number 。那么，它会显示您特定硬件所对应的 Machine Name

+
+

1.1.1. phyBOARD-Polis 器件

+ + + + + + +
+../../../_images/polis-front.jpg +
+

phyBOARD-Polis 器件（顶部）

+
+
+
+../../../_images/polis-back.jpg + +
+

phyBOARD-Polis 器件（底部）

+
+
+
+
+
+
+
+

2. 开始使用

+

该 phyCORE-i.MX8M Mini Kit 包含预先烧写好的SD卡。它包含 phytec-qt6demo-image 镜像，可以直接用作启动盘。默认情况下，核心板上的eMMC仅烧写了U-Boot。您可以从 PHYTEC下载服务器 获取所有镜像资源。本章将解释如何将BSP镜像烧写到SD卡以及如何启动开发板。

+

有几种方法可以将镜像写入SD卡或eMMC。最为人熟知的方式是使用Linux命令行工具 dd 进行简单的顺序写入。另一种方法是使用PHYTEC的自研程序 partup ，它可以让格式化复杂系统的过程变得简单。您可以从其发布页面获取 预编译的Linux partup 二进制文件 。请阅读 partup的readme文件 来获取安装指导。

+
+

2.1. 下载镜像

+

phytec-qt6demo-image 镜像包含完整系统所需的所有必要文件，您需确保镜像中各个分区以及裸数据都会被正确写入启动盘。可以从 PHYTEC 下载服务器 下载 partup 镜像文件或者是可以使用 dd 进行烧写的 WIC 镜像。

+

从下载服务器获取 partup 镜像文件或WIC镜像：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt6demo-image-phyboard-polis-imx8mm-5.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+
+
+
+

备注

+

针对eMMC，我们建议使用partup去烧写比较大的或者是有复杂分区配置的镜像，因为它在写入速度上比 dd 更快，并且可以对闪存设备进行更灵活的配置。

+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要创建SD卡启动盘，必须要拥有Linux PC上的root权限。在选择烧写设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+
+

2.2.1. 寻找正确的设备

+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行命令：

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+

卸载所有这些分区，例如：

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

现在，SD卡已经准备好可以使用 partup 、 dd 或 bmap-tools 来写入镜像。

+
+
+

2.2.2. 使用partup

+

使用partup烧写SD卡只需一个命令：

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-polis-imx8mm-5.partup /dev/<your_device>
+
+
+

确保将 <your_device> 替换为您之前找到的设备名称。

+

关于partup的进一步使用说明，请参阅其 官方文档 。

+
+

备注

+

partup 的优点在于能够清除 MMC 用户区中的特定区域，这在我们的应用场景中用于擦除 U-Boot 环境。这是一个 bmaptool 无法解决的已知问题，如下所述。

+

partup相较于其他烧写工具的一个主要优势是，它可以配置MMC的特定部分，比如他可以直接写入eMMCboot分区，无需调用其他命令。

+
+
+
+

2.2.3. 使用bmap-tools

+

准备SD卡的另一种方法是使用 bmap-tools。Yocto会自动为WIC镜像创建一个映射文件（<IMAGENAME>-<MACHINE>.wic.bmap），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host:~$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /dev/<your_device>
+
+
+

将 <your_device> 替换为您之前找到的SD卡设备名称，并确保将文件 <IMAGENAME>-<MACHINE>.wic.bmap 与WIC镜像文件放在一起，以便bmaptool知道哪些块需要写入，哪些块需要跳过。

+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.2.4. 使用 dd

+

在卸载所有SD卡的挂载分区后，您可以烧写SD卡。

+

一些PHYTEC BSP会生成未压缩的镜像（文件名扩展名为*.wic），而另一些则生成压缩的镜像（文件名扩展名为*.wic.xz）。

+

要写入未压缩的镜像（*.wic），请使用以下命令：

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

或者要写入压缩后的镜像（*.wic.xz），请使用以下命令：

+
host:~$ xzcat phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

再次确保将 <your_device> 替换为之前找到的设备名称。

+

参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

+
+
+
+

2.3. 首次启动

+ + + + + + + +
启动模式选择
+../../../_images/SD_Card_Boot.jpg +
+

Mini

+
+
+
+
    +

  • 插入SD卡

    • +

  • 使用 micro USB 线将开发板的 (X30) 调试USB口和主机连接起来

    • +

  • 给开发板通电

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 8M Mini BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (kirkstone).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (kirkstone).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-IMX8MM ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-xwayland MACHINE=phyboard-polis-imx8mm-5 ./phyLinux init -p imx8mm -r BSP-Yocto-NXP-i.MX8MM-PD23.1.0
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 phyboard-polis-imx8mm-5 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx8mm.bin: ARM可信固件二进制文件

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY固件镜像

    • +

  • imx-boot：由imx-mkimage编译的bootloader镜像，包括SPL、U-Boot、ARM可信固件和DDR固件。这是最终的可引导bootloader镜像。

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx8mm-phyboard-polis-rdk*.dtb：内核设备树文件

    • +

  • imx8mm-phy*.dtbo: 内核设备树overlay文件

    • +

  • phytec-qt6demo-image*.tar.gz: 根文件系统

    • +

  • phytec-qt6demo-image*.wic: SD卡镜像

    • +
+
+
+
+
+

4. 安装操作系统

+
+

4.1. 启动模式开关 (S1)

+

该 phyBOARD-Polis 具有一个启动配置开关，带有六个可单独切换的开关，用于选择 phyCORE-i.MX 8M Mini 的默认启动源。

+
+

4.1.1. Mini

+ + + + + + + + + + +
启动模式选择
+../../../_images/eMMC.jpg +
+

eMMC（核心板的默认启动方式）

+
+
+
+../../../_images/SPI_NOR1.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download2.png +
+

USB

+
+
+
+../../../_images/SD_Card_Boot.jpg +
+

SD卡

+
+
+
+ + + + + + + +
切换UART1的RS485和RS232模式
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+
+
+

4.2. 烧写eMMC

+

为了保持文档的一致性和简洁性，假设已经配置好了TFTP服务器；所有生成的镜像（如上所列）都被复制到默认的/srv/tftp目录。如果您没有进行设置，您需要修改路径到包含镜像的目录。有关如何设置TFTP服务器和目录的说明，请参见 Setup Network Host 。

+

要从 eMMC 启动，请确保 BSP 镜像已正确烧写到 eMMC，并且 bootmode switch (S1) 设置为 eMMC。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行上述命令来检查系统启动在这种条件下是否会到影响。如果 mmcblk2p1 和 mmcblk1p1 具有相同的UUID，则会影响系统正确启动。

+
+
+

4.2.1. 从网络烧写 eMMC

+

i.MX 8M Mini 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

4.2.1.1. 在开发板的U-Boot中通过网络烧写eMMC

+

这些步骤将展示如何通过网络更新eMMC。

+
+

小技巧

+

此步骤仅在镜像文件小于1GB的情况下会被执行成功，因为在启用OPTEE后，Bootloader中可用的RAM大小有限，不足以加载超过1GB的镜像

+
+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

通过网络将您的镜像加载到内存中：

+
    +

  • 使用DHCP

    +
    u-boot=> dhcp phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.1 (1 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.1
+Filename 'phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • 使用静态IP地址（必须先设置serverip和ipaddr）。

    +
    u-boot=> tftp ${loadaddr} phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
+
+
+
+

4.2.1.2. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

使用一条命令，通过网络ssh协议将带有块映射的压缩或未压缩的镜像发送到开发板的eMMC上使用，执行：

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic.* /tmp && bmaptool copy /tmp/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /dev/mmcblk2
+
+
+
+
+

4.2.1.3. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

查看主机上可用的镜像文件：

+
host:~$ ls /srv/tftp
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic.bmap
+
+
+

通过网络ssh协议使用 bmaptool 命令将镜像发送到开发板的eMMC：

+
host:~$ scp /srv/tftp/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /dev/mmcblk2"
+
+
+
+
+
+

4.2.2. 在运行的U-Boot中通过网络烧写eMMC U-Boot镜像

+

可以在U-Boot中更新U-Boot镜像imx-boot，eMMC上的U-Boot需要位于eMMC的user区域。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x42 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.3. 从USB大容量存储设备烧写eMMC

+
+

4.2.3.1. 在开发板上通过U-Boot从USB烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件小于1GB的情况下会被执行成功，因为在启用OPTEE后，Bootloader中可用的RAM大小有限，不足以加载超过1GB的镜像

+
+

下面这些步骤展示如何通过USB设备更新eMMC。将|ref-bootswitch| 配置为SD卡启动，并插入SD卡。给开发板上电并进入U-Boot环境。将已存储了未压缩WIC镜像的优盘插入开发板USB接口。

+

将镜像从USB设备加载到RAM中：

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} *.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. 在运行的Linux系统中从USB烧写eMMC

+

下面这些步骤展示如何在Linux系统上使用USB大容量存储设备烧写eMMC。您需要一个保存了完整镜像的U盘和一个可从SD卡启动的核心板（例如 phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic）。将 bootmode switch (S1) 设置为SD卡启动。

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ ls /mnt
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic.bmap
+
    +
    +
    • +

  • 将镜像写入 phyCORE-i.MX 8M Mini eMMC（无分区的 MMC 设备 2）：

    +
    target:~$ bmaptool copy /mnt/phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    小技巧

    +

    在此之前，您需要将 bootmode switch (S1) 配置为 eMMC。

    +
    +
    • +
+
+
+
+

4.2.4. 从SD卡烧写eMMC

+

即使没有可用的网络，您也可以更新eMMC。为此，您需要一个位于SD卡上的镜像文件（ *.wic ）。由于镜像文件相当大，您需要在SD卡创建第三个分区。要创建新分区或扩展您的SD卡，请参见 Resizing ext4 Root Filesystem 。

+

或者，使用partup包烧写SD卡，如 Getting Started 中所述。这样就可使用SD卡的全部容量。

+
+

4.2.4.1. 在开发板的uboot环境中通过SD卡烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1GB的情况下有效，因为在启用OPTEE后，Bootloader中可用的RAM大小有限。如果镜像文件过大，请阅读 在开发板上通过SD卡更新eMMC 一节

+
+
    +

  • 将一个可用的镜像烧写到SD卡，并创建一个EXT4格式的第三分区。将WIC镜像（例如 phytec-qt6demo-image.wic）复制到该分区。

    • +

  • 将 bootmode switch (S1) 配置为 SD 卡并插入 SD 卡。

    • +

  • 打开电源并进入U-Boot。

    • +

  • 加载镜像：

    +
    u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • 将当前mmc设备切换到eMMC：

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • 将您的WIC镜像（例如 phytec-qt6demo-image.wic）从SD卡烧写到eMMC。这将对卡进行分区，并将imx-boot、Image、dtb、dtbo和根文件系统复制到eMMC。

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • 关闭电源并将 bootmode switch (S1) 更改为 eMMC。

    • +
+
+
+

4.2.4.2. 在开发板的linux环境中通过SD卡烧写eMMC

+

您也可以在Linux系统中烧写eMMC。您只需要一个partup包或保存在SD卡上的WIC镜像。

+
    +

  • 检查在SD卡上保存的partup包或WIC镜像文件：

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.partup
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic.bmap
+
    +
    +
    • +

  • 使用 partup 将镜像写入 phyCORE-i.MX 8M Mini 的 eMMC（MMC 设备 2 不带 分区字样）：

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-polis-imx8mm-5.partup /dev/mmcblk2
+
    +
    +

    使用partup烧写的优点是可以充分利用eMMC设备的全部容量，会相应自动调整分区大小。

    +
    +

    备注

    +

    另外，也可以使用 bmaptool 工具：

    +
    target:~$ bmaptool copy phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /dev/mmcblk2
+
    +
    +

    请注意，在使用 bmaptool 烧写时，根文件系统分区并不会使用eMMC的最大容量。

    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    警告

    +

    在此之前，您需要将 bootmode switch (S1) 配置为 eMMC。

    +
    +
    • +
+
+
+
+
+

4.3. 烧写 SPI NOR Flash

+

phyCORE-i.MX8MM 模块可选配SPI NOR Flash。要从SPI Flash启动，请将 bootmode switch (S1) 设置为 SPI NOR 。SPI Flash通常比较小。phyBOARD-Pollux-i.MX8MP开发套件仅配备32MB的SPI NOR Flash。只能存储bootloader及其环境变量。默认情况下，内核、设备树和文件系统会从eMMC加载。

+

SPI NOR Flash分区表在U-Boot环境变量中定义。可以通过以下命令打印：

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. 通过网络烧写SPI NOR Flash

+

SPI NOR可以包含bootloader及其环境变量。arm64的linux内核无法自行解压缩，内核镜像大小超出了phyCORE-i.MX 8M Mini 上的SPI NOR Flash的容量。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+
+

4.3.1.1. 在开发板的U-Boot环境中通过网络烧写SPI NOR

+

类似于通过网络更新eMMC，请确保正确设置主机PC。IP地址需要设置为192.168.3.10，子网掩码设置为255.255.255.0，并且需要有一个可用的TFTP服务。在进行读写之前，需要对SPI NOR Flash进行枚举：

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像。确保您使用了正确的镜像文件。通过tftp加载镜像，然后将bootloader写入Flash：

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+

4.3.1.2. 在开发板linux环境中通过网络烧写SPI NOR Flash

+
    +

  • 将镜像从主机复制到开发板：

    +
    host:~$ scp imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • 查找要擦除的U-boot分区的块数：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除U-Boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+

4.3.2. 从SD卡烧写SPI NOR Flash

+

SPI NOR Flash上的bootloader也可以通过SD卡进行烧写。

+
+

4.3.2.1. 在开发板的U-Boot环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi复制到SD卡的第一个分区。

    • +

  • 在进行读写操作之前，需要对SPI-NOR Flash进行枚举：

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像，请确保使用正确的镜像文件。从SD卡加载镜像，擦除并将bootloader写入flash：

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+

4.3.2.2. 在开发板的linux环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi复制到SD卡的第一个分区。

    • +

  • 挂载SD卡：

    +
    target:~$ mount /dev/mmcblk1p1 /mnt
+
    +
    +
    • +

  • 查找要擦除的U-Boot分区的块数：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除u-boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-polis-imx8mm-5-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC： L-1006e.A5 RAUC Update & Device Management Manual 。

+
+
+
+

5. 开发

+
+

5.1. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.1.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.2. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.2.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核镜像复制到您的tftp目录中：

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • 将设备树复制到您的tftp目录：

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • 将您想要使用的所有overlay文件复制到您的tftp目录中：

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-polis-imx8mm-5.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.2.2. 设置网络启动的bootenv.txt文件

+

在您的tftp目录中创建一个bootenv.txt文件，并将以下变量写入其中。

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> 必须替换为您想要使用的overlay设备树文件名。用空格分隔文件名。例如：

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

小技巧

+

所有支持的设备树overlay在 device tree 章节中。

+
+
+
+

5.2.3. 开发板上的网络设置

+

如果要自定义开发板上的以太网配置，请按照此处的说明进行操作： Network Environment Customization

+
+
+

5.2.4. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.3.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. 获取镜像

+

可以从我们的服务器下载imx-boot，或者从Yocto编译目录中的build/deploy/images/phyboard-polis-imx8mm-5/获取它。要将wic镜像烧写到eMMC，你还需要 phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic。

+
+
+

5.3.3. 开发板准备

+

将 bootmode switch (S1) 设置为 USB串行下载。同时，将 USB 端口 X2 连接到主机。

+
+
+

5.3.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 (X30) 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.3.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic
+
+
+
+
+
+

5.4. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone git://git.phytec.de/u-boot-imx）

+
+
+

5.4.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-imx 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • 我们的 i.MX 8M Mini 内核是基于 linux-imx 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. 获取SDK

+

您可以在此处下载SDK 这里，或者使用Yocto去编译生成SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

在成功编译后，SDK安装包保存在 build/deploy*/sdk。

+
+
+

5.4.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-4.0.13.sh
+host:~$ ./phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-4.0.13.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-xwayland/4.0.13):
+You are about to install the SDK to "/opt/ampliphy-vendor-xwayland/4.0.13". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-vendor-xwayland/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. 单独编译U-Boot

+
+

备注

+

SD卡复位引脚的regulator已被禁用，以确保与1532.1版本底板的兼容性。如果您拥有1532.2(a)或更高版本的主板，您可以启用设备树节点以获得最佳性能。在imx8mm-phyboard-polis-rdk-u-boot.dtsi文件中，删除以下行：

+
/delete-node/ &reg_usdhc2_vmmc;
+/delete-property/ vmmc-supply;
+
+
+
+
+

5.5.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本中使用的**tag**称为 v2022.04_2.2.2-phy5

    • +

  • 查看所需的 U-Boot tag：

    +
    host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2022.04_2.2.2-phy5
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor-xwayland/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. 获取所需的二进制文件

+

要编译bootloader，您需要将这些文件复制到您的 u-boot-imx 编译目录，并将其重命名以适应 mkimage 脚本：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx8mm.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以在yocto工程目录中获取 bl31-imx8mm.bin、tee.bin和lpddr4_*.bin：BSP Images

+

或者你可以在这里下载文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-polis-imx8mm-5/imx-boot-tools/

+
+

警告

+

确保您重命名所需的文件，以和 mkimage tool 兼容。

+
+
+
+

5.5.3. 编译bootloader

+
    +

  • 编译 flash.bin (imx-boot):

    +
    host:~/u-boot-imx$ make phycore-imx8mm_defconfig
+host:~/u-boot-imx$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. 将bootloader烧写到块设备上

+

flash.bin 文件可以在 u-boot-imx/ 目录下找到，现在可以进行烧写。需要指定芯片特定的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 8M Mini

33 kiB

33 kiB

/dev/mmcblk2

+

例如，烧写SD卡：

+
host:~/u-boot-imx$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=33 conv=sync
+
+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+

5.5.5. 使用固定内存大小编译U-Boot

+

如果您的系统因为EEPROM中的硬件信息损坏或丢失而无法启动，您可以创建一个具有固定RAM大小的flash.bin。但您仍应联系我们支持部门以烧写正确的EEPROM数据。

+

按照步骤获取U-boot源代码，并切换到 Build U-Boot 章节说明的分支。

+

Edit the file configs/phycore-imx8mm_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MM=y
+CONFIG_PHYCORE_IMX8MM_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MM_RAM_SIZE_4GB=y
+
+
+

选择正确的RAM大小，确保与核心板上的贴装的器件一致，取消注释该RAM大小的行。保存更改后，按照 Build U-Boot 章节的剩余步骤进行操作。

+
+
+
+

5.6. 单独编译内核

+
+

5.6.1. 配置源代码

+
    +

  • 使用的 linux-imx 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v5.15.71_2.2.2-phy3

    • +

  • Check out 所需的 linux-imx 标签：

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v5.15.71_2.2.2-phy3
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor-xwayland/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-imx$ make imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-imx/arch/arm64/boot/Image 找到

    • +

  • dtb文件可以在 ~/linux-imx/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. 将内核复制到SD卡

+

内核及module和对应的设备树二进制文件可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. 获取BSP开发中版本

+
+

5.7.1. 当前release的开发中版本

+

这些release manifest文件是为了让您访问 Yocto BSP的开发版本。它们不会在phyLinux选择菜单中显示，需要手动选择。可以使用以下命令行来完成此操作：

+
host:~$ ./phyLinux init -p imx8mm -r BSP-Yocto-NXP-i.MX8MM-PD23.1.y
+
+
+

这将初始化一个BSP，用于跟踪当前版本（ BSP-Yocto-NXP-i.MX8MM-PD23.1.0 ）的最新开发版本。从现在开始，在此文件夹中执行 repo sync 将从我们的Git仓库中拉取所有最新的更改：

+
host:~$ repo sync
+
+
+
+
+

5.7.2. 即将发布版本的开发中版本

+

即将发布版本的开发中版本可以通过这种方式访问。请执行以下命令，并查找一个比最新版本（ BSP-Yocto-NXP-i.MX8MM-PD23.1.0 ）的PDXX.Y数字更高的版本，并且以 .y 结尾：

+
host:~$ ./phyLinux init -p imx8mm
+
+
+
+
+
+

5.8. 获取最新的Upstream支持

+

我们有一个使用Yocto主分支（不是NXP发布的）的manifest，他使用upstream的Linux和U-Boot。这可以用来测试最新的upstream kernel/U-Boot。

+
+

备注

+

master分支的manifest反映了最新的开发状态。有时会出现一些bug。我们会定期修复master分支。

+
+
host:~$ ./phyLinux init -p imx8mm -r BSP-Yocto-Ampliphy-i.MX8MM-master
+
+
+
+
+

5.9. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.9.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将 phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将 phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic 镜像复制到其中。然后卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-polis-imx8mm-5.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 8M Mini BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 8M Mini 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Board.dts - 包含module dtsi 文件。从SoC i.MX 8M Mini 引出并在底板使用的设备也包含在此 dts 中。

    • +

  • Overlay.dtso - 根据核心板或底板上可选硬件（例如 SPI 闪存或 PEB-AV-10）的情况来启用/禁用一些功能。

    • +
+

在Linux内核的根目录下，我们的 i.MX 8 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。例如扩展板的硬件描述。对比源码中的include，overlay是用覆盖的方式来生效。overlay也可以根据节点是否连接来设置节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/overlays 中。

+

phyboard-polis-imx8mm-5.conf 可用的overlay文件有：

+
imx8mm-phyboard-polis-peb-eval-01.dtbo
+imx8mm-phyboard-polis-peb-av-010.dtbo
+imx8mm-phycore-rpmsg.dtbo
+imx8mm-phycore-no-eth.dtbo
+imx8mm-phycore-no-spiflash.dtbo
+imx8mm-vm016.dtbo
+imx8mm-vm016-fpdlink.dtbo
+imx8mm-vm017.dtbo
+imx8mm-vm017-fpdlink.dtbo
+imx8mm-dual-vm017-fpdlink.dtbo
+
+
+

可以在Linux或U-Boot环境下配置overlay。overlay是在引导命令调用后、内核加载之前生效。接下来的部分将更详细地解释配置方法。

+
+

6.2.2.1. 设置 ${overlays} 变量

+

${overlays} U-Boot 环境变量包含一个以空格分隔的overlay文件列表，这些overlay文件将在启动过程中应用。根据启动源，overlay文件必须放置在 eMMC/SD 卡的启动分区中，或者通过 tftp 加载。在 $KERNEL_DEVICETREE 这个 Yocto machine 变量中设置的 overlay 文件将自动添加到最终 WIC 镜像的启动分区中。

+

${overlays} 变量可以直接在U-Boot环境中设置，也可以作为外部 bootenv.txt 环境文件的一部分。默认情况下， ${overlays} 变量来自位于启动分区的 bootenv.txt 文件。您可以在已启动的开发板上从Linux读取和写入该文件：

+
target:~$ cat /boot/bootenv.txt
+overlays=imx8mm-phyboard-polis-rdk-peb-eval-01.dtbo imx8mm-phyboard-polis-peb-av-010.dtbo
+
+
+

更改将在下次重启后生效。如果没有可用的 bootenv.txt 文件，可以直接在U-Boot环境中设置overlay变量。

+
u-boot=> setenv overlays imx8mm-phyboard-polis-peb-av-010.dtbo
+u-boot=> printenv overlays
+overlays=imx8mm-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

如果用户定义了 ${overlays} 变量，同时存在 bootenv.txt 文件，则需要设置 ${no_bootenv} 变量：

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx8mm-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

有关环境的更多信息，请参见 U-boot External Environment subsection of the +device tree overlay section。

+

我们使用 ${overlays} 变量来描述在运行时无法自动检测的扩展板和摄像头。如果想禁用 ${overlays} 变量中列出的overlay，可以在U-Boot的环境中将 ${no_overlays} 变量设置为 1。

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+

6.2.2.2. 扩展命令

+

使用U-Boot扩展命令能够轻松加载由回调函数 extension_board_scan() 检测并添加到列表中的overlay。以这种方式应用的overlay会禁用核心板上未贴装的组件。检测是通过读取出厂EEPROM数据（EEPROM SoM Detection）来实现的。

+

这取决于核心板型号是否会应用任何设备树overlay。要检查在U-Boot中运行的SoM是否会应用overlay，请运行：

+
u-boot=> extension scan
+Found 1 extension board(s).
+u-boot=> extension list
+Extension 0: phyCORE-i.MX8MM no SPI flash
+        Manufacturer:           PHYTEC
+        Version:
+        Devicetree overlay:     imx8mm-phycore-no-spiflash.dtbo
+        Other information:      SPI flash not populated on SoM
+
+
+

如果没有可用的EEPROM数据，则不加载任何设备树overlay。

+

为了禁止在启动时自动运行扩展命令，可以在bootloader环境中将 ${no_extensions} 变量设置为 1 ：

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot外部环境

+

在Linux内核启动时，外部环境 bootenv.txt 文本文件将从MMC设备的boot分区或通过TFTP加载。该文件的主要目的是存储 ${overlays} 变量。这可以针对不同的machine在Yocto中预定义不同的overlay配置。文件的内容在meta-phytec中的Yocto recipe中的bootenv中定义： https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=kirkstone

+

该文件中也可以设置其他变量。这些变量将覆盖环境中现有的设置。但只有对boot命令后进行计算的变量生效，例如 ${nfsroot} 或 ${mmcargs}。在文件中更改其他变量将不会有作用。以网络启动的用法作为示例。

+

如果无法加载外部环境，启动过程将继续进行，并使用自带的环境变量值。

+
+
+

6.2.4. 在Linux环境下更改开发板上的U-boot环境变量

+

Libubootenv是我们镜像中包含的一个工具，用于在开发板linux上修改U-Boot环境。

+

使用以下命令打印U-Boot环境：

+
target:~$ fw_printenv
+
+
+

使用以下命令修改U-Boot环境：

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

小心

+

Libubootenv会读取配置文件中配置的环境变量。要修改的环境变量会被插入到该文件中，默认情况下使用eMMC中存储环境变量。

+

如果eMMC没有被烧写过或者eMMC环境被擦除，libubootenv将无法工作。您应该修改 /etc/fw_env.config 文件，以匹配您想要使用的环境源。

+
+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 8M Mini BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 8M Mini BSP设备树概念部分，以了解我们的 i.MX 8 BSP设备树模型。

+

以下部分概述了 i.MX 8 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 8M Mini 引脚复用

+

该 i.MX 8M Mini Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 8M Mini 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 8M Mini 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是 imx8mm-phyboard-polis-rdk.dts中UART1设备的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX     0x00
+                MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX      0x00
+                MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B  0x00
+                MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B  0x00
+        >;
+};
+
+
+

字符串的第一部分 MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX 指定了引脚（在这个例子中是 SAI2_RXFS）。字符串的第二部分（UART1_DCE_RX）是该引脚当前的复用选项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部上拉电阻是否被激活。在当前配置中，内部电阻是禁用的。

+
+
+

7.2. RS232/RS485

+

i.MX 8M Mini SoC 提供最多 4 个 UART 单元。PHYTEC 开发板支持不同数量 UART 单元。UART1 也可以用作 RS-485。为此，需要正确设置 bootmode switch (S1)：

+ + + + + + + +
切换UART1的RS485和RS232模式
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+

7.2.1. RS232

+
    +

  • 以人类可读的格式显示终端的当前设置：

    +
    target:~$ stty -a
+
    +
    +
    • +

  • UART接口的配置可以通过stty命令完成。例如：

    +
    target:~$ stty -F /dev/ttymxc0 115200 crtscts raw -echo
+
    +
    +
    • +

  • 通过简单的echo和cat，可以测试基本的通信。示例：

    +
    target:~$ echo 123 > /dev/ttymxc0
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

主机应打印出 "123"。

+
+
+

7.2.2. RS485

+
+

提示

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

为了方便测试，请查看linux-serial-test。这个工具会通过调用RS485的IOCTL，发送恒定的数据流。

+
target:~$ linux-serial-test -p /dev/ttymxc0 -b 115200 --rs485 0
+
+
+

有关linux-serial-test工具及其参数的更多信息，请访问此链接：linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Linux kernel文档描述了如何在C代码中调用IOCTL： https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection1.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see "test" printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final "count for this session". There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+

RS232和RS485的设备树表示：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n291

+
+
+
+
+

7.3. 网络

+

phyBOARD-Polis-i.MX 8M Mini 提供一个千兆以太网接口。

+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n59。

+

+
+

7.3.1. 网络配置

+
+

7.3.1.1. U-boot网络环境

+
    +

  • 要在bootloader中查找以太网设置：

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • 在将主机设置为IP 192.168.3.10和子网掩码255.255.255.0的情况下，开发板应该返回：

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • 如果您需要进行任何更改：

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> 应该是 ipaddr、netmask、gatewayip 或 serverip 中的一个。<value> 将是所选参数的设定值。

    +
    • +

  • 您所做的更改目前是临时的。要保存这些更改：

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

在这里，您也可以将IP地址更改为DHCP，而不是使用静态IP地址。

+
    +

  • 配置：

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • 设置 TFTP 和 NFS 的路径。修改可以如下所示：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+

小技巧

+

像nfsroot和netargs这样的变量可以被U-boot外部环境重新赋值。对于网络启动，外部环境将通过tftp加载。例如，要在 bootenv.txt 文件中设置nfsroot变量，请在tftproot目录修改：

+
nfsroot=/home/user/nfssrc
+
+
+

无需在开发板上存储这些信息。请注意，U-boot外部环境对于像 ipaddr 或 serveraddr 这样的变量不起作用，因为它们在加载外部环境之前已经被设置完成。

+
+
+
+

7.3.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. 无线局域网

+

为了支持WLAN和蓝牙，我们使用来自LSR的Sterling-LWB模块。该模块支持2.4 GHz，并且可以在多种模式下运行，如客户端模式、使用WEP、WPA、WPA2加密的接入点（AP）模式等。有关该模块的更多信息，请访问 https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. 连接到WLAN网络

+

首先设置您所在国家的正确监管域：

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

你将会看到：

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

设置无线接口：

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

现在您可以扫描可用的网络：

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

您可以使用一个跨平台的客户端，名为wpa_supplicant，支持WEP、WPA和WPA2，以建立加密连接。

+

为此，请将网络凭据添加到文件 /etc/wpa_supplicant.conf 中：

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

现在可以建立连接：

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

这会得到如下输出：

+
...
+ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (kirkstone).

+

首先，创建目录：

+
target:~$ mkdir -p /etc/systemd/network/
+
+
+

然后在 /etc/systemd/network/10-wlan0.network 中添加以下配置片段：

+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+

现在，请重启网络守护进程以使配置生效：

+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+
+

7.3.3. 蓝牙

+

Bluetooth is connected to UART2 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

现在您可以扫描环境中的可见蓝牙设备。在默认配置下，蓝牙是不可见的。

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. 可见性

+

要激活可见性：

+
target:~$ hciconfig hci0 piscan
+
+
+

要禁用可见性：

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. 连接

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

备注

+

如果连接失败并出现错误信息：“连接失败：org.bluez.Error.Failed”，请尝试使用以下命令重新启动PulseAudio：

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC 卡

+

该 i.MX 8M Mini 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

MMC（SD卡插槽）接口的DT配置可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n383

+

eMMC接口的DT配置可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n335

+
+
+

7.5. eMMC设备

+

PHYTEC模块如phyCORE-i.MX 8M Mini 配备了eMMC存储芯片作为主要存储。eMMC设备使用多层单元（MLC）或三层单元（TLC）技术来实现存储，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 8M Mini ，并在Linux内核中作为块设备表示，如SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.5.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），该层负责处理原始MLC或TLC的磨损均衡、块管理和错误更正码（ECC）。这需要定期执行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 通过以下命令使能BKOPS_EN：

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.5.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 8M Mini SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.5.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
+
+

7.5.5. 启用伪SLC模式

+

eMMC设备使用 MLC或TLC 来存储数据。与NAND Flash中使用的SLC相比，MLC或TLC在成本更低的情况下，可靠性较低且错误率较高。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. 擦除设备

+

可以直接擦除eMMC设备，而不是通过写零覆盖。eMMC块管理算法将擦除底层的MLC或TLC，或者将这些块标记为可丢弃。设备上的数据将丢失，并将被读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.5.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 8M Mini 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.5.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

下表是 i.MX 8M Mini SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 8M Mini

33 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.6. SPI主设备

+

i.MX 8M Mini 控制器包含一个 FlexSPI 和一个 ECSPI IP 核。FlexSPI 主控制器支持两个 SPI 通道，最多可连接 4 个设备。每个通道支持单通道/双通道/四通道/八通道模式的数据传输（1/2/4/8 条数据线）。ECSPI 控制器支持 3 个 SPI 接口，每个接口都有一个专用的CS（chip select）引脚。由于CS也可通过 GPIO 实现，因此每个通道上可以连接多个设备。

+
+

7.6.1. SPI NOR 烧写

+

phyCORE-i.MX 8M Mini 配备有一个 QSPI NOR Flash，该 Flash 连接到 i.MX 8M Mini 的 FlexSPI 接口。QSPI NOR Flash 可用于启动。有关烧写和启动模式设置的详细信息，请参见不同的章节。由于 SPI NOR Flash 的空间有限，因此仅可存储bootloader。默认情况下，内核、设备树和根文件系统来自 eMMC。

+

bootloader程序通过EEPROM数据检测是否安装了SPI Flash。如果没有安装SPI Flash，则在启动期间应用设备树overlay，通过扩展命令禁用SPI Flash设备树节点。如果没有可用的EEPROM数据，SPI NOR Flash节点将始终启用。有关更多信息，请参阅设备树overlay部分。

+

bootloader程序还可以通过内核的mtdparts启动参数修改设备树，将SPI MTD分区表传递给Linux。BSP中的默认分区布局设置为：

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

这是一个预定义的bootloader环境变量，可以在运行时更改。从Linux用户空间，可以通过/dev/mtd<N>设备访问NOR Flash分区，其中<N>是与要访问的NOR Flash分区相关联的MTD设备编号。要找到分区的正确MTD设备编号，请在目标上运行：

+
root@phyboard-polis-imx8mm-5:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

它列出了所有MTD设备及其对应的分区名称。闪存节点在模块DTS中的SPI主节点内定义。SPI节点包含连接到此SPI总线的所有设备，在这种情况下只有SPI NOR Flash。

+

设备树中SPI主节点的定义可以在这里找到：

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n87

+
+
+
+

7.7. GPIOs

+

phyBOARD-Polis 具有一组专门用于GPIO的引脚。这些引脚直接连接到 i.MX 8M Mini 引脚，并被复用为 GPIO。它们可以直接在 Linux 用户空间中使用。处理器将其 GPIO 组织为5个GPIO组（GPIO1 – GPIO5），每个组包含 32 个GPIO。gpiochip0、gpiochip32、gpiochip64、gpiochip96 和 gpiochip128 是这些内部 i.MX 8M Mini GPIO 组 GPIO1 – GPIO5 的 sysfs 表示。

+

GPIO被标识为GPIO<X>_<Y>（例如：GPIO5_07）。<X>表示GPIO Bank，从1计数到5，而<Y>表示该Bank内的GPIO。<Y>从0计数到31（每个bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如从gpiochip0的GPIO 20）：

    +
    target:~$ gpioget gpiochip0 20
+
    +
    +
    • +

  • 将gpiochip0上的GPIO 20的值设置为0并退出工具：

    +
    target:~$ gpioset --mode=exit gpiochip0 20=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.7.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用 CONFIG_GPIO_SYSFS 后才能支持。要在menuconfig中使 CONFIG_GPIO_SYSFS 可见，必须首先启用选项 CONFIG_EXPERT 。

+

您也可以将此选项添加到您在 Linux 内核源代码 arch/arm64/configs/ 目录下使用的 defconfig 中。例如，我们基于 NXP 的BSP版本，这个defconfig可以是 imx8_phytec_distro.config

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+

设备树 imx8mm-phyboard-polis-rdk.dts 中一些GPIO引脚的管脚复用：

+
pinctrl_leds: leds1grp {
+        fsl,pins = <
+                MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1       0x16
+                MX8MM_IOMUXC_GPIO1_IO14_GPIO1_IO14      0x16
+                MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x16
+        >;
+};
+
+
+
+
+
+

7.8. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

这里的 LED 灯包括蓝色的 mmc、绿色的 心跳和红色的 emmc，它们都在 phyBOARD-Polis 上。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

用户输入/输出配置的设备树配置可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n36

+
+
+

7.9. I²C总线

+

该 i.MX 8M Mini 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 8M Mini 的I²C模块。 本节描述了我们 phyBOARD-Polis 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

通用 I²C1 总线配置（例如 imx8mm-phycore-som.dtsi）： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n119

+

通用 I²C4 总线配置（例如 imx8mm-phyboard-polis-rdk.dts）： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n244

+
+
+

7.10. EEPROM

+

在 phyCORE-i.MX8MM 上有一个i2c EEPROM闪存。它有两个地址。主EEPROM空间（总线：I2C-0 地址：0x51）和ID页（总线：I2C-0 地址：0x59）可以通过Linux中的sysfs接口进行访问。主EEPROM和ID页的前256个字节用于板检测，不可被覆盖。覆盖保留的空间将导致启动问题。

+
+

7.10.1. phyCORE-i.MX8MM 上的I2C EEPROM

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

phyCORE-i.MX8MM SoM上的I2C EEPROM连接到I2C-0总线的I2C地址0x51。可以直接对该设备进行读写操作：

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

要用零填充4KiB的EEPROM（总线：I2C-0 地址：0x51），并保留EEPROM数据，请使用：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM 检测

+

在 phyCORE-i.MX8MM 上配置的I2C EEPROM具有一个可通过I2C地址0x59在i2c0上寻址的独立ID页面，以及一个可通过I2C地址0x51在i2c0上寻址的正常区域。PHYTEC使用这个32字节的数据区域来存储关于SoM的信息，包括PCB版本和配置。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果EEPROM ID页面数据和正常区域的前256个字节被删除，bootloader程序将回退到 phyCORE-i.MX8MM Kit RAM设置，即 2GiB RAM。

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

使用API修订版2数据格式烧写的核心板将在早期启动阶段打印出有关模块的信息。

+
+
+

7.10.3. 恢复EEPROM数据

+

硬件数据已预先写入两个EEPROM数据空间。如果您不小心删除或覆盖了Normal区域，可以将ID区域的硬件检查数据复制到正常区域。

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1
+
+
+
+

备注

+

如果您删除了两个EEPROM空间，请联系我们的支持团队！

+
+

DT 表示法，例如在 phyCORE-i.MX 8M Mini 文件 imx8mm-phycore-som.dtsi 中，可以在我们的 PHYTEC git 中找到： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n311

+
+
+
+

7.11. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC唤醒alarm

+

可以从实时时钟（RTC）发出中断以唤醒系统。该格式使用Unix纪元时间，即自1970年1月1日UTC午夜以来的秒数。要在从挂起到RAM状态后的4分钟唤醒系统，请输入：

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

备注

+

内部唤醒alarm时间将被向上舍入到下一个分钟，因为alarm功能不支持秒。

+
+
+
+

7.11.2. RTC参数

+

实时时钟（RTC）具有一些功能，可以通过 hwclock 工具进行读取和设置。

+
    +

  • 我们可以通过以下方式检查RTC支持的功能：

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x11.
+
    +
    +

    这个值的含义在内核中进行了编码，每个位的定义为：

    +
    #define RTC_FEATURE_ALARM              0
+#define RTC_FEATURE_ALARM_RES_MINUTE   1
+#define RTC_FEATURE_NEED_WEEK_DAY      2
+#define RTC_FEATURE_ALARM_RES_2S       3
+#define RTC_FEATURE_UPDATE_INTERRUPT   4
+#define RTC_FEATURE_CORRECTION         5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE 6
+#define RTC_FEATURE_CNT                7
+
    +
    +
    • +

  • 我们可以通过以下方式检查RTC BSM（Backup Switchover Mode 备份切换模式）：

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • 我们可以通过以下方式设置RTC BSM：

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    BSM位的定义为：

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    小技巧

    +

    您应该将BSM模式设置为DSM或LSM，以便在初始电源不可用时，RTC可以切换到备用电源。请查看 RV-3028 RTC的Datasheet，以了解LSM（电平切换模式）和DSM（直接切换模式）这两个定义的工作模式。

    +
    +
    • +
+

I²C RTCs的DT表示: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n319

+
+
+
+

7.12. USB主控制器

+

i.MX 8M Mini SoC的USB控制器为众多消费类便携设备提供了一种低成本的连接以及数据传输解决方案，传输速率最高可达480 Mbps（高速 'HS'）。USB子系统具有两个独立的USB控制器IP。两个IP都是即插即用（OTG）控制器IP，能够充当USB外设设备或USB主机。每个IP都连接到一个USB 2.0物理层（PHY）。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+

USB2（host）配置在内核设备树 imx8mm-phyboard-polis-rdk.dts 中：

+
&usbotg2 {
+        dr_mode = "host";
+        picophy,pre-emp-curr-control = <3>;
+        picophy,dc-vol-level-adjust = <7>;
+        status = "okay";
+};
+
+
+

USB主机的DT表示：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n347

+
+
+

7.13. USB OTG

+

大多数PHYTEC板提供USB OTG接口。USB OTG端口会自动作为USB设备或USB主机工作。模式取决于连接到USB OTG端口的USB硬件。例如，如果将USB大容量存储设备连接到USB OTG端口，该设备将显示为 /dev/sda 。

+
+

7.13.1. 作为USB设备

+

为了将开发板作为USB设备连接到USB主机（例如PC），您需要配置相应的USB gadget。通过USB configfs，您可以定义USB gadget的参数和功能。BSP包含作为kernel module 的USB configfs支持。

+
target:~$ modprobe libcomposite
+
+
+

例子:

+
    +

  • 首先，定义参数，例如USB Vendor和product ID，并为英语（0x409）设置信息字符串：

    • +
+
+

提示

+

为了节省时间，请复制这些命令并在脚本中执行它们

+
+
cd /sys/kernel/config/usb_gadget/
+mkdir g1
+cd g1/
+echo "0x1d6b" > idVendor
+echo "0x0104" > idProduct
+mkdir strings/0x409
+echo "0123456789" > strings/0x409/serialnumber
+echo "Foo Inc." > strings/0x409/manufacturer
+echo "Bar Gadget" > strings/0x409/product
+
+
+
    +

  • 接下来，为大容量存储 gadget 创建一个文件：

    • +
+
target:~$ dd if=/dev/zero of=/tmp/file.img bs=1M count=64
+
+
+
    +

  • 现在你可以创建你想要使用的功能：

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir functions/acm.GS0
+mkdir functions/ecm.usb0
+mkdir functions/mass_storage.0
+echo /tmp/file.img > functions/mass_storage.0/lun.0/file
+
+
+
    +

  • acm: 串行设备 gadget，创建类似 /dev/ttyGS0 的串行接口。

    • +

  • ecm: 以太网 gadget，创建以太网接口，例如 usb0

    • +

  • mass_storage: 主机可以像处理其他USB大容量存储设备一样，对设备的大容量存储进行分区、格式化和挂载。

    • +
+
    +

  • 将定义的功能绑定到配置：

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir configs/c.1
+mkdir configs/c.1/strings/0x409
+echo "CDC ACM+ECM+MS" > configs/c.1/strings/0x409/configuration
+ln -s functions/acm.GS0 configs/c.1/
+ln -s functions/ecm.usb0 configs/c.1/
+ln -s functions/mass_storage.0 configs/c.1/
+
+
+
    +

  • 最后，使用以下命令启动USB gadget：

    • +
+
target:~$ cd /sys/kernel/config/usb_gadget/g1
+target:~$ ls /sys/class/udc/
+ci_hdrc.0
+target:~$ echo "ci_hdrc.0" >UDC
+
+
+

如果您的系统有多个USB设备或OTG端口，您可以将正确的端口传递给USB设备控制器（UDC）。

+
    +

  • 要停止USB gadget 并解除绑定已使用的功能，请执行：

    • +
+
target:~$ echo "" > /sys/kernel/config/usb_gadget/g1/UDC
+
+
+

两个USB接口在内核设备树 imx8mm-phyboard-polis-rdk.dts 中被配置为主机。请参见： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n335

+
+
+
+

7.14. CAN FD

+

The phyBOARD-Polis has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
+

提示

+

phyBOARD-Polis 具有一个通过 SPI 连接的外部 CAN FD 芯片 MCP2518FD。由于使用了SPI，限制了 CAN FD 的数据传输速率上限。

+
+
+

提示

+

在phyBOARD-Polis-i.MX8MM上，如果需要，可以通过将S5设置为ON来启用端接电阻。

+
+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。两个CAN接口显示为can0和can1。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    can0的信息将如下所示：

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+
+

警告

+

mcp2518fd SPI到CAN FD只支持从125kB/s开始的波特率。可以选择更慢的速率，但可能无法正常工作。

+
+

imx8mm-phyboard-polis-rdk 的设备树CAN配置.dts: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts?h=v5.15.71_2.2.2-phy3#n175

+
+
+

7.15. PCIe

+

phyCORE-i.MX 8M Mini 具有一个 Mini-PCIe 插槽。一般来说，PCIe 会自动检测总线上的新设备。在连接设备并启动系统后，您可以使用命令 lspci 查看所有被识别的 PCIe 设备。

+
    +

  • 输入：

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • 你将收到：

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

在这个例子中，PCIe设备是 英特尔 WiFi Link 5100 。

+

对于PCIe设备，您必须在内核配置中启用正确的驱动程序。例如，这款WLAN卡是由英特尔制造的。必须启用的驱动程序选项名为 CONFIG_IWLWIFI ，可以在内核配置中的 Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimate 下找到。

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • linux-imx的表示为：virtual/kernel

      • +
    +
    • +
+

对于某些设备，如WLAN卡，需要额外的二进制固件文件。这些固件文件必须放置在 /lib/firmware/ 目录中，才能使用该设备。

+
    +

  • 输入：

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • 例如，如果您尝试启动网络接口：

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • 您将在串口控制台上获得以下输出：

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

小技巧

+

某些PCIe设备，例如以太网卡，即使没有从 /lib/firmware/ 加载固件文件，也可能正常工作，而你收到了如上输出第一行所示的错误消息。这是因为一些制造商在板卡本身提供了固件作为后备。在这种情况下，设备的行为和输出在很大程度上依赖于制造商的固件。

+
+
+
+

7.16. 音频

+

PEB-AV-10-Connector有两个版本，其中1531.1版本配备了TI TLV320AIC3007音频编解码器（CODEC）。音频数据通过I2S传输，并通过I2C进行控制。

+

有一个符合OMTP标准的3.5mm耳机插孔和一个8针接口，用于连接带有AV连接器的音频设备。这个8针接口包含单声道扬声器、耳机和线路输入信号（line-in）。

+

要检查您的声卡驱动程序是否正确加载以及设备名称，请输入以下命令以查看播放设备：

+
target:~$ aplay -L
+
+
+

或输入录音设备：

+
target:~$ arecord -L
+
+
+
+

7.16.1. Alsamixer

+

要检查声卡的功能，请输入：

+
target:~$ alsamixer
+
+
+

您应该会看到很多选项，因为音频IC具有许多可以测试的功能。通过SSH打开alsamixer的图形界面比通过调试串口打开更易于使用。所有混音点都有单声道或立体声增益控制。"MM"表示该功能被静音（左右输出均为静音），可以通过按' m '切换。您还可以通过按' < ' 左和 ' > '切换右声道输出。使用 tab 键，您可以在播放和录音控制之间切换。

+
+
+

7.16.2. 恢复默认音量

+

一些默认设置存储在 /var/lib/alsa/asound.state 中。您可以使用以下命令保存当前的alsa设置：

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

您可以通过以下方式恢复已保存的alsa设置：

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.16.3. ALSA配置

+

我们的BSP附带一个ALSA配置文件 /etc/asound.conf 。

+

ALSA配置文件可以根据需要进行编辑或删除，它并不是ALSA正常工作所必需的。

+
target:~$ vi /etc/asound.conf
+
+
+

要将PEB-AV-10设置为输出，请将 playback.pcm 从 "dummy" 设置为 "pebav10":

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

如果听不到声音，请将播放设备更改为软件音量控制播放设备，将 playback.pcm 设置为相应的软音量播放设备，例如“softvol_pebav10”。使用alsamixer控制来调整音量级别。

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.16.4. PulseAudio 配置

+

对于使用 Pulseaudio 的应用程序，请检查可用的音频输出设备：

+
target:~$ pactl list short sinks
+
+
+

要选择输出设备，请输入：

+
target:~$ pactl set-default-sink <sink_number>
+
+
+
+
+

7.16.5. 播放

+

运行speaker-test以检查播放功能：

+
target:~$ speaker-test -c 2 -t wav
+
+
+

要播放简单的音频流，您可以使用aplay。例如，要播放ALSA测试音频：

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

要播放其他格式，例如mp3，您可以使用Gstreamer：

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.16.6. 录音

+

arecord 是一个命令行工具，用于录制音频流，默认输入源为线路输入。要选择不同的音频源，可以使用 alsamixer。例如，打开 右侧 PGA 混音器 Mic3R 和 左侧 PGA 混音器 Mic3R，以便通过 3.5mm 插孔录制来自 TLV320 编解码器的麦克风输入音频。

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

提示

+

由于播放和录音共享硬件接口，因此无法在同时进行播放和录音操作时使用不同的采样率和格式。

+
+

设备树音频配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mm-phyboard-polis-peb-av-010.dtsi?h=v5.15.71_2.2.2-phy3#n54

+
+
+
+

7.17. 视频

+
+

7.17.1. 视频与Gstreamer

+

默认情况下，BSP安装了一个示例视频，路径为 /usr/share/qtphy/videos/ 。可以使用以下命令之一开始视频播放：

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.18. 显示

+

10英寸显示屏始终处于使能状态。如果PEB-AV连接器未连接，启动时可能会出现错误信息。

+
+

7.18.1. Qt Demo

+

使用 phytec-qt6demo-image 时，Weston会在启动时启动。我们的Qt6 DEMO应用程序名为“qtphy”，可以通过以下方式停止：

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • 要重新开始Demo，请运行：

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • 要禁用Demo的自动启动，请运行：

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • 要启用Demo的自动启动，请运行：

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston可以通过以下方式停止：

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

备注

+

在关闭Weston之前，必须先关闭Qt Demo。

+
+
+
+

7.18.2. 背光控制

+

如果LCD连接到PHYTEC开发板，可以通过Linux内核的sysfs接口控制其背光。系统中所有可用的背光设备可以在文件夹/sys/class/backlight中找到。读取相应的文件并向其写入数据可以控制背光。

+
+

备注

+

一些具有多显示的开发板在 /sys/class/backlight 有多个背光控制。比如：backlight0和backlight1

+
+
    +

  • 例如，要获取最大亮度级别（max_brightness），请执行：

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    有效的亮度值范围是 0 到 <max_brightness>。

    +
    • +

  • 要获取当前亮度级别，请输入：

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • 写入文件brightness以更改亮度：

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    例如，关闭背光。

    +

    有关所有文件的文档，请参见 https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight。

    +
    • +
+

PEB-AV-10的设备树可以在这里找到: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mm-phyboard-polis-peb-av-010.dtsi?h=v5.15.71_2.2.2-phy3

+
+
+
+

7.19. 电源管理

+
+

7.19.1. CPU核心频率调节

+

i.MX 8M Mini SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。调整频率和电压被称为“动态电压和频率调整”（DVFS）。i.MX 8M Mini BSP支持DVFS功能。Linux内核提供了一个DVFS框架，允许每个CPU核心设置最小或最大频率和一个管理其运行的governor。根据使用的 i.MX 8 型号，支持几种不同的频率。

+
+

小技巧

+

尽管DVFS框架为每个CPU核心提供了频率设置，但一个CPU核心的频率更改会影响其他CPU核心。因此，所有CPU核心始终共享相同的DVFS设置。每个核心的单独DVFS设置是不可能的。

+
+
    +

  • 要获取完整列表，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    例如 i.MX 8MPlus CPU，最高可达约 1.6 GHz，则结果将是：

    +
    1200000 1600000
+
    +
    +
    • +

  • 要查询当前的频率输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

governor 会根据它们的目标自动选择这些频率中的一个。

+
    +

  • 列出所有可用的 governor，使用以下命令：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    结果是：

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative governor 与 ondemand governor 非常相似。只是它的行为有所不同，它会更保守地增减CPU速度，而不是在CPU有任何负载的瞬间就跳到最大速度。

    • +

  • ondemand （默认）根据当前系统负载在可能的CPU核心频率之间切换。当系统负载超过特定值时，它会立即提高CPU核心频率。

    • +

  • powersave 始终选择最低的CPU核心频率。

    • +

  • performance 始终选择最高的CPU核心频率。

    • +

  • userspace 允许以root身份运行的用户或用户空间程序设置特定频率（例如，设置为1600000）。输入：

    • +

  • 要查询当前的 governor，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    您通常会得到：

    +
    ondemand
+
    +
    +
    • +

  • 切换到另一个governor（例如，userspace）可以通过以下方式完成：

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • 现在你可以设置频率：

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

有关governor的更详细信息，请参阅Linux内核代码库中的Linux内核文档，路径为 Documentation/admin-guide/pm/cpufreq.rst 。

+
+
+

7.19.2. CPU核心管理

+

该 i.MX 8M Mini SoC 芯片上可以有多个处理器核心。例如，该 i.MX 8M Mini 具有 4 个 ARM 核心，可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    这里系统有四个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.19.3. 挂起到RAM

+

phyCORE-i.MX8MM 支持基本的挂起和恢复。可以使用不同的唤醒源。挂起/恢复可以通过以下方式实现：

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

要通过串行控制台唤醒，请运行

+
target:~$ echo enabled > /sys/class/tty/ttymxc2/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.20. 热管理

+
+

7.20.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.20.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 8M Mini SoC 平台上使用热管理内核 API。 i.MX 8 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个触发点。这些触发点根据CPU型号的不同而有所不同。主要区分工业版和商业版。

+ + + + + + + + + + + + + + + + + +

商业

工业

被动（警告）

85°C

95°C

严重（关机）

90°C

100°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并实施冷却措施。内核中可用的热政策（也称为thermal governor）包括：Step Wise、Fair Share、Bang Bang和Userspace。BSP中使用的默认策略是Step Wise。如果sysfs文件temp中的SoC温度值高于 trip_point_0 ，则CPU频率将设置为最低CPU频率。当SoC温度降到 trip_point_0 以下时，限制将被解除。

+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+

7.20.3. GPIO风扇

+
+

备注

+

Only GPIO fan supported.

+
+

一个GPIO控制的风扇可以连接到 phyBOARD-Polis-i.MX 8M Mini。该SoC包含一个温度传感器，该传感器被用于热频率调节。风扇无法通过内核进行控制。我们使用lmsensors和hwmon来实现这一点。lmsensors定期读取温度，并在可配置的阈值下启用或禁用风扇。对于 phyBOARD-Polis-i.MX 8M Mini，这个阈值是60°C。

+

设置可以在配置文件中进行配置：

+
/etc/fancontrol
+
+
+

风扇控制在启动时由systemd服务启动。可以通过以下方式禁用它：

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.21. 看门狗

+

PHYTEC i.MX 8M Mini 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.21.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.22. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 8M Mini 提供一次性可编程fuse，用于存储信息，例如 MAC 地址、启动配置和其他永久设置（在 i.MX 8M Mini reference manual中称为“片上 OTP 控制器 (OCOTP_CTRL)”）。以下列表摘自 i.MX 8M Mini reference manual，包括 OCOTP_CTRL 中的一些有用寄存器（基地址为0x30350000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为0x30350000

描述

OCOTP_MAC_ADDR0

9

0

0x640

包含ENET0 MAC地址的低32位

OCOTP_MAC_ADDR1

9

1

0x650

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

OCOTP_MAC_ADDR2

9

2

0x660

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 8M Mini Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.22.1. 在uBoot中读取fuse的值

+

您可以使用内存映射的shadow寄存器读取fuse寄存器。要计算内存地址，请使用以下公式计算：

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.22.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+
+

8. i.MX 8M Mini M4 Core

+

除了Cortex-A53核心外，SoC中还集成了一个Cortex-M4 Core 作为MCU。我们的Yocto-Linux-BSP在A53核心上运行，而 M4 Core 可以作为辅助CPU，用于使用裸机或RTOS固件执行额外任务。两种核心都可以访问相同的外设，因此外设的使用需要在 M4 Core 的固件或Linux操作系统的设备树中进行限制。本节将描述如何编译固件示例以及如何在 phyBOARD-Polis 上运行它们。

+

phyBOARD-Polis 目前由 NXP MCUXpresso SDK 和 Zephyr 项目支持。本节仅描述 NXP MCUXpresso SDK，因为目前 MCUXpresso SDK 支持的功能更多。

+

如果您想在Zephyr项目中使用 M4 Core ，请参考Zephyr项目文档：

+ +
+

8.1. 获取固件示例

+

固件可以使用NXP MCUxpresso SDK和兼容的编译工具链通过命令行工具进行编译。

+
+

8.1.1. 获取源代码

+

MCUX SDK以及 i.MX 8M Mini 的示例可以从PHYTEC的GitHub页面获取：

+ +
    +

  1. 通过west初始化MCUX SDK：

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    这将创建一个 mcuxsdk 目录，并在其中包含 mcux-sdk 仓库。mcux-sdk-phytec-examples 仓库将自动克隆到 mcuxsdk 目录中。给定的参数 <VERSION> 是 mcux-sdk 仓库的分支名称，代表 MCUX SDK 版本。要获取最新的测试版本，您可以使用 2.13.0。

    +
    +

    备注

    +

    west 是一个仓库管理工具，也是 Zephyr 项目的一部分。要安装 west，您可以使用 pip。在这个示例中，west 被安装在一个 Python 虚拟环境中:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. 更新依赖项：

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    目录 examples-phytec 包含了所有移植并测试过的示例，适用于 phyBOARD-Polis 和版本为 2.13.0 的 MCUX。

    +

    要编译固件，需要一个编译器工具链和make/cmake。GNU ARM 嵌入式工具链可能在您的主机linux发行版的仓库中可用，例如Ubuntu。

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    编译器工具链也可以直接从 https://developer.arm.com/ 获取。在解压缩文件后，必须将 ARMGCC_DIR 添加到环境变量中，例如，对于位于主目录中的 ARM toolchain 10-2020-q4-major 版本：

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. 编译固件

+

要编译PHYTEC示例，需要先设置环境

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

编译固件的脚本位于 <sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc。每个可运行的内存位置都有相应的编译脚本，例如：

+
host:~$ ./build_release.sh
+
+
+

要编译运行在 M4 Core 的 TCM 上的固件。输出将放置在 armgcc 目录下的 release/ 中。.bin 文件可以在 U-Boot 中运行，而 .elf 文件可以在 Linux 中运行。

+

要编译在DRAM上运行的固件，请运行脚本build_ddr_release。例如。

+
host:~$ ./build_ddr_release.sh
+
+
+

输出将放置在armgcc目录下的ddr_release/中。.bin文件可以在U-Boot中运行，而.elf文件可以在Linux中运行。

+
+
+
+

8.2. 运行 M4 Core 示例

+

有两种方法可以运行 M4 Core 的固件，在Linux中使用Remoteproc以及在U-Boot。

+

要接收调试信息，请在您的主机PC上启动您喜欢的终端软件（例如Minicom、Tio或Tera Term），并将其配置为115200波特率、8个数据位、无奇偶校验和1个停止位（8n1），且不使用握手。

+

一旦Micro USB电缆连接到 phyBOARD-Polis 上的USB调试端口，就会注册两个ttyUSB设备。一个打印来自A53核心的调试UART的消息，另一个打印来自 M4 Core 的调试UART的消息。

+
+

8.2.1. 从U-Boot运行示例

+

要使用bootloader U-Boot加载固件，可以使用bootaux命令：

+
    +

  1. 准备一张烧写了BSP镜像的SD卡

    2. +

  2. 将生成的 .bin 文件复制到 SD 卡的第一个分区

    3. +

  3. 通过按任意键停止自动启动

    4. +

  4. 根据固件类型输入命令：

    5. +
+

对于在 M4 Core 的TCM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

用于在DRAM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

程序的输出应显示在 M4 Core 的调试UART上。

+
+
+

8.2.2. 通过Remoteproc在Linux上运行示例

+

Remoteproc是一个模块，允许您在运行时从Linux控制 M4 Core 。可以加载为TCM编译的固件，并可以启动或停止执行。要使用Remoteproc，需要设置设备树Overlay：

+

在开发板的/boot目录中编辑bootenv.txt文件，添加 imx8mm-phycore-rpmsg.dtbo ：

+
overlays=imx8mm-phycore-rpmsg.dtbo
+
+
+

重启目标并在U-Boot中执行:

+
u-boot=> run prepare_mcore
+
+
+

M4 Core 的固件 .elf 文件可以在 /lib/firmware 下找到。要加载固件，请输入：

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

要加载不同的固件，M4 Core 需要停止：

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

备注

+

在开发板上找到的 /lib/firmware 中的例子来自NXP的Yocto层meta-imx。要使用您通过MCUX SDK自己编译的样本，请在编译后将它们复制到开发板的 /lib/firmware 中。

+
+
+ +
+
+
+

9. BSP扩展

+
+

9.1. Chromium

+

我们的BSP支持Chromium。您只需几个步骤即可将其包含在 phytec-qt6demo-image 中。

+
+

9.1.1. 将Chromium添加到您的local.conf文件中

+

要包含Chromium，您需要在您的local.conf中添加以下行。您可以在<yocto_dir>/build/conf/local.conf中找到这个配置文件。这将把Chromium添加到您下一个镜像编译中。:

+
IMAGE_INSTALL:append = " chromium-ozone-wayland"
+
+
+
+

备注

+

编译Chromium需要很长时间。

+
+
+
+

9.1.2. 在开发板上运行Chromium

+

要运行Chromium，需要一些参数来使用硬件图形加速：

+
target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox
+
+
+

如果您想通过SSH启动Chromium，您必须首先定义运行Chromium的显示器。例如：

+
target$ DISPLAY=:0
+
+
+

在您定义完这个之后，您可以通过上述所示的Weston虚拟终端启动它。

+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mn/head.html b/previews/271/zh_CN/bsp/imx8/imx8mn/head.html new file mode 100644 index 000000000..a5f9851e5 --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mn/head.html @@ -0,0 +1,3374 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + + + + +

L-1002e.Ax i.MX 8M Nano BSP 手册模板

文档标题

L-1002e.Ax i.MX 8M Nano BSP 手册模板

文档类型

BSP 手册

型号

L-1002e.Ax

Yocto 手册

发布日期

XXXX/XX/XX

母文档

L-1002e.Ax i.MX 8M Nano BSP 手册模板

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP 发布日期

BSP 状态

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 phyCORE-i.MX8M Nano Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads 中找到。

+
+

1.1. 支持的硬件

+

支持的 i.MX 8M Nano 系统芯片 (SoC) 的 phyBOARD-Polis。

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-NXP-i.MX8MM-PD23.1.0 的所有Machine及其对应的Article Numbers(产品型号)： 网址. 如果您在该网页 Supported Machines 一节选择了特定的 Machine Name ，您可以查看被选中machine下的包含的 Article Number(产品型号) 以及简要的硬件描述。如果您只有 Article Number ，可以将 Machine Name 下拉菜单留空，仅选择您的 Article Number 。那么，它会显示您特定硬件所对应的 Machine Name

+
+

1.1.1. phyBOARD-Polis 器件

+ + + + + + +
+../../../_images/polis-front.jpg +
+

phyBOARD-Polis 器件（顶部）

+
+
+
+../../../_images/polis-back.jpg + +
+

phyBOARD-Polis 器件（底部）

+
+
+
+
+
+
+
+

2. 开始使用

+

该 phyCORE-i.MX8M Nano Kit 包含预先烧写好的SD卡。它包含 phytec-headless-image 镜像，可以直接用作启动盘。默认情况下，核心板上的eMMC仅烧写了U-Boot。您可以从 PHYTEC下载服务器 获取所有镜像资源。本章将解释如何将BSP镜像烧写到SD卡以及如何启动开发板。

+

有几种方法可以将镜像写入SD卡或eMMC。最为人熟知的方式是使用Linux命令行工具 dd 进行简单的顺序写入。另一种方法是使用PHYTEC的自研程序 partup ，它可以让格式化复杂系统的过程变得简单。您可以从其发布页面获取 预编译的Linux partup 二进制文件 。请阅读 partup的readme文件 来获取安装指导。

+
+

2.1. 下载镜像

+

phytec-headless-image 镜像包含完整系统所需的所有必要文件，您需确保镜像中各个分区以及裸数据都会被正确写入启动盘。可以从 PHYTEC 下载服务器 下载 partup 镜像文件或者是可以使用 dd 进行烧写的 WIC 镜像。

+

从下载服务器获取 partup 镜像文件或WIC镜像：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.wic
+
+
+
+

备注

+

针对eMMC，我们建议使用partup去烧写比较大的或者是有复杂分区配置的镜像，因为它在写入速度上比 dd 更快，并且可以对闪存设备进行更灵活的配置。

+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要创建SD卡启动盘，必须要拥有Linux PC上的root权限。在选择烧写设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+
+

2.2.1. 寻找正确的设备

+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行命令：

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+

卸载所有这些分区，例如：

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

现在，SD卡已经准备好可以使用 partup 、 dd 或 bmap-tools 来写入镜像。

+
+
+

2.2.2. 使用bmap-tools

+

烧写SD卡的其中一种方法是使用 bmap-tools 。Yocto会自动为WIC镜像创建一个block map文件（ <IMAGENAME>-<MACHINE>.wic.bmap ），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host:~$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host:~$ bmaptool copy phytec-headless-image-phyboard-polis-imx8mn-2?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

将 <your_device> 替换为您之前找到的SD卡设备名称，并确保将文件 <IMAGENAME>-<MACHINE>.wic.bmap 与WIC镜像文件放在一起，以便bmaptool知道哪些块需要写入，哪些块需要跳过。

+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.2.3. 使用partup

+

使用partup烧写SD卡只需一个命令：

+
host:~$ sudo partup install phytec-headless-image-phyboard-polis-imx8mn-2?(.rootfs).partup /dev/<your_device>
+
+
+

确保将 <your_device> 替换为您之前找到的设备名称。

+

关于partup的进一步使用说明，请参阅其 官方文档 。

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 release notes 。

+
+
+

备注

+

partup 具有清除eMMC user区域中特定区域的功能，我们提供的partup程序中用该功能擦除U-Boot环境变量。这是 bmaptool 工具所无法完成的一点，如前一部分所提到的。

+

partup相较于其他烧写工具的一个主要优势是，它可以配置MMC的特定部分，比如他可以直接写入eMMCboot分区，无需调用其他命令。

+
+
+
+

2.2.4. 使用 dd

+

在卸载所有SD卡的挂载分区后，您可以烧写SD卡。

+

一些PHYTEC BSP会生成未压缩的镜像（文件名扩展名为*.wic），而另一些则生成压缩的镜像（文件名扩展名为*.wic.xz）。

+

要写入未压缩的镜像（*.wic），请使用以下命令：

+
host:~$ sudo dd if=phytec-headless-image-phyboard-polis-imx8mn-2?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

或者要写入压缩后的镜像（*.wic.xz），请使用以下命令：

+
host:~$ xzcat phytec-headless-image-phyboard-polis-imx8mn-2?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

再次确保将 <your_device> 替换为之前找到的设备名称。

+

参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

+
+
+
+

2.3. 首次启动

+ + + + + + + +
启动模式选择
+../../../_images/Nano_SD_BOOT.jpg + +
+

SD卡启动

+
+
+
+
    +

  • 插入SD卡

    • +

  • 使用 micro USB 线将开发板的 (X30) 调试USB口和主机连接起来

    • +

  • 给开发板通电

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 8M Nano BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (kirkstone).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (kirkstone).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-IMX8MM ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-vendor MACHINE=phyboard-polis-imx8mn-2 ./phyLinux init -p imx8mn -r BSP-Yocto-NXP-i.MX8MM-PD23.1.0
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 phyboard-polis-imx8mn-2 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx8mn.bin: ARM可信固件二进制文件

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY固件镜像

    • +

  • imx-boot：由imx-mkimage编译的bootloader镜像，包括SPL、U-Boot、ARM可信固件和DDR固件。这是最终的可引导bootloader镜像。

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx8mn-phyboard-polis*.dtb: 内核设备树文件

    • +

  • imx8mn-phy*.dtbo：内核设备树overlay文件

    • +

  • phytec-headless-image*.tar.gz: 根文件系统

    • +

  • phytec-headless-image*.rootfs.wic.xz: 压缩的SD卡镜像

    • +
+
+
+
+
+

4. 安装操作系统

+
+

4.1. 启动模式开关 (S1)

+

该 phyBOARD-Polis 具有一个启动配置开关，带有六个可单独切换的开关，用于选择 phyCORE-i.MX 8M Nano 的默认启动源。

+

硬件修订主板：1532.2及更新版本

+ + + + + + + + + + + + + +
启动模式选择
+../../../_images/Nano_eMMC_BOOT.png + +
+

eMMC（核心板的默认启动方式）

+
+
+
+../../../_images/Nano_Serial_downloader_BOOT.png + +
+

USB串行下载器

+
+
+
+../../../_images/Nano_SD_BOOT.jpg + +
+

SD卡

+
+
+
+../../../_images/Nano_Fuse_BOOT.png + +
+

内部fuse

+
+
+
+../../../_images/Nano_QSPI_BOOT.png + +
+

SPI NOR

+
+
+

+ + + + + + + +
通过开关(S1)的第5位在USB HOST/OTG之间切换。
+../../../_images/USB_HOST.jpg + +
+

USB 主机

+
+
+
+../../../_images/USB_OTG.png + +
+

USB OTG

+
+
+
+ + + + + + + +
通过开关(S1)的第4位在UART1的RS485/RS232之间切换。
+../../../_images/UART1_RS4851.png + +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS2321.jpg + +
+

UART1 RS232

+
+
+
+
+
+

4.2. 烧写eMMC

+

为了保持文档的一致性和简洁性，假设已经配置好了TFTP服务器；所有生成的镜像（如上所列）都被复制到默认的/srv/tftp目录。如果您没有进行设置，您需要修改路径到包含镜像的目录。有关如何设置TFTP服务器和目录的说明，请参见 Setup Network Host 。

+

要从 eMMC 启动，请确保 BSP 镜像已正确烧写到 eMMC，并且 bootmode switch (S1) 设置为 eMMC。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行上述命令来检查系统启动在这种条件下是否会到影响。如果 mmcblk2p1 和 mmcblk1p1 具有相同的UUID，则会影响系统正确启动。

+
+
+

4.2.1. 从网络烧写 eMMC

+

i.MX 8M Nano 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

4.2.1.1. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

查看主机上可用的镜像文件：

+
host:~$ ls /srv/tftp
+phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.xz
+phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.bmap
+
+
+

通过网络ssh协议使用 bmaptool 命令将镜像发送到开发板的eMMC：

+
host:~$ scp /srv/tftp/phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.xz /dev/mmcblk2"
+
+
+
+
+

4.2.1.2. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

使用以下命令，通过网络将压缩或未压缩的镜像和配套的 *.bmap 文件传送到核心板并写入 eMMC：

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.* /tmp && bmaptool copy /tmp/phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.xz /dev/mmcblk2
+
+
+
+
+

4.2.1.3. 在开发板的U-Boot中通过网络烧写eMMC

+

这些步骤将展示如何通过网络更新eMMC。

+
+

小技巧

+

此步骤仅在镜像文件小于1GB的情况下会被执行成功，因为在启用OPTEE后，Bootloader中可用的RAM大小有限，不足以加载超过1GB的镜像

+
+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

解压缩您的镜像

+
host:~$ unxz /srv/tftp/phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.xz
+
+
+

通过网络将您的镜像加载到内存中：

+
    +

  • 使用DHCP

    +
    u-boot=> dhcp phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.1 (1 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.1
+Filename 'phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • 使用静态IP地址（必须先设置serverip和ipaddr）。

    +
    u-boot=> tftp ${loadaddr} phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
+
+
+
+
+

4.2.2. 在运行的U-Boot中通过网络烧写eMMC U-Boot镜像

+

可以在U-Boot中更新U-Boot镜像imx-boot，eMMC上的U-Boot需要位于eMMC的user区域。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.3. 从USB大容量存储设备烧写eMMC

+
+

4.2.3.1. 在运行的Linux系统中从USB烧写eMMC

+

下面这些步骤展示如何在Linux系统上使用USB大容量存储设备烧写eMMC。您需要一个保存了完整镜像的U盘和一个可从SD卡启动的核心板。（例如： phytec-headless-image-phyboard-polis-imx8mn-2.|yocto-imageext| ）。将 bootmode switch (S1) 设置为SD卡。

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ ls /mnt
+phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.xz
+phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.bmap
+
    +
    +
    • +

  • 将镜像写入 phyCORE-i.MX 8M Nano eMMC（无分区的 MMC 设备 2）：

    +
    target:~$ bmaptool copy /mnt/phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.xz /dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    小技巧

    +

    在此之前，您需要将 bootmode switch (S1) 配置为 eMMC。

    +
    +
    • +
+
+
+

4.2.3.2. 在开发板上通过U-Boot从USB烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件小于1GB的情况下会被执行成功，因为在启用OPTEE后，Bootloader中可用的RAM大小有限，不足以加载超过1GB的镜像

+
+

下面这些步骤展示如何通过USB设备更新eMMC。将 bootmode switch (S1) 配置为SD卡并插入SD卡。给开发板上电并进入U-Boot环境。将已存储了未压缩WIC镜像的优盘插入开发板USB接口。

+

将镜像从USB设备加载到RAM中：

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 0x58000000 phytec-headless-image-|yocto-machinename|.rootfs.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write 0x58000000 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+
+

4.2.4. 从SD卡烧写eMMC

+

即使没有可用的网络，您也可以更新eMMC。为此，您需要一个位于SD卡上的镜像文件（ *.wic ）。由于镜像文件相当大，您需要在SD卡创建第三个分区。要创建新分区或扩展您的SD卡，请参见 Resizing ext4 Root Filesystem 。

+

或者，使用partup包烧写SD卡，如 Getting Started 中所述。这样就可使用SD卡的全部容量。

+
+

4.2.4.1. 在开发板的linux环境中通过SD卡烧写eMMC

+

您也可以在Linux系统中烧写eMMC。您只需要一个partup包或保存在SD卡上的WIC镜像。

+
    +

  • 检查在SD卡上保存的partup包或WIC镜像文件：

    +
    target:~$ ls
+phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.partup
+phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.xz
+phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.bmap
+
    +
    +
    • +

  • 使用 partup 将镜像写入 phyCORE-i.MX 8M Nano 的 eMMC（MMC 设备 2 不带 分区字样）：

    +
    target:~$ partup install phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.partup /dev/mmcblk2
+
    +
    +

    使用partup烧写的优点是可以充分利用eMMC设备的全部容量，会相应自动调整分区大小。

    +
    +

    备注

    +

    另外，也可以使用 bmaptool 工具：

    +
    target:~$ bmaptool copy phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic.xz /dev/mmcblk2
+
    +
    +

    请注意，在使用 bmaptool 烧写时，根文件系统分区并不会使用eMMC的最大容量。

    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    警告

    +

    在此之前，您需要将 bootmode switch (S1) 配置为 eMMC。

    +
    +
    • +
+
+
+

4.2.4.2. 在开发板的uboot环境中通过SD卡烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1GB的情况下有效，因为在启用OPTEE后，Bootloader中可用的RAM大小有限。如果镜像文件过大，请阅读 在开发板上通过SD卡更新eMMC 一节

+
+
    +

  • 将一个可用的镜像烧写到SD卡，并创建一个EXT4格式的第三分区。将WIC镜像（例如 phytec-headless-image.rootfs.wic）复制到该分区。

    • +

  • 将 bootmode switch (S1) 配置为 SD 卡并插入 SD 卡。

    • +

  • 打开电源并进入U-Boot。

    • +

  • 加载镜像：

    +
    u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • 将当前mmc设备切换到eMMC：

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • 将您的WIC镜像（例如 phytec-headless-image.rootfs.wic）从SD卡烧写到eMMC。这将对emmc进行分区，并将imx-boot、Image、dtb、dtbo和根文件系统复制到eMMC。

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • 关闭电源并将 bootmode switch (S1) 更改为 eMMC。

    • +
+
+
+
+
+

4.3. 烧写 SPI NOR Flash

+

phyCORE-i.MX8MN 模块可选配SPI NOR Flash。要从SPI Flash启动，请将 bootmode switch (S1) 设置为 SPI NOR 。SPI Flash通常比较小。phyBOARD-Pollux-i.MX8MP开发套件仅配备32MB的SPI NOR Flash。只能存储bootloader及其环境变量。默认情况下，内核、设备树和文件系统会从eMMC加载。

+

SPI NOR Flash分区表在U-Boot环境变量中定义。可以通过以下命令打印：

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. 通过网络烧写SPI NOR Flash

+

SPI NOR可以包含bootloader及其环境变量。arm64的linux内核无法自行解压缩，内核镜像大小超出了phyCORE-i.MX 8M Nano 上的SPI NOR Flash的容量。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+
+

4.3.1.1. 在开发板linux环境中通过网络烧写SPI NOR Flash

+
    +

  • 将镜像从主机复制到开发板：

    +
    host:~$ scp imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • 查找要擦除的U-boot分区的块数：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除U-Boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.1.2. 在开发板的U-Boot环境中通过网络烧写SPI NOR

+

类似于通过网络更新eMMC，请确保正确设置主机PC。IP地址需要设置为192.168.3.10，子网掩码设置为255.255.255.0，并且需要有一个可用的TFTP服务。在进行读写之前，需要对SPI NOR Flash进行枚举：

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像。确保您使用了正确的镜像文件。通过tftp加载镜像，然后将bootloader写入Flash：

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+

4.3.2. 从SD卡烧写SPI NOR Flash

+

SPI NOR Flash上的bootloader也可以通过SD卡进行烧写。

+
+

4.3.2.1. 在开发板的linux环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi复制到SD卡的第一个分区。

    • +

  • 挂载SD卡：

    +
    target:~$ mount /dev/mmcblk1p1 /mnt
+
    +
    +
    • +

  • 查找要擦除的U-Boot分区的块数：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除u-boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.2.2. 在开发板的U-Boot环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi复制到SD卡的第一个分区。

    • +

  • 在进行读写操作之前，需要对SPI-NOR Flash进行枚举：

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像，请确保使用正确的镜像文件。从SD卡加载镜像，擦除并将bootloader写入flash：

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC： L-1006e.A6 RAUC Update & Device Management Manual 。

+
+
+
+

5. 开发

+
+

5.1. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.1.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.2. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.2.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核镜像复制到您的tftp目录中：

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • 将设备树复制到您的tftp目录：

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • 将您想要使用的所有overlay文件复制到您的tftp目录中：

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-headless-image-phyboard-polis-imx8mn-2.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.2.2. 设置网络启动的bootenv.txt文件

+

在您的tftp目录中创建一个bootenv.txt文件，并将以下变量写入其中。

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> 必须替换为您想要使用的overlay设备树文件名。用空格分隔文件名。例如：

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

小技巧

+

所有支持的设备树overlay在 device tree 章节中。

+
+
+
+

5.2.3. 开发板上的网络设置

+

如果要自定义开发板上的以太网配置，请按照此处的说明进行操作： Network Environment Customization

+
+
+

5.2.4. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.3.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. 获取镜像

+

从我们的服务器下载imx-boot，或者从您Yocto工程中的build/deploy-ampliphy-vendor/images/phyboard-polis-imx8mn-2/路径获取。要将wic镜像烧写到eMMC，你还需要 phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic。

+
+
+

5.3.3. 开发板准备

+

将 bootmode switch (S1) 设置为 USB串行下载。同时，将 USB 端口 X2 连接到主机。

+
+
+

5.3.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 (X30) 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.3.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-headless-image-phyboard-polis-imx8mn-2.rootfs.wic
+
+
+
+
+

5.3.7. 通过UUU工具烧写SPI NOR Flash

+

执行并给开发板上电：

+
host:~$ sudo uuu -b qspi imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi
+
+
+

这将更新SPI NOR Flash上的U-Boot，但不会更新环境。您可能需要擦除旧环境，以便加载新U-Boot的默认环境：

+
u-boot=> env erase
+u-boot=> reset
+
+
+
+
+
+

5.4. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone git://git.phytec.de/u-boot-imx）

+
+
+

5.4.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-imx 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • 我们的 i.MX 8M Nano 内核是基于 linux-imx 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. 获取SDK

+

您可以在此处下载SDK 这里，或者使用Yocto去编译生成SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-headless-image # or another image
+
    +
    +
    • +
+

在成功编译后，SDK安装包保存在 build/deploy*/sdk。

+
+
+

5.4.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-vendor-glibc-x86_64-phytec-headless-image-cortexa53-crypto-toolchain-4.0.13.sh
+host:~$ ./phytec-ampliphy-vendor-glibc-x86_64-phytec-headless-image-cortexa53-crypto-toolchain-4.0.13.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor/4.0.13):
+You are about to install the SDK to "/opt/ampliphy-vendor/4.0.13". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-vendor/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. 单独编译U-Boot

+
+

5.5.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本中使用的**tag**称为 v2022.04_2.2.2-phy5

    • +

  • 查看所需的 U-Boot tag：

    +
    host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2022.04_2.2.2-phy5
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. 获取所需的二进制文件

+

要编译bootloader，您需要将这些文件复制到您的 u-boot-imx 编译目录，并将其重命名以适应 mkimage 脚本：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx8mn.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以在yocto工程目录中获取 bl31-imx8mn.bin、tee.bin和lpddr4_*.bin：BSP Images

+

或者你可以在这里下载文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/imx-boot-tools/

+
+

警告

+

确保您重命名所需的文件，以和 mkimage tool 兼容。

+
+
+
+

5.5.3. 编译bootloader

+
    +

  • 编译 flash.bin (imx-boot):

    +
    host:~/u-boot-imx$ make phycore-imx8mn_defconfig
+host:~/u-boot-imx$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. 将bootloader烧写到块设备上

+

flash.bin 文件可以在 u-boot-imx/ 目录下找到，现在可以进行烧写。需要指定芯片特定的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

+

例如，烧写SD卡：

+
host:~/u-boot-imx$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+
+

5.6. 单独编译内核

+
+

5.6.1. 配置源代码

+
    +

  • 使用的 linux-imx 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v5.15.71_2.2.2-phy3

    • +

  • Check out 所需的 linux-imx 标签：

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v5.15.71_2.2.2-phy3
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-imx$ make imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-imx/arch/arm64/boot/Image 找到

    • +

  • dtb文件可以在 ~/linux-imx/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. 将内核复制到SD卡

+

内核及module和对应的设备树二进制文件可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. 获取BSP开发中版本

+
+

5.7.1. 当前release的开发中版本

+

这些release manifest文件是为了让您访问 Yocto BSP的开发版本。它们不会在phyLinux选择菜单中显示，需要手动选择。可以使用以下命令行来完成此操作：

+
host:~$ ./phyLinux init -p imx8mn -r BSP-Yocto-NXP-i.MX8MM-PD23.1.y
+
+
+

这将初始化一个BSP，用于跟踪当前版本（ BSP-Yocto-NXP-i.MX8MM-PD23.1.0 ）的最新开发版本。从现在开始，在此文件夹中执行 repo sync 将从我们的Git仓库中拉取所有最新的更改：

+
host:~$ repo sync
+
+
+
+
+

5.7.2. 即将发布版本的开发中版本

+

即将发布版本的开发中版本可以通过这种方式访问。请执行以下命令，并查找一个比最新版本（ BSP-Yocto-NXP-i.MX8MM-PD23.1.0 ）的PDXX.Y数字更高的版本，并且以 .y 结尾：

+
host:~$ ./phyLinux init -p imx8mn
+
+
+
+
+
+

5.8. 获取最新的Upstream支持

+

我们有一个使用Yocto主分支（不是NXP发布的）的manifest，他使用upstream的Linux和U-Boot。这可以用来测试最新的upstream kernel/U-Boot。

+
+

备注

+

master分支的manifest反映了最新的开发状态。有时会出现一些bug。我们会定期修复master分支。

+
+
host:~$ ./phyLinux init -p imx8mn -r BSP-Yocto-Ampliphy-i.MX8MM-master
+
+
+
+
+

5.9. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.9.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将 phytec-headless-image-phyboard-polis-imx8mn-2.wic 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-headless-image-phyboard-polis-imx8mn-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将 phytec-headless-image-phyboard-polis-imx8mn-2.wic 镜像复制到其中。然后卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-headless-image-phyboard-polis-imx8mn-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 8M Nano BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 8M Nano 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Board.dts - 包含module dtsi 文件。从SoC i.MX 8M Nano 引出并在底板使用的设备也包含在此 dts 中。

    • +

  • Overlay.dtso - 根据核心板或底板上可选硬件（例如 SPI 闪存或 PEB-AV-10）的情况来启用/禁用一些功能。

    • +
+

在Linux内核的根目录下，我们的 i.MX 8 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。下面是扩展板的硬件描述。对比源码中的include，overlay通过覆盖的方式来生效。overlay也可以根据实际开发板的硬件配置来设置设备树节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/ 中。

+

phyboard-polis-imx8mn-2.conf 可用的overlay文件有：

+
imx8mn-phyboard-polis-peb-eval-01.dtbo
+imx8mn-phyboard-polis-peb-av-010.dtbo
+imx8mn-phycore-rpmsg.dtbo
+imx8mn-phycore-no-eth.dtbo
+imx8mn-phycore-no-spiflash.dtbo
+imx8mn-vm016.dtbo
+imx8mn-vm016-fpdlink.dtbo
+imx8mn-vm017.dtbo
+imx8mn-vm017-fpdlink.dtbo
+imx8mn-dual-vm017-fpdlink.dtbo
+
+
+

可以在Linux或U-Boot环境下配置overlay。overlay是在引导命令调用后、内核加载之前生效。接下来的部分将更详细地解释配置方法。

+
+

6.2.2.1. 设置 ${overlays} 变量

+

${overlays} U-Boot 环境变量包含一个以空格分隔的overlay文件列表，这些overlay文件将在启动过程中应用。根据启动源，overlay文件必须放置在 eMMC/SD 卡的启动分区中，或者通过 tftp 加载。在 $KERNEL_DEVICETREE 这个 Yocto machine 变量中设置的 overlay 文件将自动添加到最终 WIC 镜像的启动分区中。

+

${overlays} 变量可以直接在U-Boot环境中设置，也可以作为外部 bootenv.txt 环境文件的一部分。默认情况下， ${overlays} 变量来自位于启动分区的 bootenv.txt 文件。您可以在已启动的开发板上从Linux读取和写入该文件：

+
target:~$ cat /boot/bootenv.txt
+overlays=imx8mn-phyboard-polis-peb-eval-01.dtbo imx8mn-phyboard-polis-peb-av-010.dtbo
+
+
+

更改将在下次重启后生效。如果没有可用的 bootenv.txt 文件，可以直接在U-Boot环境中设置overlay变量。

+
u-boot=> setenv overlays imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> printenv overlays
+overlays=imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

如果用户定义了 ${overlays} 变量，同时存在 bootenv.txt 文件，则需要设置 ${no_bootenv} 变量：

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

有关环境的更多信息，请参见 U-boot External Environment subsection of the +device tree overlay section。

+

我们使用 ${overlays} 变量来描述在运行时无法自动检测的扩展板和摄像头。如果想禁用 ${overlays} 变量中列出的overlay，可以在U-Boot的环境中将 ${no_overlays} 变量设置为 1。

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+

6.2.2.2. 扩展命令

+

使用U-Boot扩展命令能够轻松加载由回调函数 extension_board_scan() 检测并添加到列表中的overlay。以这种方式应用的overlay会禁用核心板上未贴装的组件。检测是通过读取出厂EEPROM数据（EEPROM SoM Detection）来实现的。

+

这取决于核心板型号是否会应用任何设备树overlay。要检查在U-Boot中运行的SoM是否会应用overlay，请运行：

+
u-boot=> extension scan
+Found 1 extension board(s).
+u-boot=> extension list
+Extension 0: phyCORE-i.MX8MN no SPI flash
+        Manufacturer:           PHYTEC
+        Version:
+        Devicetree overlay:     imx8mn-phycore-no-spiflash.dtbo
+        Other information:      SPI flash not populated on SoM
+
+
+

如果没有可用的EEPROM数据，则不加载任何设备树overlay。

+

为了禁止在启动时自动运行扩展命令，可以在bootloader环境中将 ${no_extensions} 变量设置为 1 ：

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot外部环境

+

在Linux内核启动时，外部环境 bootenv.txt 文本文件将从MMC设备的boot分区或通过TFTP加载。该文件的主要目的是存储 ${overlays} 变量。这可以针对不同的machine在Yocto中预定义不同的overlay配置。文件的内容在meta-phytec中的Yocto recipe中的bootenv中定义： https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=kirkstone

+

该文件中也可以设置其他变量。这些变量将覆盖环境中现有的设置。但只有对boot命令后进行计算的变量生效，例如 ${nfsroot} 或 ${mmcargs}。在文件中更改其他变量将不会有作用。以网络启动的用法作为示例。

+

如果无法加载外部环境，启动过程将继续进行，并使用自带的环境变量值。

+
+
+

6.2.4. 在Linux环境下更改开发板上的U-boot环境变量

+

Libubootenv是我们镜像中包含的一个工具，用于在开发板linux上修改U-Boot环境。

+

使用以下命令打印U-Boot环境：

+
target:~$ fw_printenv
+
+
+

使用以下命令修改U-Boot环境：

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

小心

+

Libubootenv会读取配置文件中配置的环境变量。要修改的环境变量会被插入到该文件中，默认情况下使用eMMC中存储环境变量。

+

如果eMMC没有被烧写过或者eMMC环境被擦除，libubootenv将无法工作。您应该修改 /etc/fw_env.config 文件，以匹配您想要使用的环境源。

+
+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 8M Nano BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 8M Nano BSP设备树概念部分，以了解我们的 i.MX 8 BSP设备树模型。

+

以下部分概述了 i.MX 8 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 8M Nano 引脚复用

+

该 i.MX 8M Nano Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 8M Nano 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 8M Nano 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是 imx8mn-phyboard-polis.dts中UART1设备的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX     0x00
+                MX8MN_IOMUXC_SAI2_RXC_UART1_DCE_RX      0x00
+                MX8MN_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B  0x00
+                MX8MN_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B  0x00
+        >;
+};
+
+
+

字符串的第一部分 MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX 指定了引脚（在此示例中为 SAI2_RXFS）。字符串的第二部分 (UART1_DCE_RX) 是该引脚的复用选项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部上拉电阻是否被激活。在当前配置下，内部电阻被禁用。

+
+
+

7.2. RS232/RS485

+

i.MX 8M Nano SoC 提供最多 4 个 UART 单元。PHYTEC 开发板支持不同数量 UART 单元。UART1 也可以用作 RS-485。为此，需要正确设置 bootmode switch (S1)：

+ + + + + + + +
切换UART1的RS485和RS232模式
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+

7.2.1. RS232

+
    +

  • 以人类可读的格式显示终端的当前设置：

    +
    target:~$ stty -a
+
    +
    +
    • +

  • UART接口的配置可以通过stty命令完成。例如：

    +
    target:~$ stty -F /dev/ttymxc0 115200 crtscts raw -echo
+
    +
    +
    • +

  • 通过简单的echo和cat，可以测试基本的通信。示例：

    +
    target:~$ echo 123 > /dev/ttymxc0
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

主机应打印出 "123"。

+
+
+

7.2.2. RS485

+
+

提示

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

为了方便测试，请查看linux-serial-test。这个工具会通过调用RS485的IOCTL，发送恒定的数据流。

+
target:~$ linux-serial-test -p /dev/ttymxc0 -b 115200 --rs485 0
+
+
+

有关linux-serial-test工具及其参数的更多信息，请访问此链接：linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Linux kernel文档描述了如何在C代码中调用IOCTL： https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection2.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see "test" printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final "count for this session". There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+

RS232和RS485的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n220

+
+
+
+
+

7.3. 网络

+

phyBOARD-Polis-i.MX 8M Nano 提供一个千兆以太网接口。

+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n50。

+

+
+

7.3.1. 网络配置

+
+

7.3.1.1. U-boot网络环境

+
    +

  • 要在bootloader中查找以太网设置：

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • 在将主机设置为IP 192.168.3.10和子网掩码255.255.255.0的情况下，开发板应该返回：

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • 如果您需要进行任何更改：

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> 应该是 ipaddr、netmask、gatewayip 或 serverip 中的一个。<value> 将是所选参数的设定值。

    +
    • +

  • 您所做的更改目前是临时的。要保存这些更改：

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

在这里，您也可以将IP地址更改为DHCP，而不是使用静态IP地址。

+
    +

  • 配置：

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • 设置 TFTP 和 NFS 的路径。修改可以如下所示：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+

小技巧

+

像nfsroot和netargs这样的变量可以被U-boot外部环境重新赋值。对于网络启动，外部环境将通过tftp加载。例如，要在 bootenv.txt 文件中设置nfsroot变量，请在tftproot目录修改：

+
nfsroot=/home/user/nfssrc
+
+
+

无需在开发板上存储这些信息。请注意，U-boot外部环境对于像 ipaddr 或 serveraddr 这样的变量不起作用，因为它们在加载外部环境之前已经被设置完成。

+
+
+
+

7.3.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. 无线局域网

+

为了支持WLAN和蓝牙，我们使用来自LSR的Sterling-LWB模块。该模块支持2.4 GHz，并且可以在多种模式下运行，如客户端模式、使用WEP、WPA、WPA2加密的接入点（AP）模式等。有关该模块的更多信息，请访问 https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. 连接到WLAN网络

+

首先设置您所在国家的正确监管域：

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

你将会看到：

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

设置无线接口：

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

现在您可以扫描可用的网络：

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

您可以使用一个跨平台的客户端，名为wpa_supplicant，支持WEP、WPA和WPA2，以建立加密连接。

+

为此，请将网络凭据添加到文件 /etc/wpa_supplicant.conf 中：

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

现在可以建立连接：

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

这会得到如下输出：

+
Successfully initialized wpa_supplicant
+
+
+

The ip address is automatically configured over DHCP. For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (kirkstone).

+
+
+
+

7.3.3. 蓝牙

+

Bluetooth is connected to UART2 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

现在您可以扫描环境中的可见蓝牙设备。在默认配置下，蓝牙是不可见的。

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. 可见性

+

要激活可见性：

+
target:~$ hciconfig hci0 piscan
+
+
+

要禁用可见性：

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. 连接

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

备注

+

如果连接失败并出现错误信息：“连接失败：org.bluez.Error.Failed”，请尝试使用以下命令重新启动PulseAudio：

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC 卡

+

该 i.MX 8M Nano 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

MMC（SD卡插槽）接口的DT配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n301

+

eMMC接口的DT配置可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n309

+
+
+

7.5. eMMC设备

+

PHYTEC模块如phyCORE-i.MX 8M Nano 配备了eMMC存储芯片作为主要存储。eMMC设备使用多层单元（MLC）或三层单元（TLC）技术来实现存储，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 8M Nano ，并在Linux内核中作为块设备表示，如SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.5.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），该层负责处理原始MLC或TLC的磨损均衡、块管理和错误更正码（ECC）。这需要定期执行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 通过以下命令使能BKOPS_EN：

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.5.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 8M Nano SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.5.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
+
+

7.5.5. 启用伪SLC模式

+

eMMC设备使用 MLC或TLC 来存储数据。与NAND Flash中使用的SLC相比，MLC或TLC在成本更低的情况下，可靠性较低且错误率较高。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. 擦除设备

+

可以直接擦除eMMC设备，而不是通过写零覆盖。eMMC块管理算法将擦除底层的MLC或TLC，或者将这些块标记为可丢弃。设备上的数据将丢失，并将被读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.5.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 8M Nano 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.5.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

下表是 i.MX 8M Nano SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.6. SPI主设备

+

i.MX 8M Nano 控制器包含一个 FlexSPI 和一个 ECSPI IP 核。FlexSPI 主控制器支持两个 SPI 通道，最多可连接 4 个设备。每个通道支持单通道/双通道/四通道/八通道模式的数据传输（1/2/4/8 条数据线）。ECSPI 控制器支持 3 个 SPI 接口，每个接口都有一个专用的CS（chip select）引脚。由于CS也可通过 GPIO 实现，因此每个通道上可以连接多个设备。

+
+

7.6.1. SPI NOR 烧写

+

phyCORE-i.MX 8M Nano 配备有一个 QSPI NOR Flash，该 Flash 连接到 i.MX 8M Nano 的 FlexSPI 接口。QSPI NOR Flash 可用于启动。有关烧写和启动模式设置的详细信息，请参见不同的章节。由于 SPI NOR Flash 的空间有限，因此仅可存储bootloader。默认情况下，内核、设备树和根文件系统来自 eMMC。

+

bootloader程序通过EEPROM数据检测是否安装了SPI Flash。如果没有安装SPI Flash，则在启动期间应用设备树overlay，通过扩展命令禁用SPI Flash设备树节点。如果没有可用的EEPROM数据，SPI NOR Flash节点将始终启用。有关更多信息，请参阅设备树overlay部分。

+

bootloader程序还可以通过内核的mtdparts启动参数修改设备树，将SPI MTD分区表传递给Linux。BSP中的默认分区布局设置为：

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

这是一个预定义的bootloader环境变量，可以在运行时更改。从Linux用户空间，可以通过/dev/mtd<N>设备访问NOR Flash分区，其中<N>是与要访问的NOR Flash分区相关联的MTD设备编号。要找到分区的正确MTD设备编号，请在目标上运行：

+
root@phyboard-polis-imx8mn-2:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

它列出了所有MTD设备及其对应的分区名称。闪存节点在模块DTS中的SPI主节点内定义。SPI节点包含连接到此SPI总线的所有设备，在这种情况下只有SPI NOR Flash。

+

设备树中SPI主节点的定义可以在这里找到：

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n78

+
+
+
+

7.7. GPIOs

+

phyBOARD-Polis 具有一组专门用于GPIO的引脚。这些引脚直接连接到 i.MX 8M Nano 引脚，并被复用为 GPIO。它们可以直接在 Linux 用户空间中使用。处理器将其 GPIO 组织为5个GPIO组（GPIO1 – GPIO5），每个组包含 32 个GPIO。gpiochip0、gpiochip32、gpiochip64、gpiochip96 和 gpiochip128 是这些内部 i.MX 8M Nano GPIO 组 GPIO1 – GPIO5 的 sysfs 表示。

+

GPIO被标识为GPIO<X>_<Y>（例如：GPIO5_07）。<X>表示GPIO Bank，从1计数到5，而<Y>表示该Bank内的GPIO。<Y>从0计数到31（每个bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo -c gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如从gpiochip0的GPIO 20）：

    +
    target:~$ gpioget -c gpiochip0 20
+
    +
    +
    • +

  • 将gpiochip0上的GPIO 20的值设置为0并退出工具：

    +
    target:~$ gpioset -z -c gpiochip0 20=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <line=value>...
+
+Set values of GPIO lines.
+
+Lines are specified by name, or optionally by offset if the chip option
+is provided.
+Values may be '1' or '0', or equivalently 'active'/'inactive' or 'on'/'off'.
+
+The line output state is maintained until the process exits, but after that
+is not guaranteed.
+
+Options:
+      --banner            display a banner on successful startup
+  -b, --bias <bias>       specify the line bias
+                  Possible values: 'pull-down', 'pull-up', 'disabled'.
+                  (default is to leave bias unchanged)
+      --by-name           treat lines as names even if they would parse as an offset
+  -c, --chip <chip>       restrict scope to a particular chip
+  -C, --consumer <name>   consumer name applied to requested lines (default is 'gpioset')
+  -d, --drive <drive>     specify the line drive mode
+                  Possible values: 'push-pull', 'open-drain', 'open-source'.
+                  (default is 'push-pull')
+  -h, --help              display this help and exit
+  -l, --active-low        treat the line as active low
+  -p, --hold-period <period>
+                  the minimum time period to hold lines at the requested values
+  -s, --strict            abort if requested line names are not unique
+  -t, --toggle <period>[,period]...
+                  toggle the line(s) after the specified period(s)
+                  If the last period is non-zero then the sequence repeats.
+      --unquoted  don't quote line names
+  -v, --version           output version information and exit
+  -z, --daemonize set values then detach from the controlling terminal
+
+Chips:
+    A GPIO chip may be identified by number, name, or path.
+    e.g. '0', 'gpiochip0', and '/dev/gpiochip0' all refer to the same chip.
+
+Periods:
+    Periods are taken as milliseconds unless units are specified. e.g. 10us.
+    Supported units are 's', 'ms', and 'us'.
+
+*Note*
+    The state of a GPIO line controlled over the character device reverts to default
+    when the last process referencing the file descriptor representing the device file exits.
+    This means that it's wrong to run gpioset, have it exit and expect the line to continue
+    being driven high or low. It may happen if given pin is floating but it must be interpreted
+    as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.7.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用 CONFIG_GPIO_SYSFS 后才能支持。要在menuconfig中使 CONFIG_GPIO_SYSFS 可见，必须首先启用选项 CONFIG_EXPERT 。

+

您也可以将此选项添加到您在 Linux 内核源代码 arch/arm64/configs/ 目录下使用的 defconfig 中。例如，我们基于 NXP 的BSP版本，这个defconfig可以是 imx8_phytec_distro.config

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+

设备树 imx8mn-phyboard-polis.dts 中一些GPIO引脚的管脚复用：

+
pinctrl_leds: leds1grp {
+        fsl,pins = <
+                MX8MN_IOMUXC_GPIO1_IO01_GPIO1_IO1       0x16
+                MX8MN_IOMUXC_GPIO1_IO14_GPIO1_IO14      0x16
+                MX8MN_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x16
+        >;
+};
+
+
+
+
+
+

7.8. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

这里的 LED 灯包括蓝色的 mmc、绿色的 心跳和红色的 emmc，它们都在 phyBOARD-Polis 上。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

GPIO配置的设备树配置可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n45

+
+
+

7.9. I²C总线

+

该 i.MX 8M Nano 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 8M Nano 的I²C模块。 本节描述了我们 phyBOARD-Polis 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

I²C1总线的DT配置（例如 imx8mn-phycore-som.dtsi）： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n106

+

I²C3总线DT配置（例如 imx8mn-phyboard-polis.dts）：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n196

+
+
+

7.10. EEPROM

+

在 phyCORE-i.MX8MN 上贴了一个 i2c 接口的 EEPROM 存储。它有两个地址。主 EEPROM 空间（总线：I2C-0 地址：0x51）可以通过 Linux 中的 sysfs 接口访问。主 EEPROM 的前 256 字节和 ID 页（总线：I2C-0 地址：0x59）用于板检测，不可修改。因此，ID 页不能通过 sysfs 接口访问。覆盖保留空间将导致启动问题。

+
+

备注

+

如果您删除了保留的EEPROM空间数据，请联系我们的支持团队！

+
+
+

7.10.1. phyCORE-i.MX8MN 上的I2C EEPROM

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

phyCORE-i.MX8MN SoM上的I2C EEPROM连接到I2C-0总线的I2C地址0x51。可以直接对该设备进行读写操作：

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

要用零填充4KiB的EEPROM（总线：I2C-0 地址：0x51），并保留EEPROM数据，请使用：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM 检测

+

在 phyCORE-i.MX8MN 上配置的I2C EEPROM具有一个可通过I2C地址0x59在i2c0上寻址的独立ID页面，以及一个可通过I2C地址0x51在i2c0上寻址的正常区域。PHYTEC使用这个32字节的数据区域来存储关于SoM的信息，包括PCB版本和配置。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果EEPROM ID页面数据和正常区域的前256个字节被删除，bootloader程序将回退到 phyCORE-i.MX8MN Kit RAM设置，即 1GiB RAM。

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

使用API修订版2数据格式烧写的核心板将在早期启动阶段打印出有关模块的信息。

+

DT表示，例如在phyCORE-i.MX 8M Nano 文件 imx8mn-phycore-som.dtsi中，可以在我们的PHYTEC git中找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n259

+
+
+
+

7.11. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC唤醒alarm

+

可以从实时时钟（RTC）发出中断以唤醒系统。该格式使用Unix纪元时间，即自1970年1月1日UTC午夜以来的秒数。要在从挂起到RAM状态后的4分钟唤醒系统，请输入：

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

备注

+

内部唤醒alarm时间将被向上舍入到下一个分钟，因为alarm功能不支持秒。

+
+
+
+

7.11.2. RTC参数

+

实时时钟（RTC）具有一些功能，可以通过 hwclock 工具进行读取和设置。

+
    +

  • 我们可以通过以下方式检查RTC支持的功能：

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    这个值的含义在内核中进行了编码，每个位的定义为：

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • 我们可以通过以下方式检查RTC BSM（Backup Switchover Mode 备份切换模式）：

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • 我们可以通过以下方式设置RTC BSM：

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    BSM位的定义为：

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    小技巧

    +

    您应该将BSM模式设置为DSM或LSM，以便在初始电源不可用时，RTC可以切换到备用电源。请查看 RV-3028 RTC的Datasheet，以了解LSM（电平切换模式）和DSM（直接切换模式）这两个定义的工作模式。

    +
    +
    • +
+

I²C RTC的设备树表示：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n267

+
+
+
+

7.12. USB主控制器

+

i.MX 8M Nano SoC 的 USB 控制器为众多消费类便携设备提供了一种低成本的连接解决方案，通过提供一种数据传输机制，使 USB 设备之间的线路/总线速度可达到 480 Mbps（高速 'HS'）。

+

该 i.MX 8M Nano SoC 具有一个设置为 OTG 模式的 USB 控制器IP。要使用Micro USB / OTG 端口，拨码开关 S1 的第 5 位必须设置为开启。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+
+
+

7.13. USB OTG

+

大多数PHYTEC板提供USB OTG接口。USB OTG端口会自动作为USB设备或USB主机工作。模式取决于连接到USB OTG端口的USB硬件。例如，如果将USB大容量存储设备连接到USB OTG端口，该设备将显示为 /dev/sda 。

+
+

7.13.1. 作为USB设备

+

为了将开发板作为USB设备连接到USB主机（例如PC），您需要配置相应的USB gadget。通过USB configfs，您可以定义USB gadget的参数和功能。BSP包含作为kernel module 的USB configfs支持。

+
target:~$ modprobe libcomposite
+
+
+

例子:

+
    +

  • 首先，定义参数，例如USB Vendor和product ID，并为英语（0x409）设置信息字符串：

    • +
+
+

提示

+

为了节省时间，请复制这些命令并在脚本中执行它们

+
+
cd /sys/kernel/config/usb_gadget/
+mkdir g1
+cd g1/
+echo "0x1d6b" > idVendor
+echo "0x0104" > idProduct
+mkdir strings/0x409
+echo "0123456789" > strings/0x409/serialnumber
+echo "Foo Inc." > strings/0x409/manufacturer
+echo "Bar Gadget" > strings/0x409/product
+
+
+
    +

  • 接下来，为大容量存储 gadget 创建一个文件：

    • +
+
target:~$ dd if=/dev/zero of=/tmp/file.img bs=1M count=64
+
+
+
    +

  • 现在你可以创建你想要使用的功能：

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir functions/acm.GS0
+mkdir functions/ecm.usb0
+mkdir functions/mass_storage.0
+echo /tmp/file.img > functions/mass_storage.0/lun.0/file
+
+
+
    +

  • acm: 串行设备 gadget，创建类似 /dev/ttyGS0 的串行接口。

    • +

  • ecm: 以太网 gadget，创建以太网接口，例如 usb0

    • +

  • mass_storage: 主机可以像处理其他USB大容量存储设备一样，对设备的大容量存储进行分区、格式化和挂载。

    • +
+
    +

  • 将定义的功能绑定到配置：

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir configs/c.1
+mkdir configs/c.1/strings/0x409
+echo "CDC ACM+ECM+MS" > configs/c.1/strings/0x409/configuration
+ln -s functions/acm.GS0 configs/c.1/
+ln -s functions/ecm.usb0 configs/c.1/
+ln -s functions/mass_storage.0 configs/c.1/
+
+
+
    +

  • 最后，使用以下命令启动USB gadget：

    • +
+
target:~$ cd /sys/kernel/config/usb_gadget/g1
+target:~$ ls /sys/class/udc/
+ci_hdrc.0
+target:~$ echo "ci_hdrc.0" >UDC
+
+
+

如果您的系统有多个USB设备或OTG端口，您可以将正确的端口传递给USB设备控制器（UDC）。

+
    +

  • 要停止USB gadget 并解除绑定已使用的功能，请执行：

    • +
+
target:~$ echo "" > /sys/kernel/config/usb_gadget/g1/UDC
+
+
+

USB接口在内核设备树|dt-carrierboard|.dts中配置为Host。请参见：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n264

+
+
+
+

7.14. CAN FD

+

The phyBOARD-Polis has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
+

提示

+

phyBOARD-Polis 具有一个通过 SPI 连接的外部 CAN FD 芯片 MCP2518FD。由于使用了SPI，限制了 CAN FD 的数据传输速率上限。

+
+
+

提示

+

在phyBOARD-Polis-i.MX8MN上，如果需要，可以通过将S5设置为ON来启用端接电阻。

+
+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。两个CAN接口显示为can0和can1。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    can0的信息将如下所示：

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+
+

警告

+

mcp2518fd SPI到CAN FD只支持从125kB/s开始的波特率。可以选择更慢的速率，但可能无法正常工作。

+
+

imx8mn-phyboard-polis.dts的设备树CAN配置: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n125

+
+
+

7.15. 电源管理

+
+

7.15.1. CPU核心频率调节

+

i.MX 8M Nano SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。调整频率和电压被称为“动态电压和频率调整”（DVFS）。i.MX 8M Nano BSP支持DVFS功能。Linux内核提供了一个DVFS框架，允许每个CPU核心设置最小或最大频率和一个管理其运行的governor。根据使用的 i.MX 8 型号，支持几种不同的频率。

+
+

小技巧

+

尽管DVFS框架为每个CPU核心提供了频率设置，但一个CPU核心的频率更改会影响其他CPU核心。因此，所有CPU核心始终共享相同的DVFS设置。每个核心的单独DVFS设置是不可能的。

+
+
    +

  • 要获取完整列表，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    例如 i.MX 8MPlus CPU，最高可达约 1.6 GHz，则结果将是：

    +
    1200000 1600000
+
    +
    +
    • +

  • 要查询当前的频率输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

governor 会根据它们的目标自动选择这些频率中的一个。

+
    +

  • 列出所有可用的 governor，使用以下命令：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    结果是：

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative governor 与 ondemand governor 非常相似。只是它的行为有所不同，它会更保守地增减CPU速度，而不是在CPU有任何负载的瞬间就跳到最大速度。

    • +

  • ondemand （默认）根据当前系统负载在可能的CPU核心频率之间切换。当系统负载超过特定值时，它会立即提高CPU核心频率。

    • +

  • powersave 始终选择最低的CPU核心频率。

    • +

  • performance 始终选择最高的CPU核心频率。

    • +

  • userspace 允许以root身份运行的用户或用户空间程序设置特定频率（例如，设置为1600000）。输入：

    • +

  • 要查询当前的 governor，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    您通常会得到：

    +
    ondemand
+
    +
    +
    • +

  • 切换到另一个governor（例如，userspace）可以通过以下方式完成：

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • 现在你可以设置频率：

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

有关governor的更详细信息，请参阅Linux内核代码库中的Linux内核文档，路径为 Documentation/admin-guide/pm/cpufreq.rst 。

+
+
+

7.15.2. CPU核心管理

+

该 i.MX 8M Nano SoC 芯片上可以有多个处理器核心。例如，该 i.MX 8M Nano 具有 4 个 ARM 核心，可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    这里系统有四个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.15.3. 挂起到RAM

+

phyCORE-i.MX8MN 支持基本的挂起和恢复。可以使用不同的唤醒源。挂起/恢复可以通过以下方式实现：

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

要通过串行控制台唤醒，请运行

+
target:~$ echo enabled > /sys/class/tty/ttymxc2/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.16. 热管理

+
+

7.16.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.16.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 8M Nano SoC 平台上使用热管理内核 API。 i.MX 8 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个触发点。这些触发点根据CPU型号的不同而有所不同。主要区分工业版和商业版。

+ + + + + + + + + + + + + + + + + +

商业

工业

被动（警告）

85°C

95°C

严重（关机）

90°C

100°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并实施冷却措施。内核中可用的热政策（也称为thermal governor）包括：Step Wise、Fair Share、Bang Bang和Userspace。BSP中使用的默认策略是Step Wise。如果sysfs文件temp中的SoC温度值高于 trip_point_0 ，则CPU频率将设置为最低CPU频率。当SoC温度降到 trip_point_0 以下时，限制将被解除。

+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+

7.16.3. GPIO风扇

+
+

备注

+

Only GPIO fan supported.

+
+

一个GPIO控制的风扇可以连接到 phyBOARD-Polis-i.MX 8M Nano。该SoC包含一个温度传感器，该传感器被用于热频率调节。风扇无法通过内核进行控制。我们使用lmsensors和hwmon来实现这一点。lmsensors定期读取温度，并在可配置的阈值下启用或禁用风扇。对于 phyBOARD-Polis-i.MX 8M Nano，这个阈值是60°C。

+

设置可以在配置文件中进行配置：

+
/etc/fancontrol
+
+
+

风扇控制在启动时由systemd服务启动。可以通过以下方式禁用它：

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.17. 看门狗

+

PHYTEC i.MX 8M Nano 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.17.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.18. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 8M Nano 提供一次性可编程fuse，用于存储信息，例如 MAC 地址、启动配置和其他永久设置（在 i.MX 8M Nano reference manual中称为“片上 OTP 控制器 (OCOTP_CTRL)”）。以下列表摘自 i.MX 8M Nano reference manual，包括 OCOTP_CTRL 中的一些有用寄存器（基地址为0x30350000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为0x30350000

描述

OCOTP_MAC_ADDR0

9

0

0x640

包含ENET0 MAC地址的低32位

OCOTP_MAC_ADDR1

9

1

0x650

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

OCOTP_MAC_ADDR2

9

2

0x660

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 8M Nano Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.18.1. 在uBoot中读取fuse的值

+

您可以使用内存映射的shadow寄存器读取fuse寄存器。要计算内存地址，请使用以下公式计算：

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.18.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mn/imx8mn.html b/previews/271/zh_CN/bsp/imx8/imx8mn/imx8mn.html new file mode 100644 index 000000000..bdbb1ed0b --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mn/imx8mn.html @@ -0,0 +1,390 @@ + + + + + + + + + i.MX 8M Nano 手册 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

i.MX 8M Nano 手册

+ +
+

BSP-Yocto-NXP-i.MX8MM-PD23.1.0

+
+

目录

+ +
+
+
+

BSP-Yocto-NXP-i.MX8MM-PD22.1.1

+
+

目录

+ +
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mn/pd22.1.1.html b/previews/271/zh_CN/bsp/imx8/imx8mn/pd22.1.1.html new file mode 100644 index 000000000..bc0962b42 --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mn/pd22.1.1.html @@ -0,0 +1,3257 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 8M Nano BSP手册

文档标题

i.MX 8M Nano BSP手册

文档类型

BSP 手册

Yocto 手册

发布日期

2023/05/25

母文档

i.MX 8M Nano BSP手册

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP 发布日期

BSP 状态

BSP-Yocto-NXP-i.MX8MM-PD22.1.1

小更新

2023/05/23

已发布

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 phyCORE-i.MX8M Nano Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads 中找到。

+
+

1.1. 支持的硬件

+

支持的 i.MX 8M Nano 系统芯片 (SoC) 的 phyBOARD-Polis。

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-NXP-i.MX8MM-PD22.1.1 的所有Machine及其对应的Article Numbers(产品型号)： 网址. 如果您在该网页 Supported Machines 一节选择了特定的 Machine Name ，您可以查看被选中machine下的包含的 Article Number(产品型号) 以及简要的硬件描述。如果您只有 Article Number ，可以将 Machine Name 下拉菜单留空，仅选择您的 Article Number 。那么，它会显示您特定硬件所对应的 Machine Name

+
+

1.1.1. phyBOARD-Polis 器件

+ + + + + + +
+../../../_images/polis-front.jpg +
+

phyBOARD-Polis 器件（顶部）

+
+
+
+../../../_images/polis-back.jpg + +
+

phyBOARD-Polis 器件（底部）

+
+
+
+
+
+
+
+

2. 开始使用

+

该 phyCORE-i.MX8M Nano Kit 包含预先烧写好的SD卡。它包含 phytec-headless-image ，可以直接用作启动盘。默认情况下，核心板的eMMC仅烧写了U-boot。您可以从 PHYTEC下载服务器 获取所有源代码。本章解释了如何将BSP镜像烧录到SD卡以及如何启动开发板。

+
+

2.1. 下载镜像

+

WIC镜像包含预先格式化的分区信息以及分区中包含的BSP文件，可以使用单个Linux命令 dd 轻松写入到SD卡上。WIC镜像可以通过Yocto编译或从PHYTEC下载服务器下载。

+

从下载服务器获取WIC文件：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.wic
+
+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要使用 dd 命令创建SD卡启动盘，您必须具有root权限。在使用 dd 指定目标设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行该命令：

    +
    host$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+
    +

  • 卸载所有分区，例如：

    +
    host$ sudo umount /dev/sde1
+
    +
    +
    • +

  • 在卸载所有分区后，您可以创建SD卡启动盘：

    +
    host$ sudo dd if=<IMAGENAME>-<MACHINE>.wic of=/dev/sdX bs=1M conv=fsync status=progress
+
    +
    +

    再次确保将 /dev/sdX 替换为之前找到的设备名称。

    +

    参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

    +
    • +
+

准备SD卡启动盘的另一种更快的方法是使用Intel的 bmap-tools 。Yocto会自动为WIC镜像创建一个block map文件（ <IMAGENAME>-<MACHINE>.wic.bmap ），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host$ bmaptool copy <IMAGENAME>-<MACHINE>.wic /dev/<your_device>
+
+
+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.3. 首次启动

+ + + + + + + +
启动模式选择
+../../../_images/Nano_SD_BOOT.jpg + +
+

SD卡启动

+
+
+
+
    +

  • 插入SD卡

    • +

  • 使用 micro USB 线将开发板的 (X30) 调试USB口和主机连接起来

    • +

  • 给开发板通电

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 8M Nano BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: L-813e.A12 Yocto Reference Manual (Hardknott).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +L-813e.A12 Yocto Reference Manual (Hardknott).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-IMX8MM ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-vendor MACHINE=phyboard-polis-imx8mn-2 ./phyLinux init -p imx8mn -r BSP-Yocto-NXP-i.MX8MM-PD22.1.1
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 phyboard-polis-imx8mn-2 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx8mm.bin: ARM可信固件二进制文件

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY固件镜像

    • +

  • imx-boot：由imx-mkimage编译的bootloader镜像，包括SPL、U-Boot、ARM可信固件和DDR固件。这是最终的可引导bootloader镜像。

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx8mn-phyboard-polis-dsi*.dtb: 内核设备树文件

    • +

  • imx8mn-phy*.dtbo：内核设备树overlay文件

    • +

  • phytec-headless-image*.tar.gz: 根文件系统

    • +

  • phytec-headless-image*.wic: SD卡镜像

    • +
+
+
+
+
+

4. 安装操作系统

+
+

4.1. 启动模式开关 (S1)

+

该 phyBOARD-Polis 具有一个启动配置开关，带有六个可单独切换的开关，用于选择 phyCORE-i.MX 8M Nano 的默认启动源。

+

硬件修订主板：1532.2及更新版本

+ + + + + + + + + + + + + +
启动模式选择
+../../../_images/Nano_eMMC_BOOT.png + +
+

eMMC（核心板的默认启动方式）

+
+
+
+../../../_images/Nano_Serial_downloader_BOOT.png + +
+

USB串行下载器

+
+
+
+../../../_images/Nano_SD_BOOT.jpg + +
+

SD卡

+
+
+
+../../../_images/Nano_Fuse_BOOT.png + +
+

内部fuse

+
+
+
+../../../_images/Nano_QSPI_BOOT.png + +
+

SPI NOR

+
+
+

+ + + + + + + +
通过开关(S1)的第5位在USB HOST/OTG之间切换。
+../../../_images/USB_HOST.jpg + +
+

USB 主机

+
+
+
+../../../_images/USB_OTG.png + +
+

USB OTG

+
+
+
+ + + + + + + +
通过开关(S1)的第4位在UART1的RS485/RS232之间切换。
+../../../_images/UART1_RS4851.png + +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS2321.jpg + +
+

UART1 RS232

+
+
+
+
+
+

4.2. 烧写eMMC

+

要从eMMC启动，请确保BSP镜像已正确烧录到eMMC，并且 bootmode switch (S1) 设置为 默认SOM启动 。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行上述命令来检查系统启动在这种条件下是否会到影响。如果 mmcblk2p1 和 mmcblk1p1 具有相同的UUID，则会影响系统正确启动。

+
+
+

4.2.1. 从网络烧写 eMMC

+

i.MX 8M Nano 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

4.2.1.1. 在开发板的u-boot环境中从网络烧写eMMC

+

这些步骤将展示如何通过网络更新eMMC。然而，此步骤仅在镜像文件小于1GB的情况下会被执行成功。如果镜像文件更大，请转到“格式化SD卡”一节。配置 bootmode switch (S1) 以从SD卡启动，并插入一张SD卡。给开发板上电并进入U-Boot环境。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+
    +

  • 通过网络将您的镜像加载到内存中：

    +
    u-boot=> tftp ${loadaddr} phytec-headless-image-phyboard-polis-imx8mn-2.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-phyboard-polis-imx8mn-2.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • 将镜像写入eMMC：

    +
    u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +
+
+
+

4.2.1.2. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！设置主机网络。

+
+

使用一条命令，通过网络ssh协议将带有块映射的压缩或未压缩的镜像发送到开发板的eMMC上使用,执行：

+
target:~$ ssh <USER>@192.168.3.10 "dd if=<path_to_file>/phytec-headless-image-phyboard-polis-imx8mn-2.wic" | dd of=/dev/mmcblk2
+
+
+
+
+

4.2.1.3. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！设置主机网络。

+
+

查看主机上可用的镜像文件：

+
host:~$ ls
+phytec-headless-image-phyboard-polis-imx8mn-2.wic
+
+
+

通过网络使用ssh将镜像用dd命令发送到您设备的eMMC：

+
host:~$ dd if=phytec-headless-image-phyboard-polis-imx8mn-2.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2"
+
+
+
+
+
+

4.2.2. 在u-boot中通过网络烧写eMMC u-boot镜像

+

如果eMMC上的bootloader位于eMMC的User区，从u-boot中更新独立的u-boot镜像imx-boot也是可能的。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！设置主机网络。

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.3. 从USB烧写eMMC

+
+

4.2.3.1. 在u-boot上从USB烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1GB时有效，因为在启用OPTEE后，Bootloader中可用的RAM大小有限。

+
+

下面这些步骤展示如何通过USB设备更新eMMC。将启动模式开关配置为 bootmode switch (S1) 并插入SD卡。给开发板上电并进入U-Boot环境。将已存储了未压缩WIC镜像的优盘插入开发板USB接口。

+

将镜像从USB设备加载到RAM中：

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} *.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. 在运行的Linux系统中从USB烧写eMMC

+

下面这些步骤展示如何在Linux系统上使用USB大容量存储设备烧写eMMC。您需要一个保存了完整镜像的U盘和一个可从SD卡启动的核心板（例如 phytec-headless-image-phyboard-polis-imx8mn-2.wic）。将引导模式开关设置为 bootmode switch (S1)。

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ cd /mnt
+target:~$ ls
+phytec-headless-image-phyboard-polis-imx8mn-2.wic
+
    +
    +
    • +

  • 显示可用的MMC设备列表：

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • eMMC设备的特征是它包含两个boot分区：(mmcblk2boot0; mmcblk2boot1)

    • +

  • 将镜像写入 phyCORE-i.MX 8M Nano eMMC（无分区的 MMC 设备 2）：

    +
    target:~$ dd if=phytec-headless-image-phyboard-polis-imx8mn-2.wic of=/dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    • +
+
+

警告

+

在此之前，您需要将启动配置开关配置 bootmode switch (S1) 设置为 默认SOM启动。

+
+
+
+
+

4.2.4. 从SD卡烧写eMMC

+

即使没有可用的网络，您也可以更新eMMC。为此，您需要一个位于SD卡上的镜像文件（ *.wic ）。由于镜像文件相当大，您需要在SD卡创建第三个分区。要创建新分区或扩展您的SD卡，请参见 Resizing ext4 Root Filesystem 。

+
+

4.2.4.1. 在u-boot上从SD卡烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1GB的情况下有效，因为在启用OPTEE后，Bootloader中可用的RAM大小有限。如果镜像文件太大，请使用“在目标上使用Linux从SD卡更新eMMC”一节。

+
+
    +

  • 将一个可用的镜像烧写到SD卡，并创建一个FAT格式的第三分区。将WIC镜像（例如 phytec-headless-image.wic）复制到该分区。

    • +

  • 将启动模式开关配置为从SD卡启动，并插入SD卡。

    • +

  • 给开发板上电并进入u-boot环境。

    • +

  • 将您的WIC镜像（例如 phytec-headless-image.wic）从SD卡烧写到eMMC。这将对卡进行分区，并将imx-boot、Image、dtb、dtbo和根文件系统复制到eMMC。

    • +

  • 加载镜像：

    +
    u-boot=> fatload mmc 1:3 ${loadaddr} phytec-headless-image-phyboard-polis-imx8mn-2.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • 切换mmc设备：

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc0(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • 关闭电源，将启动模式开关切换到默认SOM启动，以从eMMC启动。

    • +
+
+
+

4.2.4.2. 在开发板的linux环境中通过SD卡烧写eMMC

+

您也可以在Linux上烧写eMMC。您只需在SD卡上保存一个完整的镜像（例如 phytec-headless-image-phyboard-polis-imx8mn-2.wic）。

+
    +

  • 查看您在SD卡上保存的镜像文件：

    +
    target:~$ ls
+phytec-headless-image-phyboard-polis-imx8mn-2.wic
+
    +
    +
    • +

  • 显示可用的MMC设备列表：

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • eMMC设备的特征是它包含两个boot分区：(mmcblk2 boot0; mmcblk2 boot1)

    • +

  • 将镜像写入 phyCORE-i.MX 8M Nano 的 eMMC (MMC 设备 2 不带 分区)：

    +
    target:~$ dd if=phytec-headless-image-phyboard-polis-imx8mn-2.wic of=/dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    • +
+
+

警告

+

在此之前，您需要将 bootmode switch (S1) 配置为默认SOM启动，以从eMMC启动。

+
+
+
+
+
+

4.3. 烧写 SPI NOR Flash

+

phyCORE-i.MX8MN 模块可选配SPI NOR Flash。要从SPI Flash启动，请将 bootmode switch (S1) 设置为 QSPI启动 以从QSPI启动。SPI Flash通常容量较小。phyBOARD-Pollux-i.MX8MP套件仅配备32MB SPI NOR Flash。只能存储bootloader及其环境。内核、设备树和文件系统默认保存在eMMC。

+

SPI NOR Flash分区表在U-Boot环境变量中定义。可以通过以下命令打印：

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. 通过网络烧写SPI NOR Flash

+

SPI NOR可以包含bootloader及其环境变量。arm64的linux内核无法自行解压缩，内核镜像大小超出了phyCORE-i.MX 8M Nano 上的SPI NOR Flash的容量。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！设置主机网络。

+
+
+

4.3.1.1. 在开发板的u-boot环境中从网络烧写SPI NOR

+

与通过网络更新eMMC类似，请确保正确设置开发主机。IP需要设置为192.168.3.10，子网掩码设置为255.255.255.0，并且需要有一个TFTP服务器。在进行读写操作之前，需要对SPI-NOR Flash进行probe：

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • 需要用特殊格式的SPI NOR Flash u-boot镜像。请确保使用正确的镜像文件。通过tftp加载镜像，擦除并将bootloader写入flash：

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+

警告

+

在写满后擦除整个SPI NOR Flash将需要相当长的时间。这可能会触发看门狗复位。因此，请在Linux中擦除整个闪存。

+
+
+
+

4.3.1.2. 在开发板linux环境中通过网络烧写SPI NOR Flash

+
    +

  • 将镜像从主机复制到开发板：

    +
    host:~$ scp imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • 找到U-boot分区的擦除块数量：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除u-boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+

4.3.2. 从SD卡烧写SPI NOR Flash

+

SPI NOR Flash上的bootloader也可以通过SD卡进行烧写。

+
+

4.3.2.1. 在开发板的u-boot环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi复制到SD卡的FAT分区。在进行读写操作之前，需要对SPI-NOR flash进行probe：

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像，请确保使用正确的镜像文件。从SD卡加载镜像，擦除并将bootloader写入flash：

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+

警告

+

在写满后擦除整个SPI NOR Flash将需要相当长的时间。这可能会触发看门狗复位。因此，请在Linux中擦除整个闪存。

+
+
+
+

4.3.2.2. 在开发板的linux环境中从SD卡烧写SPI NOR

+
    +

  • 挂载SD卡：

    +
    host:~$ mount /dev/mmcblkp1 /mnt
+
    +
    +
    • +

  • 查找u-boot分区的擦除块数量：

    +
    target:~$  mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除u-boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC：L-1006e.A3 RAUC 更新与设备管理手册。

+
+
+
+

5. 开发

+
+

5.1. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.1.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.2. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.2.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核镜像复制到您的tftp目录中：

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • 将设备树复制到您的tftp目录：

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • 将您想要使用的所有overlay文件复制到您的tftp目录中：

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-headless-image-phyboard-polis-imx8mn-2.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.2.2. 设置网络启动的bootenv.txt文件

+

在您的tftp目录中创建一个bootenv.txt文件，并将以下变量写入其中。

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> 必须替换为您想要使用的overlay设备树文件名。用空格分隔文件名。例如：

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

小技巧

+

所有支持的设备树overlay在 device tree 章节中。

+
+
+
+

5.2.3. 开发板上的网络设置

+

如果要自定义开发板上的以太网配置，请按照此处的说明进行操作： Network Environment Customization

+
+
+

5.2.4. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.3.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. 获取镜像

+

可以从我们的服务器下载imx-boot，或者从Yocto编译目录中的build/deploy/images/phyboard-polis-imx8mn-2/获取它。要将wic镜像烧写到eMMC，你还需要 phytec-headless-image-phyboard-polis-imx8mn-2.wic。

+
+
+

5.3.3. 开发板准备

+

将 bootmode switch (S1) 设置为 USB串行下载。同时，将 USB 端口 X2 连接到主机。

+
+
+

5.3.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 (X30) 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.3.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-headless-image-phyboard-polis-imx8mn-2.wic
+
+
+
+
+
+

5.4. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone git://git.phytec.de/u-boot-imx）

+
+
+

5.4.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-imx 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • 我们的 i.MX 8M Nano 内核是基于 linux-imx 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. 获取SDK

+

您可以在此处下载SDK 这里，或者使用Yocto去编译生成SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-headless-image # or another image
+
    +
    +
    • +
+

在成功编译后，SDK安装包保存在 build/deploy*/sdk。

+
+
+

5.4.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-vendor-glibc-x86_64-phytec-headless-image-cortexa53-crypto-toolchain-BSP-Yocto-NXP-i.MX8MP-PD22.1.1.sh
+host:~$ ./phytec-ampliphy-vendor-glibc-x86_64-phytec-headless-image-cortexa53-crypto-toolchain-BSP-Yocto-NXP-i.MX8MP-PD22.1.1.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor/BSP-Yocto-NXP-i.MX8MP-PD22.1.1):
+You are about to install the SDK to "/opt/ampliphy-vendor/BSP-Yocto-NXP-i.MX8MP-PD22.1.1". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-vendor/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. 单独编译U-Boot

+
+

5.5.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本的 tag 称为 v2021.04_2.2.0-phy13

    • +

  • 查看所需的 U-Boot tag：

    • +
+
host:~$ cd ~/u-boot-imx/
+host:~$ git fetch --all --tags
+host:~$ git checkout tags/v2021.04_2.2.0-phy13
+
+
+
    +

  • 从技术上讲，您现在可以编译U-Boot，但实际上还需要一些进一步的步骤：

    +
      +

    • 创建您自己的开发分支：

      +
      host:~$ git switch --create <new-branch>
+
      +
      +
      +

      备注

      +

      您可以根据您的需要自行命名您的开发分支，这只是一个示例。

      +
      +
      • +
    +
    • +

  • 设置编译环境：

    +
    host:~$ source /opt/ampliphy-vendor/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +

  • 在编译镜像之前，请设置此环境变量：

    +
    host:~$ export ATF_LOAD_ADDR=0x960000
+
    +
    +
    • +
+
+
+

5.5.2. 获取所需的二进制文件

+

要编译bootloader，您需要将这些文件复制到您的 u-boot-imx 编译目录，并将其重命名以适应 mkimage 脚本：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx8mn.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以在yocto工程目录中获取 bl31-imx8mn.bin、tee.bin和lpddr4_*.bin：BSP Images

+

或者你可以在这里下载文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD22.1.1/images/ampliphy-vendor/phyboard-polis-imx8mn-2/imx-boot-tools/

+
+

警告

+

确保您重命名所需的文件，以和 mkimage tool 兼容。

+
+
+
+

5.5.3. 编译bootloader

+
    +

  • 编译 flash.bin (imx-boot):

    +
    host:~$ make phycore-imx8mn_defconfig
+host:~$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. 将bootloader烧写到块设备上

+

flash.bin 文件可以在 u-boot-imx/ 目录中找到。需要一个特定于芯片的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

+

例如，烧写SD卡：

+
host:~$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+
+

5.6. 单独编译内核

+
+

5.6.1. 配置源代码

+
    +

  • 使用的 linux-imx 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v5.10.72_2.2.0-phy17

    • +

  • Check out 所需的 linux-imx 标签：

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v5.10.72_2.2.0-phy17
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-imx$ make imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-imx/arch/arm64/boot/Image 找到

    • +

  • dtb文件可以在 ~/linux-imx/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. 将内核复制到SD卡

+

内核及module和对应的设备树二进制文件可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. 获取BSP开发中版本

+
+

5.7.1. 当前release的开发中版本

+

这些release manifest文件是为了让您访问 Yocto BSP的开发版本。它们不会在phyLinux选择菜单中显示，需要手动选择。可以使用以下命令行来完成此操作：

+
host:~$ ./phyLinux init -p imx8mn -r BSP-Yocto-NXP-i.MX8MM-PD22.1.y
+
+
+

这将初始化一个BSP，用于跟踪当前版本（ BSP-Yocto-NXP-i.MX8MM-PD22.1.1 ）的最新开发版本。从现在开始，在此文件夹中执行 repo sync 将从我们的Git仓库中拉取所有最新的更改：

+
host:~$ repo sync
+
+
+
+
+

5.7.2. 即将发布版本的开发中版本

+

即将发布版本的开发中版本可以通过这种方式访问。请执行以下命令，并查找一个比最新版本（ BSP-Yocto-NXP-i.MX8MM-PD22.1.1 ）的PDXX.Y数字更高的版本，并且以 .y 结尾：

+
host:~$ ./phyLinux init -p imx8mn
+
+
+
+
+
+

5.8. 获取最新的Upstream支持

+

我们有一个使用Yocto主分支（不是NXP发布的）的manifest，他使用upstream的Linux和U-Boot。这可以用来测试最新的upstream kernel/U-Boot。

+
+

备注

+

master分支的manifest反映了最新的开发状态。有时会出现一些bug。我们会定期修复master分支。

+
+
host:~$ ./phyLinux init -p imx8mn -r BSP-Yocto-Ampliphy-i.MX8MM-master
+
+
+
+
+

5.9. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.9.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将 phytec-headless-image-phyboard-polis-imx8mn-2.wic 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-headless-image-phyboard-polis-imx8mn-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将 phytec-headless-image-phyboard-polis-imx8mn-2.wic 镜像复制到其中。然后卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-headless-image-phyboard-polis-imx8mn-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 8M Nano BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 8M Nano 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Carrierboard.dtsi - 包括来自于 i.MX 8M Nano SoC 的外设，在底板上使用的外设的设备树配置包含在这个 dtsi 中。

    • +

  • Board.dts - 包含底板和核心板的dtsi文件。以及使能一些底板或核心板上的器件和配置。例如，phyCORE-i.MX 8M Nano 核心板可能安装MIPI DSI到LVDS的转换器也可能没有，则Board.dts文件会根据安装情况来对该转换器进行使能配置。而不是在Module.dtsi中配置

    • +
+

在Linux内核的根目录下，我们的 i.MX 8 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。例如扩展板的硬件描述。对比源码中的include，overlay是用覆盖的方式来生效。overlay也可以根据节点是否连接来设置节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/overlays 中。

+

phyboard-polis-imx8mn-2.conf 可用的overlay文件有：

+
imx8mn-phyboard-polis-peb-eval-01.dtbo
+imx8mn-phyboard-polis-peb-av-010.dtbo
+imx8mn-phycore-rpmsg.dtbo
+imx8mn-phycore-no-eth.dtbo
+imx8mn-phycore-no-spiflash.dtbo
+imx8mn-vm016.dtbo
+imx8mn-vm016-fpdlink.dtbo
+imx8mn-vm017.dtbo
+imx8mn-vm017-fpdlink.dtbo
+imx8mn-dual-vm017-fpdlink.dtbo
+
+
+

可以在Linux或U-Boot环境下配置overlay。overlay是在引导命令调用后、内核加载之前生效。接下来的部分将更详细地解释配置方法。

+
+

6.2.2.1. 设置 ${overlays} 变量

+

${overlays} U-Boot 环境变量包含一个以空格分隔的overlay文件列表，这些overlay文件将在启动过程中应用。根据启动源，overlay文件必须放置在 eMMC/SD 卡的启动分区中，或者通过 tftp 加载。在 $KERNEL_DEVICETREE 这个 Yocto machine 变量中设置的 overlay 文件将自动添加到最终 WIC 镜像的启动分区中。

+

${overlays} 变量可以直接在U-Boot环境中设置，也可以作为外部 bootenv.txt 环境文件的一部分。默认情况下， ${overlays} 变量来自位于启动分区的 bootenv.txt 文件。您可以在已启动的开发板上从Linux读取和写入该文件：

+
target:~$ cat /boot/bootenv.txt
+overlays=imx8mn-phyboard-polis-peb-eval-01.dtbo imx8mn-phyboard-polis-peb-av-010.dtbo
+
+
+

更改将在下次重启后生效。如果没有可用的 bootenv.txt 文件，可以直接在U-Boot环境中设置overlay变量。

+
u-boot=> setenv overlays imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> printenv overlays
+overlays=imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

如果用户定义了 ${overlays} 变量，同时存在 bootenv.txt 文件，则需要设置 ${no_bootenv} 变量：

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

有关环境的更多信息，请参见 U-boot External Environment subsection of the +device tree overlay section。

+

我们使用 ${overlays} 变量来描述在运行时无法自动检测的扩展板和摄像头。如果想禁用 ${overlays} 变量中列出的overlay，可以在U-Boot的环境中将 ${no_overlays} 变量设置为 1。

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+

6.2.2.2. 扩展命令

+

使用U-Boot扩展命令能够轻松加载由回调函数 extension_board_scan() 检测并添加到列表中的overlay。以这种方式应用的overlay会禁用核心板上未贴装的组件。检测是通过读取出厂EEPROM数据（EEPROM SoM Detection）来实现的。

+

这取决于核心板型号是否会应用任何设备树overlay。要检查在U-Boot中运行的SoM是否会应用overlay，请运行：

+
u-boot=> extension scan
+Found 1 extension board(s).
+u-boot=> extension list
+Extension 0: phyCORE-i.MX8MN no SPI flash
+        Manufacturer:           PHYTEC
+        Version:
+        Devicetree overlay:     imx8mn-phycore-no-spiflash.dtbo
+        Other information:      SPI flash not populated on SoM
+
+
+

如果没有可用的EEPROM数据，则不加载任何设备树overlay。

+

为了禁止在启动时自动运行扩展命令，可以在bootloader环境中将 ${no_extensions} 变量设置为 1 ：

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot外部环境

+

在Linux内核启动时，外部环境 bootenv.txt 文本文件将从MMC设备的boot分区或通过TFTP加载。该文件的主要目的是存储 ${overlays} 变量。这可以针对不同的machine在Yocto中预定义不同的overlay配置。文件的内容在meta-phytec中的Yocto recipe中的bootenv中定义： https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=hardknott

+

该文件中也可以设置其他变量。这些变量将覆盖环境中现有的设置。但只有对boot命令后进行计算的变量生效，例如 ${nfsroot} 或 ${mmcargs}。在文件中更改其他变量将不会有作用。以网络启动的用法作为示例。

+

如果无法加载外部环境，启动过程将继续进行，并使用自带的环境变量值。

+
+
+

6.2.4. 在Linux环境下更改开发板上的U-boot环境变量

+

Libubootenv是我们镜像中包含的一个工具，用于在开发板linux上修改U-Boot环境。

+

使用以下命令打印U-Boot环境：

+
target:~$ fw_printenv
+
+
+

使用以下命令修改U-Boot环境：

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

小心

+

Libubootenv会读取配置文件中配置的环境变量。要修改的环境变量会被插入到该文件中，默认情况下使用eMMC中存储环境变量。

+

如果eMMC没有被烧写过或者eMMC环境被擦除，libubootenv将无法工作。您应该修改 /etc/fw_env.config 文件，以匹配您想要使用的环境源。

+
+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 8M Nano BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 8M Nano BSP设备树概念部分，以了解我们的 i.MX 8 BSP设备树模型。

+

以下部分概述了 i.MX 8 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 8M Nano 引脚复用

+

该 i.MX 8M Nano Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 8M Nano 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 8M Nano 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是imx8mn-phyboard-polis.dtsi中UART1设备的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX     0x00
+                MX8MN_IOMUXC_SAI2_RXC_UART1_DCE_RX      0x00
+                MX8MN_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B  0x00
+                MX8MN_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B  0x00
+        >;
+};
+
+
+

字符串的第一部分 MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX 指定了引脚（在此示例中为 SAI2_RXFS）。字符串的第二部分 (UART1_DCE_RX) 是该引脚的复用选项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部上拉电阻是否被激活。在当前配置下，内部电阻被禁用。

+
+
+

7.2. RS232/RS485

+

i.MX 8M Nano SoC 提供最多 4 个 UART 单元。PHYTEC 开发板支持不同数量 UART 单元。UART1 也可以用作 RS-485。为此，需要正确设置 bootmode switch (S1)：

+ + + + + + + +
切换UART1的RS485和RS232模式
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+

7.2.1. RS232

+
    +

  • 以人类可读的格式显示终端的当前设置：

    +
    target:~$ stty -a
+
    +
    +
    • +

  • UART接口的配置可以通过stty命令完成。例如：

    +
    target:~$ stty -F /dev/ttymxc0 115200 crtscts raw -echo
+
    +
    +
    • +

  • 通过简单的echo和cat，可以测试基本的通信。示例：

    +
    target:~$ echo 123 > /dev/ttymxc0
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

主机应打印出 "123"。

+
+
+

7.2.2. RS485

+
+

提示

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

为了方便测试，请查看linux-serial-test。这个工具会通过调用RS485的IOCTL，发送恒定的数据流。

+
target:~$ linux-serial-test -p /dev/ttymxc0 -b 115200 --rs485 0
+
+
+

有关linux-serial-test工具及其参数的更多信息，请访问此链接：linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Linux kernel文档描述了如何在C代码中调用IOCTL： https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+

RS232和RS485的设备树表示：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n166

+
+
+
+

7.3. 网络

+

phyBOARD-Polis-i.MX 8M Nano 提供一个千兆以太网接口。

+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n47。

+

+
+

7.3.1. 网络配置

+
+

7.3.1.1. U-boot网络环境

+
    +

  • 要在bootloader中查找以太网设置：

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • 在将主机设置为IP 192.168.3.10和子网掩码255.255.255.0的情况下，开发板应该返回：

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • 如果您需要进行任何更改：

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> 应该是 ipaddr、netmask、gatewayip 或 serverip 中的一个。<value> 将是所选参数的设定值。

    +
    • +

  • 您所做的更改目前是临时的。要保存这些更改：

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

在这里，您也可以将IP地址更改为DHCP，而不是使用静态IP地址。

+
    +

  • 配置：

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • 设置 TFTP 和 NFS 的路径。修改可以如下所示：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+

小技巧

+

像nfsroot和netargs这样的变量可以被U-boot外部环境重新赋值。对于网络启动，外部环境将通过tftp加载。例如，要在 bootenv.txt 文件中设置nfsroot变量，请在tftproot目录修改：

+
nfsroot=/home/user/nfssrc
+
+
+

无需在开发板上存储这些信息。请注意，U-boot外部环境对于像 ipaddr 或 serveraddr 这样的变量不起作用，因为它们在加载外部环境之前已经被设置完成。

+
+
+
+

7.3.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. 无线局域网

+

为了支持WLAN和蓝牙，我们使用来自LSR的Sterling-LWB模块。该模块支持2.4 GHz，并且可以在多种模式下运行，如客户端模式、使用WEP、WPA、WPA2加密的接入点（AP）模式等。有关该模块的更多信息，请访问 https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. 连接到WLAN网络

+

首先设置您所在国家的正确监管域：

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

你将会看到：

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

设置无线接口：

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

现在您可以扫描可用的网络：

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

您可以使用一个跨平台的客户端，名为wpa_supplicant，支持WEP、WPA和WPA2，以建立加密连接。

+

为此，请将网络凭据添加到文件 /etc/wpa_supplicant.conf 中：

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

现在可以建立连接：

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

这会得到如下输出：

+
...
+ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

要完成配置，您可以配置DHCP以接收IP地址（大多数WLAN接入点都支持）。有关其他可能的IP配置，请参阅 L-813e.A12 Yocto Reference Manual (Hardknott) 中的“更改网络配置”部分。

+

首先，创建目录：

+
target:~$ mkdir -p /etc/systemd/network/
+
+
+

然后在 /etc/systemd/network/10-wlan0.network 中添加以下配置片段：

+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+

现在，请重启网络守护进程以使配置生效：

+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+
+

7.3.3. 蓝牙

+

Bluetooth is connected to UART2 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

现在您可以扫描环境中的可见蓝牙设备。在默认配置下，蓝牙是不可见的。

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. 可见性

+

要激活可见性：

+
target:~$ hciconfig hci0 piscan
+
+
+

要禁用可见性：

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. 连接

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

备注

+

如果连接失败并出现错误信息：“连接失败：org.bluez.Error.Failed”，请尝试使用以下命令重新启动PulseAudio：

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC 卡

+

该 i.MX 8M Nano 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

MMC（SD卡插槽）接口的DT配置可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n238

+

eMMC接口的DT配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n293

+
+
+

7.5. eMMC设备

+

PHYTEC模块，如phyCORE-i.MX 8M Nano，配备了一个eMMC存储芯片作为主要存储。eMMC设备包含MLC存储单元，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 8M Nano，并在Linux内核中被表示为块设备，类似于SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.5.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），负责处理原始MLC单元的磨损平衡、块管理和错误纠正码（ECC）。这需要定期进行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+

mmc这个linux工具目前不支持启用自动BKOPS功能。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops enable /dev/mmcblk2
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.5.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 8M Nano SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n> <partition> <device>
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.5.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
    +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+
+
+

7.5.5. 启用伪SLC模式

+

eMMC设备使用 多层单元内存（MLC） 来存储数据。与NAND Flash中使用的单层单元（SLC）内存单元相比，MLC内存单元具有更低的可靠性和更高的错误率，但成本更低。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. 擦除设备

+

可以直接擦除eMMC设备，而不是用零覆盖它。eMMC块管理算法将会擦除MLC存储单元或将这些块标记为丢弃。设备上的数据将丢失，并且读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.5.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 8M Nano 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.5.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

下表是 i.MX 8M Nano SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.6. SPI主设备

+

i.MX 8M Nano 控制器包含一个 FlexSPI 和一个 ECSPI IP 核。FlexSPI 主控制器支持两个 SPI 通道，最多可连接 4 个设备。每个通道支持单通道/双通道/四通道/八通道模式的数据传输（1/2/4/8 条数据线）。ECSPI 控制器支持 3 个 SPI 接口，每个接口都有一个专用的CS（chip select）引脚。由于CS也可通过 GPIO 实现，因此每个通道上可以连接多个设备。

+
+

7.6.1. SPI NOR 烧写

+

phyCORE-i.MX 8M Nano 配备有一个 QSPI NOR Flash，该 Flash 连接到 i.MX 8M Nano 的 FlexSPI 接口。QSPI NOR Flash 可用于启动。有关烧写和启动模式设置的详细信息，请参见不同的章节。由于 SPI NOR Flash 的空间有限，因此仅可存储bootloader。默认情况下，内核、设备树和根文件系统来自 eMMC。

+

bootloader程序通过EEPROM数据检测是否安装了SPI Flash。如果没有安装SPI Flash，则在启动期间应用设备树overlay，通过扩展命令禁用SPI Flash设备树节点。如果没有可用的EEPROM数据，SPI NOR Flash节点将始终启用。有关更多信息，请参阅设备树overlay部分。

+

bootloader程序还可以通过内核的mtdparts启动参数修改设备树，将SPI MTD分区表传递给Linux。BSP中的默认分区布局设置为：

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

这是一个预定义的bootloader环境变量，可以在运行时更改。从Linux用户空间，可以通过/dev/mtd<N>设备访问NOR Flash分区，其中<N>是与要访问的NOR Flash分区相关联的MTD设备编号。要找到分区的正确MTD设备编号，请在目标上运行：

+
root@phyboard-polis-imx8mn-2:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

它列出了所有MTD设备及其对应的分区名称。闪存节点在模块DTS中的SPI主节点内定义。SPI节点包含连接到此SPI总线的所有设备，在这种情况下只有SPI NOR Flash。

+

设备树中SPI主节点的定义可以在这里找到：

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n75

+
+
+
+

7.7. GPIOs

+

phyBOARD-Polis 具有一组专门用于GPIO的引脚。这些引脚直接连接到 i.MX 8M Nano 引脚，并被复用为 GPIO。它们可以直接在 Linux 用户空间中使用。处理器将其 GPIO 组织为5个GPIO组（GPIO1 – GPIO5），每个组包含 32 个GPIO。gpiochip0、gpiochip32、gpiochip64、gpiochip96 和 gpiochip128 是这些内部 i.MX 8M Nano GPIO 组 GPIO1 – GPIO5 的 sysfs 表示。

+

GPIO被标识为GPIO<X>_<Y>（例如：GPIO5_07）。<X>表示GPIO Bank，从1计数到5，而<Y>表示该Bank内的GPIO。<Y>从0计数到31（每个bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如从gpiochip0的GPIO 20）：

    +
    target:~$ gpioget gpiochip0 20
+
    +
    +
    • +

  • 将gpiochip0上的GPIO 20的值设置为0并退出工具：

    +
    target:~$ gpioset --mode=exit gpiochip0 20=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.7.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用 CONFIG_GPIO_SYSFS 后才能支持。要在menuconfig中使 CONFIG_GPIO_SYSFS 可见，必须首先启用选项 CONFIG_EXPERT 。

+

您也可以将此选项添加到您在 Linux 内核源代码 arch/arm64/configs/ 目录下使用的 defconfig 中。例如，我们基于 NXP 的BSP版本，这个defconfig可以是 imx8_phytec_distro.config

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

您也可以创建一个新的config片段。有关详细信息，请参阅我们的《Yocto参考手册<yocto-ref-manual-kernel-and-bootloader-config>》。

+

设备树中的某些GPIO引脚的引脚复用 imx8mn-phyboard-polis.dtsi:

+
pinctrl_leds: leds1grp {
+        fsl,pins = <
+                MX8MN_IOMUXC_GPIO1_IO01_GPIO1_IO1       0x16
+                MX8MN_IOMUXC_GPIO1_IO14_GPIO1_IO14      0x16
+                MX8MN_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x16
+        >;
+};
+
+
+
+
+
+

7.8. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+mmc1::@    mmc2::@    user-led1@ user-led2@ user-led3@
+
+
+

这里的 LED 灯包括蓝色的 mmc、绿色的 心跳和红色的 emmc，它们都在 phyBOARD-Polis 上。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 255 > /sys/class/leds/user-led1/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/user-led1/brightness
+
    +
    +
    • +
+

GPIO设备树配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n35

+
+
+

7.9. I²C总线

+

该 i.MX 8M Nano 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 8M Nano 的I²C模块。 本节描述了我们 phyBOARD-Polis 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

I²C1总线的DT配置（例如 imx8mn-phycore-som.dtsi）： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n98

+

I²C3总线的DT配置（例如 imx8mn-phyboard-polis.dtsi）： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n147

+
+
+

7.10. EEPROM

+

在 phyCORE-i.MX8MN 上有一个i2c EEPROM闪存。它有两个地址。主EEPROM空间（总线：I2C-0 地址：0x51）和ID页（总线：I2C-0 地址：0x59）可以通过Linux中的sysfs接口进行访问。主EEPROM和ID页的前256个字节用于板检测，不可被覆盖。覆盖保留的空间将导致启动问题。

+
+

7.10.1. phyCORE-i.MX8MN 上的I2C EEPROM

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

phyCORE-i.MX8MN SoM上的I2C EEPROM连接到I2C-0总线的I2C地址0x51。可以直接对该设备进行读写操作：

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

要用零填充4KiB的EEPROM（总线：I2C-0 地址：0x51），并保留EEPROM数据，请使用：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM 检测

+

在 phyCORE-i.MX8MN 上配置的I2C EEPROM具有一个可通过I2C地址0x59在i2c0上寻址的独立ID页面，以及一个可通过I2C地址0x51在i2c0上寻址的正常区域。PHYTEC使用这个32字节的数据区域来存储关于SoM的信息，包括PCB版本和配置。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果EEPROM ID页面数据和正常区域的前256个字节被删除，bootloader程序将回退到 phyCORE-i.MX8MN Kit RAM设置，即 1GiB RAM。

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

使用API修订版2数据格式烧写的核心板将在早期启动阶段打印出有关模块的信息。

+
+
+

7.10.3. 恢复EEPROM数据

+

硬件数据已预先写入两个EEPROM数据空间。如果您不小心删除或覆盖了Normal区域，可以将ID区域的硬件检查数据复制到正常区域。

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1
+
+
+
+

备注

+

如果您删除了两个EEPROM空间，请联系我们的支持团队！

+
+

phyCORE-i.MX 8M Nano 的设备树配置 imx8mn-phycore-som.dtsi可以在我们的PHYTEC git中找到： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n248

+
+
+
+

7.11. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC唤醒alarm

+

可以从实时时钟（RTC）发出中断以唤醒系统。该格式使用Unix纪元时间，即自1970年1月1日UTC午夜以来的秒数。要在从挂起到RAM状态后的4分钟唤醒系统，请输入：

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

备注

+

内部唤醒alarm时间将被向上舍入到下一个分钟，因为alarm功能不支持秒。

+
+

I²C RTCs的DT表示：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.10.72_2.2.0-phy9#n254

+
+
+
+

7.12. USB主控制器

+

i.MX 8M Nano SoC 的 USB 控制器为众多消费类便携设备提供了一种低成本的连接解决方案，通过提供一种数据传输机制，使 USB 设备之间的线路/总线速度可达到 480 Mbps（高速 'HS'）。

+

该 i.MX 8M Nano SoC 具有一个设置为 OTG 模式的 USB 控制器IP。要使用Micro USB / OTG 端口，拨码开关 S1 的第 5 位必须设置为开启。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+
+
+

7.13. USB OTG

+

大多数PHYTEC板提供USB OTG接口。USB OTG端口会自动作为USB设备或USB主机工作。模式取决于连接到USB OTG端口的USB硬件。例如，如果将USB大容量存储设备连接到USB OTG端口，该设备将显示为 /dev/sda 。

+
+

7.13.1. 作为USB设备

+

为了将开发板作为USB设备连接到USB主机（例如PC），您需要配置相应的USB gadget。通过USB configfs，您可以定义USB gadget的参数和功能。BSP包含作为kernel module 的USB configfs支持。

+
target:~$ modprobe libcomposite
+
+
+

例子:

+
    +

  • 首先，定义参数，例如USB Vendor和product ID，并为英语（0x409）设置信息字符串：

    • +
+
+

提示

+

为了节省时间，请复制这些命令并在脚本中执行它们

+
+
cd /sys/kernel/config/usb_gadget/
+mkdir g1
+cd g1/
+echo "0x1d6b" > idVendor
+echo "0x0104" > idProduct
+mkdir strings/0x409
+echo "0123456789" > strings/0x409/serialnumber
+echo "Foo Inc." > strings/0x409/manufacturer
+echo "Bar Gadget" > strings/0x409/product
+
+
+
    +

  • 接下来，为大容量存储 gadget 创建一个文件：

    • +
+
target:~$ dd if=/dev/zero of=/tmp/file.img bs=1M count=64
+
+
+
    +

  • 现在你可以创建你想要使用的功能：

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir functions/acm.GS0
+mkdir functions/ecm.usb0
+mkdir functions/mass_storage.0
+echo /tmp/file.img > functions/mass_storage.0/lun.0/file
+
+
+
    +

  • acm: 串行设备 gadget，创建类似 /dev/ttyGS0 的串行接口。

    • +

  • ecm: 以太网 gadget，创建以太网接口，例如 usb0

    • +

  • mass_storage: 主机可以像处理其他USB大容量存储设备一样，对设备的大容量存储进行分区、格式化和挂载。

    • +
+
    +

  • 将定义的功能绑定到配置：

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir configs/c.1
+mkdir configs/c.1/strings/0x409
+echo "CDC ACM+ECM+MS" > configs/c.1/strings/0x409/configuration
+ln -s functions/acm.GS0 configs/c.1/
+ln -s functions/ecm.usb0 configs/c.1/
+ln -s functions/mass_storage.0 configs/c.1/
+
+
+
    +

  • 最后，使用以下命令启动USB gadget：

    • +
+
target:~$ cd /sys/kernel/config/usb_gadget/g1
+target:~$ ls /sys/class/udc/
+ci_hdrc.0
+target:~$ echo "ci_hdrc.0" >UDC
+
+
+

如果您的系统有多个USB设备或OTG端口，您可以将正确的端口传递给USB设备控制器（UDC）。

+
    +

  • 要停止USB gadget 并解除绑定已使用的功能，请执行：

    • +
+
target:~$ echo "" > /sys/kernel/config/usb_gadget/g1/UDC
+
+
+

两个USB接口在内核设备树 imx8mn-phyboard-polis.dtsi 中配置为Host。请参见：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n206

+
+
+
+

7.14. CAN FD

+

The phyBOARD-Polis has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
+

提示

+

phyBOARD-Polis 具有一个通过 SPI 连接的外部 CAN FD 芯片 MCP2518FD。由于使用了SPI，限制了 CAN FD 的数据传输速率上限。

+
+
+

提示

+

在phyBOARD-Polis-i.MX8MN上，如果需要，可以通过将S5设置为ON来启用端接电阻。

+
+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。两个CAN接口显示为can0和can1。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    can0的信息将如下所示：

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+
+

警告

+

mcp2518fd SPI到CAN FD只支持从125kB/s开始的波特率。可以选择更慢的速率，但可能无法正常工作。

+
+

imx8mn-phyboard-polis 的设备树CAN配置： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtsi?h=v5.10.72_2.2.0-phy17#n104

+
+
+

7.15. 电源管理

+
+

7.15.1. CPU核心频率调节

+

i.MX 8M Nano SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。调整频率和电压被称为“动态电压和频率调整”（DVFS）。i.MX 8M Nano BSP支持DVFS功能。Linux内核提供了一个DVFS框架，允许每个CPU核心设置最小或最大频率和一个管理其运行的governor。根据使用的 i.MX 8 型号，支持几种不同的频率。

+
+

小技巧

+

尽管DVFS框架为每个CPU核心提供了频率设置，但一个CPU核心的频率更改会影响其他CPU核心。因此，所有CPU核心始终共享相同的DVFS设置。每个核心的单独DVFS设置是不可能的。

+
+
    +

  • 要获取完整列表，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    例如 i.MX 8MPlus CPU，最高可达约 1.6 GHz，则结果将是：

    +
    1200000 1600000
+
    +
    +
    • +

  • 要查询当前的频率输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

governor 会根据它们的目标自动选择这些频率中的一个。

+
    +

  • 列出所有可用的 governor，使用以下命令：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    结果是：

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative governor 与 ondemand governor 非常相似。只是它的行为有所不同，它会更保守地增减CPU速度，而不是在CPU有任何负载的瞬间就跳到最大速度。

    • +

  • ondemand （默认）根据当前系统负载在可能的CPU核心频率之间切换。当系统负载超过特定值时，它会立即提高CPU核心频率。

    • +

  • powersave 始终选择最低的CPU核心频率。

    • +

  • performance 始终选择最高的CPU核心频率。

    • +

  • userspace 允许以root身份运行的用户或用户空间程序设置特定频率（例如，设置为1600000）。输入：

    • +

  • 要查询当前的 governor，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    您通常会得到：

    +
    ondemand
+
    +
    +
    • +

  • 切换到另一个governor（例如，userspace）可以通过以下方式完成：

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • 现在你可以设置频率：

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

有关governor的更详细信息，请参阅Linux内核代码库中的Linux内核文档，路径为 Documentation/admin-guide/pm/cpufreq.rst 。

+
+
+

7.15.2. CPU核心管理

+

该 i.MX 8M Nano SoC 芯片上可以有多个处理器核心。例如，该 i.MX 8M Nano 具有 4 个 ARM 核心，可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    这里系统有四个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.15.3. 挂起到RAM

+

phyCORE-i.MX8MN 支持基本的挂起和恢复。可以使用不同的唤醒源。挂起/恢复可以通过以下方式实现：

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

要通过串行控制台唤醒，请运行

+
target:~$ echo enabled > /sys/class/tty/ttymxc2/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.16. 热管理

+
+

7.16.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.16.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 8M Nano SoC 平台上使用热管理内核 API。 i.MX 8 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个触发点。这些触发点根据CPU型号的不同而有所不同。主要区分工业版和商业版。

+ + + + + + + + + + + + + + + + + +

商业

工业

被动（警告）

85°C

95°C

严重（关机）

90°C

100°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并实施冷却措施。内核中可用的热政策（也称为thermal governor）包括：Step Wise、Fair Share、Bang Bang和Userspace。BSP中使用的默认策略是Step Wise。如果sysfs文件temp中的SoC温度值高于 trip_point_0 ，则CPU频率将设置为最低CPU频率。当SoC温度降到 trip_point_0 以下时，限制将被解除。

+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+

7.16.3. GPIO风扇

+
+

备注

+

Only GPIO fan supported.

+
+

一个GPIO控制的风扇可以连接到 phyBOARD-Polis-i.MX 8M Nano。该SoC包含一个温度传感器，该传感器被用于热频率调节。风扇无法通过内核进行控制。我们使用lmsensors和hwmon来实现这一点。lmsensors定期读取温度，并在可配置的阈值下启用或禁用风扇。对于 phyBOARD-Polis-i.MX 8M Nano，这个阈值是60°C。

+

设置可以在配置文件中进行配置：

+
/etc/fancontrol
+
+
+

风扇控制在启动时由systemd服务启动。可以通过以下方式禁用它：

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.17. 看门狗

+

PHYTEC i.MX 8M Nano 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.17.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.18. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 8M Nano 提供一次性可编程fuse，用于存储信息，例如 MAC 地址、启动配置和其他永久设置（在 i.MX 8M Nano reference manual中称为“片上 OTP 控制器 (OCOTP_CTRL)”）。以下列表摘自 i.MX 8M Nano reference manual，包括 OCOTP_CTRL 中的一些有用寄存器（基地址为0x30350000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为0x30350000

描述

OCOTP_MAC_ADDR0

9

0

0x640

包含ENET0 MAC地址的低32位

OCOTP_MAC_ADDR1

9

1

0x650

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

OCOTP_MAC_ADDR2

9

2

0x660

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 8M Nano Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.18.1. 在uBoot中读取fuse的值

+

您可以使用内存映射的shadow寄存器读取fuse寄存器。要计算内存地址，请使用以下公式计算：

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.18.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+
+

8. BSP扩展

+
+

8.1. Chromium

+

我们的BSP支持Chromium。您只需几个步骤即可将其包含在 phytec-headless-image 中。

+
+

8.1.1. 将Chromium添加到您的local.conf文件中

+

要包含Chromium，您需要在您的local.conf中添加以下行。您可以在<yocto_dir>/build/conf/local.conf中找到这个配置文件。这将把Chromium添加到您下一个镜像编译中。:

+
IMAGE_INSTALL_append = " chromium-ozone-wayland"
+
+
+
+

备注

+

编译Chromium需要很长时间。

+
+
+
+

8.1.2. 在开发板上运行Chromium

+

要运行Chromium，需要一些参数来使用硬件图形加速：

+
target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox
+
+
+

如果您想通过SSH启动Chromium，您必须首先定义运行Chromium的显示器。例如：

+
target$ DISPLAY=:0
+
+
+

在您定义完这个之后，您可以通过上述所示的Weston虚拟终端启动它。

+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mn/pd23.1.0.html b/previews/271/zh_CN/bsp/imx8/imx8mn/pd23.1.0.html new file mode 100644 index 000000000..030a0df61 --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mn/pd23.1.0.html @@ -0,0 +1,3353 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 8M Nano BSP手册

文档标题

i.MX 8M Nano BSP手册

文档类型

BSP 手册

Yocto 手册

Kirkstone

发布日期

2024/01/10

母文档

i.MX 8M Nano BSP手册

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP发布日期

BSP 状态

BSP-Yocto-NXP-i.MX8MM-PD23.1.0

大版本

2023/12/12

已发布

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 phyCORE-i.MX8M Nano Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-mini/nano/#downloads 中找到。

+
+

1.1. 支持的硬件

+

支持的 i.MX 8M Nano 系统芯片 (SoC) 的 phyBOARD-Polis。

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-NXP-i.MX8MM-PD23.1.0 的所有Machine及其对应的Article Numbers(产品型号)： 网址. 如果您在该网页 Supported Machines 一节选择了特定的 Machine Name ，您可以查看被选中machine下的包含的 Article Number(产品型号) 以及简要的硬件描述。如果您只有 Article Number ，可以将 Machine Name 下拉菜单留空，仅选择您的 Article Number 。那么，它会显示您特定硬件所对应的 Machine Name

+
+

1.1.1. phyBOARD-Polis 器件

+ + + + + + +
+../../../_images/polis-front.jpg +
+

phyBOARD-Polis 器件（顶部）

+
+
+
+../../../_images/polis-back.jpg + +
+

phyBOARD-Polis 器件（底部）

+
+
+
+
+
+
+
+

2. 开始使用

+

该 phyCORE-i.MX8M Nano Kit 包含预先烧写好的SD卡。它包含 phytec-headless-image 镜像，可以直接用作启动盘。默认情况下，核心板上的eMMC仅烧写了U-Boot。您可以从 PHYTEC下载服务器 获取所有镜像资源。本章将解释如何将BSP镜像烧写到SD卡以及如何启动开发板。

+

有几种方法可以将镜像写入SD卡或eMMC。最为人熟知的方式是使用Linux命令行工具 dd 进行简单的顺序写入。另一种方法是使用PHYTEC的自研程序 partup ，它可以让格式化复杂系统的过程变得简单。您可以从其发布页面获取 预编译的Linux partup 二进制文件 。请阅读 partup的readme文件 来获取安装指导。

+
+

2.1. 下载镜像

+

phytec-headless-image 镜像包含完整系统所需的所有必要文件，您需确保镜像中各个分区以及裸数据都会被正确写入启动盘。可以从 PHYTEC 下载服务器 下载 partup 镜像文件或者是可以使用 dd 进行烧写的 WIC 镜像。

+

从下载服务器获取 partup 镜像文件或WIC镜像：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/phytec-headless-image-phyboard-polis-imx8mn-2.wic
+
+
+
+

备注

+

针对eMMC，我们建议使用partup去烧写比较大的或者是有复杂分区配置的镜像，因为它在写入速度上比 dd 更快，并且可以对闪存设备进行更灵活的配置。

+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要创建SD卡启动盘，必须要拥有Linux PC上的root权限。在选择烧写设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+
+

2.2.1. 寻找正确的设备

+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行命令：

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+

卸载所有这些分区，例如：

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

现在，SD卡已经准备好可以使用 partup 、 dd 或 bmap-tools 来写入镜像。

+
+
+

2.2.2. 使用partup

+

使用partup烧写SD卡只需一个命令：

+
host:~$ sudo partup install phytec-headless-image-phyboard-polis-imx8mn-2.partup /dev/<your_device>
+
+
+

确保将 <your_device> 替换为您之前找到的设备名称。

+

关于partup的进一步使用说明，请参阅其 官方文档 。

+
+

备注

+

partup 的优点在于能够清除 MMC 用户区中的特定区域，这在我们的应用场景中用于擦除 U-Boot 环境。这是一个 bmaptool 无法解决的已知问题，如下所述。

+

partup相较于其他烧写工具的一个主要优势是，它可以配置MMC的特定部分，比如他可以直接写入eMMCboot分区，无需调用其他命令。

+
+
+
+

2.2.3. 使用bmap-tools

+

准备SD卡的另一种方法是使用 bmap-tools。Yocto会自动为WIC镜像创建一个映射文件（<IMAGENAME>-<MACHINE>.wic.bmap），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host:~$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host:~$ bmaptool copy phytec-headless-image-phyboard-polis-imx8mn-2.wic /dev/<your_device>
+
+
+

将 <your_device> 替换为您之前找到的SD卡设备名称，并确保将文件 <IMAGENAME>-<MACHINE>.wic.bmap 与WIC镜像文件放在一起，以便bmaptool知道哪些块需要写入，哪些块需要跳过。

+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.2.4. 使用 dd

+

在卸载所有SD卡的挂载分区后，您可以烧写SD卡。

+

一些PHYTEC BSP会生成未压缩的镜像（文件名扩展名为*.wic），而另一些则生成压缩的镜像（文件名扩展名为*.wic.xz）。

+

要写入未压缩的镜像（*.wic），请使用以下命令：

+
host:~$ sudo dd if=phytec-headless-image-phyboard-polis-imx8mn-2.wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

或者要写入压缩后的镜像（*.wic.xz），请使用以下命令：

+
host:~$ xzcat phytec-headless-image-phyboard-polis-imx8mn-2.wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

再次确保将 <your_device> 替换为之前找到的设备名称。

+

参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

+
+
+
+

2.3. 首次启动

+ + + + + + + +
启动模式选择
+../../../_images/Nano_SD_BOOT.jpg + +
+

SD卡启动

+
+
+
+
    +

  • 插入SD卡

    • +

  • 使用 micro USB 线将开发板的 (X30) 调试USB口和主机连接起来

    • +

  • 给开发板通电

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 8M Nano BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (kirkstone).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (kirkstone).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-IMX8MM ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-vendor MACHINE=phyboard-polis-imx8mn-2 ./phyLinux init -p imx8mn -r BSP-Yocto-NXP-i.MX8MM-PD23.1.0
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 phyboard-polis-imx8mn-2 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx8mn.bin: ARM可信固件二进制文件

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY固件镜像

    • +

  • imx-boot：由imx-mkimage编译的bootloader镜像，包括SPL、U-Boot、ARM可信固件和DDR固件。这是最终的可引导bootloader镜像。

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx8mn-phyboard-polis*.dtb: 内核设备树文件

    • +

  • imx8mn-phy*.dtbo：内核设备树overlay文件

    • +

  • phytec-headless-image*.tar.gz: 根文件系统

    • +

  • phytec-headless-image*.wic: SD卡镜像

    • +
+
+
+
+
+

4. 安装操作系统

+
+

4.1. 启动模式开关 (S1)

+

该 phyBOARD-Polis 具有一个启动配置开关，带有六个可单独切换的开关，用于选择 phyCORE-i.MX 8M Nano 的默认启动源。

+

硬件修订主板：1532.2及更新版本

+ + + + + + + + + + + + + +
启动模式选择
+../../../_images/Nano_eMMC_BOOT.png + +
+

eMMC（核心板的默认启动方式）

+
+
+
+../../../_images/Nano_Serial_downloader_BOOT.png + +
+

USB串行下载器

+
+
+
+../../../_images/Nano_SD_BOOT.jpg + +
+

SD卡

+
+
+
+../../../_images/Nano_Fuse_BOOT.png + +
+

内部fuse

+
+
+
+../../../_images/Nano_QSPI_BOOT.png + +
+

SPI NOR

+
+
+

+ + + + + + + +
通过开关(S1)的第5位在USB HOST/OTG之间切换。
+../../../_images/USB_HOST.jpg + +
+

USB 主机

+
+
+
+../../../_images/USB_OTG.png + +
+

USB OTG

+
+
+
+ + + + + + + +
通过开关(S1)的第4位在UART1的RS485/RS232之间切换。
+../../../_images/UART1_RS4851.png + +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS2321.jpg + +
+

UART1 RS232

+
+
+
+
+
+

4.2. 烧写eMMC

+

为了保持文档的一致性和简洁性，假设已经配置好了TFTP服务器；所有生成的镜像（如上所列）都被复制到默认的/srv/tftp目录。如果您没有进行设置，您需要修改路径到包含镜像的目录。有关如何设置TFTP服务器和目录的说明，请参见 Setup Network Host 。

+

要从 eMMC 启动，请确保 BSP 镜像已正确烧写到 eMMC，并且 bootmode switch (S1) 设置为 eMMC。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行上述命令来检查系统启动在这种条件下是否会到影响。如果 mmcblk2p1 和 mmcblk1p1 具有相同的UUID，则会影响系统正确启动。

+
+
+

4.2.1. 从网络烧写 eMMC

+

i.MX 8M Nano 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

4.2.1.1. 在开发板的U-Boot中通过网络烧写eMMC

+

这些步骤将展示如何通过网络更新eMMC。

+
+

小技巧

+

此步骤仅在镜像文件小于1GB的情况下会被执行成功，因为在启用OPTEE后，Bootloader中可用的RAM大小有限，不足以加载超过1GB的镜像

+
+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

通过网络将您的镜像加载到内存中：

+
    +

  • 使用DHCP

    +
    u-boot=> dhcp phytec-headless-image-phyboard-polis-imx8mn-2.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.1 (1 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.1
+Filename 'phytec-headless-image-phyboard-polis-imx8mn-2.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • 使用静态IP地址（必须先设置serverip和ipaddr）。

    +
    u-boot=> tftp ${loadaddr} phytec-headless-image-phyboard-polis-imx8mn-2.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-phyboard-polis-imx8mn-2.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
+
+
+
+

4.2.1.2. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

使用一条命令，通过网络ssh协议将带有块映射的压缩或未压缩的镜像发送到开发板的eMMC上使用，执行：

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-headless-image-phyboard-polis-imx8mn-2.wic /tmp && bmaptool copy /tmp/phytec-headless-image-phyboard-polis-imx8mn-2.wic /dev/mmcblk2
+
+
+
+
+

4.2.1.3. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

查看主机上可用的镜像文件：

+
host:~$ ls /srv/tftp
+phytec-headless-image-phyboard-polis-imx8mn-2.wic
+phytec-headless-image-phyboard-polis-imx8mn-2.wic.bmap
+
+
+

通过网络ssh协议使用 bmaptool 命令将镜像发送到开发板的eMMC：

+
host:~$ scp /srv/tftp/phytec-headless-image-phyboard-polis-imx8mn-2.wic root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-headless-image-phyboard-polis-imx8mn-2.wic /dev/mmcblk2"
+
+
+
+
+
+

4.2.2. 在运行的U-Boot中通过网络烧写eMMC U-Boot镜像

+

可以在U-Boot中更新U-Boot镜像imx-boot，eMMC上的U-Boot需要位于eMMC的user区域。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.3. 从USB大容量存储设备烧写eMMC

+
+

4.2.3.1. 在开发板上通过U-Boot从USB烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件小于1GB的情况下会被执行成功，因为在启用OPTEE后，Bootloader中可用的RAM大小有限，不足以加载超过1GB的镜像

+
+

下面这些步骤展示如何通过USB设备更新eMMC。将|ref-bootswitch| 配置为SD卡启动，并插入SD卡。给开发板上电并进入U-Boot环境。将已存储了未压缩WIC镜像的优盘插入开发板USB接口。

+

将镜像从USB设备加载到RAM中：

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} *.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. 在运行的Linux系统中从USB烧写eMMC

+

下面这些步骤展示如何在Linux系统上使用USB大容量存储设备烧写eMMC。您需要一个保存了完整镜像的U盘和一个可从SD卡启动的核心板（例如 phytec-headless-image-phyboard-polis-imx8mn-2.wic）。将 bootmode switch (S1) 设置为SD卡启动。

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ ls /mnt
+phytec-headless-image-phyboard-polis-imx8mn-2.wic
+phytec-headless-image-phyboard-polis-imx8mn-2.wic.bmap
+
    +
    +
    • +

  • 将镜像写入 phyCORE-i.MX 8M Nano eMMC（无分区的 MMC 设备 2）：

    +
    target:~$ bmaptool copy /mnt/phytec-headless-image-phyboard-polis-imx8mn-2.wic /dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    小技巧

    +

    在此之前，您需要将 bootmode switch (S1) 配置为 eMMC。

    +
    +
    • +
+
+
+
+

4.2.4. 从SD卡烧写eMMC

+

即使没有可用的网络，您也可以更新eMMC。为此，您需要一个位于SD卡上的镜像文件（ *.wic ）。由于镜像文件相当大，您需要在SD卡创建第三个分区。要创建新分区或扩展您的SD卡，请参见 Resizing ext4 Root Filesystem 。

+

或者，使用partup包烧写SD卡，如 Getting Started 中所述。这样就可使用SD卡的全部容量。

+
+

4.2.4.1. 在开发板的uboot环境中通过SD卡烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1GB的情况下有效，因为在启用OPTEE后，Bootloader中可用的RAM大小有限。如果镜像文件过大，请阅读 在开发板上通过SD卡更新eMMC 一节

+
+
    +

  • 将一个可用的镜像烧写到SD卡，并创建一个EXT4格式的第三分区。将WIC镜像（例如 phytec-headless-image.wic）复制到该分区。

    • +

  • 将 bootmode switch (S1) 配置为 SD 卡并插入 SD 卡。

    • +

  • 打开电源并进入U-Boot。

    • +

  • 加载镜像：

    +
    u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-phyboard-polis-imx8mn-2.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • 将当前mmc设备切换到eMMC：

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • 将您的WIC镜像（例如 phytec-headless-image.wic）从SD卡烧写到eMMC。这将对卡进行分区，并将imx-boot、Image、dtb、dtbo和根文件系统复制到eMMC。

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • 关闭电源并将 bootmode switch (S1) 更改为 eMMC。

    • +
+
+
+

4.2.4.2. 在开发板的linux环境中通过SD卡烧写eMMC

+

您也可以在Linux系统中烧写eMMC。您只需要一个partup包或保存在SD卡上的WIC镜像。

+
    +

  • 检查在SD卡上保存的partup包或WIC镜像文件：

    +
    target:~$ ls
+phytec-headless-image-phyboard-polis-imx8mn-2.partup
+phytec-headless-image-phyboard-polis-imx8mn-2.wic
+phytec-headless-image-phyboard-polis-imx8mn-2.wic.bmap
+
    +
    +
    • +

  • 使用 partup 将镜像写入 phyCORE-i.MX 8M Nano 的 eMMC（MMC 设备 2 不带 分区字样）：

    +
    target:~$ partup install phytec-headless-image-phyboard-polis-imx8mn-2.partup /dev/mmcblk2
+
    +
    +

    使用partup烧写的优点是可以充分利用eMMC设备的全部容量，会相应自动调整分区大小。

    +
    +

    备注

    +

    另外，也可以使用 bmaptool 工具：

    +
    target:~$ bmaptool copy phytec-headless-image-phyboard-polis-imx8mn-2.wic /dev/mmcblk2
+
    +
    +

    请注意，在使用 bmaptool 烧写时，根文件系统分区并不会使用eMMC的最大容量。

    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    警告

    +

    在此之前，您需要将 bootmode switch (S1) 配置为 eMMC。

    +
    +
    • +
+
+
+
+
+

4.3. 烧写 SPI NOR Flash

+

phyCORE-i.MX8MN 模块可选配SPI NOR Flash。要从SPI Flash启动，请将 bootmode switch (S1) 设置为 SPI NOR 。SPI Flash通常比较小。phyBOARD-Pollux-i.MX8MP开发套件仅配备32MB的SPI NOR Flash。只能存储bootloader及其环境变量。默认情况下，内核、设备树和文件系统会从eMMC加载。

+

SPI NOR Flash分区表在U-Boot环境变量中定义。可以通过以下命令打印：

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. 通过网络烧写SPI NOR Flash

+

SPI NOR可以包含bootloader及其环境变量。arm64的linux内核无法自行解压缩，内核镜像大小超出了phyCORE-i.MX 8M Nano 上的SPI NOR Flash的容量。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+
+

4.3.1.1. 在开发板的U-Boot环境中通过网络烧写SPI NOR

+

类似于通过网络更新eMMC，请确保正确设置主机PC。IP地址需要设置为192.168.3.10，子网掩码设置为255.255.255.0，并且需要有一个可用的TFTP服务。在进行读写之前，需要对SPI NOR Flash进行枚举：

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像。确保您使用了正确的镜像文件。通过tftp加载镜像，然后将bootloader写入Flash：

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+

4.3.1.2. 在开发板linux环境中通过网络烧写SPI NOR Flash

+
    +

  • 将镜像从主机复制到开发板：

    +
    host:~$ scp imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • 查找要擦除的U-boot分区的块数：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除U-Boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+

4.3.2. 从SD卡烧写SPI NOR Flash

+

SPI NOR Flash上的bootloader也可以通过SD卡进行烧写。

+
+

4.3.2.1. 在开发板的U-Boot环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi复制到SD卡的第一个分区。

    • +

  • 在进行读写操作之前，需要对SPI-NOR Flash进行枚举：

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像，请确保使用正确的镜像文件。从SD卡加载镜像，擦除并将bootloader写入flash：

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+

4.3.2.2. 在开发板的linux环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi复制到SD卡的第一个分区。

    • +

  • 挂载SD卡：

    +
    target:~$ mount /dev/mmcblk1p1 /mnt
+
    +
    +
    • +

  • 查找要擦除的U-Boot分区的块数：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除u-boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-polis-imx8mn-2-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC： L-1006e.A5 RAUC Update & Device Management Manual 。

+
+
+
+

5. 开发

+
+

5.1. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.1.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.2. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.2.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核镜像复制到您的tftp目录中：

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • 将设备树复制到您的tftp目录：

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • 将您想要使用的所有overlay文件复制到您的tftp目录中：

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-headless-image-phyboard-polis-imx8mn-2.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.2.2. 设置网络启动的bootenv.txt文件

+

在您的tftp目录中创建一个bootenv.txt文件，并将以下变量写入其中。

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> 必须替换为您想要使用的overlay设备树文件名。用空格分隔文件名。例如：

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

小技巧

+

所有支持的设备树overlay在 device tree 章节中。

+
+
+
+

5.2.3. 开发板上的网络设置

+

如果要自定义开发板上的以太网配置，请按照此处的说明进行操作： Network Environment Customization

+
+
+

5.2.4. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.3.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. 获取镜像

+

可以从我们的服务器下载imx-boot，或者从Yocto编译目录中的build/deploy/images/phyboard-polis-imx8mn-2/获取它。要将wic镜像烧写到eMMC，你还需要 phytec-headless-image-phyboard-polis-imx8mn-2.wic。

+
+
+

5.3.3. 开发板准备

+

将 bootmode switch (S1) 设置为 USB串行下载。同时，将 USB 端口 X2 连接到主机。

+
+
+

5.3.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 (X30) 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.3.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-headless-image-phyboard-polis-imx8mn-2.wic
+
+
+
+
+
+

5.4. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone git://git.phytec.de/u-boot-imx）

+
+
+

5.4.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-imx 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • 我们的 i.MX 8M Nano 内核是基于 linux-imx 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. 获取SDK

+

您可以在此处下载SDK 这里，或者使用Yocto去编译生成SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-headless-image # or another image
+
    +
    +
    • +
+

在成功编译后，SDK安装包保存在 build/deploy*/sdk。

+
+
+

5.4.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-vendor-glibc-x86_64-phytec-headless-image-cortexa53-crypto-toolchain-4.0.13.sh
+host:~$ ./phytec-ampliphy-vendor-glibc-x86_64-phytec-headless-image-cortexa53-crypto-toolchain-4.0.13.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor/4.0.13):
+You are about to install the SDK to "/opt/ampliphy-vendor/4.0.13". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-vendor/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. 单独编译U-Boot

+
+

5.5.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本中使用的**tag**称为 v2022.04_2.2.2-phy5

    • +

  • 查看所需的 U-Boot tag：

    +
    host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2022.04_2.2.2-phy5
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. 获取所需的二进制文件

+

要编译bootloader，您需要将这些文件复制到您的 u-boot-imx 编译目录，并将其重命名以适应 mkimage 脚本：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx8mn.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以在yocto工程目录中获取 bl31-imx8mn.bin、tee.bin和lpddr4_*.bin：BSP Images

+

或者你可以在这里下载文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MM/BSP-Yocto-NXP-i.MX8MM-PD23.1.0/images/ampliphy-vendor/phyboard-polis-imx8mn-2/imx-boot-tools/

+
+

警告

+

确保您重命名所需的文件，以和 mkimage tool 兼容。

+
+
+
+

5.5.3. 编译bootloader

+
    +

  • 编译 flash.bin (imx-boot):

    +
    host:~/u-boot-imx$ make phycore-imx8mn_defconfig
+host:~/u-boot-imx$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. 将bootloader烧写到块设备上

+

flash.bin 文件可以在 u-boot-imx/ 目录下找到，现在可以进行烧写。需要指定芯片特定的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

+

例如，烧写SD卡：

+
host:~/u-boot-imx$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+
+

5.6. 单独编译内核

+
+

5.6.1. 配置源代码

+
    +

  • 使用的 linux-imx 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v5.15.71_2.2.2-phy3

    • +

  • Check out 所需的 linux-imx 标签：

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v5.15.71_2.2.2-phy3
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-imx$ make imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-imx/arch/arm64/boot/Image 找到

    • +

  • dtb文件可以在 ~/linux-imx/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. 将内核复制到SD卡

+

内核及module和对应的设备树二进制文件可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. 获取BSP开发中版本

+
+

5.7.1. 当前release的开发中版本

+

这些release manifest文件是为了让您访问 Yocto BSP的开发版本。它们不会在phyLinux选择菜单中显示，需要手动选择。可以使用以下命令行来完成此操作：

+
host:~$ ./phyLinux init -p imx8mn -r BSP-Yocto-NXP-i.MX8MM-PD23.1.y
+
+
+

这将初始化一个BSP，用于跟踪当前版本（ BSP-Yocto-NXP-i.MX8MM-PD23.1.0 ）的最新开发版本。从现在开始，在此文件夹中执行 repo sync 将从我们的Git仓库中拉取所有最新的更改：

+
host:~$ repo sync
+
+
+
+
+

5.7.2. 即将发布版本的开发中版本

+

即将发布版本的开发中版本可以通过这种方式访问。请执行以下命令，并查找一个比最新版本（ BSP-Yocto-NXP-i.MX8MM-PD23.1.0 ）的PDXX.Y数字更高的版本，并且以 .y 结尾：

+
host:~$ ./phyLinux init -p imx8mn
+
+
+
+
+
+

5.8. 获取最新的Upstream支持

+

我们有一个使用Yocto主分支（不是NXP发布的）的manifest，他使用upstream的Linux和U-Boot。这可以用来测试最新的upstream kernel/U-Boot。

+
+

备注

+

master分支的manifest反映了最新的开发状态。有时会出现一些bug。我们会定期修复master分支。

+
+
host:~$ ./phyLinux init -p imx8mn -r BSP-Yocto-Ampliphy-i.MX8MM-master
+
+
+
+
+

5.9. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.9.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将 phytec-headless-image-phyboard-polis-imx8mn-2.wic 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-headless-image-phyboard-polis-imx8mn-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将 phytec-headless-image-phyboard-polis-imx8mn-2.wic 镜像复制到其中。然后卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-headless-image-phyboard-polis-imx8mn-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 8M Nano BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 8M Nano 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Board.dts - 包含module dtsi 文件。从SoC i.MX 8M Nano 引出并在底板使用的设备也包含在此 dts 中。

    • +

  • Overlay.dtso - 根据核心板或底板上可选硬件（例如 SPI 闪存或 PEB-AV-10）的情况来启用/禁用一些功能。

    • +
+

在Linux内核的根目录下，我们的 i.MX 8 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。例如扩展板的硬件描述。对比源码中的include，overlay是用覆盖的方式来生效。overlay也可以根据节点是否连接来设置节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/overlays 中。

+

phyboard-polis-imx8mn-2.conf 可用的overlay文件有：

+
imx8mn-phyboard-polis-peb-eval-01.dtbo
+imx8mn-phyboard-polis-peb-av-010.dtbo
+imx8mn-phycore-rpmsg.dtbo
+imx8mn-phycore-no-eth.dtbo
+imx8mn-phycore-no-spiflash.dtbo
+imx8mn-vm016.dtbo
+imx8mn-vm016-fpdlink.dtbo
+imx8mn-vm017.dtbo
+imx8mn-vm017-fpdlink.dtbo
+imx8mn-dual-vm017-fpdlink.dtbo
+
+
+

可以在Linux或U-Boot环境下配置overlay。overlay是在引导命令调用后、内核加载之前生效。接下来的部分将更详细地解释配置方法。

+
+

6.2.2.1. 设置 ${overlays} 变量

+

${overlays} U-Boot 环境变量包含一个以空格分隔的overlay文件列表，这些overlay文件将在启动过程中应用。根据启动源，overlay文件必须放置在 eMMC/SD 卡的启动分区中，或者通过 tftp 加载。在 $KERNEL_DEVICETREE 这个 Yocto machine 变量中设置的 overlay 文件将自动添加到最终 WIC 镜像的启动分区中。

+

${overlays} 变量可以直接在U-Boot环境中设置，也可以作为外部 bootenv.txt 环境文件的一部分。默认情况下， ${overlays} 变量来自位于启动分区的 bootenv.txt 文件。您可以在已启动的开发板上从Linux读取和写入该文件：

+
target:~$ cat /boot/bootenv.txt
+overlays=imx8mn-phyboard-polis-peb-eval-01.dtbo imx8mn-phyboard-polis-peb-av-010.dtbo
+
+
+

更改将在下次重启后生效。如果没有可用的 bootenv.txt 文件，可以直接在U-Boot环境中设置overlay变量。

+
u-boot=> setenv overlays imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> printenv overlays
+overlays=imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

如果用户定义了 ${overlays} 变量，同时存在 bootenv.txt 文件，则需要设置 ${no_bootenv} 变量：

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx8mn-phyboard-polis-peb-av-010.dtbo
+u-boot=> boot
+
+
+

有关环境的更多信息，请参见 U-boot External Environment subsection of the +device tree overlay section。

+

我们使用 ${overlays} 变量来描述在运行时无法自动检测的扩展板和摄像头。如果想禁用 ${overlays} 变量中列出的overlay，可以在U-Boot的环境中将 ${no_overlays} 变量设置为 1。

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+

6.2.2.2. 扩展命令

+

使用U-Boot扩展命令能够轻松加载由回调函数 extension_board_scan() 检测并添加到列表中的overlay。以这种方式应用的overlay会禁用核心板上未贴装的组件。检测是通过读取出厂EEPROM数据（EEPROM SoM Detection）来实现的。

+

这取决于核心板型号是否会应用任何设备树overlay。要检查在U-Boot中运行的SoM是否会应用overlay，请运行：

+
u-boot=> extension scan
+Found 1 extension board(s).
+u-boot=> extension list
+Extension 0: phyCORE-i.MX8MN no SPI flash
+        Manufacturer:           PHYTEC
+        Version:
+        Devicetree overlay:     imx8mn-phycore-no-spiflash.dtbo
+        Other information:      SPI flash not populated on SoM
+
+
+

如果没有可用的EEPROM数据，则不加载任何设备树overlay。

+

为了禁止在启动时自动运行扩展命令，可以在bootloader环境中将 ${no_extensions} 变量设置为 1 ：

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot外部环境

+

在Linux内核启动时，外部环境 bootenv.txt 文本文件将从MMC设备的boot分区或通过TFTP加载。该文件的主要目的是存储 ${overlays} 变量。这可以针对不同的machine在Yocto中预定义不同的overlay配置。文件的内容在meta-phytec中的Yocto recipe中的bootenv中定义： https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=kirkstone

+

该文件中也可以设置其他变量。这些变量将覆盖环境中现有的设置。但只有对boot命令后进行计算的变量生效，例如 ${nfsroot} 或 ${mmcargs}。在文件中更改其他变量将不会有作用。以网络启动的用法作为示例。

+

如果无法加载外部环境，启动过程将继续进行，并使用自带的环境变量值。

+
+
+

6.2.4. 在Linux环境下更改开发板上的U-boot环境变量

+

Libubootenv是我们镜像中包含的一个工具，用于在开发板linux上修改U-Boot环境。

+

使用以下命令打印U-Boot环境：

+
target:~$ fw_printenv
+
+
+

使用以下命令修改U-Boot环境：

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

小心

+

Libubootenv会读取配置文件中配置的环境变量。要修改的环境变量会被插入到该文件中，默认情况下使用eMMC中存储环境变量。

+

如果eMMC没有被烧写过或者eMMC环境被擦除，libubootenv将无法工作。您应该修改 /etc/fw_env.config 文件，以匹配您想要使用的环境源。

+
+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 8M Nano BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 8M Nano BSP设备树概念部分，以了解我们的 i.MX 8 BSP设备树模型。

+

以下部分概述了 i.MX 8 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 8M Nano 引脚复用

+

该 i.MX 8M Nano Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 8M Nano 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 8M Nano 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是 imx8mn-phyboard-polis.dts中UART1设备的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX     0x00
+                MX8MN_IOMUXC_SAI2_RXC_UART1_DCE_RX      0x00
+                MX8MN_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B  0x00
+                MX8MN_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B  0x00
+        >;
+};
+
+
+

字符串的第一部分 MX8MN_IOMUXC_SAI2_RXFS_UART1_DCE_TX 指定了引脚（在此示例中为 SAI2_RXFS）。字符串的第二部分 (UART1_DCE_RX) 是该引脚的复用选项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部上拉电阻是否被激活。在当前配置下，内部电阻被禁用。

+
+
+

7.2. RS232/RS485

+

i.MX 8M Nano SoC 提供最多 4 个 UART 单元。PHYTEC 开发板支持不同数量 UART 单元。UART1 也可以用作 RS-485。为此，需要正确设置 bootmode switch (S1)：

+ + + + + + + +
切换UART1的RS485和RS232模式
+../../../_images/UART1_RS485.png +
+

UART1 RS485

+
+
+
+../../../_images/UART1_RS232.jpg +
+

UART1 RS232

+
+
+
+
+

7.2.1. RS232

+
    +

  • 以人类可读的格式显示终端的当前设置：

    +
    target:~$ stty -a
+
    +
    +
    • +

  • UART接口的配置可以通过stty命令完成。例如：

    +
    target:~$ stty -F /dev/ttymxc0 115200 crtscts raw -echo
+
    +
    +
    • +

  • 通过简单的echo和cat，可以测试基本的通信。示例：

    +
    target:~$ echo 123 > /dev/ttymxc0
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

主机应打印出 "123"。

+
+
+

7.2.2. RS485

+
+

提示

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

为了方便测试，请查看linux-serial-test。这个工具会通过调用RS485的IOCTL，发送恒定的数据流。

+
target:~$ linux-serial-test -p /dev/ttymxc0 -b 115200 --rs485 0
+
+
+

有关linux-serial-test工具及其参数的更多信息，请访问此链接：linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Linux kernel文档描述了如何在C代码中调用IOCTL： https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection2.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see "test" printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final "count for this session". There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+

RS232和RS485的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n220

+
+
+
+
+

7.3. 网络

+

phyBOARD-Polis-i.MX 8M Nano 提供一个千兆以太网接口。

+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n50。

+

+
+

7.3.1. 网络配置

+
+

7.3.1.1. U-boot网络环境

+
    +

  • 要在bootloader中查找以太网设置：

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • 在将主机设置为IP 192.168.3.10和子网掩码255.255.255.0的情况下，开发板应该返回：

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • 如果您需要进行任何更改：

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> 应该是 ipaddr、netmask、gatewayip 或 serverip 中的一个。<value> 将是所选参数的设定值。

    +
    • +

  • 您所做的更改目前是临时的。要保存这些更改：

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

在这里，您也可以将IP地址更改为DHCP，而不是使用静态IP地址。

+
    +

  • 配置：

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • 设置 TFTP 和 NFS 的路径。修改可以如下所示：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+

小技巧

+

像nfsroot和netargs这样的变量可以被U-boot外部环境重新赋值。对于网络启动，外部环境将通过tftp加载。例如，要在 bootenv.txt 文件中设置nfsroot变量，请在tftproot目录修改：

+
nfsroot=/home/user/nfssrc
+
+
+

无需在开发板上存储这些信息。请注意，U-boot外部环境对于像 ipaddr 或 serveraddr 这样的变量不起作用，因为它们在加载外部环境之前已经被设置完成。

+
+
+
+

7.3.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. 无线局域网

+

为了支持WLAN和蓝牙，我们使用来自LSR的Sterling-LWB模块。该模块支持2.4 GHz，并且可以在多种模式下运行，如客户端模式、使用WEP、WPA、WPA2加密的接入点（AP）模式等。有关该模块的更多信息，请访问 https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. 连接到WLAN网络

+

首先设置您所在国家的正确监管域：

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

你将会看到：

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

设置无线接口：

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

现在您可以扫描可用的网络：

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

您可以使用一个跨平台的客户端，名为wpa_supplicant，支持WEP、WPA和WPA2，以建立加密连接。

+

为此，请将网络凭据添加到文件 /etc/wpa_supplicant.conf 中：

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

现在可以建立连接：

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

这会得到如下输出：

+
...
+ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (kirkstone).

+

首先，创建目录：

+
target:~$ mkdir -p /etc/systemd/network/
+
+
+

然后在 /etc/systemd/network/10-wlan0.network 中添加以下配置片段：

+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+

现在，请重启网络守护进程以使配置生效：

+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+
+

7.3.3. 蓝牙

+

Bluetooth is connected to UART2 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

现在您可以扫描环境中的可见蓝牙设备。在默认配置下，蓝牙是不可见的。

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. 可见性

+

要激活可见性：

+
target:~$ hciconfig hci0 piscan
+
+
+

要禁用可见性：

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. 连接

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

备注

+

如果连接失败并出现错误信息：“连接失败：org.bluez.Error.Failed”，请尝试使用以下命令重新启动PulseAudio：

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC 卡

+

该 i.MX 8M Nano 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

MMC（SD卡插槽）接口的DT配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n301

+

eMMC接口的DT配置可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n309

+
+
+

7.5. eMMC设备

+

PHYTEC模块如phyCORE-i.MX 8M Nano 配备了eMMC存储芯片作为主要存储。eMMC设备使用多层单元（MLC）或三层单元（TLC）技术来实现存储，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 8M Nano ，并在Linux内核中作为块设备表示，如SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.5.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），该层负责处理原始MLC或TLC的磨损均衡、块管理和错误更正码（ECC）。这需要定期执行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 通过以下命令使能BKOPS_EN：

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.5.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 8M Nano SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.5.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
+
+

7.5.5. 启用伪SLC模式

+

eMMC设备使用 MLC或TLC 来存储数据。与NAND Flash中使用的SLC相比，MLC或TLC在成本更低的情况下，可靠性较低且错误率较高。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. 擦除设备

+

可以直接擦除eMMC设备，而不是通过写零覆盖。eMMC块管理算法将擦除底层的MLC或TLC，或者将这些块标记为可丢弃。设备上的数据将丢失，并将被读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.5.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 8M Nano 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.5.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

下表是 i.MX 8M Nano SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.6. SPI主设备

+

i.MX 8M Nano 控制器包含一个 FlexSPI 和一个 ECSPI IP 核。FlexSPI 主控制器支持两个 SPI 通道，最多可连接 4 个设备。每个通道支持单通道/双通道/四通道/八通道模式的数据传输（1/2/4/8 条数据线）。ECSPI 控制器支持 3 个 SPI 接口，每个接口都有一个专用的CS（chip select）引脚。由于CS也可通过 GPIO 实现，因此每个通道上可以连接多个设备。

+
+

7.6.1. SPI NOR 烧写

+

phyCORE-i.MX 8M Nano 配备有一个 QSPI NOR Flash，该 Flash 连接到 i.MX 8M Nano 的 FlexSPI 接口。QSPI NOR Flash 可用于启动。有关烧写和启动模式设置的详细信息，请参见不同的章节。由于 SPI NOR Flash 的空间有限，因此仅可存储bootloader。默认情况下，内核、设备树和根文件系统来自 eMMC。

+

bootloader程序通过EEPROM数据检测是否安装了SPI Flash。如果没有安装SPI Flash，则在启动期间应用设备树overlay，通过扩展命令禁用SPI Flash设备树节点。如果没有可用的EEPROM数据，SPI NOR Flash节点将始终启用。有关更多信息，请参阅设备树overlay部分。

+

bootloader程序还可以通过内核的mtdparts启动参数修改设备树，将SPI MTD分区表传递给Linux。BSP中的默认分区布局设置为：

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

这是一个预定义的bootloader环境变量，可以在运行时更改。从Linux用户空间，可以通过/dev/mtd<N>设备访问NOR Flash分区，其中<N>是与要访问的NOR Flash分区相关联的MTD设备编号。要找到分区的正确MTD设备编号，请在目标上运行：

+
root@phyboard-polis-imx8mn-2:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

它列出了所有MTD设备及其对应的分区名称。闪存节点在模块DTS中的SPI主节点内定义。SPI节点包含连接到此SPI总线的所有设备，在这种情况下只有SPI NOR Flash。

+

设备树中SPI主节点的定义可以在这里找到：

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n78

+
+
+
+

7.7. GPIOs

+

phyBOARD-Polis 具有一组专门用于GPIO的引脚。这些引脚直接连接到 i.MX 8M Nano 引脚，并被复用为 GPIO。它们可以直接在 Linux 用户空间中使用。处理器将其 GPIO 组织为5个GPIO组（GPIO1 – GPIO5），每个组包含 32 个GPIO。gpiochip0、gpiochip32、gpiochip64、gpiochip96 和 gpiochip128 是这些内部 i.MX 8M Nano GPIO 组 GPIO1 – GPIO5 的 sysfs 表示。

+

GPIO被标识为GPIO<X>_<Y>（例如：GPIO5_07）。<X>表示GPIO Bank，从1计数到5，而<Y>表示该Bank内的GPIO。<Y>从0计数到31（每个bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如从gpiochip0的GPIO 20）：

    +
    target:~$ gpioget gpiochip0 20
+
    +
    +
    • +

  • 将gpiochip0上的GPIO 20的值设置为0并退出工具：

    +
    target:~$ gpioset --mode=exit gpiochip0 20=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.7.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用 CONFIG_GPIO_SYSFS 后才能支持。要在menuconfig中使 CONFIG_GPIO_SYSFS 可见，必须首先启用选项 CONFIG_EXPERT 。

+

您也可以将此选项添加到您在 Linux 内核源代码 arch/arm64/configs/ 目录下使用的 defconfig 中。例如，我们基于 NXP 的BSP版本，这个defconfig可以是 imx8_phytec_distro.config

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+

设备树 imx8mn-phyboard-polis.dts 中一些GPIO引脚的管脚复用：

+
pinctrl_leds: leds1grp {
+        fsl,pins = <
+                MX8MN_IOMUXC_GPIO1_IO01_GPIO1_IO1       0x16
+                MX8MN_IOMUXC_GPIO1_IO14_GPIO1_IO14      0x16
+                MX8MN_IOMUXC_GPIO1_IO15_GPIO1_IO15      0x16
+        >;
+};
+
+
+
+
+
+

7.8. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

这里的 LED 灯包括蓝色的 mmc、绿色的 心跳和红色的 emmc，它们都在 phyBOARD-Polis 上。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

GPIO配置的设备树配置可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n45

+
+
+

7.9. I²C总线

+

该 i.MX 8M Nano 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 8M Nano 的I²C模块。 本节描述了我们 phyBOARD-Polis 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

I²C1总线的DT配置（例如 imx8mn-phycore-som.dtsi）： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n106

+

I²C3总线DT配置（例如 imx8mn-phyboard-polis.dts）：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n196

+
+
+

7.10. EEPROM

+

在 phyCORE-i.MX8MN 上有一个i2c EEPROM闪存。它有两个地址。主EEPROM空间（总线：I2C-0 地址：0x51）和ID页（总线：I2C-0 地址：0x59）可以通过Linux中的sysfs接口进行访问。主EEPROM和ID页的前256个字节用于板检测，不可被覆盖。覆盖保留的空间将导致启动问题。

+
+

7.10.1. phyCORE-i.MX8MN 上的I2C EEPROM

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

phyCORE-i.MX8MN SoM上的I2C EEPROM连接到I2C-0总线的I2C地址0x51。可以直接对该设备进行读写操作：

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

要用零填充4KiB的EEPROM（总线：I2C-0 地址：0x51），并保留EEPROM数据，请使用：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM 检测

+

在 phyCORE-i.MX8MN 上配置的I2C EEPROM具有一个可通过I2C地址0x59在i2c0上寻址的独立ID页面，以及一个可通过I2C地址0x51在i2c0上寻址的正常区域。PHYTEC使用这个32字节的数据区域来存储关于SoM的信息，包括PCB版本和配置。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果EEPROM ID页面数据和正常区域的前256个字节被删除，bootloader程序将回退到 phyCORE-i.MX8MN Kit RAM设置，即 1GiB RAM。

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

使用API修订版2数据格式烧写的核心板将在早期启动阶段打印出有关模块的信息。

+
+
+

7.10.3. 恢复EEPROM数据

+

硬件数据已预先写入两个EEPROM数据空间。如果您不小心删除或覆盖了Normal区域，可以将ID区域的硬件检查数据复制到正常区域。

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1
+
+
+
+

备注

+

如果您删除了两个EEPROM空间，请联系我们的支持团队！

+
+

DT表示，例如在phyCORE-i.MX 8M Nano 文件 imx8mn-phycore-som.dtsi中，可以在我们的PHYTEC git中找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n259

+
+
+
+

7.11. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC唤醒alarm

+

可以从实时时钟（RTC）发出中断以唤醒系统。该格式使用Unix纪元时间，即自1970年1月1日UTC午夜以来的秒数。要在从挂起到RAM状态后的4分钟唤醒系统，请输入：

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

备注

+

内部唤醒alarm时间将被向上舍入到下一个分钟，因为alarm功能不支持秒。

+
+
+
+

7.11.2. RTC参数

+

实时时钟（RTC）具有一些功能，可以通过 hwclock 工具进行读取和设置。

+
    +

  • 我们可以通过以下方式检查RTC支持的功能：

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x11.
+
    +
    +

    这个值的含义在内核中进行了编码，每个位的定义为：

    +
    #define RTC_FEATURE_ALARM              0
+#define RTC_FEATURE_ALARM_RES_MINUTE   1
+#define RTC_FEATURE_NEED_WEEK_DAY      2
+#define RTC_FEATURE_ALARM_RES_2S       3
+#define RTC_FEATURE_UPDATE_INTERRUPT   4
+#define RTC_FEATURE_CORRECTION         5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE 6
+#define RTC_FEATURE_CNT                7
+
    +
    +
    • +

  • 我们可以通过以下方式检查RTC BSM（Backup Switchover Mode 备份切换模式）：

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • 我们可以通过以下方式设置RTC BSM：

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    BSM位的定义为：

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    小技巧

    +

    您应该将BSM模式设置为DSM或LSM，以便在初始电源不可用时，RTC可以切换到备用电源。请查看 RV-3028 RTC的Datasheet，以了解LSM（电平切换模式）和DSM（直接切换模式）这两个定义的工作模式。

    +
    +
    • +
+

I²C RTC的设备树表示：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n267

+
+
+
+

7.12. USB主控制器

+

i.MX 8M Nano SoC 的 USB 控制器为众多消费类便携设备提供了一种低成本的连接解决方案，通过提供一种数据传输机制，使 USB 设备之间的线路/总线速度可达到 480 Mbps（高速 'HS'）。

+

该 i.MX 8M Nano SoC 具有一个设置为 OTG 模式的 USB 控制器IP。要使用Micro USB / OTG 端口，拨码开关 S1 的第 5 位必须设置为开启。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+
+
+

7.13. USB OTG

+

大多数PHYTEC板提供USB OTG接口。USB OTG端口会自动作为USB设备或USB主机工作。模式取决于连接到USB OTG端口的USB硬件。例如，如果将USB大容量存储设备连接到USB OTG端口，该设备将显示为 /dev/sda 。

+
+

7.13.1. 作为USB设备

+

为了将开发板作为USB设备连接到USB主机（例如PC），您需要配置相应的USB gadget。通过USB configfs，您可以定义USB gadget的参数和功能。BSP包含作为kernel module 的USB configfs支持。

+
target:~$ modprobe libcomposite
+
+
+

例子:

+
    +

  • 首先，定义参数，例如USB Vendor和product ID，并为英语（0x409）设置信息字符串：

    • +
+
+

提示

+

为了节省时间，请复制这些命令并在脚本中执行它们

+
+
cd /sys/kernel/config/usb_gadget/
+mkdir g1
+cd g1/
+echo "0x1d6b" > idVendor
+echo "0x0104" > idProduct
+mkdir strings/0x409
+echo "0123456789" > strings/0x409/serialnumber
+echo "Foo Inc." > strings/0x409/manufacturer
+echo "Bar Gadget" > strings/0x409/product
+
+
+
    +

  • 接下来，为大容量存储 gadget 创建一个文件：

    • +
+
target:~$ dd if=/dev/zero of=/tmp/file.img bs=1M count=64
+
+
+
    +

  • 现在你可以创建你想要使用的功能：

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir functions/acm.GS0
+mkdir functions/ecm.usb0
+mkdir functions/mass_storage.0
+echo /tmp/file.img > functions/mass_storage.0/lun.0/file
+
+
+
    +

  • acm: 串行设备 gadget，创建类似 /dev/ttyGS0 的串行接口。

    • +

  • ecm: 以太网 gadget，创建以太网接口，例如 usb0

    • +

  • mass_storage: 主机可以像处理其他USB大容量存储设备一样，对设备的大容量存储进行分区、格式化和挂载。

    • +
+
    +

  • 将定义的功能绑定到配置：

    • +
+
cd /sys/kernel/config/usb_gadget/g1
+mkdir configs/c.1
+mkdir configs/c.1/strings/0x409
+echo "CDC ACM+ECM+MS" > configs/c.1/strings/0x409/configuration
+ln -s functions/acm.GS0 configs/c.1/
+ln -s functions/ecm.usb0 configs/c.1/
+ln -s functions/mass_storage.0 configs/c.1/
+
+
+
    +

  • 最后，使用以下命令启动USB gadget：

    • +
+
target:~$ cd /sys/kernel/config/usb_gadget/g1
+target:~$ ls /sys/class/udc/
+ci_hdrc.0
+target:~$ echo "ci_hdrc.0" >UDC
+
+
+

如果您的系统有多个USB设备或OTG端口，您可以将正确的端口传递给USB设备控制器（UDC）。

+
    +

  • 要停止USB gadget 并解除绑定已使用的功能，请执行：

    • +
+
target:~$ echo "" > /sys/kernel/config/usb_gadget/g1/UDC
+
+
+

USB接口在内核设备树|dt-carrierboard|.dts中配置为Host。请参见：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n264

+
+
+
+

7.14. CAN FD

+

The phyBOARD-Polis has one CAN interface supporting CAN FD. It is supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
+

提示

+

phyBOARD-Polis 具有一个通过 SPI 连接的外部 CAN FD 芯片 MCP2518FD。由于使用了SPI，限制了 CAN FD 的数据传输速率上限。

+
+
+

提示

+

在phyBOARD-Polis-i.MX8MN上，如果需要，可以通过将S5设置为ON来启用端接电阻。

+
+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。两个CAN接口显示为can0和can1。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    can0的信息将如下所示：

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+
+

警告

+

mcp2518fd SPI到CAN FD只支持从125kB/s开始的波特率。可以选择更慢的速率，但可能无法正常工作。

+
+

imx8mn-phyboard-polis.dts的设备树CAN配置: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mn-phyboard-polis.dts?h=v5.15.71_2.2.2-phy3#n125

+
+
+

7.15. 电源管理

+
+

7.15.1. CPU核心频率调节

+

i.MX 8M Nano SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。调整频率和电压被称为“动态电压和频率调整”（DVFS）。i.MX 8M Nano BSP支持DVFS功能。Linux内核提供了一个DVFS框架，允许每个CPU核心设置最小或最大频率和一个管理其运行的governor。根据使用的 i.MX 8 型号，支持几种不同的频率。

+
+

小技巧

+

尽管DVFS框架为每个CPU核心提供了频率设置，但一个CPU核心的频率更改会影响其他CPU核心。因此，所有CPU核心始终共享相同的DVFS设置。每个核心的单独DVFS设置是不可能的。

+
+
    +

  • 要获取完整列表，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    例如 i.MX 8MPlus CPU，最高可达约 1.6 GHz，则结果将是：

    +
    1200000 1600000
+
    +
    +
    • +

  • 要查询当前的频率输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

governor 会根据它们的目标自动选择这些频率中的一个。

+
    +

  • 列出所有可用的 governor，使用以下命令：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    结果是：

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative governor 与 ondemand governor 非常相似。只是它的行为有所不同，它会更保守地增减CPU速度，而不是在CPU有任何负载的瞬间就跳到最大速度。

    • +

  • ondemand （默认）根据当前系统负载在可能的CPU核心频率之间切换。当系统负载超过特定值时，它会立即提高CPU核心频率。

    • +

  • powersave 始终选择最低的CPU核心频率。

    • +

  • performance 始终选择最高的CPU核心频率。

    • +

  • userspace 允许以root身份运行的用户或用户空间程序设置特定频率（例如，设置为1600000）。输入：

    • +

  • 要查询当前的 governor，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    您通常会得到：

    +
    ondemand
+
    +
    +
    • +

  • 切换到另一个governor（例如，userspace）可以通过以下方式完成：

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • 现在你可以设置频率：

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

有关governor的更详细信息，请参阅Linux内核代码库中的Linux内核文档，路径为 Documentation/admin-guide/pm/cpufreq.rst 。

+
+
+

7.15.2. CPU核心管理

+

该 i.MX 8M Nano SoC 芯片上可以有多个处理器核心。例如，该 i.MX 8M Nano 具有 4 个 ARM 核心，可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    这里系统有四个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.15.3. 挂起到RAM

+

phyCORE-i.MX8MN 支持基本的挂起和恢复。可以使用不同的唤醒源。挂起/恢复可以通过以下方式实现：

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

要通过串行控制台唤醒，请运行

+
target:~$ echo enabled > /sys/class/tty/ttymxc2/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.16. 热管理

+
+

7.16.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.16.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 8M Nano SoC 平台上使用热管理内核 API。 i.MX 8 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个触发点。这些触发点根据CPU型号的不同而有所不同。主要区分工业版和商业版。

+ + + + + + + + + + + + + + + + + +

商业

工业

被动（警告）

85°C

95°C

严重（关机）

90°C

100°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并实施冷却措施。内核中可用的热政策（也称为thermal governor）包括：Step Wise、Fair Share、Bang Bang和Userspace。BSP中使用的默认策略是Step Wise。如果sysfs文件temp中的SoC温度值高于 trip_point_0 ，则CPU频率将设置为最低CPU频率。当SoC温度降到 trip_point_0 以下时，限制将被解除。

+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+

7.16.3. GPIO风扇

+
+

备注

+

Only GPIO fan supported.

+
+

一个GPIO控制的风扇可以连接到 phyBOARD-Polis-i.MX 8M Nano。该SoC包含一个温度传感器，该传感器被用于热频率调节。风扇无法通过内核进行控制。我们使用lmsensors和hwmon来实现这一点。lmsensors定期读取温度，并在可配置的阈值下启用或禁用风扇。对于 phyBOARD-Polis-i.MX 8M Nano，这个阈值是60°C。

+

设置可以在配置文件中进行配置：

+
/etc/fancontrol
+
+
+

风扇控制在启动时由systemd服务启动。可以通过以下方式禁用它：

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.17. 看门狗

+

PHYTEC i.MX 8M Nano 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.17.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.18. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 8M Nano 提供一次性可编程fuse，用于存储信息，例如 MAC 地址、启动配置和其他永久设置（在 i.MX 8M Nano reference manual中称为“片上 OTP 控制器 (OCOTP_CTRL)”）。以下列表摘自 i.MX 8M Nano reference manual，包括 OCOTP_CTRL 中的一些有用寄存器（基地址为0x30350000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为0x30350000

描述

OCOTP_MAC_ADDR0

9

0

0x640

包含ENET0 MAC地址的低32位

OCOTP_MAC_ADDR1

9

1

0x650

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

OCOTP_MAC_ADDR2

9

2

0x660

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 8M Nano Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.18.1. 在uBoot中读取fuse的值

+

您可以使用内存映射的shadow寄存器读取fuse寄存器。要计算内存地址，请使用以下公式计算：

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.18.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mp-libra-fpsc/head.html b/previews/271/zh_CN/bsp/imx8/imx8mp-libra-fpsc/head.html new file mode 100644 index 000000000..185559f28 --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mp-libra-fpsc/head.html @@ -0,0 +1,4042 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+ +
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + + + + + +

L-XXXXX.Xx i.MX 8M Plus FPSC +BSP ManualHead

文档标题

L-XXXXX.Xx i.MX 8M Plus FPSC +BSP Manual Head

文档类型

BSP 手册

型号

L-XXXXX.Xx

Yocto 手册

发布日期

XXXX/XX/XX

母文档

L-XXXXX.Xx i.MX 8M Plus FPSC +BSP Manual Head

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP 发布日期

BSP 状态

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 Libra i.MX 8M Plus FPSC Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads 中找到。

+
+

1.1. 支持的硬件

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-NXP-i.MX8MP-PD24.1.0 的所有Machine及其对应的Article Numbers(产品型号)： 网页.

+

如果您在“Supported Machines”一栏选择了特定的 Machine Name ，您可以查看该machine下可用的 Article Numbers 以及硬件信息的简短描述。如果您只有硬件的 Article Numbers ，您可以将 Machine Name 下拉菜单留空，仅选择您的 Article Numbers 。现在，它应该会显示您特定硬件所需的 Machine Name

+
+

1.1.1. Libra 器件

+
+../../../_images/Libra-front-components.jpg + +
+

Libra Components (top)

+
+
+
+../../../_images/Libra-back-components.jpg + +
+

Libra Components (bottom)

+
+
+
+
+
+
+

2. 开始使用

+

该 Libra i.MX 8M Plus FPSC Kit 包含预先烧写好的SD卡。它包含 phytec-qt6demo-image 镜像，可以直接用作启动盘。默认情况下，核心板上的eMMC仅烧写了U-Boot。您可以从 PHYTEC下载服务器 获取所有镜像资源。本章将解释如何将BSP镜像烧写到SD卡以及如何启动开发板。

+

有几种方法可以将镜像写入SD卡或eMMC。最为人熟知的方式是使用Linux命令行工具 dd 进行简单的顺序写入。另一种方法是使用PHYTEC的自研程序 partup ，它可以让格式化复杂系统的过程变得简单。您可以从其发布页面获取 预编译的Linux partup 二进制文件 。请阅读 partup的readme文件 来获取安装指导。

+
+

2.1. 下载镜像

+

phytec-qt6demo-image 镜像包含完整系统所需的所有必要文件，您需确保镜像中各个分区以及裸数据都会被正确写入启动盘。可以从 PHYTEC 下载服务器 下载 partup 镜像文件或者是可以使用 dd 进行烧写的 WIC 镜像。

+

从下载服务器获取 partup 镜像文件或WIC镜像：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+
+

备注

+

针对eMMC，我们建议使用partup去烧写比较大的或者是有复杂分区配置的镜像，因为它在写入速度上比 dd 更快，并且可以对闪存设备进行更灵活的配置。

+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要创建SD卡启动盘，必须要拥有Linux PC上的root权限。在选择烧写设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+
+

2.2.1. 寻找正确的设备

+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行命令：

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+

卸载所有这些分区，例如：

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

现在，SD卡已经准备好可以使用 partup 、 dd 或 bmap-tools 来写入镜像。

+
+
+

2.2.2. 使用bmap-tools

+

烧写SD卡的其中一种方法是使用 bmap-tools 。Yocto会自动为WIC镜像创建一个block map文件（ <IMAGENAME>-<MACHINE>.wic.bmap ），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host:~$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host:~$ bmaptool copy phytec-qt6demo-image-libra-imx8mp-1?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

将 <your_device> 替换为您之前找到的SD卡设备名称，并确保将文件 <IMAGENAME>-<MACHINE>.wic.bmap 与WIC镜像文件放在一起，以便bmaptool知道哪些块需要写入，哪些块需要跳过。

+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.2.3. 使用partup

+

使用partup烧写SD卡只需一个命令：

+
host:~$ sudo partup install phytec-qt6demo-image-libra-imx8mp-1?(.rootfs).partup /dev/<your_device>
+
+
+

确保将 <your_device> 替换为您之前找到的设备名称。

+

关于partup的进一步使用说明，请参阅其 官方文档 。

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 release notes 。

+
+
+

备注

+

partup 具有清除eMMC user区域中特定区域的功能，我们提供的partup程序中用该功能擦除U-Boot环境变量。这是 bmaptool 工具所无法完成的一点，如前一部分所提到的。

+

partup相较于其他烧写工具的一个主要优势是，它可以配置MMC的特定部分，比如他可以直接写入eMMCboot分区，无需调用其他命令。

+
+
+
+

2.2.4. 使用 dd

+

在卸载所有SD卡的挂载分区后，您可以烧写SD卡。

+

一些PHYTEC BSP会生成未压缩的镜像（文件名扩展名为*.wic），而另一些则生成压缩的镜像（文件名扩展名为*.wic.xz）。

+

要写入未压缩的镜像（*.wic），请使用以下命令：

+
host:~$ sudo dd if=phytec-qt6demo-image-libra-imx8mp-1?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

或者要写入压缩后的镜像（*.wic.xz），请使用以下命令：

+
host:~$ xzcat phytec-qt6demo-image-libra-imx8mp-1?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

再次确保将 <your_device> 替换为之前找到的设备名称。

+

参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

+
+
+
+

2.3. 首次启动

+ +../../../_images/SD_Card_Boot2.png +
    +

  • 插入SD卡

    • +

  • 使用 micro USB 线将开发板的 (X1) 调试USB口和主机连接起来

    • +

  • 给开发板通电

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (scarthgap).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (scarthgap).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-IMX8MP-FPSC ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-xwayland MACHINE=libra-imx8mp-1 ./phyLinux init -p imx8mp-fpsc -r BSP-Yocto-NXP-i.MX8MP-PD24.1.0
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 libra-imx8mp-1 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx8mp.bin: ARM可信固件二进制文件

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY固件镜像

    • +

  • imx-boot：由imx-mkimage编译的bootloader镜像，包括SPL、U-Boot、ARM可信固件和DDR固件。这是最终的可引导bootloader镜像。

    • +

  • fitImage: Linux内核FIT镜像

    • +

  • fitImage-its*.its

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx8mp-libra-rdk-fpsc*.dtb: Kernel device tree file

    • +

  • imx8mp-phy*.dtbo: 内核设备树overlay文件

    • +

  • phytec-qt6demo-image*.tar.gz: 根文件系统

    • +

  • phytec-qt6demo-image*.rootfs.wic.xz: 压缩的SD卡镜像

    • +
+
+
+
+
+

4. 安装操作系统

+
+

4.1. 启动模式开关 (S3)

+
+

小技巧

+

硬件修订版底板：1552.2

+
+

该 Libra 具有一个（启动源配置）开关，配有四个可单独切换的位，用于选择phyCORE-i.MX 8M Plus 默认的启动源。

+ + + + + + + + + + + +
+../../../_images/eMMC2.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses2.png +
+

内部fuse

+
+
+
+../../../_images/SPI_NOR2.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download3.png +
+

USB

+
+
+
+../../../_images/SD_Card_Boot2.png +
+

SD卡

+
+
+
+../../../_images/JTAG_Mode.png +
+

JTAG Mode

+
+
+
+
+
+

4.2. 烧写eMMC

+

为了保持文档的一致性和简洁性，假设已经配置好了TFTP服务器；所有生成的镜像（如上所列）都被复制到默认的/srv/tftp目录。如果您没有进行设置，您需要修改路径到包含镜像的目录。有关如何设置TFTP服务器和目录的说明，请参见 Setup Network Host 。

+

要从 eMMC 启动，请确保 BSP 镜像已正确烧写到 eMMC，并且 bootmode switch (S3) 设置为 eMMC。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行上述命令来检查系统启动在这种条件下是否会到影响。如果 mmcblk2p1 和 mmcblk1p1 具有相同的UUID，则会影响系统正确启动。

+
+
+

4.2.1. 从网络烧写 eMMC

+

i.MX 8M Plus 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

4.2.1.1. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

查看主机上可用的镜像文件：

+
host:~$ ls /srv/tftp
+phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.xz
+phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.bmap
+
+
+

通过网络ssh协议使用 bmaptool 命令将镜像发送到开发板的eMMC：

+
host:~$ scp /srv/tftp/phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.xz /dev/mmcblk2"
+
+
+
+
+

4.2.1.2. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

使用以下命令，通过网络将压缩或未压缩的镜像和配套的 *.bmap 文件传送到核心板并写入 eMMC：

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.* /tmp && bmaptool copy /tmp/phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.xz /dev/mmcblk2
+
+
+
+
+

4.2.1.3. 在开发板的U-Boot中通过网络烧写eMMC

+

这些步骤将展示如何通过网络更新eMMC。

+
+

小技巧

+

此步骤仅在镜像文件小于1GB的情况下会被执行成功，因为在启用OPTEE后，Bootloader中可用的RAM大小有限，不足以加载超过1GB的镜像

+
+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

解压缩您的镜像

+
host:~$ unxz /srv/tftp/phytec-headless-image-libra-imx8mp-1.rootfs.wic.xz
+
+
+

通过网络将您的镜像加载到内存中：

+
    +

  • 使用DHCP

    +
    u-boot=> dhcp phytec-headless-image-libra-imx8mp-1.rootfs.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.1 (1 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.1
+Filename 'phytec-headless-image-libra-imx8mp-1.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • 使用静态IP地址（必须先设置serverip和ipaddr）。

    +
    u-boot=> tftp ${loadaddr} phytec-headless-image-libra-imx8mp-1.rootfs.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-libra-imx8mp-1.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
+
+
+
+
+

4.2.2. 在运行的U-Boot中通过网络烧写eMMC U-Boot镜像

+

可以在U-Boot中更新U-Boot镜像imx-boot，eMMC上的U-Boot需要位于eMMC的user区域。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.3. 从USB大容量存储设备烧写eMMC

+
+

4.2.3.1. 在运行的Linux系统中从USB烧写eMMC

+

下面这些步骤展示如何在Linux系统上使用USB大容量存储设备烧写eMMC。您需要一个保存了完整镜像的U盘和一个可从SD卡启动的核心板。（例如： phytec-qt6demo-image-libra-imx8mp-1.|yocto-imageext| ）。将 bootmode switch (S3) 设置为SD卡。

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ ls /mnt
+phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.xz
+phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.bmap
+
    +
    +
    • +

  • 将镜像写入 phyCORE-i.MX 8M Plus eMMC（无分区的 MMC 设备 2）：

    +
    target:~$ bmaptool copy /mnt/phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.xz /dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    小技巧

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+

4.2.3.2. 在开发板上通过U-Boot从USB烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件小于1GB的情况下会被执行成功，因为在启用OPTEE后，Bootloader中可用的RAM大小有限，不足以加载超过1GB的镜像

+
+

下面这些步骤展示如何通过USB设备更新eMMC。将 bootmode switch (S3) 配置为SD卡并插入SD卡。给开发板上电并进入U-Boot环境。将已存储了未压缩WIC镜像的优盘插入开发板USB接口。

+

将镜像从USB设备加载到RAM中：

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 0x58000000 phytec-headless-image-|yocto-machinename|.rootfs.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write 0x58000000 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+
+

4.2.4. 从SD卡烧写eMMC

+

即使没有可用的网络，您也可以更新eMMC。为此，您需要一个位于SD卡上的镜像文件（ *.wic ）。由于镜像文件相当大，您需要在SD卡创建第三个分区。要创建新分区或扩展您的SD卡，请参见 Resizing ext4 Root Filesystem 。

+

或者，使用partup包烧写SD卡，如 Getting Started 中所述。这样就可使用SD卡的全部容量。

+
+

4.2.4.1. 在开发板的linux环境中通过SD卡烧写eMMC

+

您也可以在Linux系统中烧写eMMC。您只需要一个partup包或保存在SD卡上的WIC镜像。

+
    +

  • 检查在SD卡上保存的partup包或WIC镜像文件：

    +
    target:~$ ls
+phytec-qt6demo-image-libra-imx8mp-1.rootfs.partup
+phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.xz
+phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.bmap
+
    +
    +
    • +

  • 使用 partup 将镜像写入 phyCORE-i.MX 8M Plus 的 eMMC（MMC 设备 2 不带 分区字样）：

    +
    target:~$ partup install phytec-qt6demo-image-libra-imx8mp-1.rootfs.partup /dev/mmcblk2
+
    +
    +

    使用partup烧写的优点是可以充分利用eMMC设备的全部容量，会相应自动调整分区大小。

    +
    +

    备注

    +

    另外，也可以使用 bmaptool 工具：

    +
    target:~$ bmaptool copy phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic.xz /dev/mmcblk2
+
    +
    +

    请注意，在使用 bmaptool 烧写时，根文件系统分区并不会使用eMMC的最大容量。

    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    警告

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+

4.2.4.2. 在开发板的uboot环境中通过SD卡烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1GB的情况下有效，因为在启用OPTEE后，Bootloader中可用的RAM大小有限。如果镜像文件过大，请阅读 在开发板上通过SD卡更新eMMC 一节

+
+
    +

  • 将一个可用的镜像烧写到SD卡，并创建一个EXT4格式的第三分区。将WIC镜像（例如 phytec-qt6demo-image.rootfs.wic）复制到该分区。

    • +

  • 将 bootmode switch (S3) 配置为 SD 卡并插入 SD 卡。

    • +

  • 打开电源并进入U-Boot。

    • +

  • 加载镜像：

    +
    u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-libra-imx8mp-1.rootfs.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • 将当前mmc设备切换到eMMC：

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • 将您的WIC镜像（例如 phytec-qt6demo-image.rootfs.wic）从SD卡烧写到eMMC。这将对emmc进行分区，并将imx-boot、Image、dtb、dtbo和根文件系统复制到eMMC。

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • 关闭电源并将 bootmode switch (S3) 更改为 eMMC。

    • +
+
+
+
+
+

4.3. 烧写 SPI NOR Flash

+

phyCORE-i.MX8MP-FPSC 模块可选配SPI NOR Flash。要从SPI Flash启动，请将 bootmode switch (S3) 设置为 SPI NOR 。SPI Flash通常比较小。phyBOARD-Pollux-i.MX8MP开发套件仅配备32MB的SPI NOR Flash。只能存储bootloader及其环境变量。默认情况下，内核、设备树和文件系统会从eMMC加载。

+

SPI NOR Flash分区表在U-Boot环境变量中定义。可以通过以下命令打印：

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. 通过网络烧写SPI NOR Flash

+

SPI NOR可以包含bootloader及其环境变量。arm64的linux内核无法自行解压缩，内核镜像大小超出了phyCORE-i.MX 8M Plus 上的SPI NOR Flash的容量。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+
+

4.3.1.1. 在开发板linux环境中通过网络烧写SPI NOR Flash

+
    +

  • 将镜像从主机复制到开发板：

    +
    host:~$ scp imx-boot-libra-imx8mp-1-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • 查找要擦除的U-boot分区的块数：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除U-Boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-libra-imx8mp-1-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.1.2. 在开发板的U-Boot环境中通过网络烧写SPI NOR

+

类似于通过网络更新eMMC，请确保正确设置主机PC。IP地址需要设置为192.168.3.10，子网掩码设置为255.255.255.0，并且需要有一个可用的TFTP服务。在进行读写之前，需要对SPI NOR Flash进行枚举：

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像。确保您使用了正确的镜像文件。通过tftp加载镜像，然后将bootloader写入Flash：

    +
    u-boot=> tftp ${loadaddr} imx-boot-libra-imx8mp-1-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+

4.3.2. 从SD卡烧写SPI NOR Flash

+

SPI NOR Flash上的bootloader也可以通过SD卡进行烧写。

+
+

4.3.2.1. 在开发板的linux环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-libra-imx8mp-1-fspi.bin-flash_evk_flexspi复制到SD卡的第一个分区。

    • +

  • 挂载SD卡：

    +
    target:~$ mount /dev/mmcblk1p1 /mnt
+
    +
    +
    • +

  • 查找要擦除的U-Boot分区的块数：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除u-boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-libra-imx8mp-1-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.2.2. 在开发板的U-Boot环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-libra-imx8mp-1-fspi.bin-flash_evk_flexspi复制到SD卡的第一个分区。

    • +

  • 在进行读写操作之前，需要对SPI-NOR Flash进行枚举：

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像，请确保使用正确的镜像文件。从SD卡加载镜像，擦除并将bootloader写入flash：

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-libra-imx8mp-1-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC： L-1006e.A6 RAUC Update & Device Management Manual 。

+
+
+

4.5. EFI Boot

+

Standardboot in U-Boot also supports booting distros over efi. By default the +U-Boot will search for a bootscript first, which is used to boot our Ampliphy +distro. If it does not find any bootscript, it will search for bootable efi +applications. So for booting over efi just make sure you don't have our distro +installed.

+
+

4.5.1. Disable booting with efi

+

To disable booting with efi you have to set the doefiboot variable to 0. +Also make sure you do not have efi or efi_mgr specified in the +bootmeths environment variable.

+
u-boot=> setenv doefiboot 0
+u-boot=> env save; env save;
+
+
+
+
+

4.5.2. Switch to only efi boot

+

If you want to only boot with efi, you can set the bootmeths environment +variable to efi. Also make sure you have the doefiboot environment variable +set to 1.

+
u-boot=> setenv bootmeths efi
+u-boot=> env save; env save;
+
+
+
+
+

4.5.3. Installing a distro

+

With efi you can install and boot different distros like openSUSE, Fedora or +Debian. First you have to get the iso Image from their website. For example:

+

https://cdimage.debian.org/debian-cd/current/arm64/iso-dvd/

+

Then copy the .iso file to a usb stick for example. Make sure you select the +correct device:

+
sudo dd if=file.iso of=/dev/sdx bs=1M conv=fsync status=progress
+
+
+

Insert the USB stick into the board and boot it. GRUB will then prompt you with +a menu where you can select what to do. Here select install. Then you have to +click through the installation menu. This is relatively straightforward and +differs a bit for every distro. You can install the distro for example to emmc +(mmc 2) or sdcard (mmc 1). Make sure you do not overwrite +your U-Boot during the install. Best to choose a different medium to install to +than the U-Boot is stored on. Otherwise manual partitioning will be required. +The automatic partitioning will start at the beginning of the disk. To not +overwrite the U-Boot, use an offset of 4MiB at the beginning of the disk.

+

During the Installation of Debian you will be asked, if you want to Force the +GRUB installation to the EFI removable media path. Select no. Also select no, +when you will be asked if you want to update the NVRAM variables. Otherwise the +grub-dummy installation step will fail and you will be sent back to the +"Force GRUB installation" prompt.

+

After the installation is complete, reboot the board and remove the +installation medium (USB-stick). The board should then boot the distro you +installed.

+

If that does not happen, check if there is a boot option set for the distro. +The easiest way is with the eficonfig command.

+
u-boot=> eficonfig
+
+
+

That will open a menu. Then you can select Edit Boot Option. It will show +you the current boot options. If this is empty or you don't find your distro, +select Add Boot Option to add a new one. For debian for example you only +need to set the description and the file. You can enter whatever you want into +the description field. When you select the file field, you can select the disc +you installed the distro on and partition number one. For example +"mmc 2:1" for emmc, or "mmc 1:1" for sdcard. The file you +need to select is at EFI/debian/grubaa64.efi. After that save, quit and +reset the board. The board should then boot into debian.

+
+
+
+
+

5. 开发

+

从这个版本开始，U-Boot中的启动行为发生了变化。之前，内核和设备树是作为单独的二进制文件提供的。现在，二者将被包含在一个单一的FIT镜像二进制文件中。此外，PHYTEC ampliphy发行版的启动逻辑被移到了一个启动脚本中，该脚本本身是一个单独的FIT镜像二进制文件的一部分。要恢复到旧的启动方式，您可以执行

+
run legacyboot
+
+
+
+

备注

+

这种启动方式已被弃用，并将在下一个版本中移除。默认情况下，通过此命令启动将返回错误，因为启动分区中缺少内核和设备树。

+
+
+

5.1. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone git://git.phytec.de/u-boot-imx）

+
+
+

5.1.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-imx 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    https://github.com/phytec/linux-phytec-imx
+
    +
    +
    • +

  • 我们的 i.MX 8M Plus 内核是基于 linux-phytec-imx 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.1.2. 获取SDK

+

您可以在此处下载SDK 这里，或者使用Yocto去编译生成SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

在成功编译后，SDK安装包保存在 build/deploy*/sdk。

+
+
+

5.1.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.x.sh
+host:~$ ./phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.x.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-xwayland/5.0.x):
+You are about to install the SDK to "/opt/ampliphy-vendor-xwayland/5.0.x". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.1.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.1.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.2. 单独编译U-Boot

+
+

5.2.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本中使用的**tag**称为 v2024.04_2.0.0-phy7

    • +

  • 查看所需的 U-Boot tag：

    +
    host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2024.04_2.0.0-phy7
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.2.2. 获取所需的二进制文件

+

要编译bootloader，您需要将这些文件复制到您的 u-boot-imx 编译目录，并将其重命名以适应 mkimage 脚本：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx8mp-fpsc.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以在yocto工程目录中获取 bl31-imx8mp-fpsc.bin、tee.bin和lpddr4_*.bin：BSP Images

+

或者你可以在这里下载文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/

+
+

警告

+

确保您重命名所需的文件，以和 mkimage tool 兼容。

+
+
+
+

5.2.3. 编译bootloader

+
    +

  • 编译 flash.bin (imx-boot):

    +
    host:~/u-boot-imx$ make imx8mp-libra_defconfig
+host:~/u-boot-imx$ make flash.bin
+
    +
    +
    • +
+
+
+

5.2.4. 将bootloader烧写到块设备上

+

flash.bin 文件可以在 u-boot-imx/ 目录下找到，现在可以进行烧写。需要指定芯片特定的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

例如，烧写SD卡：

+
host:~/u-boot-imx$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+

5.2.5. 使用固定内存大小编译U-Boot

+

如果您的系统因为EEPROM中的硬件信息损坏或丢失而无法启动，您可以创建一个具有固定RAM大小的flash.bin。但您仍应联系我们支持部门以烧写正确的EEPROM数据。

+

按照步骤获取U-boot源代码，并切换到 Build U-Boot 章节说明的分支。

+

Edit the file configs/imx8mp-libra_defconfig:

+
CONFIG_TARGET_IMX8MP_LIBRA=y
+CONFIG_IMX8MP_LIBRA_RAM_SIZE_FIX=y
+# CONFIG_IMX8MP_LIBRA_RAM_SIZE_1GB=y
+# CONFIG_IMX8MP_LIBRA_RAM_SIZE_2GB=y
+# CONFIG_IMX8MP_LIBRA_RAM_SIZE_4GB=y
+
+
+

选择正确的RAM大小，确保与核心板上的贴装的器件一致，取消注释该RAM大小的行。保存更改后，按照 Build U-Boot 章节的剩余步骤进行操作。

+
+
+
+

5.3. 单独编译内核

+

内核与设备树一起打包在FIT镜像中。U-Boot已被配置为能够加载FIT镜像并引导其中包含的内核。因此，内核镜像必须打包在FIT镜像中。

+
+

5.3.1. 配置源代码

+
    +

  • 使用的 linux-phytec-imx 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v6.6.23-2.0.0-phy10

    • +

  • Check out 所需的 linux-phytec-imx 标签：

    +
    host:~$ git clone https://github.com/phytec/linux-phytec-imx
+host:~$ cd ~/linux-phytec-imx/
+host:~/linux-phytec-imx$ git fetch --all --tags
+host:~/linux-phytec-imx$ git checkout tags/v6.6.23-2.0.0-phy10
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-phytec-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-phytec-imx$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.3.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-phytec-imx$ make imx8_phytec_defconfig
+host:~/linux-phytec-imx$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-phytec-imx/arch/arm64/boot/Image.gz 找到

    • +

  • dtb文件可以在 ~/linux-phytec-imx/arch/arm64/boot/dts/freescale/imx8mp-libra-rdk-fpsc.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-phytec-imx$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.3.3. 将内核打包成FIT镜像

+

要简单地替换内核，您需要一个 image tree source (.its)文件。如果您已经使用Yocto编译了我们的BSP，可以从此处提到的目录获取its文件： BSP Images 或者您可以在这里下载该文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/

+

将 .its 文件复制到当前工作目录，创建一个指向内核镜像的链接，并使用 mkimage 创建最终的 fitImage。

+
host:~/linux-phytec-imx$ cp /path/to/yocto/deploydir/fitimage-its*.its .
+                  && ln -s arch/arm64/boot/Image.gz linux.bin
+                  && uboot-mkimage -f fitImage-its*.its fitImage
+
+
+
+
+

5.3.4. 将FIT镜像和内核模块复制到SD卡

+

FIT镜像以及内核module可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-phytec-imx$ cp fitImage /path/to/sdcard/boot/
+host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.4. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.4.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.4.2. 获取镜像

+

从我们的服务器下载imx-boot，或者从您Yocto工程中的build/deploy-ampliphy-vendor-xwayland/images/libra-imx8mp-1/路径获取。要将wic镜像烧写到eMMC，你还需要 phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic。

+
+
+

5.4.3. 开发板准备

+

将 bootmode switch (S3) 设置为 USB串行下载。同时，将 USB 端口 X5 (upper connector) 连接到主机。

+
+
+

5.4.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 (X1) 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.4.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.4.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-libra-imx8mp-1.rootfs.wic
+
+
+
+
+

5.4.7. 通过UUU工具烧写SPI NOR Flash

+

执行并给开发板上电：

+
host:~$ sudo uuu -b qspi imx-boot-libra-imx8mp-1-fspi.bin-flash_evk_flexspi
+
+
+

这将更新SPI NOR Flash上的U-Boot，但不会更新环境。您可能需要擦除旧环境，以便加载新U-Boot的默认环境：

+
u-boot=> env erase
+u-boot=> reset
+
+
+
+
+
+

5.5. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.5.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.5.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.5.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.6. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.6.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核fitimage复制到您的tftp目录中：

    +
    host:~$ cp fitImage /srv/tftp
+
    +
    +
    • +

  • 将启动脚本复制到您的tftp目录中：

    +
    host:~$ cp boot.scr.uimg /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-libra-imx8mp-1.rootfs.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.6.2. 设置网络启动的bootenv.txt文件

+

在您的tftp目录中创建一个bootenv.txt文件，并将以下变量写入其中。

+
nfsroot=/srv/nfs
+overlays=<overlayconfignames>
+
+
+

<overlayconfignames> 替换为您想要使用的设备树overlay配置名称。用#号分隔配置名称。例如：

+
overlays=conf-example-overlay1.dtbo#conf-example-overlay2.dtbo
+
+
+
+

小技巧

+

所有支持的设备树overlay文件都在 device tree 章节中。或者可以通过以下命令打印：

+
host:~$ dumpimage -l fitImage
+
+
+
+
+
+

5.6.3. 开发板上的网络设置

+

如果要自定义开发板上的以太网配置，请按照此处的说明进行操作： Network Environment Customization

+
+
+

5.6.4. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> setenv boot_targets ethernet
+u-boot=> bootflow scan -lb
+
    +
    +
    • +
+
+
+
+

5.7. 获取BSP开发中版本

+
+

5.7.1. 当前release的开发中版本

+

这些release manifest文件是为了让您访问 Yocto BSP的开发版本。它们不会在phyLinux选择菜单中显示，需要手动选择。可以使用以下命令行来完成此操作：

+
host:~$ ./phyLinux init -p imx8mp-fpsc -r BSP-Yocto-NXP-i.MX8MP-FPSC-PD25.1.y
+
+
+

这将初始化一个BSP，用于跟踪当前版本（ BSP-Yocto-NXP-i.MX8MP-PD24.1.0 ）的最新开发版本。从现在开始，在此文件夹中执行 repo sync 将从我们的Git仓库中拉取所有最新的更改：

+
host:~$ repo sync
+
+
+
+
+

5.7.2. 即将发布版本的开发中版本

+

即将发布版本的开发中版本可以通过这种方式访问。请执行以下命令，并查找一个比最新版本（ BSP-Yocto-NXP-i.MX8MP-PD24.1.0 ）的PDXX.Y数字更高的版本，并且以 .y 结尾：

+
host:~$ ./phyLinux init -p imx8mp-fpsc
+
+
+
+
+
+

5.8. 获取最新的Upstream支持

+

我们有一个使用Yocto主分支（不是NXP发布的）的manifest，他使用upstream的Linux和U-Boot。这可以用来测试最新的upstream kernel/U-Boot。

+
+

备注

+

master分支的manifest反映了最新的开发状态。有时会出现一些bug。我们会定期修复master分支。

+
+
host:~$ ./phyLinux init -p imx8mp-fpsc -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.9.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将 phytec-qt6demo-image-libra-imx8mp-1.wic 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-qt6demo-image-libra-imx8mp-1.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将 phytec-qt6demo-image-libra-imx8mp-1.wic 镜像复制到其中。然后卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-libra-imx8mp-1.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+

5.10. Switch back to legacyboot

+
+

警告

+

As we switched to standardboot with fitimage as default, legacyboot is +deprecated. We kept the option to switch back to legacyboot for this +release, but it will be removed in the future.

+
+
+

5.10.1. Changes in Yocto

+

By default, the fitImage and bootscript will be deployed into the wic.xz Image. +To switch back to legacyboot, you need to replace the fitImage and bootscript +for the kernel image and the devicetrees. They are still in the deploy +folder from the Yocto build, so you can manually copy them to the boot +partition on your device. Otherwise you can do the following changes in Yocto +to get the kernel and devicetrees deployed in the Image again.

+

First create the variable KERNEL_DEVICETREE_DEPLOY. This can be done for +example in the local.conf file in your build directory conf/local.conf. +The variable is basically a copy of the KERNEL_DEVICETREE variable that is +set in conf/machine/libra-imx8mp-1.conf in meta-phytec but the freescale +at the beginning needs to be removed, so that only the devicetree filename are +left. In the end it should look something like this:

+
KERNEL_DEVICETREE_DEPLOY = " \
+     imx8mp-phyboard-pollux-rdk.dtb \
+     imx8mp-phyboard-pollux-isp-csi1.dtbo \
+     imx8mp-phyboard-pollux-isp-csi2.dtbo \
+     imx8mp-phyboard-pollux-isi-csi1.dtbo \
+     imx8mp-phyboard-pollux-isi-csi2.dtbo \
+     imx8mp-phyboard-pollux-peb-av-10.dtbo \
+     imx8mp-phyboard-pollux-peb-wlbt-05.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2-fpdlink-port1.dtbo \
+     imx8mp-phycore-no-eth.dtbo \
+     imx8mp-phycore-no-rtc.dtbo \
+     imx8mp-phycore-no-spiflash.dtbo \
+     imx8mp-phycore-rpmsg.dtbo \
+"
+
+
+

Then add this line:

+
IMAGE_BOOT_FILES:mx8m-nxp-bsp:append = " Image oftree ${KERNEL_DEVICETREE_DEPLOY}"
+
+
+
+

备注

+

A clean might be required for this to work.

+
bitbake -c cleanall phytec-qt6demo-image
+
+
+
+

Then start the build:

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

5.10.2. Changes in U-Boot environment

+

To re-enable legacyboot set the following variable:

+
uboot=> setenv dolegacyboot 1
+uboot=> env save; env save;
+uboot=> boot
+
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 8M Plus 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Board.dts - 包含module dtsi 文件。从SoC i.MX 8M Plus 引出并在底板使用的设备也包含在此 dts 中。

    • +

  • Overlay.dtso - 根据核心板或底板上可选硬件（例如 SPI 闪存或 PEB-AV-10）的情况来启用/禁用一些功能。

    • +
+

在Linux内核的根目录下，我们的 i.MX 8 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。下面是扩展板的硬件描述。对比源码中的include，overlay通过覆盖的方式来生效。overlay也可以根据实际开发板的硬件配置来设置设备树节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/ 中。

+

libra-imx8mp-1.conf 可用的overlay文件有：

+
imx8mp-isi-csi1.dtbo
+imx8mp-isi-csi2.dtbo
+imx8mp-isp-csi1.dtbo
+imx8mp-isp-csi2.dtbo
+imx8mp-libra-peb-av-10.dtbo
+imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+imx8mp-phycore-no-eth.dtbo
+imx8mp-phycore-no-rtc.dtbo
+imx8mp-phycore-no-spiflash.dtbo
+imx8mp-phycore-rpmsg.dtbo
+imx8mp-vm016-csi1.dtbo
+imx8mp-vm016-csi1-fpdlink.dtbo
+imx8mp-vm016-csi2.dtbo
+imx8mp-vm016-csi2-fpdlink.dtbo
+imx8mp-vm017-csi1.dtbo
+imx8mp-vm017-csi1-fpdlink.dtbo
+imx8mp-vm017-csi2.dtbo
+imx8mp-vm017-csi2-fpdlink.dtbo
+
+
+

Otherwise you can show the content of a FIT image including all overlay +configs in the FIT image with this command in Linux:

+
host:~$ dumpimage -l /boot/fitImage
+
+
+

or in U-Boot:

+
u-boot=> load mmc ${mmcdev}:1 ${loadaddr} fitImage
+u-boot=> iminfo
+
+
+

可以在Linux或U-Boot环境下配置overlay。overlay是在引导命令调用后、内核加载之前生效。接下来的部分将更详细地解释配置方法。

+
+

6.2.2.1. 设置 ${overlays} 变量

+

The ${overlays} U-Boot environment variable contains a number-sign (#) +separated list of overlays that will be applied during boot. The overlays +listed in the overlays variable must be included in the FIT image. Overlays set +in the $KERNEL_DEVICETREE Yocto machine variable will automatically be added to +the FIT image.

+

The ${overlays} variable can either be set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +When desired to use the overlays variable as set manually in the U-Boot +environment, disable bootenv by setting env set no_bootenv 1 as the overlays +variable may be overwritten during the execution of the boot script. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=conf-imx8mp-libra-rdk-fpsc-peb-eval-01.dtbo#conf-imx8mp-libra-peb-av-10.dtbo
+
+
+

更改将在下次重启后生效。如果没有可用的 bootenv.txt 文件，可以直接在U-Boot环境中设置overlay变量。

+
u-boot=> setenv overlays conf-imx8mp-libra-peb-av-10.dtbo
+u-boot=> printenv overlays
+overlays=conf-imx8mp-libra-peb-av-10.dtbo
+u-boot=> boot
+
+
+

如果用户定义了 ${overlays} 变量，同时存在 bootenv.txt 文件，则需要设置 ${no_bootenv} 变量：

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays conf-imx8mp-libra-peb-av-10.dtbo
+u-boot=> boot
+
+
+

有关环境的更多信息，请参见 U-boot External Environment subsection of the +device tree overlay section。

+

We use the ${overlays} variable for overlays describing expansion boards and +cameras that can not be detected during run time. To prevent applying overlays +unset the overlays variable and set no_bootenv to anything other than 0.

+
u-boot=> env delete overlays
+u-boot=> env set no_bootenv 1
+
+
+

If desired to use the bootenv.txt file for setting U-Boot variables other than +overlays and having overlays disabled, remove the overlays definition line from +the bootenv.txt file instead of setting no_bootenv.

+
+
+

6.2.2.2. SoM Variants

+

Additional overlays are applied automatically to disable components that are not +populated on the SoM. The detection is done with the EEPROM data (EEPROM SoM +Detection) found on the SoM i2c EEPROM.

+

这取决于核心板型号是否会应用任何设备树overlay。要检查在U-Boot中运行的SoM是否会应用overlay，请运行：

+
u-boot=> env print fit_extensions
+
+
+

如果没有可用的EEPROM数据，则不加载任何设备树overlay。

+

To prevent application of the SoM variant related overlays the +${no_extensions} variable can be set to 1 in the bootloader environment:

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot外部环境

+

在Linux内核启动时，外部环境 bootenv.txt 文本文件将从MMC设备的boot分区或通过TFTP加载。该文件的主要目的是存储 ${overlays} 变量。这可以针对不同的machine在Yocto中预定义不同的overlay配置。文件的内容在meta-phytec中的Yocto recipe中的bootenv中定义： https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=scarthgap

+

该文件中也可以设置其他变量。这些变量将覆盖环境中现有的设置。但只有对boot命令后进行计算的变量生效，例如 ${nfsroot} 或 ${mmcargs}。在文件中更改其他变量将不会有作用。以网络启动的用法作为示例。

+

如果无法加载外部环境，启动过程将继续进行，并使用自带的环境变量值。

+
+
+

6.2.4. 在Linux环境下更改开发板上的U-boot环境变量

+

Libubootenv是我们镜像中包含的一个工具，用于在开发板linux上修改U-Boot环境。

+

使用以下命令打印U-Boot环境：

+
target:~$ fw_printenv
+
+
+

使用以下命令修改U-Boot环境：

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

小心

+

Libubootenv会读取配置文件中配置的环境变量。要修改的环境变量会被插入到该文件中，默认情况下使用eMMC中存储环境变量。

+

如果eMMC没有被烧写过或者eMMC环境被擦除，libubootenv将无法工作。您应该修改 /etc/fw_env.config 文件，以匹配您想要使用的环境源。

+
+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 8M Plus BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 8M Plus BSP设备树概念部分，以了解我们的 i.MX 8 BSP设备树模型。

+

以下部分概述了 i.MX 8 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 8M Plus 引脚复用

+

该 i.MX 8M Plus Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 8M Plus 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 8M Plus 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是 imx8mp-libra-rdk-fpsc.dts中UART1设备的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x140
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x140
+        >;
+};
+
+
+

字符串的第一部分 MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 指定了引脚（在这个例子中是 UART1_RXD）。字符串的第二部分（UART1_DCE_RX）是该引脚所选的复用项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部拉电阻是否被激活。在当前情况下，内部拉电阻被禁用。

+

The device tree representation for UART1 pinmuxing: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L373

+
+
+

7.2. RS232/RS485

+

phyCORE-i.MX 8M Plus 支持最多 4 个 UART 单元。在 Libra 上，UART1（调试串口）和 UART4 的 TTL 电平信号被连接到 Silicon Labs CP2105 UART 到 USB 转换IC。这个 USB 信号通过 Micro-USB 连接器 X1 输出。UART3 位于 X6（扩展连接器），为 TTL 电平信号。UART2 连接到一个多协议收发器IC，可转换为 RS-232 或 RS-485，RS-232 和 RS-485 信号位于连接器 X2 。多协议配置通过主板上的跳线 JP3 和 JP4 完成。更多信息，请参阅 phyCORE-i.MX 8M Plus/Libra 硬件手册中的 UARTs 部分。

+

对于RS-232和RS-485，使用相同的设备树节点。RS485模式可以通过ioctl TIOCSRS485 来启用。双向通讯支持也可以通过ioctl进行配置。请查看我们的小示例应用程序rs485test，该程序也包含在BSP中。需要设置跳线 JP3 和 JP4 。

+
+

7.2.1. RS232

+
    +

  • 以人类可读的格式显示终端的当前设置：

    +
    target:~$ stty -a
+
    +
    +
    • +

  • UART接口的配置可以通过stty命令完成。例如：

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • 通过简单的echo和cat，可以测试基本的通信。示例：

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

主机应打印出 "123"。

+
+
+

7.2.2. RS485

+
+

提示

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

为了方便测试，请查看linux-serial-test。这个工具会通过调用RS485的IOCTL，发送恒定的数据流。

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

有关linux-serial-test工具及其参数的更多信息，请访问此链接：linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Linux kernel文档描述了如何在C代码中调用IOCTL： https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection3.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see "test" printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final "count for this session". There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+
+
+

7.2.2.2. RS485 full-duplex

+

For full-duplex mode your connection setup should look like this:

+../../../_images/RS485_fullduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For full-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 1
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  true
+Bus termination enabled:  false
+
+
+

Also here you can do the echo test to see if sending and receiving works:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see "test" printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

To check if the full-duplex operation works, you need to use the +linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=114660, tx=118755, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=118755, tx=114660, rx err=0
+
+
+

In this example both targets will send and receive simultaneously. They will +receive for 15sec and send for 10sec. The receiver needs to receive a bit +longer, so that all sent messages will get received. Remember to start both +targets almost simultaneously. A small difference in start time is accounted +for with the -W 2 option. At the end the program will print the final +"count for this session". There you can check that all transmitted frames were +received.

+

All the test examples are target to target, but can also be done with host to +target with a USB to rs485 converter. You may need to adjust the interfaces for +commands to work on the host then.

+

The device tree representation for RS232 and RS485: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L412

+
+
+
+
+

7.3. 网络

+

Libra-i.MX 8M Plus 提供两个以太网接口。我们的核心板和底板各提供一个千兆以太网接口。

+
+

警告

+

硬件中的以太网接口命名约定（ethernet0 和 ethernet1）与Linux中的网络接口（eth0 和 eth1）不一致。因此，请注意这些差异：

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L50。

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the Libra can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L179.

+
+

7.3.1. 网络配置

+
+

7.3.1.1. U-boot网络环境

+
    +

  • 要在bootloader中查找以太网设置：

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • 在将主机设置为IP 192.168.3.10和子网掩码255.255.255.0的情况下，开发板应该返回：

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • 如果您需要进行任何更改：

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> 应该是 ipaddr、netmask、gatewayip 或 serverip 中的一个。<value> 将是所选参数的设定值。

    +
    • +

  • 您所做的更改目前是临时的。要保存这些更改：

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

在这里，您也可以将IP地址更改为DHCP，而不是使用静态IP地址。

+
    +

  • 配置：

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • 设置 TFTP 和 NFS 的路径。修改可以如下所示：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+

小技巧

+

像nfsroot和netargs这样的变量可以被U-boot外部环境重新赋值。对于网络启动，外部环境将通过tftp加载。例如，要在 bootenv.txt 文件中设置nfsroot变量，请在tftproot目录修改：

+
nfsroot=/home/user/nfssrc
+
+
+

无需在开发板上存储这些信息。请注意，U-boot外部环境对于像 ipaddr 或 serveraddr 这样的变量不起作用，因为它们在加载外部环境之前已经被设置完成。

+
+
+
+

7.3.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. 无线局域网

+

在 Libra 上，WLAN和蓝牙由PEB-WLBT-05扩展板提供。PEB-WLBT-05的 Libra 快速入门指南向您展示了如何安装PEB-WLBT-05。

+
+

小技巧

+

对于BSP版本PD22.1及更新版本，需要先激活PEB-WLBT-05 Overlay，否则PEB-WLBT-05将无法被识别。

+
target:~$ vi /boot/bootenv.txt
+
+
+

之后，bootenv.txt 文件应该如下所示（它还可以包含其他设备树overlay！）：

+
overlays=conf-imx8mp-libra-peb-wlbt-05.dtbo
+
+
+

更改将在重启后应用：

+
target:~$ reboot
+
+
+

有关设备树overlay的更多信息，请阅读 device tree 章节。

+
+

为了支持WLAN和蓝牙，我们使用来自LSR的Sterling-LWB模块。该模块支持2.4 GHz，并且可以在多种模式下运行，如客户端模式、使用WEP、WPA、WPA2加密的接入点（AP）模式等。有关该模块的更多信息，请访问 https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. 连接到WLAN网络

+

首先设置您所在国家的正确监管域：

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

你将会看到：

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

设置无线接口：

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

现在您可以扫描可用的网络：

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

您可以使用一个跨平台的客户端，名为wpa_supplicant，支持WEP、WPA和WPA2，以建立加密连接。

+

为此，请将网络凭据添加到文件 /etc/wpa_supplicant.conf 中：

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

现在可以建立连接：

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

这会得到如下输出：

+
Successfully initialized wpa_supplicant
+
+
+

The ip address is automatically configured over DHCP. For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (scarthgap).

+
+
+
+

7.3.3. 蓝牙

+

Bluetooth is supported on Libra with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section.

+

Bluetooth is connected to UART3 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

现在您可以扫描环境中的可见蓝牙设备。在默认配置下，蓝牙是不可见的。

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. 可见性

+

要激活可见性：

+
target:~$ hciconfig hci0 piscan
+
+
+

要禁用可见性：

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. 连接

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

备注

+

如果连接失败并出现错误信息：“连接失败：org.bluez.Error.Failed”，请尝试使用以下命令重新启动PulseAudio：

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC 卡

+

该 i.MX 8M Plus 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L422

+

DT configuration for the eMMC interface can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L214

+
+
+

7.5. eMMC设备

+

PHYTEC模块如phyCORE-i.MX 8M Plus 配备了eMMC存储芯片作为主要存储。eMMC设备使用多层单元（MLC）或三层单元（TLC）技术来实现存储，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 8M Plus ，并在Linux内核中作为块设备表示，如SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.5.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），该层负责处理原始MLC或TLC的磨损均衡、块管理和错误更正码（ECC）。这需要定期执行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 通过以下命令使能BKOPS_EN：

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.5.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 8M Plus SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.5.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
+
+

7.5.5. 启用伪SLC模式

+

eMMC设备使用 MLC或TLC 来存储数据。与NAND Flash中使用的SLC相比，MLC或TLC在成本更低的情况下，可靠性较低且错误率较高。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. 擦除设备

+

可以直接擦除eMMC设备，而不是通过写零覆盖。eMMC块管理算法将擦除底层的MLC或TLC，或者将这些块标记为可丢弃。设备上的数据将丢失，并将被读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.5.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 8M Plus 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.5.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

下表是 i.MX 8M Plus SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.6. SPI主设备

+

i.MX 8M Plus 控制器包含一个 FlexSPI 和一个 ECSPI IP 核。FlexSPI 主控制器支持两个 SPI 通道，最多可连接 4 个设备。每个通道支持单通道/双通道/四通道/八通道模式的数据传输（1/2/4/8 条数据线）。ECSPI 控制器支持 3 个 SPI 接口，每个接口都有一个专用的CS（chip select）引脚。由于CS也可通过 GPIO 实现，因此每个通道上可以连接多个设备。

+
+

7.6.1. SPI NOR 烧写

+

phyCORE-i.MX 8M Plus 配备有一个 QSPI NOR Flash，该 Flash 连接到 i.MX 8M Plus 的 FlexSPI 接口。QSPI NOR Flash 可用于启动。有关烧写和启动模式设置的详细信息，请参见不同的章节。由于 SPI NOR Flash 的空间有限，因此仅可存储bootloader。默认情况下，内核、设备树和根文件系统来自 eMMC。

+

bootloader程序通过EEPROM数据检测是否安装了SPI Flash。如果没有安装SPI Flash，则在启动期间应用设备树overlay，通过扩展命令禁用SPI Flash设备树节点。如果没有可用的EEPROM数据，SPI NOR Flash节点将始终启用。有关更多信息，请参阅设备树overlay部分。

+

bootloader程序还可以通过内核的mtdparts启动参数修改设备树，将SPI MTD分区表传递给Linux。BSP中的默认分区布局设置为：

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

这是一个预定义的bootloader环境变量，可以在运行时更改。从Linux用户空间，可以通过/dev/mtd<N>设备访问NOR Flash分区，其中<N>是与要访问的NOR Flash分区相关联的MTD设备编号。要找到分区的正确MTD设备编号，请在目标上运行：

+
root@libra-imx8mp-1:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

它列出了所有MTD设备及其对应的分区名称。闪存节点在模块DTS中的SPI主节点内定义。SPI节点包含连接到此SPI总线的所有设备，在这种情况下只有SPI NOR Flash。

+

设备树中SPI主节点的定义可以在这里找到：

+

https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L76

+
+
+
+

7.7. GPIOs

+

Libra 具有一组专门用于GPIO的引脚。这些引脚直接连接到 i.MX 8M Plus 引脚，并被复用为 GPIO。它们可以直接在 Linux 用户空间中使用。处理器将其 GPIO 组织为5个GPIO组（GPIO1 – GPIO5），每个组包含 32 个GPIO。gpiochip0、gpiochip32、gpiochip64、gpiochip96 和 gpiochip128 是这些内部 i.MX 8M Plus GPIO 组 GPIO1 – GPIO5 的 sysfs 表示。

+

GPIO被标识为GPIO<X>_<Y>（例如：GPIO5_07）。<X>表示GPIO Bank，从1计数到5，而<Y>表示该Bank内的GPIO。<Y>从0计数到31（每个bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo -c gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如从gpiochip0的GPIO 20）：

    +
    target:~$ gpioget -c gpiochip0 20
+
    +
    +
    • +

  • 将gpiochip0上的GPIO 20的值设置为0并退出工具：

    +
    target:~$ gpioset -z -c gpiochip0 20=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <line=value>...
+
+Set values of GPIO lines.
+
+Lines are specified by name, or optionally by offset if the chip option
+is provided.
+Values may be '1' or '0', or equivalently 'active'/'inactive' or 'on'/'off'.
+
+The line output state is maintained until the process exits, but after that
+is not guaranteed.
+
+Options:
+      --banner            display a banner on successful startup
+  -b, --bias <bias>       specify the line bias
+                  Possible values: 'pull-down', 'pull-up', 'disabled'.
+                  (default is to leave bias unchanged)
+      --by-name           treat lines as names even if they would parse as an offset
+  -c, --chip <chip>       restrict scope to a particular chip
+  -C, --consumer <name>   consumer name applied to requested lines (default is 'gpioset')
+  -d, --drive <drive>     specify the line drive mode
+                  Possible values: 'push-pull', 'open-drain', 'open-source'.
+                  (default is 'push-pull')
+  -h, --help              display this help and exit
+  -l, --active-low        treat the line as active low
+  -p, --hold-period <period>
+                  the minimum time period to hold lines at the requested values
+  -s, --strict            abort if requested line names are not unique
+  -t, --toggle <period>[,period]...
+                  toggle the line(s) after the specified period(s)
+                  If the last period is non-zero then the sequence repeats.
+      --unquoted  don't quote line names
+  -v, --version           output version information and exit
+  -z, --daemonize set values then detach from the controlling terminal
+
+Chips:
+    A GPIO chip may be identified by number, name, or path.
+    e.g. '0', 'gpiochip0', and '/dev/gpiochip0' all refer to the same chip.
+
+Periods:
+    Periods are taken as milliseconds unless units are specified. e.g. 10us.
+    Supported units are 's', 'ms', and 'us'.
+
+*Note*
+    The state of a GPIO line controlled over the character device reverts to default
+    when the last process referencing the file descriptor representing the device file exits.
+    This means that it's wrong to run gpioset, have it exit and expect the line to continue
+    being driven high or low. It may happen if given pin is floating but it must be interpreted
+    as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.7.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用 CONFIG_GPIO_SYSFS 后才能支持。要在menuconfig中使 CONFIG_GPIO_SYSFS 可见，必须首先启用选项 CONFIG_EXPERT 。

+

您也可以将此选项添加到您在 Linux 内核源代码 arch/arm64/configs/ 目录下使用的 defconfig 中。例如，我们基于 NXP 的BSP版本，这个defconfig可以是 imx8_phytec_distro.config

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+
+
+
+

7.8. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

这里的 LED 灯包括蓝色的 mmc、绿色的 心跳和红色的 emmc，它们都在 Libra 上。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L255

+
+
+

7.9. I²C总线

+

该 i.MX 8M Plus 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 8M Plus 的I²C模块。 本节描述了我们 Libra 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

General I²C1 bus configuration (e.g. imx8mp-phycore-fpsc.dtsi): +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L113

+

General I²C2 bus configuration (e.g. imx8mp-libra-rdk-fpsc.dts) +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L239

+
+
+

7.10. EEPROM

+

在 phyCORE-i.MX8MP-FPSC 上贴了一个 i2c 接口的 EEPROM 存储。它有两个地址。主 EEPROM 空间（总线：I2C-0 地址：0x51）可以通过 Linux 中的 sysfs 接口访问。主 EEPROM 的前 256 字节和 ID 页（总线：I2C-0 地址：0x59）用于板检测，不可修改。因此，ID 页不能通过 sysfs 接口访问。覆盖保留空间将导致启动问题。

+
+

备注

+

如果您删除了保留的EEPROM空间数据，请联系我们的支持团队！

+
+
+

7.10.1. phyCORE-i.MX8MP-FPSC 上的I2C EEPROM

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

phyCORE-i.MX8MP-FPSC SoM上的I2C EEPROM连接到I2C-0总线的I2C地址0x51。可以直接对该设备进行读写操作：

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

要用零填充4KiB的EEPROM（总线：I2C-0 地址：0x51），并保留EEPROM数据，请使用：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM 检测

+

在 phyCORE-i.MX8MP-FPSC 上配置的I2C EEPROM具有一个可通过I2C地址0x59在i2c0上寻址的独立ID页面，以及一个可通过I2C地址0x51在i2c0上寻址的正常区域。PHYTEC使用这个32字节的数据区域来存储关于SoM的信息，包括PCB版本和配置。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果EEPROM ID页面数据和正常区域的前256个字节被删除，bootloader程序将回退到 phyCORE-i.MX8MP-FPSC Kit RAM设置，即 2GiB RAM。

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

使用API修订版2数据格式烧写的核心板将在早期启动阶段打印出有关模块的信息。

+

DT representation, e.g. in phyCORE-i.MX 8M Plus file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L201

+
+
+
+

7.11. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC唤醒alarm

+

可以从实时时钟（RTC）发出中断以唤醒系统。该格式使用Unix纪元时间，即自1970年1月1日UTC午夜以来的秒数。要在从挂起到RAM状态后的4分钟唤醒系统，请输入：

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

备注

+

内部唤醒alarm时间将被向上舍入到下一个分钟，因为alarm功能不支持秒。

+
+
+
+

7.11.2. RTC参数

+

实时时钟（RTC）具有一些功能，可以通过 hwclock 工具进行读取和设置。

+
    +

  • 我们可以通过以下方式检查RTC支持的功能：

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    这个值的含义在内核中进行了编码，每个位的定义为：

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • 我们可以通过以下方式检查RTC BSM（Backup Switchover Mode 备份切换模式）：

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • 我们可以通过以下方式设置RTC BSM：

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    BSM位的定义为：

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    小技巧

    +

    您应该将BSM模式设置为DSM或LSM，以便在初始电源不可用时，RTC可以切换到备用电源。请查看 RV-3028 RTC的Datasheet，以了解LSM（电平切换模式）和DSM（直接切换模式）这两个定义的工作模式。

    +
    +
    • +
+

DT representation for I²C RTCs: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L208

+
+
+
+

7.12. USB主控制器

+

i.MX 8M Plus SoC的USB控制器为众多消费类便携设备提供了一种低成本的连接解决方案，实现USB设备之间的数据传输，传输速度可达4 Gbit/s（超高速'SS'）。USB子系统具有两个独立的USB控制器。这两个控制器都能够作为USBDevice或USB Host使用。每个核心都连接到一个USB 3.0物理层（PHY）。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+

DT representation for USB Host: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L380

+
+
+

7.13. CAN FD

+

The Libra has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。两个CAN接口显示为can0和can1。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    can0的信息将如下所示：

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+
+

警告

+

mcp2518fd SPI到CAN FD只支持从125kB/s开始的波特率。可以选择更慢的速率，但可能无法正常工作。

+
+

Device Tree CAN configuration of imx8mp-libra-rdk-fpsc.dts: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L203

+
+
+

7.14. PCIe

+

phyCORE-i.MX 8M Plus 具有一个 Mini-PCIe 插槽。一般来说，PCIe 会自动检测总线上的新设备。在连接设备并启动系统后，您可以使用命令 lspci 查看所有被识别的 PCIe 设备。

+
    +

  • 输入：

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • 你将收到：

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

在这个例子中，PCIe设备是 英特尔 WiFi Link 5100 。

+

对于PCIe设备，您必须在内核配置中启用正确的驱动程序。例如，这款WLAN卡是由英特尔制造的。必须启用的驱动程序选项名为 CONFIG_IWLWIFI ，可以在内核配置中的 Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimate 下找到。

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • linux-imx的表示为：virtual/kernel

      • +
    +
    • +
+

对于某些设备，如WLAN卡，需要额外的二进制固件文件。这些固件文件必须放置在 /lib/firmware/ 目录中，才能使用该设备。

+
    +

  • 输入：

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • 例如，如果您尝试启动网络接口：

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • 您将在串口控制台上获得以下输出：

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

小技巧

+

某些PCIe设备，例如以太网卡，即使没有从 /lib/firmware/ 加载固件文件，也可能正常工作，而你收到了如上输出第一行所示的错误消息。这是因为一些制造商在板卡本身提供了固件作为后备。在这种情况下，设备的行为和输出在很大程度上依赖于制造商的固件。

+
+

Device Tree PCIe configuration of imx8mp-libra-rdk-fpsc.dts: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L345

+
+
+

7.15. 音频

+

支持的播放设备包括HDMI和PEB-AV-10连接器上的TI TLV320AIC3007音频编解码器（CODEC）IC。在AV连接器上，有一个符合OMTP标准的3.5mm耳机插孔和一个8针排针。8针排针包含单声道扬声器、耳机和line-in信号。

+
+

备注

+

使用PEB-AV-10连接器进行显示输出时，不支持通过HDMI作为音频输出。音频输出设备必须与视频输出设备匹配。

+
+

要检查您的声卡驱动程序是否正确加载以及设备名称，请输入以下命令以查看播放设备：

+
target:~$ aplay -L
+
+
+

或输入录音设备：

+
target:~$ arecord -L
+
+
+
+

7.15.1. Alsamixer

+

要检查声卡的功能，请输入：

+
target:~$ alsamixer
+
+
+

您应该会看到很多选项，因为音频IC具有许多可以测试的功能。通过SSH打开alsamixer的图形界面比通过调试串口打开更易于使用。所有混音点都有单声道或立体声增益控制。"MM"表示该功能被静音（左右输出均为静音），可以通过按' m '切换。您还可以通过按' < ' 左和 ' > '切换右声道输出。使用 tab 键，您可以在播放和录音控制之间切换。

+
+
+

7.15.2. 恢复默认音量

+

一些默认设置存储在 /var/lib/alsa/asound.state 中。您可以使用以下命令保存当前的alsa设置：

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

您可以通过以下方式恢复已保存的alsa设置：

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.15.3. ALSA配置

+

我们的BSP附带一个ALSA配置文件 /etc/asound.conf 。

+

ALSA配置文件可以根据需要进行编辑或删除，它并不是ALSA正常工作所必需的。

+
target:~$ vi /etc/asound.conf
+
+
+

要将PEB-AV-10设置为输出，请将 playback.pcm 从 "dummy" 设置为 "pebav10":

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

如果听不到声音，请将播放设备更改为软件音量控制播放设备，将 playback.pcm 设置为相应的软音量播放设备，例如“softvol_pebav10”。使用alsamixer控制来调整音量级别。

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.15.4. PulseAudio 配置

+

对于使用 Pulseaudio 的应用程序，请检查可用的音频输出设备：

+
target:~$ pactl list short sinks
+
+
+

要选择输出设备，请输入：

+
target:~$ pactl set-default-sink <sink_number>
+
+
+
+
+

7.15.5. 播放

+

运行speaker-test以检查播放功能：

+
target:~$ speaker-test -c 2 -t wav
+
+
+

要播放简单的音频流，您可以使用aplay。例如，要播放ALSA测试音频：

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

要播放其他格式，例如mp3，您可以使用Gstreamer：

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.15.6. 录音

+

arecord 是一个命令行工具，用于录制音频流，默认输入源为线路输入。要选择不同的音频源，可以使用 alsamixer。例如，打开 右侧 PGA 混音器 Mic3R 和 左侧 PGA 混音器 Mic3R，以便通过 3.5mm 插孔录制来自 TLV320 编解码器的麦克风输入音频。

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

提示

+

由于播放和录音共享硬件接口，因此无法在同时进行播放和录音操作时使用不同的采样率和格式。

+
+

Device Tree Audio configuration: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L58

+
+
+
+

7.16. 视频

+
+

7.16.1. 视频与Gstreamer

+

默认情况下，BSP安装了一个示例视频，路径为 /usr/share/qtphy/videos/ 。可以使用以下命令之一开始视频播放：

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.17. 显示

+

该 Libra 支持多达3种不同的显示输出。可以同时使用两种。下表显示了不同接口所需的扩展板和设备树overlay。

+ + + + + + + + + + + + + + + + + + + + + +

接口

扩展板

设备树overlay

HDMI

Libra

不需要overlay（默认启用）

LVDS0

PEB-AV-10

imx8mp-libra-peb-av-10.dtbo （默认加载）

LVDS1

Libra

如果使用PEB-AV-10 overlay，则禁用

+
+

备注

+
    +

  • 在更改Weston输出时，请确保音频输出也相匹配。

    • +

  • LVDS0 (使用PEB-AV-10扩展) 和 LVDS1 (板载) 不能同时使用。

    • +
+
+

HDMI在设备树中始终启用。其他接口可以通过设备树overlay进行启用。

+

默认启用的接口是HDMI和LVDS0（PEB-AV-010）。我们的 PEB-AV-10 支持10英寸edt,etml1010g0dka显示屏。

+
+

备注

+

当前的显示驱动程序将连接到LVDS的LCD的像素时钟限制为74.25MHz（或其分频）。如果这满足不了您的需求，请联系支持团队以获得进一步的帮助。

+
+
+

7.17.1. Weston 配置

+

为了让Weston正确的显示，需要进行正确的配置。这将在/etc/xdg/weston/weston.ini中完成。

+
+

7.17.1.1. 单一显示器

+

在我们的BSP中，默认的Weston输出设置为HDMI。

+
[output]
+name=HDMI-A-1
+mode=preferred
+
+[output]
+name=LVDS-1
+mode=off
+
+
+

当使用LVDS0（PEB-AV-10）作为输出时，将HDMI-A-1的输出模式设置为off，将LVDS-1的输出模式设置为current。

+
[output]
+name=HDMI-A-1
+mode=off
+
+[output]
+name=LVDS-1
+mode=current
+
+
+

如果您想使用LVDS1（板载），则需要去掉overlay。请从bootenv.txt中移除imx8mp-phyboard-pollux-peb-av-xxx.dtbo。

+
+
+

7.17.1.2. 双显示器

+
+

备注

+

对于双显示和三显示输出，您无法同时使用LVDS1（板载）和HDMI。

+
+

在HDMI和LVDS0（PEB-AV-10）的双屏模式下进行双显示时，两个模式必须设置为：

+
[output]
+name=HDMI-A-1
+mode=preferred
+
+[output]
+name=LVDS-1
+mode=current
+
+
+
+
+
+

7.17.2. Qt Demo

+

使用 phytec-qt6demo-image 时，Weston会在启动时启动。我们的Qt6 DEMO应用程序名为“qtphy”，可以通过以下方式停止：

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • 要重新开始Demo，请运行：

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • 要禁用Demo的自动启动，请运行：

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • 要启用Demo的自动启动，请运行：

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston可以通过以下方式停止：

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

备注

+

在关闭Weston之前，必须先关闭Qt Demo。

+
+
+
+

7.17.3. 背光控制

+

如果LCD连接到PHYTEC开发板，可以通过Linux内核的sysfs接口控制其背光。系统中所有可用的背光设备可以在文件夹/sys/class/backlight中找到。读取相应的文件并向其写入数据可以控制背光。

+
+

备注

+

一些具有多显示的开发板在 /sys/class/backlight 有多个背光控制。比如：backlight0和backlight1

+
+
    +

  • 例如，要获取最大亮度级别（max_brightness），请执行：

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    有效的亮度值范围是 0 到 <max_brightness>。

    +
    • +

  • 要获取当前亮度级别，请输入：

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • 写入文件brightness以更改亮度：

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    例如，关闭背光。

    +

    有关所有文件的文档，请参见 https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight。

    +
    • +
+

Device tree description of LVDS-1 and HDMI can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L294 +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L218

+

The device tree of LVDS-0 on PEB-AV-10 can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L133

+
+
+
+

7.18. 电源管理

+
+

7.18.1. CPU核心频率调节

+

i.MX 8M Plus SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。调整频率和电压被称为“动态电压和频率调整”（DVFS）。i.MX 8M Plus BSP支持DVFS功能。Linux内核提供了一个DVFS框架，允许每个CPU核心设置最小或最大频率和一个管理其运行的governor。根据使用的 i.MX 8 型号，支持几种不同的频率。

+
+

小技巧

+

尽管DVFS框架为每个CPU核心提供了频率设置，但一个CPU核心的频率更改会影响其他CPU核心。因此，所有CPU核心始终共享相同的DVFS设置。每个核心的单独DVFS设置是不可能的。

+
+
    +

  • 要获取完整列表，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    例如 i.MX 8MPlus CPU，最高可达约 1.6 GHz，则结果将是：

    +
    1200000 1600000
+
    +
    +
    • +

  • 要查询当前的频率输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

governor 会根据它们的目标自动选择这些频率中的一个。

+
    +

  • 列出所有可用的 governor，使用以下命令：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    结果是：

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative governor 与 ondemand governor 非常相似。只是它的行为有所不同，它会更保守地增减CPU速度，而不是在CPU有任何负载的瞬间就跳到最大速度。

    • +

  • ondemand （默认）根据当前系统负载在可能的CPU核心频率之间切换。当系统负载超过特定值时，它会立即提高CPU核心频率。

    • +

  • powersave 始终选择最低的CPU核心频率。

    • +

  • performance 始终选择最高的CPU核心频率。

    • +

  • userspace 允许以root身份运行的用户或用户空间程序设置特定频率（例如，设置为1600000）。输入：

    • +

  • 要查询当前的 governor，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    您通常会得到：

    +
    ondemand
+
    +
    +
    • +

  • 切换到另一个governor（例如，userspace）可以通过以下方式完成：

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • 现在你可以设置频率：

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

有关governor的更详细信息，请参阅Linux内核代码库中的Linux内核文档，路径为 Documentation/admin-guide/pm/cpufreq.rst 。

+
+
+

7.18.2. CPU核心管理

+

该 i.MX 8M Plus SoC 芯片上可以有多个处理器核心。例如，该 i.MX 8M Plus 具有 4 个 ARM 核心，可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    这里系统有四个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.18.3. 挂起到RAM

+

phyCORE-i.MX8MP-FPSC 支持基本的挂起和恢复。可以使用不同的唤醒源。挂起/恢复可以通过以下方式实现：

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

要通过串行控制台唤醒，请运行

+
target:~$ echo enabled > /sys/class/tty/ttymxc0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.19. 热管理

+
+

7.19.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.19.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 8M Plus SoC 平台上使用热管理内核 API。 i.MX 8 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个触发点。这些触发点根据CPU型号的不同而有所不同。主要区分工业版和商业版。

+ + + + + + + + + + + + + + + + + +

商业

工业

被动（警告）

85°C

95°C

严重（关机）

90°C

100°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并实施冷却措施。内核中可用的热政策（也称为thermal governor）包括：Step Wise、Fair Share、Bang Bang和Userspace。BSP中使用的默认策略是Step Wise。如果sysfs文件temp中的SoC温度值高于 trip_point_0 ，则CPU频率将设置为最低CPU频率。当SoC温度降到 trip_point_0 以下时，限制将被解除。

+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+

7.19.3. GPIO风扇

+
+

备注

+

Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan +to GPIO fan due to availability. The PWM fan will not be supported +anymore and will not function with the new release.

+
+

一个GPIO控制的风扇可以连接到 Libra-i.MX 8M Plus。该SoC包含一个温度传感器，该传感器被用于热频率调节。风扇无法通过内核进行控制。我们使用lmsensors和hwmon来实现这一点。lmsensors定期读取温度，并在可配置的阈值下启用或禁用风扇。对于 Libra-i.MX 8M Plus，这个阈值是60°C。

+

设置可以在配置文件中进行配置：

+
/etc/fancontrol
+
+
+

风扇控制在启动时由systemd服务启动。可以通过以下方式禁用它：

+
target:~$ systemctl disable fancontrol
+
+
+

The device tree description of GPIO Fan can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L35

+
+
+
+

7.20. 看门狗

+

PHYTEC i.MX 8M Plus 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.20.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.21. snvs电源按键

+

连接到开关按钮的 X_ONOFF 引脚可以长按以触发关机，而无需软件干预，或用于唤醒系统以退出挂起状态。使用 snvs_pwrkey 驱动程序时，当按下按钮时，KEY_POWER 事件也会报告给用户空间。默认情况下，systemd 被配置为忽略此类事件。关机而无需软件干预的功能以及从挂起状态唤醒的功能未被配置。可以在 /etc/systemd/logind.conf 中配置按下开/关按钮时通过 systemd 触发关机，配置方法如下：

+
HandlePowerKey=poweroff
+
+
+
+
+

7.22. NPU

+

i.MX 8M Plus SoC包含一个高达2.3 TOPS的人工智能运算加速器。有关NPU的信息，请参考我们最新的phyCORE-i.MX 8M Plus AI套件指南，该指南可以在phyCORE-i.MX 8M Plus 下载部分找到：L-1015e.A1 phyCORE-i.MX 8M Plus AI Kit Guide

+
+
+

7.23. ISP

+

i.MX 8M Plus SoC包含一个图像信号处理器（ISP）。有关更多信息，请参阅|sbc| i.MX 8M Plus 文档中的使用ISP部分。

+
+
+

7.24. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 8M Plus 提供一次性可编程fuse，用于存储信息，例如 MAC 地址、启动配置和其他永久设置（在 i.MX 8M Plus reference manual中称为“片上 OTP 控制器 (OCOTP_CTRL)”）。以下列表摘自 i.MX 8M Plus reference manual，包括 OCOTP_CTRL 中的一些有用寄存器（基地址为0x30350000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为0x30350000

描述

OCOTP_MAC_ADDR0

9

0

0x640

包含ENET0 MAC地址的低32位

OCOTP_MAC_ADDR1

9

1

0x650

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

OCOTP_MAC_ADDR2

9

2

0x660

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 8M Plus Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.24.1. 在uBoot中读取fuse的值

+

您可以使用内存映射的shadow寄存器读取fuse寄存器。要计算内存地址，请使用以下公式计算：

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.24.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+
+

8. i.MX 8M Plus M7 Core

+

除了Cortex-A53核心外，SoC中还集成了一个Cortex-M7 Core 作为MCU。我们的Yocto-Linux-BSP在A53核心上运行，而 M7 Core 可以作为辅助CPU，用于使用裸机或RTOS固件执行额外任务。两种核心都可以访问相同的外设，因此外设的使用需要在 M7 Core 的固件或Linux操作系统的设备树中进行限制。本节将描述如何编译固件示例以及如何在 Libra 上运行它们。

+

Libra 目前由 NXP MCUXpresso SDK 和 Zephyr 项目支持。本节仅描述 NXP MCUXpresso SDK，因为目前 MCUXpresso SDK 支持的功能更多。

+

如果您想在Zephyr项目中使用 M7 Core ，请参考Zephyr项目文档：

+ +
+

8.1. 获取固件示例

+

固件可以使用NXP MCUxpresso SDK和兼容的编译工具链通过命令行工具进行编译。

+
+

8.1.1. 获取源代码

+

MCUX SDK以及 i.MX 8M Plus 的示例可以从PHYTEC的GitHub页面获取：

+ +
    +

  1. 通过west初始化MCUX SDK：

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    这将创建一个 mcuxsdk 目录，并在其中包含 mcux-sdk 仓库。mcux-sdk-phytec-examples 仓库将自动克隆到 mcuxsdk 目录中。给定的参数 <VERSION> 是 mcux-sdk 仓库的分支名称，代表 MCUX SDK 版本。要获取最新的测试版本，您可以使用 2.13.0。

    +
    +

    备注

    +

    west 是一个仓库管理工具，也是 Zephyr 项目的一部分。要安装 west，您可以使用 pip。在这个示例中，west 被安装在一个 Python 虚拟环境中:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. 更新依赖项：

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    目录 examples-phytec 包含了所有移植并测试过的示例，适用于 Libra 和版本为 2.13.0 的 MCUX。

    +

    要编译固件，需要一个编译器工具链和make/cmake。GNU ARM 嵌入式工具链可能在您的主机linux发行版的仓库中可用，例如Ubuntu。

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    编译器工具链也可以直接从 https://developer.arm.com/ 获取。在解压缩文件后，必须将 ARMGCC_DIR 添加到环境变量中，例如，对于位于主目录中的 ARM toolchain 10-2020-q4-major 版本：

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. 编译固件

+

要编译PHYTEC示例，需要先设置环境

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

编译固件的脚本位于 <sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc。每个可运行的内存位置都有相应的编译脚本，例如：

+
host:~$ ./build_release.sh
+
+
+

要编译运行在 M7 Core 的 TCM 上的固件。输出将放置在 armgcc 目录下的 release/ 中。.bin 文件可以在 U-Boot 中运行，而 .elf 文件可以在 Linux 中运行。

+

要编译在DRAM上运行的固件，请运行脚本build_ddr_release。例如。

+
host:~$ ./build_ddr_release.sh
+
+
+

输出将放置在armgcc目录下的ddr_release/中。.bin文件可以在U-Boot中运行，而.elf文件可以在Linux中运行。

+
+
+
+

8.2. 运行 M7 Core 示例

+

有两种方法可以运行 M7 Core 的固件，在Linux中使用Remoteproc以及在U-Boot。

+

要接收调试信息，请在您的主机PC上启动您喜欢的终端软件（例如Minicom、Tio或Tera Term），并将其配置为115200波特率、8个数据位、无奇偶校验和1个停止位（8n1），且不使用握手。

+

一旦Micro USB电缆连接到 Libra 上的USB调试端口，就会注册两个ttyUSB设备。一个打印来自A53核心的调试UART的消息，另一个打印来自 M7 Core 的调试UART的消息。

+
+

8.2.1. 从U-Boot运行示例

+

要使用bootloader U-Boot加载固件，可以使用bootaux命令：

+
    +

  1. 准备一张烧写了BSP镜像的SD卡

    2. +

  2. 将生成的 .bin 文件复制到 SD 卡的第一个分区

    3. +

  3. 通过按任意键停止自动启动

    4. +

  4. 根据固件类型输入命令：

    5. +
+

对于在 M7 Core 的TCM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

用于在DRAM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

程序的输出应显示在 M7 Core 的调试UART上。

+
+
+

8.2.2. 通过Remoteproc在Linux上运行示例

+

Remoteproc是一个模块，允许您在运行时从Linux控制 M7 Core 。可以加载为TCM编译的固件，并可以启动或停止执行。要使用Remoteproc，需要设置设备树Overlay：

+

在开发板的/boot目录中编辑bootenv.txt文件，添加 conf-imx8mp-phycore-fpsc-rpmsg.dtbo ：

+
overlays=conf-imx8mp-phycore-fpsc-rpmsg.dtbo
+
+
+

重启目标并在U-Boot中执行:

+
u-boot=> run prepare_mcore
+
+
+

M7 Core 的固件 .elf 文件可以在 /lib/firmware 下找到。要加载固件，请输入：

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

要加载不同的固件，M7 Core 需要停止：

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

备注

+

在开发板上找到的 /lib/firmware 中的例子来自NXP的Yocto层meta-imx。要使用您通过MCUX SDK自己编译的样本，请在编译后将它们复制到开发板的 /lib/firmware 中。

+
+
+ +
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.html b/previews/271/zh_CN/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.html new file mode 100644 index 000000000..5e14291d9 --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.html @@ -0,0 +1,243 @@ + + + + + + + + + Libra i.MX 8M Plus FPSC Manuals — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

Libra i.MX 8M Plus FPSC Manuals

+ +
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mp/head.html b/previews/271/zh_CN/bsp/imx8/imx8mp/head.html new file mode 100644 index 000000000..06fd3bf36 --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mp/head.html @@ -0,0 +1,4076 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + + + + + +

L-1017e.Ax i.MX 8M Plus BSP +ManualHead

文档标题

L-1017e.Ax i.MX 8M Plus BSP 手册模板

文档类型

BSP 手册

型号

L-1017e.Ax

Yocto 手册

发布日期

XXXX/XX/XX

母文档

L-1017e.Ax i.MX 8M Plus BSP 手册模板

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP 发布日期

BSP 状态

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 phyCORE-i.MX8M Plus Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads 中找到。

+
+

1.1. 支持的硬件

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-NXP-i.MX8MP-PD24.1.0 的所有Machine及其对应的Article Numbers(产品型号)： 网页.

+

如果您在“Supported Machines”一栏选择了特定的 Machine Name ，您可以查看该machine下可用的 Article Numbers 以及硬件信息的简短描述。如果您只有硬件的 Article Numbers ，您可以将 Machine Name 下拉菜单留空，仅选择您的 Article Numbers 。现在，它应该会显示您特定硬件所需的 Machine Name

+
+

1.1.1. phyBOARD-Pollux 器件

+
+../../../_images/phyBOARD-Pollux-front-components.jpg + +
+

phyBOARD-Pollux 器件图（顶部）

+
+
+
+../../../_images/phyBOARD-Pollux-back-components.jpg + +
+

phyBOARD-Pollux 器件图（底部）

+
+
+
+
+
+
+

2. 开始使用

+

该 phyCORE-i.MX8M Plus Kit 包含预先烧写好的SD卡。它包含 phytec-qt6demo-image 镜像，可以直接用作启动盘。默认情况下，核心板上的eMMC仅烧写了U-Boot。您可以从 PHYTEC下载服务器 获取所有镜像资源。本章将解释如何将BSP镜像烧写到SD卡以及如何启动开发板。

+

有几种方法可以将镜像写入SD卡或eMMC。最为人熟知的方式是使用Linux命令行工具 dd 进行简单的顺序写入。另一种方法是使用PHYTEC的自研程序 partup ，它可以让格式化复杂系统的过程变得简单。您可以从其发布页面获取 预编译的Linux partup 二进制文件 。请阅读 partup的readme文件 来获取安装指导。

+
+

2.1. 下载镜像

+

phytec-qt6demo-image 镜像包含完整系统所需的所有必要文件，您需确保镜像中各个分区以及裸数据都会被正确写入启动盘。可以从 PHYTEC 下载服务器 下载 partup 镜像文件或者是可以使用 dd 进行烧写的 WIC 镜像。

+

从下载服务器获取 partup 镜像文件或WIC镜像：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+
+

备注

+

针对eMMC，我们建议使用partup去烧写比较大的或者是有复杂分区配置的镜像，因为它在写入速度上比 dd 更快，并且可以对闪存设备进行更灵活的配置。

+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要创建SD卡启动盘，必须要拥有Linux PC上的root权限。在选择烧写设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+
+

2.2.1. 寻找正确的设备

+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行命令：

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+

卸载所有这些分区，例如：

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

现在，SD卡已经准备好可以使用 partup 、 dd 或 bmap-tools 来写入镜像。

+
+
+

2.2.2. 使用bmap-tools

+

烧写SD卡的其中一种方法是使用 bmap-tools 。Yocto会自动为WIC镜像创建一个block map文件（ <IMAGENAME>-<MACHINE>.wic.bmap ），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host:~$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

将 <your_device> 替换为您之前找到的SD卡设备名称，并确保将文件 <IMAGENAME>-<MACHINE>.wic.bmap 与WIC镜像文件放在一起，以便bmaptool知道哪些块需要写入，哪些块需要跳过。

+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.2.3. 使用partup

+

使用partup烧写SD卡只需一个命令：

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).partup /dev/<your_device>
+
+
+

确保将 <your_device> 替换为您之前找到的设备名称。

+

关于partup的进一步使用说明，请参阅其 官方文档 。

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 release notes 。

+
+
+

备注

+

partup 具有清除eMMC user区域中特定区域的功能，我们提供的partup程序中用该功能擦除U-Boot环境变量。这是 bmaptool 工具所无法完成的一点，如前一部分所提到的。

+

partup相较于其他烧写工具的一个主要优势是，它可以配置MMC的特定部分，比如他可以直接写入eMMCboot分区，无需调用其他命令。

+
+
+
+

2.2.4. 使用 dd

+

在卸载所有SD卡的挂载分区后，您可以烧写SD卡。

+

一些PHYTEC BSP会生成未压缩的镜像（文件名扩展名为*.wic），而另一些则生成压缩的镜像（文件名扩展名为*.wic.xz）。

+

要写入未压缩的镜像（*.wic），请使用以下命令：

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

或者要写入压缩后的镜像（*.wic.xz），请使用以下命令：

+
host:~$ xzcat phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

再次确保将 <your_device> 替换为之前找到的设备名称。

+

参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

+
+
+
+

2.3. 首次启动

+ +../../../_images/SD_Card_Boot1.png +
    +

  • 插入SD卡

    • +

  • 使用 micro USB 线将开发板的 (X1) 调试USB口和主机连接起来

    • +

  • 给开发板通电

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (scarthgap).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (scarthgap).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-IMX8MP ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-xwayland MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD24.1.0
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 phyboard-pollux-imx8mp-3 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx8mp.bin: ARM可信固件二进制文件

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY固件镜像

    • +

  • imx-boot：由imx-mkimage编译的bootloader镜像，包括SPL、U-Boot、ARM可信固件和DDR固件。这是最终的可引导bootloader镜像。

    • +

  • fitImage: Linux内核FIT镜像

    • +

  • fitImage-its*.its

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx8mp-phyboard-pollux-rdk*.dtb: 内核设备树文件

    • +

  • imx8mp-phy*.dtbo: 内核设备树overlay文件

    • +

  • phytec-qt6demo-image*.tar.gz: 根文件系统

    • +

  • phytec-qt6demo-image*.rootfs.wic.xz: 压缩的SD卡镜像

    • +
+
+
+
+
+

4. 安装操作系统

+
+

4.1. 启动模式开关 (S3)

+
+

小技巧

+

硬件修订版底板：1552.2

+
+

该 phyBOARD-Pollux 具有一个（启动源配置）开关，配有四个可单独切换的位，用于选择phyCORE-i.MX 8M Plus 默认的启动源。

+ + + + + + + + + + + +
+../../../_images/eMMC1.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses1.png +
+

内部fuse

+
+
+
+../../../_images/SPI_NOR.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download1.png +
+

USB

+
+
+
+../../../_images/SD_Card_Boot1.png +
+

SD卡

+
+
+
+../../../_images/Test_Mode.png +
+

测试模式

+
+
+
+
+
+

4.2. 烧写eMMC

+

为了保持文档的一致性和简洁性，假设已经配置好了TFTP服务器；所有生成的镜像（如上所列）都被复制到默认的/srv/tftp目录。如果您没有进行设置，您需要修改路径到包含镜像的目录。有关如何设置TFTP服务器和目录的说明，请参见 Setup Network Host 。

+

要从 eMMC 启动，请确保 BSP 镜像已正确烧写到 eMMC，并且 bootmode switch (S3) 设置为 eMMC。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行上述命令来检查系统启动在这种条件下是否会到影响。如果 mmcblk2p1 和 mmcblk1p1 具有相同的UUID，则会影响系统正确启动。

+
+
+

4.2.1. 从网络烧写 eMMC

+

i.MX 8M Plus 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

4.2.1.1. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

查看主机上可用的镜像文件：

+
host:~$ ls /srv/tftp
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
+
+

通过网络ssh协议使用 bmaptool 命令将镜像发送到开发板的eMMC：

+
host:~$ scp /srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2"
+
+
+
+
+

4.2.1.2. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

使用以下命令，通过网络将压缩或未压缩的镜像和配套的 *.bmap 文件传送到核心板并写入 eMMC：

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.* /tmp && bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
+
+
+
+

4.2.1.3. 在开发板的U-Boot中通过网络烧写eMMC

+

这些步骤将展示如何通过网络更新eMMC。

+
+

小技巧

+

此步骤仅在镜像文件小于1GB的情况下会被执行成功，因为在启用OPTEE后，Bootloader中可用的RAM大小有限，不足以加载超过1GB的镜像

+
+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

解压缩您的镜像

+
host:~$ unxz /srv/tftp/phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+

通过网络将您的镜像加载到内存中：

+
    +

  • 使用DHCP

    +
    u-boot=> dhcp phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.1 (1 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.1
+Filename 'phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • 使用静态IP地址（必须先设置serverip和ipaddr）。

    +
    u-boot=> tftp ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
+
+
+
+
+

4.2.2. 在运行的U-Boot中通过网络烧写eMMC U-Boot镜像

+

可以在U-Boot中更新U-Boot镜像imx-boot，eMMC上的U-Boot需要位于eMMC的user区域。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.3. 从USB大容量存储设备烧写eMMC

+
+

4.2.3.1. 在运行的Linux系统中从USB烧写eMMC

+

下面这些步骤展示如何在Linux系统上使用USB大容量存储设备烧写eMMC。您需要一个保存了完整镜像的U盘和一个可从SD卡启动的核心板。（例如： phytec-qt6demo-image-phyboard-pollux-imx8mp-3.|yocto-imageext| ）。将 bootmode switch (S3) 设置为SD卡。

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ ls /mnt
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
    +
    +
    • +

  • 将镜像写入 phyCORE-i.MX 8M Plus eMMC（无分区的 MMC 设备 2）：

    +
    target:~$ bmaptool copy /mnt/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    小技巧

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+

4.2.3.2. 在开发板上通过U-Boot从USB烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件小于1GB的情况下会被执行成功，因为在启用OPTEE后，Bootloader中可用的RAM大小有限，不足以加载超过1GB的镜像

+
+

下面这些步骤展示如何通过USB设备更新eMMC。将 bootmode switch (S3) 配置为SD卡并插入SD卡。给开发板上电并进入U-Boot环境。将已存储了未压缩WIC镜像的优盘插入开发板USB接口。

+

将镜像从USB设备加载到RAM中：

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 0x58000000 phytec-headless-image-|yocto-machinename|.rootfs.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write 0x58000000 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+
+

4.2.4. 从SD卡烧写eMMC

+

即使没有可用的网络，您也可以更新eMMC。为此，您需要一个位于SD卡上的镜像文件（ *.wic ）。由于镜像文件相当大，您需要在SD卡创建第三个分区。要创建新分区或扩展您的SD卡，请参见 Resizing ext4 Root Filesystem 。

+

或者，使用partup包烧写SD卡，如 Getting Started 中所述。这样就可使用SD卡的全部容量。

+
+

4.2.4.1. 在开发板的linux环境中通过SD卡烧写eMMC

+

您也可以在Linux系统中烧写eMMC。您只需要一个partup包或保存在SD卡上的WIC镜像。

+
    +

  • 检查在SD卡上保存的partup包或WIC镜像文件：

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
    +
    +
    • +

  • 使用 partup 将镜像写入 phyCORE-i.MX 8M Plus 的 eMMC（MMC 设备 2 不带 分区字样）：

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup /dev/mmcblk2
+
    +
    +

    使用partup烧写的优点是可以充分利用eMMC设备的全部容量，会相应自动调整分区大小。

    +
    +

    备注

    +

    另外，也可以使用 bmaptool 工具：

    +
    target:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
    +
    +

    请注意，在使用 bmaptool 烧写时，根文件系统分区并不会使用eMMC的最大容量。

    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    警告

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+

4.2.4.2. 在开发板的uboot环境中通过SD卡烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1GB的情况下有效，因为在启用OPTEE后，Bootloader中可用的RAM大小有限。如果镜像文件过大，请阅读 在开发板上通过SD卡更新eMMC 一节

+
+
    +

  • 将一个可用的镜像烧写到SD卡，并创建一个EXT4格式的第三分区。将WIC镜像（例如 phytec-qt6demo-image.rootfs.wic）复制到该分区。

    • +

  • 将 bootmode switch (S3) 配置为 SD 卡并插入 SD 卡。

    • +

  • 打开电源并进入U-Boot。

    • +

  • 加载镜像：

    +
    u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • 将当前mmc设备切换到eMMC：

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • 将您的WIC镜像（例如 phytec-qt6demo-image.rootfs.wic）从SD卡烧写到eMMC。这将对emmc进行分区，并将imx-boot、Image、dtb、dtbo和根文件系统复制到eMMC。

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • 关闭电源并将 bootmode switch (S3) 更改为 eMMC。

    • +
+
+
+
+
+

4.3. 烧写 SPI NOR Flash

+

phyCORE-i.MX8MP 模块可选配SPI NOR Flash。要从SPI Flash启动，请将 bootmode switch (S3) 设置为 SPI NOR 。SPI Flash通常比较小。phyBOARD-Pollux-i.MX8MP开发套件仅配备32MB的SPI NOR Flash。只能存储bootloader及其环境变量。默认情况下，内核、设备树和文件系统会从eMMC加载。

+

SPI NOR Flash分区表在U-Boot环境变量中定义。可以通过以下命令打印：

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. 通过网络烧写SPI NOR Flash

+

SPI NOR可以包含bootloader及其环境变量。arm64的linux内核无法自行解压缩，内核镜像大小超出了phyCORE-i.MX 8M Plus 上的SPI NOR Flash的容量。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+
+

4.3.1.1. 在开发板linux环境中通过网络烧写SPI NOR Flash

+
    +

  • 将镜像从主机复制到开发板：

    +
    host:~$ scp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • 查找要擦除的U-boot分区的块数：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除U-Boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.1.2. 在开发板的U-Boot环境中通过网络烧写SPI NOR

+

类似于通过网络更新eMMC，请确保正确设置主机PC。IP地址需要设置为192.168.3.10，子网掩码设置为255.255.255.0，并且需要有一个可用的TFTP服务。在进行读写之前，需要对SPI NOR Flash进行枚举：

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像。确保您使用了正确的镜像文件。通过tftp加载镜像，然后将bootloader写入Flash：

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+

4.3.2. 从SD卡烧写SPI NOR Flash

+

SPI NOR Flash上的bootloader也可以通过SD卡进行烧写。

+
+

4.3.2.1. 在开发板的linux环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi复制到SD卡的第一个分区。

    • +

  • 挂载SD卡：

    +
    target:~$ mount /dev/mmcblk1p1 /mnt
+
    +
    +
    • +

  • 查找要擦除的U-Boot分区的块数：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除u-boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.2.2. 在开发板的U-Boot环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi复制到SD卡的第一个分区。

    • +

  • 在进行读写操作之前，需要对SPI-NOR Flash进行枚举：

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像，请确保使用正确的镜像文件。从SD卡加载镜像，擦除并将bootloader写入flash：

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC： L-1006e.A6 RAUC Update & Device Management Manual 。

+
+
+

4.5. EFI Boot

+

Standardboot in U-Boot also supports booting distros over efi. By default the +U-Boot will search for a bootscript first, which is used to boot our Ampliphy +distro. If it does not find any bootscript, it will search for bootable efi +applications. So for booting over efi just make sure you don't have our distro +installed.

+
+

4.5.1. Disable booting with efi

+

To disable booting with efi you have to set the doefiboot variable to 0. +Also make sure you do not have efi or efi_mgr specified in the +bootmeths environment variable.

+
u-boot=> setenv doefiboot 0
+u-boot=> env save; env save;
+
+
+
+
+

4.5.2. Switch to only efi boot

+

If you want to only boot with efi, you can set the bootmeths environment +variable to efi. Also make sure you have the doefiboot environment variable +set to 1.

+
u-boot=> setenv bootmeths efi
+u-boot=> env save; env save;
+
+
+
+
+

4.5.3. Installing a distro

+

With efi you can install and boot different distros like openSUSE, Fedora or +Debian. First you have to get the iso Image from their website. For example:

+

https://cdimage.debian.org/debian-cd/current/arm64/iso-dvd/

+

Then copy the .iso file to a usb stick for example. Make sure you select the +correct device:

+
sudo dd if=file.iso of=/dev/sdx bs=1M conv=fsync status=progress
+
+
+

Insert the USB stick into the board and boot it. GRUB will then prompt you with +a menu where you can select what to do. Here select install. Then you have to +click through the installation menu. This is relatively straightforward and +differs a bit for every distro. You can install the distro for example to emmc +(mmc 2) or sdcard (mmc 1). Make sure you do not overwrite +your U-Boot during the install. Best to choose a different medium to install to +than the U-Boot is stored on. Otherwise manual partitioning will be required. +The automatic partitioning will start at the beginning of the disk. To not +overwrite the U-Boot, use an offset of 4MiB at the beginning of the disk.

+

During the Installation of Debian you will be asked, if you want to Force the +GRUB installation to the EFI removable media path. Select no. Also select no, +when you will be asked if you want to update the NVRAM variables. Otherwise the +grub-dummy installation step will fail and you will be sent back to the +"Force GRUB installation" prompt.

+

After the installation is complete, reboot the board and remove the +installation medium (USB-stick). The board should then boot the distro you +installed.

+

If that does not happen, check if there is a boot option set for the distro. +The easiest way is with the eficonfig command.

+
u-boot=> eficonfig
+
+
+

That will open a menu. Then you can select Edit Boot Option. It will show +you the current boot options. If this is empty or you don't find your distro, +select Add Boot Option to add a new one. For debian for example you only +need to set the description and the file. You can enter whatever you want into +the description field. When you select the file field, you can select the disc +you installed the distro on and partition number one. For example +"mmc 2:1" for emmc, or "mmc 1:1" for sdcard. The file you +need to select is at EFI/debian/grubaa64.efi. After that save, quit and +reset the board. The board should then boot into debian.

+
+
+
+
+

5. 开发

+

从这个版本开始，U-Boot中的启动行为发生了变化。之前，内核和设备树是作为单独的二进制文件提供的。现在，二者将被包含在一个单一的FIT镜像二进制文件中。此外，PHYTEC ampliphy发行版的启动逻辑被移到了一个启动脚本中，该脚本本身是一个单独的FIT镜像二进制文件的一部分。要恢复到旧的启动方式，您可以执行

+
run legacyboot
+
+
+
+

备注

+

这种启动方式已被弃用，并将在下一个版本中移除。默认情况下，通过此命令启动将返回错误，因为启动分区中缺少内核和设备树。

+
+
+

5.1. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone git://git.phytec.de/u-boot-imx）

+
+
+

5.1.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-imx 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    https://github.com/phytec/linux-phytec-imx
+
    +
    +
    • +

  • 我们的 i.MX 8M Plus 内核是基于 linux-phytec-imx 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.1.2. 获取SDK

+

您可以在此处下载SDK 这里，或者使用Yocto去编译生成SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

在成功编译后，SDK安装包保存在 build/deploy*/sdk。

+
+
+

5.1.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.x.sh
+host:~$ ./phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.x.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-xwayland/5.0.x):
+You are about to install the SDK to "/opt/ampliphy-vendor-xwayland/5.0.x". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.1.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.1.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.2. 单独编译U-Boot

+
+

5.2.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本中使用的**tag**称为 v2024.04_2.0.0-phy7

    • +

  • 查看所需的 U-Boot tag：

    +
    host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2024.04_2.0.0-phy7
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.2.2. 获取所需的二进制文件

+

要编译bootloader，您需要将这些文件复制到您的 u-boot-imx 编译目录，并将其重命名以适应 mkimage 脚本：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx8mp.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以在yocto工程目录中获取 bl31-imx8mp.bin、tee.bin和lpddr4_*.bin：BSP Images

+

或者你可以在这里下载文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/

+
+

警告

+

确保您重命名所需的文件，以和 mkimage tool 兼容。

+
+
+
+

5.2.3. 编译bootloader

+
    +

  • 编译 flash.bin (imx-boot):

    +
    host:~/u-boot-imx$ make phycore-imx8mp_defconfig
+host:~/u-boot-imx$ make flash.bin
+
    +
    +
    • +
+
+
+

5.2.4. 将bootloader烧写到块设备上

+

flash.bin 文件可以在 u-boot-imx/ 目录下找到，现在可以进行烧写。需要指定芯片特定的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

例如，烧写SD卡：

+
host:~/u-boot-imx$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+

5.2.5. 使用固定内存大小编译U-Boot

+

如果您的系统因为EEPROM中的硬件信息损坏或丢失而无法启动，您可以创建一个具有固定RAM大小的flash.bin。但您仍应联系我们支持部门以烧写正确的EEPROM数据。

+

按照步骤获取U-boot源代码，并切换到 Build U-Boot 章节说明的分支。

+

Edit the file configs/phycore-imx8mp_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+
+
+

选择正确的RAM大小，确保与核心板上的贴装的器件一致，取消注释该RAM大小的行。保存更改后，按照 Build U-Boot 章节的剩余步骤进行操作。

+
+
+

5.2.6. 编译支持固定RAM大小与频率的U-Boot

+

从PD23.1.0 NXP或PD24.1.2 Mainline 版本开始，PCB为1549.3版本的核心板及更新版本的phyCORE-i.MX 8M Plus SoM支持2GHz内存时序。这些将在支持的板上自动启用，但也可以手动启用或禁用。

+

Edit the file configs/phycore-imx8mp_defconfig. +The fixed RAM size with 2GHz timings will be used:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+CONFIG_PHYCORE_IMX8MP_RAM_FREQ_FIX=y
+CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+
+
+

在保存更改后，按照 Build U-Boot 中剩下的步骤操作。

+
+
+

5.2.7. 编译固定的RAM频率的U-Boot

+

从PD24.1.2 Mainline版本或者 PD24.1.0 NXP 版本开始，U-Boot可以编译成只固定RAM频率，RAM大小还是保持从EEPROM读取。

+

Edit the file configs/phycore-imx8mp_defconfig. +The RAM size from EEPROM with fixed frequency will be used:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_FREQ_FIX=y
+# CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+# CONFIG_PHYCORE_IMX8MP_USE_1_5GHZ_RAM_TIMINGS=y
+
+
+

在保存更改后，按照 Build U-Boot 中剩下的步骤操作。

+
+
+
+

5.3. 单独编译内核

+

内核与设备树一起打包在FIT镜像中。U-Boot已被配置为能够加载FIT镜像并引导其中包含的内核。因此，内核镜像必须打包在FIT镜像中。

+
+

5.3.1. 配置源代码

+
    +

  • 使用的 linux-phytec-imx 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v6.6.23-2.0.0-phy10

    • +

  • Check out 所需的 linux-phytec-imx 标签：

    +
    host:~$ git clone https://github.com/phytec/linux-phytec-imx
+host:~$ cd ~/linux-phytec-imx/
+host:~/linux-phytec-imx$ git fetch --all --tags
+host:~/linux-phytec-imx$ git checkout tags/v6.6.23-2.0.0-phy10
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-phytec-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-phytec-imx$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.3.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-phytec-imx$ make imx8_phytec_defconfig
+host:~/linux-phytec-imx$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-phytec-imx/arch/arm64/boot/Image.gz 找到

    • +

  • dtb文件可以在 ~/linux-phytec-imx/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-phytec-imx$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.3.3. 将内核打包成FIT镜像

+

要简单地替换内核，您需要一个 image tree source (.its)文件。如果您已经使用Yocto编译了我们的BSP，可以从此处提到的目录获取its文件： BSP Images 或者您可以在这里下载该文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/

+

将 .its 文件复制到当前工作目录，创建一个指向内核镜像的链接，并使用 mkimage 创建最终的 fitImage。

+
host:~/linux-phytec-imx$ cp /path/to/yocto/deploydir/fitimage-its*.its .
+                  && ln -s arch/arm64/boot/Image.gz linux.bin
+                  && uboot-mkimage -f fitImage-its*.its fitImage
+
+
+
+
+

5.3.4. 将FIT镜像和内核模块复制到SD卡

+

FIT镜像以及内核module可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-phytec-imx$ cp fitImage /path/to/sdcard/boot/
+host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.4. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.4.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.4.2. 获取镜像

+

从我们的服务器下载imx-boot，或者从您Yocto工程中的build/deploy-ampliphy-vendor-xwayland/images/phyboard-pollux-imx8mp-3/路径获取。要将wic镜像烧写到eMMC，你还需要 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic。

+
+
+

5.4.3. 开发板准备

+

将 bootmode switch (S3) 设置为 USB串行下载。同时，将 USB 端口 X5 (upper connector) 连接到主机。

+
+
+

5.4.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 (X1) 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.4.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.4.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
+
+
+
+

5.4.7. 通过UUU工具烧写SPI NOR Flash

+

执行并给开发板上电：

+
host:~$ sudo uuu -b qspi imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+
+
+

这将更新SPI NOR Flash上的U-Boot，但不会更新环境。您可能需要擦除旧环境，以便加载新U-Boot的默认环境：

+
u-boot=> env erase
+u-boot=> reset
+
+
+
+
+
+

5.5. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.5.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.5.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.5.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.6. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.6.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核fitimage复制到您的tftp目录中：

    +
    host:~$ cp fitImage /srv/tftp
+
    +
    +
    • +

  • 将启动脚本复制到您的tftp目录中：

    +
    host:~$ cp boot.scr.uimg /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.6.2. 设置网络启动的bootenv.txt文件

+

在您的tftp目录中创建一个bootenv.txt文件，并将以下变量写入其中。

+
nfsroot=/srv/nfs
+overlays=<overlayconfignames>
+
+
+

<overlayconfignames> 替换为您想要使用的设备树overlay配置名称。用#号分隔配置名称。例如：

+
overlays=conf-example-overlay1.dtbo#conf-example-overlay2.dtbo
+
+
+
+

小技巧

+

所有支持的设备树overlay文件都在 device tree 章节中。或者可以通过以下命令打印：

+
host:~$ dumpimage -l fitImage
+
+
+
+
+
+

5.6.3. 开发板上的网络设置

+

如果要自定义开发板上的以太网配置，请按照此处的说明进行操作： Network Environment Customization

+
+
+

5.6.4. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> setenv boot_targets ethernet
+u-boot=> bootflow scan -lb
+
    +
    +
    • +
+
+
+
+

5.7. 获取BSP开发中版本

+
+

5.7.1. 当前release的开发中版本

+

这些release manifest文件是为了让您访问 Yocto BSP的开发版本。它们不会在phyLinux选择菜单中显示，需要手动选择。可以使用以下命令行来完成此操作：

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD24.1.y
+
+
+

这将初始化一个BSP，用于跟踪当前版本（ BSP-Yocto-NXP-i.MX8MP-PD24.1.0 ）的最新开发版本。从现在开始，在此文件夹中执行 repo sync 将从我们的Git仓库中拉取所有最新的更改：

+
host:~$ repo sync
+
+
+
+
+

5.7.2. 即将发布版本的开发中版本

+

即将发布版本的开发中版本可以通过这种方式访问。请执行以下命令，并查找一个比最新版本（ BSP-Yocto-NXP-i.MX8MP-PD24.1.0 ）的PDXX.Y数字更高的版本，并且以 .y 结尾：

+
host:~$ ./phyLinux init -p imx8mp
+
+
+
+
+
+

5.8. 获取最新的Upstream支持

+

我们有一个使用Yocto主分支（不是NXP发布的）的manifest，他使用upstream的Linux和U-Boot。这可以用来测试最新的upstream kernel/U-Boot。

+
+

备注

+

master分支的manifest反映了最新的开发状态。有时会出现一些bug。我们会定期修复master分支。

+
+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.9.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic 镜像复制到其中。然后卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+

5.10. Switch back to legacyboot

+
+

警告

+

As we switched to standardboot with fitimage as default, legacyboot is +deprecated. We kept the option to switch back to legacyboot for this +release, but it will be removed in the future.

+
+
+

5.10.1. Changes in Yocto

+

By default, the fitImage and bootscript will be deployed into the wic.xz Image. +To switch back to legacyboot, you need to replace the fitImage and bootscript +for the kernel image and the devicetrees. They are still in the deploy +folder from the Yocto build, so you can manually copy them to the boot +partition on your device. Otherwise you can do the following changes in Yocto +to get the kernel and devicetrees deployed in the Image again.

+

First create the variable KERNEL_DEVICETREE_DEPLOY. This can be done for +example in the local.conf file in your build directory conf/local.conf. +The variable is basically a copy of the KERNEL_DEVICETREE variable that is +set in conf/machine/phyboard-pollux-imx8mp-3.conf in meta-phytec but the freescale +at the beginning needs to be removed, so that only the devicetree filename are +left. In the end it should look something like this:

+
KERNEL_DEVICETREE_DEPLOY = " \
+     imx8mp-phyboard-pollux-rdk.dtb \
+     imx8mp-phyboard-pollux-isp-csi1.dtbo \
+     imx8mp-phyboard-pollux-isp-csi2.dtbo \
+     imx8mp-phyboard-pollux-isi-csi1.dtbo \
+     imx8mp-phyboard-pollux-isi-csi2.dtbo \
+     imx8mp-phyboard-pollux-peb-av-10.dtbo \
+     imx8mp-phyboard-pollux-peb-wlbt-05.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2-fpdlink-port1.dtbo \
+     imx8mp-phycore-no-eth.dtbo \
+     imx8mp-phycore-no-rtc.dtbo \
+     imx8mp-phycore-no-spiflash.dtbo \
+     imx8mp-phycore-rpmsg.dtbo \
+"
+
+
+

Then add this line:

+
IMAGE_BOOT_FILES:mx8m-nxp-bsp:append = " Image oftree ${KERNEL_DEVICETREE_DEPLOY}"
+
+
+
+

备注

+

A clean might be required for this to work.

+
bitbake -c cleanall phytec-qt6demo-image
+
+
+
+

Then start the build:

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

5.10.2. Changes in U-Boot environment

+

To re-enable legacyboot set the following variable:

+
uboot=> setenv dolegacyboot 1
+uboot=> env save; env save;
+uboot=> boot
+
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 8M Plus 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Board.dts - 包含module dtsi 文件。从SoC i.MX 8M Plus 引出并在底板使用的设备也包含在此 dts 中。

    • +

  • Overlay.dtso - 根据核心板或底板上可选硬件（例如 SPI 闪存或 PEB-AV-10）的情况来启用/禁用一些功能。

    • +
+

在Linux内核的根目录下，我们的 i.MX 8 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。下面是扩展板的硬件描述。对比源码中的include，overlay通过覆盖的方式来生效。overlay也可以根据实际开发板的硬件配置来设置设备树节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/ 中。

+

phyboard-pollux-imx8mp-3.conf 可用的overlay文件有：

+
imx8mp-isi-csi1.dtbo
+imx8mp-isi-csi2.dtbo
+imx8mp-isp-csi1.dtbo
+imx8mp-isp-csi2.dtbo
+imx8mp-phyboard-pollux-peb-av-10.dtbo
+imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+imx8mp-phycore-no-eth.dtbo
+imx8mp-phycore-no-rtc.dtbo
+imx8mp-phycore-no-spiflash.dtbo
+imx8mp-phycore-rpmsg.dtbo
+imx8mp-vm016-csi1.dtbo
+imx8mp-vm016-csi1-fpdlink.dtbo
+imx8mp-vm016-csi2.dtbo
+imx8mp-vm016-csi2-fpdlink.dtbo
+imx8mp-vm017-csi1.dtbo
+imx8mp-vm017-csi1-fpdlink.dtbo
+imx8mp-vm017-csi2.dtbo
+imx8mp-vm017-csi2-fpdlink.dtbo
+
+
+

Otherwise you can show the content of a FIT image including all overlay +configs in the FIT image with this command in Linux:

+
host:~$ dumpimage -l /boot/fitImage
+
+
+

or in U-Boot:

+
u-boot=> load mmc ${mmcdev}:1 ${loadaddr} fitImage
+u-boot=> iminfo
+
+
+

可以在Linux或U-Boot环境下配置overlay。overlay是在引导命令调用后、内核加载之前生效。接下来的部分将更详细地解释配置方法。

+
+

6.2.2.1. 设置 ${overlays} 变量

+

The ${overlays} U-Boot environment variable contains a number-sign (#) +separated list of overlays that will be applied during boot. The overlays +listed in the overlays variable must be included in the FIT image. Overlays set +in the $KERNEL_DEVICETREE Yocto machine variable will automatically be added to +the FIT image.

+

The ${overlays} variable can either be set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +When desired to use the overlays variable as set manually in the U-Boot +environment, disable bootenv by setting env set no_bootenv 1 as the overlays +variable may be overwritten during the execution of the boot script. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=conf-imx8mp-phyboard-pollux-rdk-peb-eval-01.dtbo#conf-imx8mp-phyboard-pollux-peb-av-10.dtbo
+
+
+

更改将在下次重启后生效。如果没有可用的 bootenv.txt 文件，可以直接在U-Boot环境中设置overlay变量。

+
u-boot=> setenv overlays conf-imx8mp-phyboard-pollux-peb-av-10.dtbo
+u-boot=> printenv overlays
+overlays=conf-imx8mp-phyboard-pollux-peb-av-10.dtbo
+u-boot=> boot
+
+
+

如果用户定义了 ${overlays} 变量，同时存在 bootenv.txt 文件，则需要设置 ${no_bootenv} 变量：

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays conf-imx8mp-phyboard-pollux-peb-av-10.dtbo
+u-boot=> boot
+
+
+

有关环境的更多信息，请参见 U-boot External Environment subsection of the +device tree overlay section。

+

We use the ${overlays} variable for overlays describing expansion boards and +cameras that can not be detected during run time. To prevent applying overlays +unset the overlays variable and set no_bootenv to anything other than 0.

+
u-boot=> env delete overlays
+u-boot=> env set no_bootenv 1
+
+
+

If desired to use the bootenv.txt file for setting U-Boot variables other than +overlays and having overlays disabled, remove the overlays definition line from +the bootenv.txt file instead of setting no_bootenv.

+
+
+

6.2.2.2. SoM Variants

+

Additional overlays are applied automatically to disable components that are not +populated on the SoM. The detection is done with the EEPROM data (EEPROM SoM +Detection) found on the SoM i2c EEPROM.

+

这取决于核心板型号是否会应用任何设备树overlay。要检查在U-Boot中运行的SoM是否会应用overlay，请运行：

+
u-boot=> env print fit_extensions
+
+
+

如果没有可用的EEPROM数据，则不加载任何设备树overlay。

+

To prevent application of the SoM variant related overlays the +${no_extensions} variable can be set to 1 in the bootloader environment:

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot外部环境

+

在Linux内核启动时，外部环境 bootenv.txt 文本文件将从MMC设备的boot分区或通过TFTP加载。该文件的主要目的是存储 ${overlays} 变量。这可以针对不同的machine在Yocto中预定义不同的overlay配置。文件的内容在meta-phytec中的Yocto recipe中的bootenv中定义： https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=scarthgap

+

该文件中也可以设置其他变量。这些变量将覆盖环境中现有的设置。但只有对boot命令后进行计算的变量生效，例如 ${nfsroot} 或 ${mmcargs}。在文件中更改其他变量将不会有作用。以网络启动的用法作为示例。

+

如果无法加载外部环境，启动过程将继续进行，并使用自带的环境变量值。

+
+
+

6.2.4. 在Linux环境下更改开发板上的U-boot环境变量

+

Libubootenv是我们镜像中包含的一个工具，用于在开发板linux上修改U-Boot环境。

+

使用以下命令打印U-Boot环境：

+
target:~$ fw_printenv
+
+
+

使用以下命令修改U-Boot环境：

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

小心

+

Libubootenv会读取配置文件中配置的环境变量。要修改的环境变量会被插入到该文件中，默认情况下使用eMMC中存储环境变量。

+

如果eMMC没有被烧写过或者eMMC环境被擦除，libubootenv将无法工作。您应该修改 /etc/fw_env.config 文件，以匹配您想要使用的环境源。

+
+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 8M Plus BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 8M Plus BSP设备树概念部分，以了解我们的 i.MX 8 BSP设备树模型。

+

以下部分概述了 i.MX 8 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 8M Plus 引脚复用

+

该 i.MX 8M Plus Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 8M Plus 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 8M Plus 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是 imx8mp-phyboard-pollux-rdk.dts中UART1设备的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x140
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x140
+        >;
+};
+
+
+

字符串的第一部分 MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 指定了引脚（在这个例子中是 UART1_RXD）。字符串的第二部分（UART1_DCE_RX）是该引脚所选的复用项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部拉电阻是否被激活。在当前情况下，内部拉电阻被禁用。

+

The device tree representation for UART1 pinmuxing: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L373

+
+
+

7.2. RS232/RS485

+

phyCORE-i.MX 8M Plus 支持最多 4 个 UART 单元。在 phyBOARD-Pollux 上，UART1（调试串口）和 UART4 的 TTL 电平信号被连接到 Silicon Labs CP2105 UART 到 USB 转换IC。这个 USB 信号通过 Micro-USB 连接器 X1 输出。UART3 位于 X6（扩展连接器），为 TTL 电平信号。UART2 连接到一个多协议收发器IC，可转换为 RS-232 或 RS-485，RS-232 和 RS-485 信号位于连接器 X2 。多协议配置通过主板上的跳线 JP3 和 JP4 完成。更多信息，请参阅 phyCORE-i.MX 8M Plus/phyBOARD-Pollux 硬件手册中的 UARTs 部分。

+

对于RS-232和RS-485，使用相同的设备树节点。RS485模式可以通过ioctl TIOCSRS485 来启用。双向通讯支持也可以通过ioctl进行配置。请查看我们的小示例应用程序rs485test，该程序也包含在BSP中。需要设置跳线 JP3 和 JP4 。

+
+

7.2.1. RS232

+
    +

  • 以人类可读的格式显示终端的当前设置：

    +
    target:~$ stty -a
+
    +
    +
    • +

  • UART接口的配置可以通过stty命令完成。例如：

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • 通过简单的echo和cat，可以测试基本的通信。示例：

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

主机应打印出 "123"。

+
+
+

7.2.2. RS485

+
+

提示

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

为了方便测试，请查看linux-serial-test。这个工具会通过调用RS485的IOCTL，发送恒定的数据流。

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

有关linux-serial-test工具及其参数的更多信息，请访问此链接：linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Linux kernel文档描述了如何在C代码中调用IOCTL： https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see "test" printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final "count for this session". There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+
+
+

7.2.2.2. RS485 full-duplex

+

For full-duplex mode your connection setup should look like this:

+../../../_images/RS485_fullduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For full-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 1
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  true
+Bus termination enabled:  false
+
+
+

Also here you can do the echo test to see if sending and receiving works:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see "test" printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

To check if the full-duplex operation works, you need to use the +linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=114660, tx=118755, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=118755, tx=114660, rx err=0
+
+
+

In this example both targets will send and receive simultaneously. They will +receive for 15sec and send for 10sec. The receiver needs to receive a bit +longer, so that all sent messages will get received. Remember to start both +targets almost simultaneously. A small difference in start time is accounted +for with the -W 2 option. At the end the program will print the final +"count for this session". There you can check that all transmitted frames were +received.

+

All the test examples are target to target, but can also be done with host to +target with a USB to rs485 converter. You may need to adjust the interfaces for +commands to work on the host then.

+

The device tree representation for RS232 and RS485: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L412

+
+
+
+
+

7.3. 网络

+

phyBOARD-Pollux-i.MX 8M Plus 提供两个以太网接口。我们的核心板和底板各提供一个千兆以太网接口。

+
+

警告

+

硬件中的以太网接口命名约定（ethernet0 和 ethernet1）与Linux中的网络接口（eth0 和 eth1）不一致。因此，请注意这些差异：

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L50。

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Pollux can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L179.

+
+

7.3.1. 网络配置

+
+

7.3.1.1. U-boot网络环境

+
    +

  • 要在bootloader中查找以太网设置：

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • 在将主机设置为IP 192.168.3.10和子网掩码255.255.255.0的情况下，开发板应该返回：

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • 如果您需要进行任何更改：

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> 应该是 ipaddr、netmask、gatewayip 或 serverip 中的一个。<value> 将是所选参数的设定值。

    +
    • +

  • 您所做的更改目前是临时的。要保存这些更改：

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

在这里，您也可以将IP地址更改为DHCP，而不是使用静态IP地址。

+
    +

  • 配置：

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • 设置 TFTP 和 NFS 的路径。修改可以如下所示：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+

小技巧

+

像nfsroot和netargs这样的变量可以被U-boot外部环境重新赋值。对于网络启动，外部环境将通过tftp加载。例如，要在 bootenv.txt 文件中设置nfsroot变量，请在tftproot目录修改：

+
nfsroot=/home/user/nfssrc
+
+
+

无需在开发板上存储这些信息。请注意，U-boot外部环境对于像 ipaddr 或 serveraddr 这样的变量不起作用，因为它们在加载外部环境之前已经被设置完成。

+
+
+
+

7.3.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. 无线局域网

+

在 phyBOARD-Pollux 上，WLAN和蓝牙由PEB-WLBT-05扩展板提供。PEB-WLBT-05的 phyBOARD-Pollux 快速入门指南向您展示了如何安装PEB-WLBT-05。

+
+

小技巧

+

对于BSP版本PD22.1及更新版本，需要先激活PEB-WLBT-05 Overlay，否则PEB-WLBT-05将无法被识别。

+
target:~$ vi /boot/bootenv.txt
+
+
+

之后，bootenv.txt 文件应该如下所示（它还可以包含其他设备树overlay！）：

+
overlays=conf-imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+
+
+

更改将在重启后应用：

+
target:~$ reboot
+
+
+

有关设备树overlay的更多信息，请阅读 device tree 章节。

+
+

为了支持WLAN和蓝牙，我们使用来自LSR的Sterling-LWB模块。该模块支持2.4 GHz，并且可以在多种模式下运行，如客户端模式、使用WEP、WPA、WPA2加密的接入点（AP）模式等。有关该模块的更多信息，请访问 https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. 连接到WLAN网络

+

首先设置您所在国家的正确监管域：

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

你将会看到：

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

设置无线接口：

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

现在您可以扫描可用的网络：

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

您可以使用一个跨平台的客户端，名为wpa_supplicant，支持WEP、WPA和WPA2，以建立加密连接。

+

为此，请将网络凭据添加到文件 /etc/wpa_supplicant.conf 中：

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

现在可以建立连接：

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

这会得到如下输出：

+
Successfully initialized wpa_supplicant
+
+
+

The ip address is automatically configured over DHCP. For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (scarthgap).

+
+
+
+

7.3.3. 蓝牙

+

Bluetooth is supported on phyBOARD-Pollux with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section.

+

Bluetooth is connected to UART3 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

现在您可以扫描环境中的可见蓝牙设备。在默认配置下，蓝牙是不可见的。

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. 可见性

+

要激活可见性：

+
target:~$ hciconfig hci0 piscan
+
+
+

要禁用可见性：

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. 连接

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

备注

+

如果连接失败并出现错误信息：“连接失败：org.bluez.Error.Failed”，请尝试使用以下命令重新启动PulseAudio：

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC 卡

+

该 i.MX 8M Plus 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L422

+

DT configuration for the eMMC interface can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L214

+
+
+

7.5. eMMC设备

+

PHYTEC模块如phyCORE-i.MX 8M Plus 配备了eMMC存储芯片作为主要存储。eMMC设备使用多层单元（MLC）或三层单元（TLC）技术来实现存储，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 8M Plus ，并在Linux内核中作为块设备表示，如SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.5.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），该层负责处理原始MLC或TLC的磨损均衡、块管理和错误更正码（ECC）。这需要定期执行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 通过以下命令使能BKOPS_EN：

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.5.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 8M Plus SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.5.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
+
+

7.5.5. 启用伪SLC模式

+

eMMC设备使用 MLC或TLC 来存储数据。与NAND Flash中使用的SLC相比，MLC或TLC在成本更低的情况下，可靠性较低且错误率较高。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. 擦除设备

+

可以直接擦除eMMC设备，而不是通过写零覆盖。eMMC块管理算法将擦除底层的MLC或TLC，或者将这些块标记为可丢弃。设备上的数据将丢失，并将被读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.5.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 8M Plus 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.5.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

下表是 i.MX 8M Plus SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.6. SPI主设备

+

i.MX 8M Plus 控制器包含一个 FlexSPI 和一个 ECSPI IP 核。FlexSPI 主控制器支持两个 SPI 通道，最多可连接 4 个设备。每个通道支持单通道/双通道/四通道/八通道模式的数据传输（1/2/4/8 条数据线）。ECSPI 控制器支持 3 个 SPI 接口，每个接口都有一个专用的CS（chip select）引脚。由于CS也可通过 GPIO 实现，因此每个通道上可以连接多个设备。

+
+

7.6.1. SPI NOR 烧写

+

phyCORE-i.MX 8M Plus 配备有一个 QSPI NOR Flash，该 Flash 连接到 i.MX 8M Plus 的 FlexSPI 接口。QSPI NOR Flash 可用于启动。有关烧写和启动模式设置的详细信息，请参见不同的章节。由于 SPI NOR Flash 的空间有限，因此仅可存储bootloader。默认情况下，内核、设备树和根文件系统来自 eMMC。

+

bootloader程序通过EEPROM数据检测是否安装了SPI Flash。如果没有安装SPI Flash，则在启动期间应用设备树overlay，通过扩展命令禁用SPI Flash设备树节点。如果没有可用的EEPROM数据，SPI NOR Flash节点将始终启用。有关更多信息，请参阅设备树overlay部分。

+

bootloader程序还可以通过内核的mtdparts启动参数修改设备树，将SPI MTD分区表传递给Linux。BSP中的默认分区布局设置为：

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

这是一个预定义的bootloader环境变量，可以在运行时更改。从Linux用户空间，可以通过/dev/mtd<N>设备访问NOR Flash分区，其中<N>是与要访问的NOR Flash分区相关联的MTD设备编号。要找到分区的正确MTD设备编号，请在目标上运行：

+
root@phyboard-pollux-imx8mp-3:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

它列出了所有MTD设备及其对应的分区名称。闪存节点在模块DTS中的SPI主节点内定义。SPI节点包含连接到此SPI总线的所有设备，在这种情况下只有SPI NOR Flash。

+

设备树中SPI主节点的定义可以在这里找到：

+

https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L76

+
+
+
+

7.7. GPIOs

+

phyBOARD-Pollux 具有一组专门用于GPIO的引脚。这些引脚直接连接到 i.MX 8M Plus 引脚，并被复用为 GPIO。它们可以直接在 Linux 用户空间中使用。处理器将其 GPIO 组织为5个GPIO组（GPIO1 – GPIO5），每个组包含 32 个GPIO。gpiochip0、gpiochip32、gpiochip64、gpiochip96 和 gpiochip128 是这些内部 i.MX 8M Plus GPIO 组 GPIO1 – GPIO5 的 sysfs 表示。

+

GPIO被标识为GPIO<X>_<Y>（例如：GPIO5_07）。<X>表示GPIO Bank，从1计数到5，而<Y>表示该Bank内的GPIO。<Y>从0计数到31（每个bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo -c gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如从gpiochip0的GPIO 20）：

    +
    target:~$ gpioget -c gpiochip0 20
+
    +
    +
    • +

  • 将gpiochip0上的GPIO 20的值设置为0并退出工具：

    +
    target:~$ gpioset -z -c gpiochip0 20=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <line=value>...
+
+Set values of GPIO lines.
+
+Lines are specified by name, or optionally by offset if the chip option
+is provided.
+Values may be '1' or '0', or equivalently 'active'/'inactive' or 'on'/'off'.
+
+The line output state is maintained until the process exits, but after that
+is not guaranteed.
+
+Options:
+      --banner            display a banner on successful startup
+  -b, --bias <bias>       specify the line bias
+                  Possible values: 'pull-down', 'pull-up', 'disabled'.
+                  (default is to leave bias unchanged)
+      --by-name           treat lines as names even if they would parse as an offset
+  -c, --chip <chip>       restrict scope to a particular chip
+  -C, --consumer <name>   consumer name applied to requested lines (default is 'gpioset')
+  -d, --drive <drive>     specify the line drive mode
+                  Possible values: 'push-pull', 'open-drain', 'open-source'.
+                  (default is 'push-pull')
+  -h, --help              display this help and exit
+  -l, --active-low        treat the line as active low
+  -p, --hold-period <period>
+                  the minimum time period to hold lines at the requested values
+  -s, --strict            abort if requested line names are not unique
+  -t, --toggle <period>[,period]...
+                  toggle the line(s) after the specified period(s)
+                  If the last period is non-zero then the sequence repeats.
+      --unquoted  don't quote line names
+  -v, --version           output version information and exit
+  -z, --daemonize set values then detach from the controlling terminal
+
+Chips:
+    A GPIO chip may be identified by number, name, or path.
+    e.g. '0', 'gpiochip0', and '/dev/gpiochip0' all refer to the same chip.
+
+Periods:
+    Periods are taken as milliseconds unless units are specified. e.g. 10us.
+    Supported units are 's', 'ms', and 'us'.
+
+*Note*
+    The state of a GPIO line controlled over the character device reverts to default
+    when the last process referencing the file descriptor representing the device file exits.
+    This means that it's wrong to run gpioset, have it exit and expect the line to continue
+    being driven high or low. It may happen if given pin is floating but it must be interpreted
+    as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.7.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用 CONFIG_GPIO_SYSFS 后才能支持。要在menuconfig中使 CONFIG_GPIO_SYSFS 可见，必须首先启用选项 CONFIG_EXPERT 。

+

您也可以将此选项添加到您在 Linux 内核源代码 arch/arm64/configs/ 目录下使用的 defconfig 中。例如，我们基于 NXP 的BSP版本，这个defconfig可以是 imx8_phytec_distro.config

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+
+
+
+

7.8. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

这里的 LED 灯包括蓝色的 mmc、绿色的 心跳和红色的 emmc，它们都在 phyBOARD-Pollux 上。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L255

+
+
+

7.9. I²C总线

+

该 i.MX 8M Plus 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 8M Plus 的I²C模块。 本节描述了我们 phyBOARD-Pollux 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

General I²C1 bus configuration (e.g. imx8mp-phycore-som.dtsi): +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L113

+

General I²C2 bus configuration (e.g. imx8mp-phyboard-pollux-rdk.dts) +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L239

+
+
+

7.10. EEPROM

+

在 phyCORE-i.MX8MP 上贴了一个 i2c 接口的 EEPROM 存储。它有两个地址。主 EEPROM 空间（总线：I2C-0 地址：0x51）可以通过 Linux 中的 sysfs 接口访问。主 EEPROM 的前 256 字节和 ID 页（总线：I2C-0 地址：0x59）用于板检测，不可修改。因此，ID 页不能通过 sysfs 接口访问。覆盖保留空间将导致启动问题。

+
+

备注

+

如果您删除了保留的EEPROM空间数据，请联系我们的支持团队！

+
+
+

7.10.1. phyCORE-i.MX8MP 上的I2C EEPROM

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

phyCORE-i.MX8MP SoM上的I2C EEPROM连接到I2C-0总线的I2C地址0x51。可以直接对该设备进行读写操作：

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

要用零填充4KiB的EEPROM（总线：I2C-0 地址：0x51），并保留EEPROM数据，请使用：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM 检测

+

在 phyCORE-i.MX8MP 上配置的I2C EEPROM具有一个可通过I2C地址0x59在i2c0上寻址的独立ID页面，以及一个可通过I2C地址0x51在i2c0上寻址的正常区域。PHYTEC使用这个32字节的数据区域来存储关于SoM的信息，包括PCB版本和配置。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果EEPROM ID页面数据和正常区域的前256个字节被删除，bootloader程序将回退到 phyCORE-i.MX8MP Kit RAM设置，即 2GiB RAM。

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

使用API修订版2数据格式烧写的核心板将在早期启动阶段打印出有关模块的信息。

+

DT representation, e.g. in phyCORE-i.MX 8M Plus file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L201

+
+
+
+

7.11. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC唤醒alarm

+

可以从实时时钟（RTC）发出中断以唤醒系统。该格式使用Unix纪元时间，即自1970年1月1日UTC午夜以来的秒数。要在从挂起到RAM状态后的4分钟唤醒系统，请输入：

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

备注

+

内部唤醒alarm时间将被向上舍入到下一个分钟，因为alarm功能不支持秒。

+
+
+
+

7.11.2. RTC参数

+

实时时钟（RTC）具有一些功能，可以通过 hwclock 工具进行读取和设置。

+
    +

  • 我们可以通过以下方式检查RTC支持的功能：

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    这个值的含义在内核中进行了编码，每个位的定义为：

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • 我们可以通过以下方式检查RTC BSM（Backup Switchover Mode 备份切换模式）：

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • 我们可以通过以下方式设置RTC BSM：

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    BSM位的定义为：

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    小技巧

    +

    您应该将BSM模式设置为DSM或LSM，以便在初始电源不可用时，RTC可以切换到备用电源。请查看 RV-3028 RTC的Datasheet，以了解LSM（电平切换模式）和DSM（直接切换模式）这两个定义的工作模式。

    +
    +
    • +
+

DT representation for I²C RTCs: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L208

+
+
+
+

7.12. USB主控制器

+

i.MX 8M Plus SoC的USB控制器为众多消费类便携设备提供了一种低成本的连接解决方案，实现USB设备之间的数据传输，传输速度可达4 Gbit/s（超高速'SS'）。USB子系统具有两个独立的USB控制器。这两个控制器都能够作为USBDevice或USB Host使用。每个核心都连接到一个USB 3.0物理层（PHY）。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+

DT representation for USB Host: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L380

+
+
+

7.13. CAN FD

+

The phyBOARD-Pollux has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。两个CAN接口显示为can0和can1。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    can0的信息将如下所示：

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+
+

警告

+

mcp2518fd SPI到CAN FD只支持从125kB/s开始的波特率。可以选择更慢的速率，但可能无法正常工作。

+
+

Device Tree CAN configuration of imx8mp-phyboard-pollux-rdk.dts: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L203

+
+
+

7.14. PCIe

+

phyCORE-i.MX 8M Plus 具有一个 Mini-PCIe 插槽。一般来说，PCIe 会自动检测总线上的新设备。在连接设备并启动系统后，您可以使用命令 lspci 查看所有被识别的 PCIe 设备。

+
    +

  • 输入：

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • 你将收到：

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

在这个例子中，PCIe设备是 英特尔 WiFi Link 5100 。

+

对于PCIe设备，您必须在内核配置中启用正确的驱动程序。例如，这款WLAN卡是由英特尔制造的。必须启用的驱动程序选项名为 CONFIG_IWLWIFI ，可以在内核配置中的 Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimate 下找到。

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • linux-imx的表示为：virtual/kernel

      • +
    +
    • +
+

对于某些设备，如WLAN卡，需要额外的二进制固件文件。这些固件文件必须放置在 /lib/firmware/ 目录中，才能使用该设备。

+
    +

  • 输入：

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • 例如，如果您尝试启动网络接口：

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • 您将在串口控制台上获得以下输出：

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

小技巧

+

某些PCIe设备，例如以太网卡，即使没有从 /lib/firmware/ 加载固件文件，也可能正常工作，而你收到了如上输出第一行所示的错误消息。这是因为一些制造商在板卡本身提供了固件作为后备。在这种情况下，设备的行为和输出在很大程度上依赖于制造商的固件。

+
+

Device Tree PCIe configuration of imx8mp-phyboard-pollux-rdk.dts: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L345

+
+
+

7.15. 音频

+

支持的播放设备包括HDMI和PEB-AV-10连接器上的TI TLV320AIC3007音频编解码器（CODEC）IC。在AV连接器上，有一个符合OMTP标准的3.5mm耳机插孔和一个8针排针。8针排针包含单声道扬声器、耳机和line-in信号。

+
+

备注

+

使用PEB-AV-10连接器进行显示输出时，不支持通过HDMI作为音频输出。音频输出设备必须与视频输出设备匹配。

+
+

要检查您的声卡驱动程序是否正确加载以及设备名称，请输入以下命令以查看播放设备：

+
target:~$ aplay -L
+
+
+

或输入录音设备：

+
target:~$ arecord -L
+
+
+
+

7.15.1. Alsamixer

+

要检查声卡的功能，请输入：

+
target:~$ alsamixer
+
+
+

您应该会看到很多选项，因为音频IC具有许多可以测试的功能。通过SSH打开alsamixer的图形界面比通过调试串口打开更易于使用。所有混音点都有单声道或立体声增益控制。"MM"表示该功能被静音（左右输出均为静音），可以通过按' m '切换。您还可以通过按' < ' 左和 ' > '切换右声道输出。使用 tab 键，您可以在播放和录音控制之间切换。

+
+
+

7.15.2. 恢复默认音量

+

一些默认设置存储在 /var/lib/alsa/asound.state 中。您可以使用以下命令保存当前的alsa设置：

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

您可以通过以下方式恢复已保存的alsa设置：

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.15.3. ALSA配置

+

我们的BSP附带一个ALSA配置文件 /etc/asound.conf 。

+

ALSA配置文件可以根据需要进行编辑或删除，它并不是ALSA正常工作所必需的。

+
target:~$ vi /etc/asound.conf
+
+
+

要将PEB-AV-10设置为输出，请将 playback.pcm 从 "dummy" 设置为 "pebav10":

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

如果听不到声音，请将播放设备更改为软件音量控制播放设备，将 playback.pcm 设置为相应的软音量播放设备，例如“softvol_pebav10”。使用alsamixer控制来调整音量级别。

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.15.4. PulseAudio 配置

+

对于使用 Pulseaudio 的应用程序，请检查可用的音频输出设备：

+
target:~$ pactl list short sinks
+
+
+

要选择输出设备，请输入：

+
target:~$ pactl set-default-sink <sink_number>
+
+
+
+
+

7.15.5. 播放

+

运行speaker-test以检查播放功能：

+
target:~$ speaker-test -c 2 -t wav
+
+
+

要播放简单的音频流，您可以使用aplay。例如，要播放ALSA测试音频：

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

要播放其他格式，例如mp3，您可以使用Gstreamer：

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.15.6. 录音

+

arecord 是一个命令行工具，用于录制音频流，默认输入源为线路输入。要选择不同的音频源，可以使用 alsamixer。例如，打开 右侧 PGA 混音器 Mic3R 和 左侧 PGA 混音器 Mic3R，以便通过 3.5mm 插孔录制来自 TLV320 编解码器的麦克风输入音频。

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

提示

+

由于播放和录音共享硬件接口，因此无法在同时进行播放和录音操作时使用不同的采样率和格式。

+
+

Device Tree Audio configuration: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L58

+
+
+
+

7.16. 视频

+
+

7.16.1. 视频与Gstreamer

+

默认情况下，BSP安装了一个示例视频，路径为 /usr/share/qtphy/videos/ 。可以使用以下命令之一开始视频播放：

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.17. 显示

+

该 phyBOARD-Pollux 支持多达3种不同的显示输出。可以同时使用两种。下表显示了不同接口所需的扩展板和设备树overlay。

+ + + + + + + + + + + + + + + + + + + + + +

接口

扩展板

设备树overlay

HDMI

phyBOARD-Pollux

不需要overlay（默认启用）

LVDS0

PEB-AV-10

imx8mp-phyboard-pollux-peb-av-10.dtbo （默认加载）

LVDS1

phyBOARD-Pollux

如果使用PEB-AV-10 overlay，则禁用

+
+

备注

+
    +

  • 在更改Weston输出时，请确保音频输出也相匹配。

    • +

  • LVDS0 (使用PEB-AV-10扩展) 和 LVDS1 (板载) 不能同时使用。

    • +
+
+

HDMI在设备树中始终启用。其他接口可以通过设备树overlay进行启用。

+

默认启用的接口是HDMI和LVDS0（PEB-AV-010）。我们的 PEB-AV-10 支持10英寸edt,etml1010g0dka显示屏。

+
+

备注

+

当前的显示驱动程序将连接到LVDS的LCD的像素时钟限制为74.25MHz（或其分频）。如果这满足不了您的需求，请联系支持团队以获得进一步的帮助。

+
+
+

7.17.1. Weston 配置

+

为了让Weston正确的显示，需要进行正确的配置。这将在/etc/xdg/weston/weston.ini中完成。

+
+

7.17.1.1. 单一显示器

+

在我们的BSP中，默认的Weston输出设置为HDMI。

+
[output]
+name=HDMI-A-1
+mode=preferred
+
+[output]
+name=LVDS-1
+mode=off
+
+
+

当使用LVDS0（PEB-AV-10）作为输出时，将HDMI-A-1的输出模式设置为off，将LVDS-1的输出模式设置为current。

+
[output]
+name=HDMI-A-1
+mode=off
+
+[output]
+name=LVDS-1
+mode=current
+
+
+

如果您想使用LVDS1（板载），则需要去掉overlay。请从bootenv.txt中移除imx8mp-phyboard-pollux-peb-av-xxx.dtbo。

+
+
+

7.17.1.2. 双显示器

+
+

备注

+

对于双显示和三显示输出，您无法同时使用LVDS1（板载）和HDMI。

+
+

在HDMI和LVDS0（PEB-AV-10）的双屏模式下进行双显示时，两个模式必须设置为：

+
[output]
+name=HDMI-A-1
+mode=preferred
+
+[output]
+name=LVDS-1
+mode=current
+
+
+
+
+
+

7.17.2. Qt Demo

+

使用 phytec-qt6demo-image 时，Weston会在启动时启动。我们的Qt6 DEMO应用程序名为“qtphy”，可以通过以下方式停止：

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • 要重新开始Demo，请运行：

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • 要禁用Demo的自动启动，请运行：

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • 要启用Demo的自动启动，请运行：

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston可以通过以下方式停止：

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

备注

+

在关闭Weston之前，必须先关闭Qt Demo。

+
+
+
+

7.17.3. 背光控制

+

如果LCD连接到PHYTEC开发板，可以通过Linux内核的sysfs接口控制其背光。系统中所有可用的背光设备可以在文件夹/sys/class/backlight中找到。读取相应的文件并向其写入数据可以控制背光。

+
+

备注

+

一些具有多显示的开发板在 /sys/class/backlight 有多个背光控制。比如：backlight0和backlight1

+
+
    +

  • 例如，要获取最大亮度级别（max_brightness），请执行：

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    有效的亮度值范围是 0 到 <max_brightness>。

    +
    • +

  • 要获取当前亮度级别，请输入：

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • 写入文件brightness以更改亮度：

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    例如，关闭背光。

    +

    有关所有文件的文档，请参见 https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight。

    +
    • +
+

Device tree description of LVDS-1 and HDMI can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L294 +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L218

+

The device tree of LVDS-0 on PEB-AV-10 can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L133

+
+
+
+

7.18. 电源管理

+
+

7.18.1. CPU核心频率调节

+

i.MX 8M Plus SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。调整频率和电压被称为“动态电压和频率调整”（DVFS）。i.MX 8M Plus BSP支持DVFS功能。Linux内核提供了一个DVFS框架，允许每个CPU核心设置最小或最大频率和一个管理其运行的governor。根据使用的 i.MX 8 型号，支持几种不同的频率。

+
+

小技巧

+

尽管DVFS框架为每个CPU核心提供了频率设置，但一个CPU核心的频率更改会影响其他CPU核心。因此，所有CPU核心始终共享相同的DVFS设置。每个核心的单独DVFS设置是不可能的。

+
+
    +

  • 要获取完整列表，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    例如 i.MX 8MPlus CPU，最高可达约 1.6 GHz，则结果将是：

    +
    1200000 1600000
+
    +
    +
    • +

  • 要查询当前的频率输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

governor 会根据它们的目标自动选择这些频率中的一个。

+
    +

  • 列出所有可用的 governor，使用以下命令：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    结果是：

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative governor 与 ondemand governor 非常相似。只是它的行为有所不同，它会更保守地增减CPU速度，而不是在CPU有任何负载的瞬间就跳到最大速度。

    • +

  • ondemand （默认）根据当前系统负载在可能的CPU核心频率之间切换。当系统负载超过特定值时，它会立即提高CPU核心频率。

    • +

  • powersave 始终选择最低的CPU核心频率。

    • +

  • performance 始终选择最高的CPU核心频率。

    • +

  • userspace 允许以root身份运行的用户或用户空间程序设置特定频率（例如，设置为1600000）。输入：

    • +

  • 要查询当前的 governor，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    您通常会得到：

    +
    ondemand
+
    +
    +
    • +

  • 切换到另一个governor（例如，userspace）可以通过以下方式完成：

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • 现在你可以设置频率：

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

有关governor的更详细信息，请参阅Linux内核代码库中的Linux内核文档，路径为 Documentation/admin-guide/pm/cpufreq.rst 。

+
+
+

7.18.2. CPU核心管理

+

该 i.MX 8M Plus SoC 芯片上可以有多个处理器核心。例如，该 i.MX 8M Plus 具有 4 个 ARM 核心，可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    这里系统有四个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.18.3. 挂起到RAM

+

phyCORE-i.MX8MP 支持基本的挂起和恢复。可以使用不同的唤醒源。挂起/恢复可以通过以下方式实现：

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

要通过串行控制台唤醒，请运行

+
target:~$ echo enabled > /sys/class/tty/ttymxc0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.19. 热管理

+
+

7.19.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.19.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 8M Plus SoC 平台上使用热管理内核 API。 i.MX 8 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个触发点。这些触发点根据CPU型号的不同而有所不同。主要区分工业版和商业版。

+ + + + + + + + + + + + + + + + + +

商业

工业

被动（警告）

85°C

95°C

严重（关机）

90°C

100°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并实施冷却措施。内核中可用的热政策（也称为thermal governor）包括：Step Wise、Fair Share、Bang Bang和Userspace。BSP中使用的默认策略是Step Wise。如果sysfs文件temp中的SoC温度值高于 trip_point_0 ，则CPU频率将设置为最低CPU频率。当SoC温度降到 trip_point_0 以下时，限制将被解除。

+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+

7.19.3. GPIO风扇

+
+

备注

+

Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan +to GPIO fan due to availability. The PWM fan will not be supported +anymore and will not function with the new release.

+
+

一个GPIO控制的风扇可以连接到 phyBOARD-Pollux-i.MX 8M Plus。该SoC包含一个温度传感器，该传感器被用于热频率调节。风扇无法通过内核进行控制。我们使用lmsensors和hwmon来实现这一点。lmsensors定期读取温度，并在可配置的阈值下启用或禁用风扇。对于 phyBOARD-Pollux-i.MX 8M Plus，这个阈值是60°C。

+

设置可以在配置文件中进行配置：

+
/etc/fancontrol
+
+
+

风扇控制在启动时由systemd服务启动。可以通过以下方式禁用它：

+
target:~$ systemctl disable fancontrol
+
+
+

The device tree description of GPIO Fan can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L35

+
+
+
+

7.20. 看门狗

+

PHYTEC i.MX 8M Plus 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.20.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.21. snvs电源按键

+

连接到开关按钮的 X_ONOFF 引脚可以长按以触发关机，而无需软件干预，或用于唤醒系统以退出挂起状态。使用 snvs_pwrkey 驱动程序时，当按下按钮时，KEY_POWER 事件也会报告给用户空间。默认情况下，systemd 被配置为忽略此类事件。关机而无需软件干预的功能以及从挂起状态唤醒的功能未被配置。可以在 /etc/systemd/logind.conf 中配置按下开/关按钮时通过 systemd 触发关机，配置方法如下：

+
HandlePowerKey=poweroff
+
+
+
+
+

7.22. NPU

+

i.MX 8M Plus SoC包含一个高达2.3 TOPS的人工智能运算加速器。有关NPU的信息，请参考我们最新的phyCORE-i.MX 8M Plus AI套件指南，该指南可以在phyCORE-i.MX 8M Plus 下载部分找到：L-1015e.A1 phyCORE-i.MX 8M Plus AI Kit Guide

+
+
+

7.23. ISP

+

i.MX 8M Plus SoC包含一个图像信号处理器（ISP）。有关更多信息，请参阅|sbc| i.MX 8M Plus 文档中的使用ISP部分。

+
+
+

7.24. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 8M Plus 提供一次性可编程fuse，用于存储信息，例如 MAC 地址、启动配置和其他永久设置（在 i.MX 8M Plus reference manual中称为“片上 OTP 控制器 (OCOTP_CTRL)”）。以下列表摘自 i.MX 8M Plus reference manual，包括 OCOTP_CTRL 中的一些有用寄存器（基地址为0x30350000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为0x30350000

描述

OCOTP_MAC_ADDR0

9

0

0x640

包含ENET0 MAC地址的低32位

OCOTP_MAC_ADDR1

9

1

0x650

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

OCOTP_MAC_ADDR2

9

2

0x660

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 8M Plus Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.24.1. 在uBoot中读取fuse的值

+

您可以使用内存映射的shadow寄存器读取fuse寄存器。要计算内存地址，请使用以下公式计算：

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.24.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+
+

8. i.MX 8M Plus M7 Core

+

除了Cortex-A53核心外，SoC中还集成了一个Cortex-M7 Core 作为MCU。我们的Yocto-Linux-BSP在A53核心上运行，而 M7 Core 可以作为辅助CPU，用于使用裸机或RTOS固件执行额外任务。两种核心都可以访问相同的外设，因此外设的使用需要在 M7 Core 的固件或Linux操作系统的设备树中进行限制。本节将描述如何编译固件示例以及如何在 phyBOARD-Pollux 上运行它们。

+

phyBOARD-Pollux 目前由 NXP MCUXpresso SDK 和 Zephyr 项目支持。本节仅描述 NXP MCUXpresso SDK，因为目前 MCUXpresso SDK 支持的功能更多。

+

如果您想在Zephyr项目中使用 M7 Core ，请参考Zephyr项目文档：

+ +
+

8.1. 获取固件示例

+

固件可以使用NXP MCUxpresso SDK和兼容的编译工具链通过命令行工具进行编译。

+
+

8.1.1. 获取源代码

+

MCUX SDK以及 i.MX 8M Plus 的示例可以从PHYTEC的GitHub页面获取：

+ +
    +

  1. 通过west初始化MCUX SDK：

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    这将创建一个 mcuxsdk 目录，并在其中包含 mcux-sdk 仓库。mcux-sdk-phytec-examples 仓库将自动克隆到 mcuxsdk 目录中。给定的参数 <VERSION> 是 mcux-sdk 仓库的分支名称，代表 MCUX SDK 版本。要获取最新的测试版本，您可以使用 2.13.0。

    +
    +

    备注

    +

    west 是一个仓库管理工具，也是 Zephyr 项目的一部分。要安装 west，您可以使用 pip。在这个示例中，west 被安装在一个 Python 虚拟环境中:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. 更新依赖项：

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    目录 examples-phytec 包含了所有移植并测试过的示例，适用于 phyBOARD-Pollux 和版本为 2.13.0 的 MCUX。

    +

    要编译固件，需要一个编译器工具链和make/cmake。GNU ARM 嵌入式工具链可能在您的主机linux发行版的仓库中可用，例如Ubuntu。

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    编译器工具链也可以直接从 https://developer.arm.com/ 获取。在解压缩文件后，必须将 ARMGCC_DIR 添加到环境变量中，例如，对于位于主目录中的 ARM toolchain 10-2020-q4-major 版本：

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. 编译固件

+

要编译PHYTEC示例，需要先设置环境

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

编译固件的脚本位于 <sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc。每个可运行的内存位置都有相应的编译脚本，例如：

+
host:~$ ./build_release.sh
+
+
+

要编译运行在 M7 Core 的 TCM 上的固件。输出将放置在 armgcc 目录下的 release/ 中。.bin 文件可以在 U-Boot 中运行，而 .elf 文件可以在 Linux 中运行。

+

要编译在DRAM上运行的固件，请运行脚本build_ddr_release。例如。

+
host:~$ ./build_ddr_release.sh
+
+
+

输出将放置在armgcc目录下的ddr_release/中。.bin文件可以在U-Boot中运行，而.elf文件可以在Linux中运行。

+
+
+
+

8.2. 运行 M7 Core 示例

+

有两种方法可以运行 M7 Core 的固件，在Linux中使用Remoteproc以及在U-Boot。

+

要接收调试信息，请在您的主机PC上启动您喜欢的终端软件（例如Minicom、Tio或Tera Term），并将其配置为115200波特率、8个数据位、无奇偶校验和1个停止位（8n1），且不使用握手。

+

一旦Micro USB电缆连接到 phyBOARD-Pollux 上的USB调试端口，就会注册两个ttyUSB设备。一个打印来自A53核心的调试UART的消息，另一个打印来自 M7 Core 的调试UART的消息。

+
+

8.2.1. 从U-Boot运行示例

+

要使用bootloader U-Boot加载固件，可以使用bootaux命令：

+
    +

  1. 准备一张烧写了BSP镜像的SD卡

    2. +

  2. 将生成的 .bin 文件复制到 SD 卡的第一个分区

    3. +

  3. 通过按任意键停止自动启动

    4. +

  4. 根据固件类型输入命令：

    5. +
+

对于在 M7 Core 的TCM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

用于在DRAM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

程序的输出应显示在 M7 Core 的调试UART上。

+
+
+

8.2.2. 通过Remoteproc在Linux上运行示例

+

Remoteproc是一个模块，允许您在运行时从Linux控制 M7 Core 。可以加载为TCM编译的固件，并可以启动或停止执行。要使用Remoteproc，需要设置设备树Overlay：

+

在开发板的/boot目录中编辑bootenv.txt文件，添加 conf-imx8mp-phycore-rpmsg.dtbo ：

+
overlays=conf-imx8mp-phycore-rpmsg.dtbo
+
+
+

重启目标并在U-Boot中执行:

+
u-boot=> run prepare_mcore
+
+
+

M7 Core 的固件 .elf 文件可以在 /lib/firmware 下找到。要加载固件，请输入：

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

要加载不同的固件，M7 Core 需要停止：

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

备注

+

在开发板上找到的 /lib/firmware 中的例子来自NXP的Yocto层meta-imx。要使用您通过MCUX SDK自己编译的样本，请在编译后将它们复制到开发板的 /lib/firmware 中。

+
+
+ +
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mp/imx8mp.html b/previews/271/zh_CN/bsp/imx8/imx8mp/imx8mp.html new file mode 100644 index 000000000..8de86757c --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mp/imx8mp.html @@ -0,0 +1,857 @@ + + + + + + + + + i.MX 8M Plus 手册 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

i.MX 8M Plus 手册

+ +
+

Mainline HEAD

+
+

目录

+ +
+
+
+

BSP-Yocto-NXP-i.MX8MP-PD24.1.0

+
+

目录

+ +
+
+
+

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2

+
+

目录

+ +
+
+
+

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1

+
+

目录

+ +
+
+
+

BSP-Yocto-NXP-i.MX8MP-PD23.1.0

+
+

目录

+ +
+
+
+

BSP-Yocto-NXP-i.MX8MP-PD22.1.2

+
+

目录

+ +
+
+
+

BSP-Yocto-NXP-i.MX8MP-PD22.1.1

+
+

目录

+ +
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mp/mainline-head.html b/previews/271/zh_CN/bsp/imx8/imx8mp/mainline-head.html new file mode 100644 index 000000000..436b2ec4b --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mp/mainline-head.html @@ -0,0 +1,2889 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + + + + + +

L-XXXXX.Xx i.MX 8M Plus BSP +ManualHead

文档标题

L-XXXXX.Xx i.MX 8M Plus BSP +Mainline Manual Head

文档类型

BSP 手册

型号

L-XXXXX.Xx

Yocto 手册

发布日期

XXXX/XX/XX

母文档

L-XXXXX.Xx i.MX 8M Plus BSP +Mainline Manual Head

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP 发布日期

BSP 状态

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 phyCORE-i.MX8M Plus Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads 中找到。

+
+

1.1. 支持的硬件

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 的所有Machine及其对应的Article Numbers(产品型号)： 网页.

+

如果您在“Supported Machines”一栏选择了特定的 Machine Name ，您可以查看该machine下可用的 Article Numbers 以及硬件信息的简短描述。如果您只有硬件的 Article Numbers ，您可以将 Machine Name 下拉菜单留空，仅选择您的 Article Numbers 。现在，它应该会显示您特定硬件所需的 Machine Name

+
+

1.1.1. phyBOARD-Pollux 器件

+
+../../../_images/phyBOARD-Pollux-front-components.jpg + +
+

phyBOARD-Pollux 器件图（顶部）

+
+
+
+../../../_images/phyBOARD-Pollux-back-components.jpg + +
+

phyBOARD-Pollux 器件图（底部）

+
+
+
+
+
+
+

2. 开始使用

+

该 phyCORE-i.MX8M Plus Kit 包含预先烧写好的SD卡。它包含 phytec-qt6demo-image 镜像，可以直接用作启动盘。默认情况下，核心板上的eMMC仅烧写了U-Boot。您可以从 PHYTEC下载服务器 获取所有镜像资源。本章将解释如何将BSP镜像烧写到SD卡以及如何启动开发板。

+

有几种方法可以将镜像写入SD卡或eMMC。最为人熟知的方式是使用Linux命令行工具 dd 进行简单的顺序写入。另一种方法是使用PHYTEC的自研程序 partup ，它可以让格式化复杂系统的过程变得简单。您可以从其发布页面获取 预编译的Linux partup 二进制文件 。请阅读 partup的readme文件 来获取安装指导。

+
+

2.1. 下载镜像

+

phytec-qt6demo-image 镜像包含完整系统所需的所有必要文件，您需确保镜像中各个分区以及裸数据都会被正确写入启动盘。可以从 PHYTEC 下载服务器 下载 partup 镜像文件或者是可以使用 dd 进行烧写的 WIC 镜像。

+

从下载服务器获取 partup 镜像文件或WIC镜像：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+
+

备注

+

针对eMMC，我们建议使用partup去烧写比较大的或者是有复杂分区配置的镜像，因为它在写入速度上比 dd 更快，并且可以对闪存设备进行更灵活的配置。

+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要创建SD卡启动盘，必须要拥有Linux PC上的root权限。在选择烧写设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+
+

2.2.1. 寻找正确的设备

+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行命令：

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+

卸载所有这些分区，例如：

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

现在，SD卡已经准备好可以使用 partup 、 dd 或 bmap-tools 来写入镜像。

+
+
+

2.2.2. 使用bmap-tools

+

烧写SD卡的其中一种方法是使用 bmap-tools 。Yocto会自动为WIC镜像创建一个block map文件（ <IMAGENAME>-<MACHINE>.wic.bmap ），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host:~$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

将 <your_device> 替换为您之前找到的SD卡设备名称，并确保将文件 <IMAGENAME>-<MACHINE>.wic.bmap 与WIC镜像文件放在一起，以便bmaptool知道哪些块需要写入，哪些块需要跳过。

+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.2.3. 使用partup

+

使用partup烧写SD卡只需一个命令：

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).partup /dev/<your_device>
+
+
+

确保将 <your_device> 替换为您之前找到的设备名称。

+

关于partup的进一步使用说明，请参阅其 官方文档 。

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 release notes 。

+
+
+

备注

+

partup 具有清除eMMC user区域中特定区域的功能，我们提供的partup程序中用该功能擦除U-Boot环境变量。这是 bmaptool 工具所无法完成的一点，如前一部分所提到的。

+

partup相较于其他烧写工具的一个主要优势是，它可以配置MMC的特定部分，比如他可以直接写入eMMCboot分区，无需调用其他命令。

+
+
+
+

2.2.4. 使用 dd

+

在卸载所有SD卡的挂载分区后，您可以烧写SD卡。

+

一些PHYTEC BSP会生成未压缩的镜像（文件名扩展名为*.wic），而另一些则生成压缩的镜像（文件名扩展名为*.wic.xz）。

+

要写入未压缩的镜像（*.wic），请使用以下命令：

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

或者要写入压缩后的镜像（*.wic.xz），请使用以下命令：

+
host:~$ xzcat phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

再次确保将 <your_device> 替换为之前找到的设备名称。

+

参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

+
+
+
+

2.3. 首次启动

+ +../../../_images/SD_Card_Boot1.png +
    +

  • 插入SD卡

    • +

  • 使用 micro USB 线将开发板的 (X1) 调试USB口和主机连接起来

    • +

  • 给开发板通电

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (scarthgap).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (scarthgap).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-IMX8MP ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-xwayland MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 phyboard-pollux-imx8mp-3 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx8mp.bin: ARM可信固件二进制文件

    • +

  • lpddr4_pmu_train_1d_dmem_202006.bin, lpddr4_pmu_train_1d_imem_202006.bin, lpddr4_pmu_train_2d_dmem_202006.bin, lpddr4_pmu_train_2d_imem_202006.bin：DDR PHY固件镜像

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx8mp-phyboard-pollux-rdk*.dtb: 内核设备树文件

    • +

  • phytec-qt6demo-image*.tar.gz: 根文件系统

    • +

  • phytec-qt6demo-image*.wic.xz: SD卡镜像

    • +
+
+
+
+
+

4. 安装操作系统

+

为了保持文档的一致性和简洁性，假设已经配置好了TFTP服务器；所有生成的镜像（如上所列）都被复制到默认的/srv/tftp目录。如果您没有进行设置，您需要修改路径到包含镜像的目录。有关如何设置TFTP服务器和目录的说明，请参见 Setup Network Host 。

+
+

4.1. 启动模式开关 (S3)

+
+

小技巧

+

硬件修订版底板：1552.2

+
+

该 phyBOARD-Pollux 具有一个（启动源配置）开关，配有四个可单独切换的位，用于选择phyCORE-i.MX 8M Plus 默认的启动源。

+ + + + + + + + + + + +
+../../../_images/eMMC1.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses1.png +
+

内部fuse

+
+
+
+../../../_images/SPI_NOR.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download1.png +
+

USB

+
+
+
+../../../_images/SD_Card_Boot1.png +
+

SD卡

+
+
+
+../../../_images/Test_Mode.png +
+

测试模式

+
+
+
+
+
+

4.2. 烧写eMMC

+

要从 eMMC 启动，请确保 BSP 镜像已正确烧写到 eMMC，并且 bootmode switch (S3) 设置为 eMMC。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行上述命令来检查系统启动在这种条件下是否会到影响。如果 mmcblk2p1 和 mmcblk1p1 具有相同的UUID，则会影响系统正确启动。

+
+
+

4.2.1. 从网络烧写 eMMC

+

i.MX 8M Plus 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

4.2.1.1. 在开发板的U-Boot中通过网络烧写eMMC

+

这些步骤将展示如何通过网络更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+
+

小技巧

+

此步骤仅在镜像文件大小小于1.28GB时有效，因为Bootloader可用的RAM空间有限。

+
+
    +

  • 解压缩镜像：

    • +
+
host:~$ unxz /srv/tftp/phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+
    +

  • 通过网络将您的镜像加载到内存中：

    +
    u-boot=> dhcp ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.11 (101 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • 将镜像写入eMMC：

    +
    u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +
+
+
+

4.2.1.2. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

使用以下命令，通过网络将压缩或未压缩的镜像和配套的 *.bmap 文件传送到核心板并写入 eMMC：

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.* /tmp && bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
+
+
+
+

4.2.1.3. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

查看主机上可用的镜像文件：

+
host:~$ ls /srv/tftp
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
+
+

通过网络ssh协议使用 bmaptool 命令将镜像发送到开发板的eMMC：

+
host:~$ scp /srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2"
+
+
+
+
+
+

4.2.2. 在运行的U-Boot中通过网络烧写eMMC U-Boot镜像

+

可以在U-Boot中更新U-Boot镜像imx-boot，eMMC上的U-Boot需要位于eMMC的user区域。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> dhcp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.3. 从USB大容量存储设备烧写eMMC

+
+

4.2.3.1. 在开发板上通过U-Boot从USB烧写eMMC

+
+

备注

+

在U-Boot中只能使用下方的USB-A端口来连接优盘。

+
+
+

小技巧

+

此步骤仅在镜像文件大小小于1.28GB时有效，因为Bootloader可用的RAM空间有限。

+
+

下面这些步骤展示如何通过USB设备更新eMMC。将 bootmode switch (S3) 配置为SD卡并插入SD卡。给开发板上电并进入U-Boot环境。将已存储了未压缩WIC镜像的优盘插入开发板USB接口。

+

将镜像从USB设备加载到RAM中：

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. 在运行的Linux系统中从USB烧写eMMC

+

下面这些步骤展示如何在Linux系统上使用USB大容量存储设备烧写eMMC。您只需要一个保存在USB优盘上的完整镜像和一个可引导的WIC镜像。（例如：phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz）。将 bootmode switch (S3) 设置为SD卡。

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ ls /mnt
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
    +
    +
    • +

  • 将镜像写入 phyCORE-i.MX 8M Plus eMMC（无分区的 MMC 设备 2）：

    +
    target:~$ bmaptool copy /mnt/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    小技巧

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+
+

4.2.4. 从SD卡烧写eMMC

+

即使没有可用的网络，您也可以更新eMMC。为此，您需要一个位于SD卡上的镜像文件（ *.wic ）。由于镜像文件相当大，您需要在SD卡创建第三个分区。要创建新分区或扩展您的SD卡，请参见 Resizing ext4 Root Filesystem 。

+

或者，使用partup包烧写SD卡，如 Getting Started 中所述。这样就可使用SD卡的全部容量。

+
+

4.2.4.1. 在开发板的uboot环境中通过SD卡烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1.28GB时有效，因为Bootloader可用的RAM空间有限。

+
+
    +

  • 将一个可用的镜像烧写到SD卡，并创建一个EXT4格式的第三分区。将WIC镜像（例如 phytec-qt6demo-image.rootfs.wic）复制到该分区。

    • +

  • 将 bootmode switch (S3) 配置为 SD 卡并插入 SD 卡。

    • +

  • 打开电源并进入U-Boot。

    • +

  • 加载镜像：

    +
    u-boot=> mmc dev 1
+u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • 将当前mmc设备切换到eMMC：

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • 将您保存在SD的WIC镜像（例如 phytec-qt6demo-image.roots.wic）烧写到eMMC。这将对卡进行分区，并将imx-boot、Image、dtb、dtbo和根文件系统复制到eMMC。

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • 关闭电源并将 bootmode switch (S3) 更改为 eMMC。

    • +
+
+
+

4.2.4.2. 在开发板的linux环境中通过SD卡烧写eMMC

+

您也可以在Linux系统中烧写eMMC。您只需要一个partup包或保存在SD卡上的WIC镜像。

+
    +

  • 检查在SD卡上保存的partup包或WIC镜像文件：

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
    +
    +
    • +

  • 使用 partup 将镜像写入 phyCORE-i.MX 8M Plus 的 eMMC（MMC 设备 2 不带 分区字样）：

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup /dev/mmcblk2
+
    +
    +

    使用partup烧写的优点是可以充分利用eMMC设备的全部容量，会相应自动调整分区大小。

    +
    +

    备注

    +

    另外，也可以使用 bmaptool 工具：

    +
    target:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
    +
    +

    请注意，在使用 bmaptool 烧写时，根文件系统分区并不会使用eMMC的最大容量。

    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    警告

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+
+
+

4.3. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC：L-1006e.A6 RAUC更新与设备管理手册。

+
+
+
+

5. 开发

+
+

5.1. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.1.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.2. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.2.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核镜像复制到您的tftp目录中：

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • 将设备树复制到您的tftp目录：

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.2.2. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.3.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. 获取镜像

+

从我们的服务器下载 imx-boot，或者从您的 Yocto 编译目录中的 build/deploy-ampliphy-xwayland/images/phyboard-pollux-imx8mp-3/ 获取它。为了将 wic 镜像烧写到 eMMC，你还需要 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic

+
+
+

5.3.3. 开发板准备

+

将 bootmode switch (S3) 设置为 USB串行下载。同时，将 USB 端口 X5 (upper connector) 连接到主机。

+
+
+

5.3.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 (X1) 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.3.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
+
+
+
+
+

5.4. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone https://github.com/phytec/u-boot-phytec.git）

+
+
+

5.4.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    https://github.com/phytec/u-boot-phytec.git
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-phytec 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    https://github.com/phytec/linux-phytec.git
+
    +
    +
    • +

  • 我们的 i.MX 8M Plus 内核是基于 linux-phytec 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
recipes-kernel/linux/linux-phytec_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-phytec_*.bb
+
+
+
+
+
+

5.4.2. 获取SDK

+

您可以在此处下载SDK 这里，或者使用Yocto去编译生成SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

在成功编译后，SDK安装包保存在 build/deploy*/sdk。

+
+
+

5.4.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.1.sh
+host:~$ ./phytec-ampliphy-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.1.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-xwayland/5.0.1):
+You are about to install the SDK to "/opt/ampliphy-xwayland/5.0.1". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-xwayland/5.0.1/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. 单独编译U-Boot

+
+

5.5.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone https://github.com/phytec/u-boot-phytec.git
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本中使用的**tag**称为 v2024.01-phy4

    • +

  • 查看所需的 U-Boot tag：

    +
    host:~$ cd ~/u-boot-phytec/
+host:~/u-boot-phytec$ git fetch --all --tags
+host:~/u-boot-phytec$ git checkout tags/v2024.01-phy4
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/u-boot-phytec$ source /opt/ampliphy-xwayland/5.0.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. 获取所需的二进制文件

+

要编译bootloader，您需要将这些文件复制到您的 u-boot-phytec 编译目录，并将其重命名以适应 mkimage 脚本：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx8mp.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以在yocto工程目录中获取 bl31-imx8mp.bin、tee.bin和lpddr4_*.bin：BSP Images

+

或者你可以在这里下载文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/

+
+

警告

+

确保您重命名所需的文件，以和 mkimage tool 兼容。

+
+
+
+

5.5.3. 编译bootloader

+
    +

  • 编译 flash.bin (imx-boot):

    +
    host:~/u-boot-phytec$ make phycore-imx8mp_defconfig
+host:~/u-boot-phytec$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. 将bootloader烧写到块设备上

+

flash.bin 文件可以在 u-boot-phytec/ 目录下找到，现在可以进行烧写。需要指定芯片特定的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

例如，烧写SD卡：

+
host:~/u-boot-phytec$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+

5.5.5. 使用固定内存大小编译U-Boot

+

如果您的系统因为EEPROM中的硬件信息损坏或丢失而无法启动，您可以创建一个具有固定RAM大小的flash.bin。但您仍应联系我们支持部门以烧写正确的EEPROM数据。

+

按照步骤获取U-boot源代码，并切换到 Build U-Boot 章节说明的分支。

+

Edit the file configs/phycore-imx8mp_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+
+
+

选择正确的RAM大小，确保与核心板上的贴装的器件一致，取消注释该RAM大小的行。保存更改后，按照 Build U-Boot 章节的剩余步骤进行操作。

+
+
+

5.5.6. 编译支持固定RAM大小与频率的U-Boot

+

从PD23.1.0 NXP或PD24.1.2 Mainline 版本开始，PCB为1549.3版本的核心板及更新版本的phyCORE-i.MX 8M Plus SoM支持2GHz内存时序。这些将在支持的板上自动启用，但也可以手动启用或禁用。

+

Edit the file configs/phycore-imx8mp_defconfig. +The fixed RAM size with 2GHz timings will be used:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+CONFIG_PHYCORE_IMX8MP_RAM_FREQ_FIX=y
+CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+
+
+

在保存更改后，按照 Build U-Boot 中剩下的步骤操作。

+
+
+

5.5.7. 编译固定的RAM频率的U-Boot

+

从PD24.1.2 Mainline版本或者 PD24.1.0 NXP 版本开始，U-Boot可以编译成只固定RAM频率，RAM大小还是保持从EEPROM读取。

+

Edit the file configs/phycore-imx8mp_defconfig. +The RAM size from EEPROM with fixed frequency will be used:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_FREQ_FIX=y
+# CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+# CONFIG_PHYCORE_IMX8MP_USE_1_5GHZ_RAM_TIMINGS=y
+
+
+

在保存更改后，按照 Build U-Boot 中剩下的步骤操作。

+
+
+
+

5.6. 单独编译内核

+
+

5.6.1. 配置源代码

+
    +

  • 使用的 linux-phytec 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v6.6.21-phy1

    • +

  • Check out 所需的 linux-phytec 标签：

    +
    host:~$ git clone https://github.com/phytec/linux-phytec.git
+host:~$ cd ~/linux-phytec/
+host:~/linux-phytec$ git fetch --all --tags
+host:~/linux-phytec$ git checkout tags/v6.6.21-phy1
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-phytec$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-phytec$ source /opt/ampliphy-xwayland/5.0.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-phytec$ make defconfig
+host:~/linux-phytec$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-phytec$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-phytec/arch/arm64/boot/Image 找到

    • +

  • dtb文件可以在 ~/linux-phytec/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-phytec$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. 将内核复制到SD卡

+

内核及module和对应的设备树二进制文件可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-phytec$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-phytec$ cp arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb /path/to/sdcard/boot/oftree
+host:~/linux-phytec$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. 获取BSP开发中版本

+
+

5.7.1. 当前release的开发中版本

+

这些release manifest文件是为了让您访问 Yocto BSP的开发版本。它们不会在phyLinux选择菜单中显示，需要手动选择。可以使用以下命令行来完成此操作：

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2
+
+
+

这将初始化一个BSP，用于跟踪当前版本（ BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 ）的最新开发版本。从现在开始，在此文件夹中执行 repo sync 将从我们的Git仓库中拉取所有最新的更改：

+
host:~$ repo sync
+
+
+
+
+

5.7.2. 即将发布版本的开发中版本

+

即将发布版本的开发中版本可以通过这种方式访问。请执行以下命令，并查找一个比最新版本（ BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 ）的PDXX.Y数字更高的版本，并且以 .y 结尾：

+
host:~$ ./phyLinux init -p imx8mp
+
+
+
+
+
+

5.8. 获取最新的Upstream支持

+

我们有一个使用Yocto主分支（不是NXP发布的）的manifest，他使用upstream的Linux和U-Boot。这可以用来测试最新的upstream kernel/U-Boot。

+
+

备注

+

master分支的manifest反映了最新的开发状态。有时会出现一些bug。我们会定期修复master分支。

+
+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.9.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将例如 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将例如 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz 镜像复制到其中。然后再次卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 8M Plus 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Board.dts - 包含module dtsi 文件。从SoC i.MX 8M Plus 引出并在底板使用的设备也包含在此 dts 中。

    • +

  • Overlay.dtso - 根据核心板或底板上可选硬件（例如 SPI 闪存或 PEB-AV-10）的情况来启用/禁用一些功能。

    • +
+

在Linux内核的根目录下，我们的 i.MX 8 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。下面是扩展板的硬件描述。对比源码中的include，overlay通过覆盖的方式来生效。overlay也可以根据实际开发板的硬件配置来设置设备树节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/ 中。

+

phyboard-pollux-imx8mp-3.conf 可用的overlay文件有：

+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 8M Plus BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 8M Plus BSP设备树概念部分，以了解我们的 i.MX 8 BSP设备树模型。

+

以下部分概述了 i.MX 8 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 8M Plus 引脚复用

+

该 i.MX 8M Plus Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 8M Plus 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 8M Plus 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是 imx8mp-phyboard-pollux-rdk.dts中UART1设备的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x140
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x140
+        >;
+};
+
+
+

字符串的第一部分 MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 指定了引脚（在这个例子中是 UART1_RXD）。字符串的第二部分（UART1_DCE_RX）是该引脚所选的复用项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部拉电阻是否被激活。在当前情况下，内部拉电阻被禁用。

+

UART1引脚复用的设备树：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L387

+
+
+

7.2. RS232/RS485

+

phyCORE-i.MX 8M Plus 支持最多 4 个 UART 单元。在 phyBOARD-Pollux 上，UART1（调试串口）和 UART4 的 TTL 电平信号被连接到 Silicon Labs CP2105 UART 到 USB 转换IC。这个 USB 信号通过 Micro-USB 连接器 X1 输出。UART3 位于 X6（扩展连接器），为 TTL 电平信号。UART2 连接到一个多协议收发器IC，可转换为 RS-232 或 RS-485，RS-232 和 RS-485 信号位于连接器 X2 。多协议配置通过主板上的跳线 JP3 和 JP4 完成。更多信息，请参阅 phyCORE-i.MX 8M Plus/phyBOARD-Pollux 硬件手册中的 UARTs 部分。

+

对于RS-232和RS-485，使用相同的设备树节点。RS485模式可以通过ioctl TIOCSRS485 来启用。双向通讯支持也可以通过ioctl进行配置。请查看我们的小示例应用程序rs485test，该程序也包含在BSP中。需要设置跳线 JP3 和 JP4 。

+
+

7.2.1. RS232

+
    +

  • 以人类可读的格式显示终端的当前设置：

    +
    target:~$ stty -a
+
    +
    +
    • +

  • UART接口的配置可以通过stty命令完成。例如：

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • 通过简单的echo和cat，可以测试基本的通信。示例：

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

主机应打印出 "123"。

+
+
+

7.2.2. RS485

+
+

提示

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

为了方便测试，请查看linux-serial-test。这个工具会通过调用RS485的IOCTL，发送恒定的数据流。

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

有关linux-serial-test工具及其参数的更多信息，请访问此链接：linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Linux kernel文档描述了如何在C代码中调用IOCTL： https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see "test" printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final "count for this session". There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+
+
+

7.2.2.2. RS485 full-duplex

+

For full-duplex mode your connection setup should look like this:

+../../../_images/RS485_fullduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For full-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 1
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  true
+Bus termination enabled:  false
+
+
+

Also here you can do the echo test to see if sending and receiving works:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see "test" printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

To check if the full-duplex operation works, you need to use the +linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=114660, tx=118755, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=118755, tx=114660, rx err=0
+
+
+

In this example both targets will send and receive simultaneously. They will +receive for 15sec and send for 10sec. The receiver needs to receive a bit +longer, so that all sent messages will get received. Remember to start both +targets almost simultaneously. A small difference in start time is accounted +for with the -W 2 option. At the end the program will print the final +"count for this session". There you can check that all transmitted frames were +received.

+

All the test examples are target to target, but can also be done with host to +target with a USB to rs485 converter. You may need to adjust the interfaces for +commands to work on the host then.

+

RS232和RS485的设备树： https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L251

+
+
+
+
+

7.3. 网络

+

phyBOARD-Pollux-i.MX 8M Plus 提供两个以太网接口。我们的核心板和底板各提供一个千兆以太网接口。

+
+

警告

+

硬件中的以太网接口命名约定（ethernet0 和 ethernet1）与Linux中的网络接口（eth0 和 eth1）不一致。因此，请注意这些差异：

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L41。

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Pollux can be found here: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L106

+
+

7.3.1. 网络配置

+
+

7.3.1.1. U-boot网络环境

+
    +

  • 我们目前在U-Boot中使用动态IP地址。这是通过以下这个变量启用的：

    +
    +
    u-boot=> printenv ip_dyn
+ip_dyn=yes
+
    +
    +
    +
    • +

  • 设置NFS的路径。一个示例如下：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+
+

7.3.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+
+

7.4. SD/MMC 卡

+

该 i.MX 8M Plus 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

MMC（SD卡插槽）接口的DT配置：https://github.com/phytec/linux-phytec//blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L261

+

eMMC接口的DT配置：https://github.com/phytec/linux-phytec//blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L181

+
+
+

7.5. eMMC设备

+

PHYTEC模块如phyCORE-i.MX 8M Plus 配备了eMMC存储芯片作为主要存储。eMMC设备使用多层单元（MLC）或三层单元（TLC）技术来实现存储，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 8M Plus ，并在Linux内核中作为块设备表示，如SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.5.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），该层负责处理原始MLC或TLC的磨损均衡、块管理和错误更正码（ECC）。这需要定期执行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 通过以下命令使能BKOPS_EN：

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.5.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 8M Plus SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.5.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
+
+

7.5.5. 启用伪SLC模式

+

eMMC设备使用 MLC或TLC 来存储数据。与NAND Flash中使用的SLC相比，MLC或TLC在成本更低的情况下，可靠性较低且错误率较高。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. 擦除设备

+

可以直接擦除eMMC设备，而不是通过写零覆盖。eMMC块管理算法将擦除底层的MLC或TLC，或者将这些块标记为可丢弃。设备上的数据将丢失，并将被读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.5.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 8M Plus 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.5.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

下表是 i.MX 8M Plus SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.6. SPI主设备

+

i.MX 8M Plus 控制器包含一个 FlexSPI 和一个 ECSPI IP 核。FlexSPI 主控制器支持两个 SPI 通道，最多可连接 4 个设备。每个通道支持单通道/双通道/四通道/八通道模式的数据传输（1/2/4/8 条数据线）。ECSPI 控制器支持 3 个 SPI 接口，每个接口都有一个专用的CS（chip select）引脚。由于CS也可通过 GPIO 实现，因此每个通道上可以连接多个设备。

+

在设备树中，SPI主节点的定义：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L67

+
+
+

7.7. GPIOs

+

phyBOARD-Pollux 具有一组专门用于GPIO的引脚。这些引脚直接连接到 i.MX 8M Plus 引脚，并被复用为 GPIO。它们可以直接在 Linux 用户空间中使用。处理器将其 GPIO 组织为5个GPIO组（GPIO1 – GPIO5），每个组包含 32 个GPIO。gpiochip0、gpiochip32、gpiochip64、gpiochip96 和 gpiochip128 是这些内部 i.MX 8M Plus GPIO 组 GPIO1 – GPIO5 的 sysfs 表示。

+

GPIO被标识为GPIO<X>_<Y>（例如：GPIO5_07）。<X>表示GPIO Bank，从1计数到5，而<Y>表示该Bank内的GPIO。<Y>从0计数到31（每个bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo -c gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如从gpiochip0的GPIO 20）：

    +
    target:~$ gpioget -c gpiochip0 20
+
    +
    +
    • +

  • 将gpiochip0上的GPIO 20的值设置为0并退出工具：

    +
    target:~$ gpioset -z -c gpiochip0 20=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <line=value>...
+
+Set values of GPIO lines.
+
+Lines are specified by name, or optionally by offset if the chip option
+is provided.
+Values may be '1' or '0', or equivalently 'active'/'inactive' or 'on'/'off'.
+
+The line output state is maintained until the process exits, but after that
+is not guaranteed.
+
+Options:
+      --banner            display a banner on successful startup
+  -b, --bias <bias>       specify the line bias
+                  Possible values: 'pull-down', 'pull-up', 'disabled'.
+                  (default is to leave bias unchanged)
+      --by-name           treat lines as names even if they would parse as an offset
+  -c, --chip <chip>       restrict scope to a particular chip
+  -C, --consumer <name>   consumer name applied to requested lines (default is 'gpioset')
+  -d, --drive <drive>     specify the line drive mode
+                  Possible values: 'push-pull', 'open-drain', 'open-source'.
+                  (default is 'push-pull')
+  -h, --help              display this help and exit
+  -l, --active-low        treat the line as active low
+  -p, --hold-period <period>
+                  the minimum time period to hold lines at the requested values
+  -s, --strict            abort if requested line names are not unique
+  -t, --toggle <period>[,period]...
+                  toggle the line(s) after the specified period(s)
+                  If the last period is non-zero then the sequence repeats.
+      --unquoted  don't quote line names
+  -v, --version           output version information and exit
+  -z, --daemonize set values then detach from the controlling terminal
+
+Chips:
+    A GPIO chip may be identified by number, name, or path.
+    e.g. '0', 'gpiochip0', and '/dev/gpiochip0' all refer to the same chip.
+
+Periods:
+    Periods are taken as milliseconds unless units are specified. e.g. 10us.
+    Supported units are 's', 'ms', and 'us'.
+
+*Note*
+    The state of a GPIO line controlled over the character device reverts to default
+    when the last process referencing the file descriptor representing the device file exits.
+    This means that it's wrong to run gpioset, have it exit and expect the line to continue
+    being driven high or low. It may happen if given pin is floating but it must be interpreted
+    as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.7.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用 CONFIG_GPIO_SYSFS 后才能支持。要在menuconfig中使 CONFIG_GPIO_SYSFS 可见，必须首先启用选项 CONFIG_EXPERT 。

+

您也可以将此选项添加到您在 Linux 内核源代码 arch/arm64/configs/ 目录下使用的 defconfig 中。例如，我们基于 NXP 的BSP版本，这个defconfig可以是 imx8_phytec_distro.config

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+
+
+
+

7.8. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

这里的 LED 灯包括蓝色的 mmc、绿色的 心跳和红色的 emmc，它们都在 phyBOARD-Pollux 上。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

GPIO的设备树配置：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L160

+
+
+

7.9. I²C总线

+

该 i.MX 8M Plus 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 8M Plus 的I²C模块。 本节描述了我们 phyBOARD-Pollux 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

I²C1 总线DT配置（例如 imx8mp-phycore-som.dtsi）： https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L81

+

I²C2总线DT配置（例如 imx8mp-phyboard-pollux-rdk.dts）： https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L145

+
+
+

7.10. EEPROM

+

在 phyCORE-i.MX8MP 上贴了一个 i2c 接口的 EEPROM 存储。它有两个地址。主 EEPROM 空间（总线：I2C-0 地址：0x51）可以通过 Linux 中的 sysfs 接口访问。主 EEPROM 的前 256 字节和 ID 页（总线：I2C-0 地址：0x59）用于板检测，不可修改。因此，ID 页不能通过 sysfs 接口访问。覆盖保留空间将导致启动问题。

+
+

备注

+

如果您删除了保留的EEPROM空间数据，请联系我们的支持团队！

+
+
+

7.10.1. phyCORE-i.MX8MP 上的I2C EEPROM

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

phyCORE-i.MX8MP SoM上的I2C EEPROM连接到I2C-0总线的I2C地址0x51。可以直接对该设备进行读写操作：

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

要用零填充4KiB的EEPROM（总线：I2C-0 地址：0x51），并保留EEPROM数据，请使用：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM 检测

+

在 phyCORE-i.MX8MP 上配置的I2C EEPROM具有一个可通过I2C地址0x59在i2c0上寻址的独立ID页面，以及一个可通过I2C地址0x51在i2c0上寻址的正常区域。PHYTEC使用这个32字节的数据区域来存储关于SoM的信息，包括PCB版本和配置。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果EEPROM ID页面数据和正常区域的前256个字节被删除，bootloader程序将回退到 phyCORE-i.MX8MP Kit RAM设置，即 2GiB RAM。

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

使用API修订版2数据格式烧写的核心板将在早期启动阶段打印出有关模块的信息。

+

核心板 phyCORE-i.MX 8M Plus 的设备树imx8mp-phycore-som.dtsi可以在PHYTEC git中找到： https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L169

+
+
+
+

7.11. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC参数

+

实时时钟（RTC）具有一些功能，可以通过 hwclock 工具进行读取和设置。

+
    +

  • 我们可以通过以下方式检查RTC支持的功能：

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    这个值的含义在内核中进行了编码，每个位的定义为：

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • 我们可以通过以下方式检查RTC BSM（Backup Switchover Mode 备份切换模式）：

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • 我们可以通过以下方式设置RTC BSM：

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    BSM位的定义为：

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    小技巧

    +

    您应该将BSM模式设置为DSM或LSM，以便在初始电源不可用时，RTC可以切换到备用电源。请查看 RV-3028 RTC的Datasheet，以了解LSM（电平切换模式）和DSM（直接切换模式）这两个定义的工作模式。

    +
    +
    • +
+

I²C RTCs 的设备树：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L175

+
+
+
+

7.12. USB主控制器

+

i.MX 8M Plus SoC的USB控制器为众多消费类便携设备提供了一种低成本的连接解决方案，实现USB设备之间的数据传输，传输速度可达4 Gbit/s（超高速'SS'）。USB子系统具有两个独立的USB控制器。这两个控制器都能够作为USBDevice或USB Host使用。每个核心都连接到一个USB 3.0物理层（PHY）。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+

USB Host的设备树：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L220

+
+
+

7.13. CAN FD

+

The phyBOARD-Pollux has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。两个CAN接口显示为can0和can1。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    can0的信息将如下所示：

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+
+

警告

+

mcp2518fd SPI到CAN FD只支持从125kB/s开始的波特率。可以选择更慢的速率，但可能无法正常工作。

+
+

Device Tree CAN configuration of imx8mp-phyboard-pollux-rdk.dts: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L130

+
+
+

7.14. 视频

+
+

7.14.1. 视频与Gstreamer

+

默认情况下，BSP安装了一个示例视频，路径为 /usr/share/qtphy/videos/ 。可以使用以下命令之一开始视频播放：

+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink fullscreen=true
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+

备注

+

Mainline BSP目前仅支持软件渲染。

+
+
+
+
+

7.15. 显示

+

phyBOARD-Pollux 通过开发板上的LVDS1连接器支持LVDS输出。LVDS接口默认启用。

+
+

7.15.1. Weston 配置

+

Weston可以在无需额外配置的情况下运行。配置选项位于 /etc/xdg/weston/weston.ini。

+

LVDS的设备树：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L182

+
+
+

7.15.2. Qt Demo

+

使用 phytec-qt6demo-image 时，Weston会在启动时启动。我们的Qt6 DEMO应用程序名为“qtphy”，可以通过以下方式停止：

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • 要重新开始Demo，请运行：

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • 要禁用Demo的自动启动，请运行：

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • 要启用Demo的自动启动，请运行：

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston可以通过以下方式停止：

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

备注

+

在关闭Weston之前，必须先关闭Qt Demo。

+
+
+
+

7.15.3. 背光控制

+

如果LCD连接到PHYTEC开发板，可以通过Linux内核的sysfs接口控制其背光。系统中所有可用的背光设备可以在文件夹/sys/class/backlight中找到。读取相应的文件并向其写入数据可以控制背光。

+
+

备注

+

一些具有多显示的开发板在 /sys/class/backlight 有多个背光控制。比如：backlight0和backlight1

+
+
    +

  • 例如，要获取最大亮度级别（max_brightness），请执行：

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    有效的亮度值范围是 0 到 <max_brightness>。

    +
    • +

  • 要获取当前亮度级别，请输入：

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • 写入文件brightness以更改亮度：

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    例如，关闭背光。

    +

    有关所有文件的文档，请参见 https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight。

    +
    • +
+
+

备注

+

我们注意到在亮度级别1上有一些明显的背光闪烁（可能是由于硬件频率问题导致的）。

+
+
+
+
+

7.16. 电源管理

+
+

7.16.1. CPU核心频率调节

+

i.MX 8M Plus SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。调整频率和电压被称为“动态电压和频率调整”（DVFS）。i.MX 8M Plus BSP支持DVFS功能。Linux内核提供了一个DVFS框架，允许每个CPU核心设置最小或最大频率和一个管理其运行的governor。根据使用的 i.MX 8 型号，支持几种不同的频率。

+
+

小技巧

+

尽管DVFS框架为每个CPU核心提供了频率设置，但一个CPU核心的频率更改会影响其他CPU核心。因此，所有CPU核心始终共享相同的DVFS设置。每个核心的单独DVFS设置是不可能的。

+
+
    +

  • 要获取完整列表，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    例如 i.MX 8MPlus CPU，最高可达约 1.6 GHz，则结果将是：

    +
    1200000 1600000
+
    +
    +
    • +

  • 要查询当前的频率输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

governor 会根据它们的目标自动选择这些频率中的一个。

+
    +

  • 列出所有可用的 governor，使用以下命令：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    结果是：

    +
    ondemand userspace performance schedutil
+
    +
    +
    • +

  • ondemand （默认）根据当前系统负载在可能的CPU核心频率之间切换。当系统负载超过特定值时，它会立即提高CPU核心频率。

    • +

  • performance 始终选择最高的CPU核心频率。

    • +

  • userspace 允许以root身份运行的用户或用户空间程序设置特定频率（例如，设置为1600000）。输入：

    • +

  • 要查询当前的 governor，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    您通常会得到：

    +
    schedutil
+
    +
    +
    • +

  • 切换到另一个governor（例如，userspace）可以通过以下方式完成：

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • 现在你可以设置频率：

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

有关governor的更详细信息，请参阅Linux内核代码库中的Linux内核文档，路径为 Documentation/admin-guide/pm/cpufreq.rst 。

+
+
+

7.16.2. CPU核心管理

+

该 i.MX 8M Plus SoC 芯片上可以有多个处理器核心。例如，该 i.MX 8M Plus 具有 4 个 ARM 核心，可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    这里系统有四个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+
+

7.17. 热管理

+
+

7.17.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.17.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 8M Plus SoC 平台上使用热管理内核 API。 i.MX 8 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个触发点。这些触发点根据CPU型号的不同而有所不同。主要区分工业版和商业版。

+ + + + + + + + + + + + + + + + + +

商业

工业

被动（警告）

85°C

95°C

严重（关机）

90°C

100°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并实施冷却措施。内核中可用的热政策（也称为thermal governor）包括：Step Wise、Fair Share、Bang Bang和Userspace。BSP中使用的默认策略是Step Wise。如果sysfs文件temp中的SoC温度值高于 trip_point_0 ，则CPU频率将设置为最低CPU频率。当SoC温度降到 trip_point_0 以下时，限制将被解除。

+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+
+

7.18. 看门狗

+

PHYTEC i.MX 8M Plus 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.18.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.19. snvs电源按键

+

连接到开/关按钮的 X_ONOFF 引脚可以长按以触发关机，而无需软件干预。使用 snvs_pwrkey 驱动程序时，当按下按钮时，KEY_POWER 事件也会报告给用户空间。默认情况下，systemd 被配置为忽略此类事件。无软件干预的关机功能没有配置。可以在 /etc/systemd/logind.conf 中配置在按下开/关按钮时通过 systemd 触发关机：

+
HandlePowerKey=poweroff
+
+
+
+
+

7.20. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 8M Plus 提供一次性可编程fuse，用于存储信息，例如 MAC 地址、启动配置和其他永久设置（在 i.MX 8M Plus reference manual中称为“片上 OTP 控制器 (OCOTP_CTRL)”）。以下列表摘自 i.MX 8M Plus reference manual，包括 OCOTP_CTRL 中的一些有用寄存器（基地址为0x30350000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为0x30350000

描述

OCOTP_MAC_ADDR0

9

0

0x640

包含ENET0 MAC地址的低32位

OCOTP_MAC_ADDR1

9

1

0x650

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

OCOTP_MAC_ADDR2

9

2

0x660

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 8M Plus Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.20.1. 在uBoot中读取fuse的值

+

您可以使用内存映射的shadow寄存器读取fuse寄存器。要计算内存地址，请使用以下公式计算：

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.20.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mp/pd22.1.1.html b/previews/271/zh_CN/bsp/imx8/imx8mp/pd22.1.1.html new file mode 100644 index 000000000..7efa11773 --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mp/pd22.1.1.html @@ -0,0 +1,3761 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 8M Plus BSP手册

文档标题

i.MX 8M Plus BSP手册

文档类型

BSP 手册

Yocto 手册

发布日期

2023/05/25

母文档

i.MX 8M Plus BSP手册

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP 发布日期

BSP 状态

BSP-Yocto-NXP-i.MX8MP-PD22.1.1

小更新

2023/05/23

已发布

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 phyCORE-i.MX8M Plus Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads 中找到。

+
+

1.1. 支持的硬件

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-NXP-i.MX8MP-PD22.1.1 的所有Machine及其对应的Article Numbers(产品型号)： 网页.

+

如果您在“Supported Machines”一栏选择了特定的 Machine Name ，您可以查看该machine下可用的 Article Numbers 以及硬件信息的简短描述。如果您只有硬件的 Article Numbers ，您可以将 Machine Name 下拉菜单留空，仅选择您的 Article Numbers 。现在，它应该会显示您特定硬件所需的 Machine Name

+
+

1.1.1. phyBOARD-Pollux 器件

+
+../../../_images/phyBOARD-Pollux-front-components.jpg + +
+

phyBOARD-Pollux 器件图（顶部）

+
+
+
+../../../_images/phyBOARD-Pollux-back-components.jpg + +
+

phyBOARD-Pollux 器件图（底部）

+
+
+
+
+
+
+

2. 开始使用

+

该 phyCORE-i.MX8M Plus Kit 包含预先烧写好的SD卡。它包含 phytec-qt5demo-image ，可以直接用作启动盘。默认情况下，核心板的eMMC仅烧写了U-boot。您可以从 PHYTEC下载服务器 获取所有源代码。本章解释了如何将BSP镜像烧录到SD卡以及如何启动开发板。

+
+

2.1. 下载镜像

+

WIC镜像包含预先格式化的分区信息以及分区中包含的BSP文件，可以使用单个Linux命令 dd 轻松写入到SD卡上。WIC镜像可以通过Yocto编译或从PHYTEC下载服务器下载。

+

从下载服务器获取WIC文件：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要使用 dd 命令创建SD卡启动盘，您必须具有root权限。在使用 dd 指定目标设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行该命令：

    +
    host$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+
    +

  • 卸载所有分区，例如：

    +
    host$ sudo umount /dev/sde1
+
    +
    +
    • +

  • 在卸载所有分区后，您可以创建SD卡启动盘：

    +
    host$ sudo dd if=<IMAGENAME>-<MACHINE>.wic of=/dev/sdX bs=1M conv=fsync status=progress
+
    +
    +

    再次确保将 /dev/sdX 替换为之前找到的设备名称。

    +

    参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

    +
    • +
+

准备SD卡启动盘的另一种更快的方法是使用Intel的 bmap-tools 。Yocto会自动为WIC镜像创建一个block map文件（ <IMAGENAME>-<MACHINE>.wic.bmap ），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host$ bmaptool copy <IMAGENAME>-<MACHINE>.wic /dev/<your_device>
+
+
+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.3. 首次启动

+ +../../../_images/SD_Card_Boot1.png +
    +

  • 插入SD卡

    • +

  • 使用 micro USB 线将开发板的 (X1) 调试USB口和主机连接起来

    • +

  • 给开发板通电

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: L-813e.A12 Yocto Reference Manual (Hardknott).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +L-813e.A12 Yocto Reference Manual (Hardknott).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-IMX8MP ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-xwayland MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD22.1.1
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-qt5demo-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 phyboard-pollux-imx8mp-3 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx8mp.bin: ARM可信固件二进制文件

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY固件镜像

    • +

  • imx-boot：由imx-mkimage编译的bootloader镜像，包括SPL、U-Boot、ARM可信固件和DDR固件。这是最终的可引导bootloader镜像。

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx8mp-phyboard-pollux-rdk*.dtb: 内核设备树文件

    • +

  • imx8mp-phy*.dtbo: 内核设备树overlay文件

    • +

  • phytec-qt5demo-image*.tar.gz: 根文件系统

    • +

  • phytec-qt5demo-image*.wic: SD卡镜像

    • +
+
+
+
+
+

4. 安装操作系统

+
+

4.1. 启动模式开关 (S3)

+
+

小技巧

+

硬件修订版底板：1552.2

+
+

该 phyBOARD-Pollux 具有一个（启动源配置）开关，配有四个可单独切换的位，用于选择phyCORE-i.MX 8M Plus 默认的启动源。

+ + + + + + + + + + + +
+../../../_images/eMMC1.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses1.png +
+

内部fuse

+
+
+
+../../../_images/SPI_NOR.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download1.png +
+

USB

+
+
+
+../../../_images/SD_Card_Boot1.png +
+

SD卡

+
+
+
+../../../_images/Test_Mode.png +
+

测试模式

+
+
+
+
+
+

4.2. 烧写eMMC

+

要从eMMC启动，请确保BSP镜像已正确烧录到eMMC，并且 bootmode switch (S3) 设置为 默认SOM启动 。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行上述命令来检查系统启动在这种条件下是否会到影响。如果 mmcblk2p1 和 mmcblk1p1 具有相同的UUID，则会影响系统正确启动。

+
+
+

4.2.1. 从网络烧写 eMMC

+

i.MX 8M Plus 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

4.2.1.1. 在开发板的u-boot环境中从网络烧写eMMC

+

这些步骤将展示如何通过网络更新eMMC。然而，此步骤仅在镜像文件小于1GB的情况下会被执行成功。如果镜像文件更大，请转到“格式化SD卡”一节。配置 bootmode switch (S3) 以从SD卡启动，并插入一张SD卡。给开发板上电并进入U-Boot环境。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+
    +

  • 通过网络将您的镜像加载到内存中：

    +
    u-boot=> tftp ${loadaddr} phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • 将镜像写入eMMC：

    +
    u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +
+
+
+

4.2.1.2. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！设置主机网络。

+
+

使用一条命令，通过网络ssh协议将带有块映射的压缩或未压缩的镜像发送到开发板的eMMC上使用,执行：

+
target:~$ ssh <USER>@192.168.3.10 "dd if=<path_to_file>/phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic" | dd of=/dev/mmcblk2
+
+
+
+
+

4.2.1.3. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！设置主机网络。

+
+

查看主机上可用的镜像文件：

+
host:~$ ls
+phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
+
+

通过网络使用ssh将镜像用dd命令发送到您设备的eMMC：

+
host:~$ dd if=phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2"
+
+
+
+
+
+

4.2.2. 在u-boot中通过网络烧写eMMC u-boot镜像

+

如果eMMC上的bootloader位于eMMC的User区，从u-boot中更新独立的u-boot镜像imx-boot也是可能的。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！设置主机网络。

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.3. 从USB烧写eMMC

+
+

4.2.3.1. 在u-boot上从USB烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1GB时有效，因为在启用OPTEE后，Bootloader中可用的RAM大小有限。

+
+

下面这些步骤展示如何通过USB设备更新eMMC。将启动模式开关配置为 bootmode switch (S3) 并插入SD卡。给开发板上电并进入U-Boot环境。将已存储了未压缩WIC镜像的优盘插入开发板USB接口。

+

将镜像从USB设备加载到RAM中：

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} *.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. 在运行的Linux系统中从USB烧写eMMC

+

下面这些步骤展示如何在Linux系统上使用USB大容量存储设备烧写eMMC。您需要一个保存了完整镜像的U盘和一个可从SD卡启动的核心板（例如 phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic）。将引导模式开关设置为 bootmode switch (S3)。

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ cd /mnt
+target:~$ ls
+phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
    +
    +
    • +

  • 显示可用的MMC设备列表：

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • eMMC设备的特征是它包含两个boot分区：(mmcblk2boot0; mmcblk2boot1)

    • +

  • 将镜像写入 phyCORE-i.MX 8M Plus eMMC（无分区的 MMC 设备 2）：

    +
    target:~$ dd if=phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic of=/dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    • +
+
+

警告

+

在此之前，您需要将启动配置开关配置 bootmode switch (S3) 设置为 默认SOM启动。

+
+
+
+
+

4.2.4. 从SD卡烧写eMMC

+

即使没有可用的网络，您也可以更新eMMC。为此，您需要一个位于SD卡上的镜像文件（*.wic）。由于镜像文件相当大，您需要扩展SD卡以使用其全部空间（如果之前没有扩展的话）。有关如何扩展SD卡，请参阅调整 ext4 根文件系统的大小一节。

+
+

4.2.4.1. 在u-boot上从SD卡烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1GB的情况下有效，因为在启用OPTEE后，Bootloader中可用的RAM大小有限。如果镜像文件太大，请使用“在目标上使用Linux从SD卡更新eMMC”一节。

+
+
    +

  • 将一个可用的镜像烧写到SD卡，并创建一个FAT格式的第三分区。将WIC镜像（例如 phytec-qt5demo-image.wic）复制到该分区。

    • +

  • 将启动模式开关配置为从SD卡启动，并插入SD卡。

    • +

  • 给开发板上电并进入u-boot环境。

    • +

  • 将您的WIC镜像（例如 phytec-qt5demo-image.wic）从SD卡烧写到eMMC。这将对卡进行分区，并将imx-boot、Image、dtb、dtbo和根文件系统复制到eMMC。

    • +

  • 加载镜像：

    +
    u-boot=> fatload mmc 1:3 ${loadaddr} phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • 切换mmc设备：

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc0(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • 关闭电源，将启动模式开关切换到默认SOM启动，以从eMMC启动。

    • +
+
+
+

4.2.4.2. 在开发板的linux环境中通过SD卡烧写eMMC

+

您也可以在Linux上烧写eMMC。您只需在SD卡上保存一个完整的镜像（例如 phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic）。

+
    +

  • 查看您在SD卡上保存的镜像文件：

    +
    target:~$ ls
+phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
    +
    +
    • +

  • 显示可用的MMC设备列表：

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • eMMC设备的特征是它包含两个boot分区：(mmcblk2 boot0; mmcblk2 boot1)

    • +

  • 将镜像写入 phyCORE-i.MX 8M Plus 的 eMMC (MMC 设备 2 不带 分区)：

    +
    target:~$ dd if=phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic of=/dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    • +
+
+

警告

+

在此之前，您需要将 bootmode switch (S3) 配置为默认SOM启动，以从eMMC启动。

+
+
+
+
+
+

4.3. 烧写 SPI NOR Flash

+

phyCORE-i.MX8MP 模块可选配SPI NOR Flash。要从SPI Flash启动，请将 bootmode switch (S3) 设置为 QSPI启动 以从QSPI启动。SPI Flash通常容量较小。phyBOARD-Pollux-i.MX8MP套件仅配备32MB SPI NOR Flash。只能存储bootloader及其环境。内核、设备树和文件系统默认保存在eMMC。

+

SPI NOR Flash分区表在U-Boot环境变量中定义。可以通过以下命令打印：

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. 通过网络烧写SPI NOR Flash

+

SPI NOR可以包含bootloader及其环境变量。arm64的linux内核无法自行解压缩，内核镜像大小超出了phyCORE-i.MX 8M Plus 上的SPI NOR Flash的容量。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！设置主机网络。

+
+
+

4.3.1.1. 在开发板的u-boot环境中从网络烧写SPI NOR

+

与通过网络更新eMMC类似，请确保正确设置开发主机。IP需要设置为192.168.3.10，子网掩码设置为255.255.255.0，并且需要有一个TFTP服务器。在进行读写操作之前，需要对SPI-NOR Flash进行probe：

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • 需要用特殊格式的SPI NOR Flash u-boot镜像。请确保使用正确的镜像文件。通过tftp加载镜像，擦除并将bootloader写入flash：

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+

警告

+

在写满后擦除整个SPI NOR Flash将需要相当长的时间。这可能会触发看门狗复位。因此，请在Linux中擦除整个闪存。

+
+
+
+

4.3.1.2. 在开发板linux环境中通过网络烧写SPI NOR Flash

+
    +

  • 将镜像从主机复制到开发板：

    +
    host:~$ scp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • 找到U-boot分区的擦除块数量：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除u-boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+

4.3.2. 从SD卡烧写SPI NOR Flash

+

SPI NOR Flash上的bootloader也可以通过SD卡进行烧写。

+
+

4.3.2.1. 在开发板的u-boot环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi复制到SD卡的FAT分区。在进行读写操作之前，需要对SPI-NOR flash进行probe：

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像，请确保使用正确的镜像文件。从SD卡加载镜像，擦除并将bootloader写入flash：

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+

警告

+

在写满后擦除整个SPI NOR Flash将需要相当长的时间。这可能会触发看门狗复位。因此，请在Linux中擦除整个闪存。

+
+
+
+

4.3.2.2. 在开发板的linux环境中从SD卡烧写SPI NOR

+
    +

  • 挂载SD卡：

    +
    host:~$ mount /dev/mmcblkp1 /mnt
+
    +
    +
    • +

  • 查找u-boot分区的擦除块数量：

    +
    target:~$  mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除u-boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC：L-1006e.A3 RAUC 更新与设备管理手册。

+
+
+
+

5. 开发

+
+

5.1. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.1.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.2. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.2.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核镜像复制到您的tftp目录中：

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • 将设备树复制到您的tftp目录：

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • 将您想要使用的所有overlay文件复制到您的tftp目录中：

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-qt5demo-image-phyboard-pollux-imx8mp-3.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.2.2. 设置网络启动的bootenv.txt文件

+

在您的tftp目录中创建一个bootenv.txt文件，并将以下变量写入其中。

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> 必须替换为您想要使用的overlay设备树文件名。用空格分隔文件名。例如：

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

小技巧

+

所有支持的设备树overlay在 device tree 章节中。

+
+
+
+

5.2.3. 开发板上的网络设置

+

如果要自定义开发板上的以太网配置，请按照此处的说明进行操作： Network Environment Customization

+
+
+

5.2.4. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.3.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. 获取镜像

+

可以从我们的服务器下载imx-boot，或者从Yocto编译目录中的build/deploy/images/phyboard-pollux-imx8mp-3/获取它。要将wic镜像烧写到eMMC，你还需要 phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic。

+
+
+

5.3.3. 开发板准备

+

将 bootmode switch (S3) 设置为 USB串行下载。同时，将 USB 端口 X5 (upper connector) 连接到主机。

+
+
+

5.3.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 (X1) 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.3.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
+
+
+
+
+

5.4. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone git://git.phytec.de/u-boot-imx）

+
+
+

5.4.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-imx 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • 我们的 i.MX 8M Plus 内核是基于 linux-imx 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. 获取SDK

+

您可以在此处下载SDK 这里，或者使用Yocto去编译生成SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt5demo-image # or another image
+
    +
    +
    • +
+

在成功编译后，SDK安装包保存在 build/deploy*/sdk。

+
+
+

5.4.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt5demo-image-cortexa53-crypto-toolchain-BSP-Yocto-NXP-i.MX8MP-PD22.1.1.sh
+host:~$ ./phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt5demo-image-cortexa53-crypto-toolchain-BSP-Yocto-NXP-i.MX8MP-PD22.1.1.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.1):
+You are about to install the SDK to "/opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.1". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. 单独编译U-Boot

+
+

5.5.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本的 tag 称为 v2021.04_2.2.0-phy13

    • +

  • 查看所需的 U-Boot tag：

    • +
+
host:~$ cd ~/u-boot-imx/
+host:~$ git fetch --all --tags
+host:~$ git checkout tags/v2021.04_2.2.0-phy13
+
+
+
    +

  • 从技术上讲，您现在可以编译U-Boot，但实际上还需要一些进一步的步骤：

    +
      +

    • 创建您自己的开发分支：

      +
      host:~$ git switch --create <new-branch>
+
      +
      +
      +

      备注

      +

      您可以根据您的需要自行命名您的开发分支，这只是一个示例。

      +
      +
      • +
    +
    • +

  • 设置编译环境：

    +
    host:~$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +

  • 在编译镜像之前，请设置此环境变量：

    +
    host:~$ export ATF_LOAD_ADDR=0x970000
+
    +
    +
    • +
+
+
+

5.5.2. 获取所需的二进制文件

+

要编译bootloader，您需要将这些文件复制到您的 u-boot-imx 编译目录，并将其重命名以适应 mkimage 脚本：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx8mp.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以在yocto工程目录中获取 bl31-imx8mp.bin、tee.bin和lpddr4_*.bin：BSP Images

+

或者你可以在这里下载文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/

+
+

警告

+

确保您重命名所需的文件，以和 mkimage tool 兼容。

+
+
+
+

5.5.3. 编译bootloader

+
    +

  • 编译 flash.bin (imx-boot):

    +
    host:~$ make phycore-imx8mp_defconfig
+host:~$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. 将bootloader烧写到块设备上

+

flash.bin 文件可以在 u-boot-imx/ 目录中找到。需要一个特定于芯片的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

例如，烧写SD卡：

+
host:~$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+

5.5.5. 使用固定内存大小编译U-Boot

+

如果您的系统因为EEPROM中的硬件信息损坏或丢失而无法启动，您可以创建一个具有固定RAM大小的flash.bin。但您仍应联系我们支持部门以烧写正确的EEPROM数据。

+

按照步骤获取U-boot源代码，并切换到 Build U-Boot 章节说明的分支。

+

Edit the file configs/phycore-imx8mp_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+
+
+

选择正确的RAM大小，确保与核心板上的贴装的器件一致，取消注释该RAM大小的行。保存更改后，按照 Build U-Boot 章节的剩余步骤进行操作。

+
+
+
+

5.6. 单独编译内核

+
+

5.6.1. 配置源代码

+
    +

  • 使用的 linux-imx 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v5.10.72_2.2.0-phy17

    • +

  • Check out 所需的 linux-imx 标签：

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v5.10.72_2.2.0-phy17
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-imx$ make imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-imx/arch/arm64/boot/Image 找到

    • +

  • dtb文件可以在 ~/linux-imx/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. 将内核复制到SD卡

+

内核及module和对应的设备树二进制文件可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. 获取BSP开发中版本

+
+

5.7.1. 当前release的开发中版本

+

这些release manifest文件是为了让您访问 Yocto BSP的开发版本。它们不会在phyLinux选择菜单中显示，需要手动选择。可以使用以下命令行来完成此操作：

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD22.1.y
+
+
+

这将初始化一个BSP，用于跟踪当前版本（ BSP-Yocto-NXP-i.MX8MP-PD22.1.1 ）的最新开发版本。从现在开始，在此文件夹中执行 repo sync 将从我们的Git仓库中拉取所有最新的更改：

+
host:~$ repo sync
+
+
+
+
+

5.7.2. 即将发布版本的开发中版本

+

即将发布版本的开发中版本可以通过这种方式访问。请执行以下命令，并查找一个比最新版本（ BSP-Yocto-NXP-i.MX8MP-PD22.1.1 ）的PDXX.Y数字更高的版本，并且以 .y 结尾：

+
host:~$ ./phyLinux init -p imx8mp
+
+
+
+
+
+

5.8. 获取最新的Upstream支持

+

我们有一个使用Yocto主分支（不是NXP发布的）的manifest，他使用upstream的Linux和U-Boot。这可以用来测试最新的upstream kernel/U-Boot。

+
+

备注

+

master分支的manifest反映了最新的开发状态。有时会出现一些bug。我们会定期修复master分支。

+
+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.9.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将 phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将 phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic 镜像复制到其中。然后卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 8M Plus 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Carrierboard.dtsi - 包括来自于 i.MX 8M Plus SoC 的外设，在底板上使用的外设的设备树配置包含在这个 dtsi 中。

    • +

  • Board.dts - 包含底板和核心板的dtsi文件。以及使能一些底板或核心板上的器件和配置。例如，phyCORE-i.MX 8M Plus 核心板可能安装MIPI DSI到LVDS的转换器也可能没有，则Board.dts文件会根据安装情况来对该转换器进行使能配置。而不是在Module.dtsi中配置

    • +
+

在Linux内核的根目录下，我们的 i.MX 8 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。例如扩展板的硬件描述。对比源码中的include，overlay是用覆盖的方式来生效。overlay也可以根据节点是否连接来设置节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/overlays 中。

+

phyboard-pollux-imx8mp-3.conf 可用的overlay文件有：

+
imx8mp-isi-csi1.dtbo
+imx8mp-isi-csi2.dtbo
+imx8mp-isp-csi1.dtbo
+imx8mp-isp-csi2.dtbo
+imx8mp-phyboard-pollux-peb-av-010.dtbo
+imx8mp-phyboard-pollux-peb-av-012.dtbo
+imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+imx8mp-phycore-no-eth.dtbo
+imx8mp-phycore-no-rtc.dtbo
+imx8mp-phycore-no-spiflash.dtbo
+imx8mp-phycore-rpmsg.dtbo
+imx8mp-vm016-csi1.dtbo
+imx8mp-vm016-csi1-fpdlink.dtbo
+imx8mp-vm016-csi2.dtbo
+imx8mp-vm016-csi2-fpdlink.dtbo
+imx8mp-vm017-csi1.dtbo
+imx8mp-vm017-csi1-fpdlink.dtbo
+imx8mp-vm017-csi2.dtbo
+imx8mp-vm017-csi2-fpdlink.dtbo
+
+
+
+

提示

+

phyboard-pollux-imx8mp-2.conf还有一个可用的overlay文件：imx8mp-phyboard-pollux-1552.1.dtbo

+
+

可以在Linux或U-Boot环境下配置overlay。overlay是在引导命令调用后、内核加载之前生效。接下来的部分将更详细地解释配置方法。

+
+

6.2.2.1. 设置 ${overlays} 变量

+

${overlays} U-Boot 环境变量包含一个以空格分隔的overlay文件列表，这些overlay文件将在启动过程中应用。根据启动源，overlay文件必须放置在 eMMC/SD 卡的启动分区中，或者通过 tftp 加载。在 $KERNEL_DEVICETREE 这个 Yocto machine 变量中设置的 overlay 文件将自动添加到最终 WIC 镜像的启动分区中。

+

${overlays} 变量可以直接在U-Boot环境中设置，也可以作为外部 bootenv.txt 环境文件的一部分。默认情况下， ${overlays} 变量来自位于启动分区的 bootenv.txt 文件。您可以在已启动的开发板上从Linux读取和写入该文件：

+
target:~$ cat /boot/bootenv.txt
+overlays=imx8mp-phyboard-pollux-rdk-peb-eval-01.dtbo imx8mp-phyboard-pollux-peb-av-010.dtbo
+
+
+

更改将在下次重启后生效。如果没有可用的 bootenv.txt 文件，可以直接在U-Boot环境中设置overlay变量。

+
u-boot=> setenv overlays imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> printenv overlays
+overlays=imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> boot
+
+
+

如果用户定义了 ${overlays} 变量，同时存在 bootenv.txt 文件，则需要设置 ${no_bootenv} 变量：

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> boot
+
+
+

有关环境的更多信息，请参见 U-boot External Environment subsection of the +device tree overlay section。

+

我们使用 ${overlays} 变量来描述在运行时无法自动检测的扩展板和摄像头。如果想禁用 ${overlays} 变量中列出的overlay，可以在U-Boot的环境中将 ${no_overlays} 变量设置为 1。

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+

6.2.2.2. 扩展命令

+

使用U-Boot扩展命令能够轻松加载由回调函数 extension_board_scan() 检测并添加到列表中的overlay。以这种方式应用的overlay会禁用核心板上未贴装的组件。检测是通过读取出厂EEPROM数据（EEPROM SoM Detection）来实现的。

+

这取决于核心板型号是否会应用任何设备树overlay。要检查在U-Boot中运行的SoM是否会应用overlay，请运行：

+
u-boot=> extension scan
+Found 1 extension board(s).
+u-boot=> extension list
+Extension 0: phyCORE-i.MX8MP no SPI flash
+        Manufacturer:           PHYTEC
+        Version:
+        Devicetree overlay:     imx8mp-phycore-no-spiflash.dtbo
+        Other information:      SPI flash not populated on SoM
+
+
+

如果没有可用的EEPROM数据，则不加载任何设备树overlay。

+

为了禁止在启动时自动运行扩展命令，可以在bootloader环境中将 ${no_extensions} 变量设置为 1 ：

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot外部环境

+

在Linux内核启动时，外部环境 bootenv.txt 文本文件将从MMC设备的boot分区或通过TFTP加载。该文件的主要目的是存储 ${overlays} 变量。这可以针对不同的machine在Yocto中预定义不同的overlay配置。文件的内容在meta-phytec中的Yocto recipe中的bootenv中定义： https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=hardknott

+

该文件中也可以设置其他变量。这些变量将覆盖环境中现有的设置。但只有对boot命令后进行计算的变量生效，例如 ${nfsroot} 或 ${mmcargs}。在文件中更改其他变量将不会有作用。以网络启动的用法作为示例。

+

如果无法加载外部环境，启动过程将继续进行，并使用自带的环境变量值。

+
+
+

6.2.4. 在Linux环境下更改开发板上的U-boot环境变量

+

Libubootenv是我们镜像中包含的一个工具，用于在开发板linux上修改U-Boot环境。

+

使用以下命令打印U-Boot环境：

+
target:~$ fw_printenv
+
+
+

使用以下命令修改U-Boot环境：

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

小心

+

Libubootenv会读取配置文件中配置的环境变量。要修改的环境变量会被插入到该文件中，默认情况下使用eMMC中存储环境变量。

+

如果eMMC没有被烧写过或者eMMC环境被擦除，libubootenv将无法工作。您应该修改 /etc/fw_env.config 文件，以匹配您想要使用的环境源。

+
+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 8M Plus BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 8M Plus BSP设备树概念部分，以了解我们的 i.MX 8 BSP设备树模型。

+

以下部分概述了 i.MX 8 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 8M Plus 引脚复用

+

该 i.MX 8M Plus Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 8M Plus 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 8M Plus 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是imx8mp-phyboard-pollux.dtsi中UART1的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x49
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x49
+        >;
+};
+
+
+

字符串的第一部分 MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 指定了引脚（在这个例子中是 UART1_RXD）。字符串的第二部分（UART1_DCE_RX）是该引脚所选的复用项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部拉电阻是否被激活。在当前情况下，内部拉电阻被禁用。

+
+
+

7.2. RS232/RS485

+

phyCORE-i.MX 8M Plus 支持最多 4 个 UART 单元。在 phyBOARD-Pollux 上，UART1（调试串口）和 UART4 的 TTL 电平信号被连接到 Silicon Labs CP2105 UART 到 USB 转换IC。这个 USB 信号通过 Micro-USB 连接器 X1 输出。UART3 位于 X6（扩展连接器），为 TTL 电平信号。UART2 连接到一个多协议收发器IC，可转换为 RS-232 或 RS-485，RS-232 和 RS-485 信号位于连接器 X2 。多协议配置通过主板上的跳线 JP3 和 JP4 完成。更多信息，请参阅 phyCORE-i.MX 8M Plus/phyBOARD-Pollux 硬件手册中的 UARTs 部分。

+

对于RS-232和RS-485，使用相同的设备树节点。RS485模式可以通过ioctl TIOCSRS485 来启用。双向通讯支持也可以通过ioctl进行配置。请查看我们的小示例应用程序rs485test，该程序也包含在BSP中。需要设置跳线 JP3 和 JP4 。

+
+

7.2.1. RS232

+
    +

  • 以人类可读的格式显示终端的当前设置：

    +
    target:~$ stty -a
+
    +
    +
    • +

  • UART接口的配置可以通过stty命令完成。例如：

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • 通过简单的echo和cat，可以测试基本的通信。示例：

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

主机应打印出 "123"。

+
+
+

7.2.2. RS485

+
+

提示

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

为了方便测试，请查看linux-serial-test。这个工具会通过调用RS485的IOCTL，发送恒定的数据流。

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

有关linux-serial-test工具及其参数的更多信息，请访问此链接：linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Linux kernel文档描述了如何在C代码中调用IOCTL： https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+

RS232和RS485的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n331

+
+
+
+

7.3. 网络

+

phyBOARD-Pollux-i.MX 8M Plus 提供两个以太网接口。我们的核心板和底板各提供一个千兆以太网接口。

+
+

警告

+

硬件中的以太网接口命名约定（ethernet0 和 ethernet1）与Linux中的网络接口（eth0 和 eth1）不一致。因此，请注意这些差异：

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n41。

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Pollux can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n141.

+
+

7.3.1. 网络配置

+
+

7.3.1.1. U-boot网络环境

+
    +

  • 要在bootloader中查找以太网设置：

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • 在将主机设置为IP 192.168.3.10和子网掩码255.255.255.0的情况下，开发板应该返回：

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • 如果您需要进行任何更改：

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> 应该是 ipaddr、netmask、gatewayip 或 serverip 中的一个。<value> 将是所选参数的设定值。

    +
    • +

  • 您所做的更改目前是临时的。要保存这些更改：

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

在这里，您也可以将IP地址更改为DHCP，而不是使用静态IP地址。

+
    +

  • 配置：

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • 设置 TFTP 和 NFS 的路径。修改可以如下所示：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+

小技巧

+

像nfsroot和netargs这样的变量可以被U-boot外部环境重新赋值。对于网络启动，外部环境将通过tftp加载。例如，要在 bootenv.txt 文件中设置nfsroot变量，请在tftproot目录修改：

+
nfsroot=/home/user/nfssrc
+
+
+

无需在开发板上存储这些信息。请注意，U-boot外部环境对于像 ipaddr 或 serveraddr 这样的变量不起作用，因为它们在加载外部环境之前已经被设置完成。

+
+
+
+

7.3.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. 无线局域网

+

在 phyBOARD-Pollux 上，WLAN和蓝牙由PEB-WLBT-05扩展板提供。PEB-WLBT-05的 phyBOARD-Pollux 快速入门指南向您展示了如何安装PEB-WLBT-05。

+
+

小技巧

+

对于BSP版本PD22.1及更新版本，需要先激活PEB-WLBT-05 Overlay，否则PEB-WLBT-05将无法被识别。

+
target:~$ vi /boot/bootenv.txt
+
+
+

之后，bootenv.txt 文件应该如下所示（它还可以包含其他设备树overlay！）：

+
overlays=imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+
+
+

更改将在重启后应用：

+
target:~$ reboot
+
+
+

有关设备树overlay的更多信息，请阅读 device tree 章节。

+
+

为了支持WLAN和蓝牙，我们使用来自LSR的Sterling-LWB模块。该模块支持2.4 GHz，并且可以在多种模式下运行，如客户端模式、使用WEP、WPA、WPA2加密的接入点（AP）模式等。有关该模块的更多信息，请访问 https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. 连接到WLAN网络

+

首先设置您所在国家的正确监管域：

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

你将会看到：

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

设置无线接口：

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

现在您可以扫描可用的网络：

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

您可以使用一个跨平台的客户端，名为wpa_supplicant，支持WEP、WPA和WPA2，以建立加密连接。

+

为此，请将网络凭据添加到文件 /etc/wpa_supplicant.conf 中：

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

现在可以建立连接：

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

这会得到如下输出：

+
...
+ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

要完成配置，您可以配置DHCP以接收IP地址（大多数WLAN接入点都支持）。有关其他可能的IP配置，请参阅 L-813e.A12 Yocto Reference Manual (Hardknott) 中的“更改网络配置”部分。

+

首先，创建目录：

+
target:~$ mkdir -p /etc/systemd/network/
+
+
+

然后在 /etc/systemd/network/10-wlan0.network 中添加以下配置片段：

+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+

现在，请重启网络守护进程以使配置生效：

+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+
+

7.3.3. 蓝牙

+

Bluetooth is supported on phyBOARD-Pollux with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section.

+

Bluetooth is connected to UART3 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

现在您可以扫描环境中的可见蓝牙设备。在默认配置下，蓝牙是不可见的。

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. 可见性

+

要激活可见性：

+
target:~$ hciconfig hci0 piscan
+
+
+

要禁用可见性：

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. 连接

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+

Bluetooth is connected to UART3 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

现在您可以扫描环境中的可见蓝牙设备。在默认配置下，蓝牙是不可见的。

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+
+

7.3.3.3. 可见性

+

要激活可见性：

+
target:~$ hciconfig hci0 piscan
+
+
+

要禁用可见性：

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.4. 连接

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

备注

+

如果连接失败并出现错误信息：“连接失败：org.bluez.Error.Failed”，请尝试使用以下命令重新启动PulseAudio：

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC 卡

+

该 i.MX 8M Plus 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

MMC（SD卡插槽）接口的DT配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n367

+

eMMC接口的DT配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n220

+
+
+

7.5. eMMC设备

+

PHYTEC模块，如phyCORE-i.MX 8M Plus，配备了一个eMMC存储芯片作为主要存储。eMMC设备包含MLC存储单元，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 8M Plus，并在Linux内核中被表示为块设备，类似于SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.5.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），负责处理原始MLC单元的磨损平衡、块管理和错误纠正码（ECC）。这需要定期进行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+

mmc这个linux工具目前不支持启用自动BKOPS功能。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops enable /dev/mmcblk2
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.5.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 8M Plus SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n> <partition> <device>
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.5.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
    +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+
+
+

7.5.5. 启用伪SLC模式

+

eMMC设备使用 多层单元内存（MLC） 来存储数据。与NAND Flash中使用的单层单元（SLC）内存单元相比，MLC内存单元具有更低的可靠性和更高的错误率，但成本更低。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. 擦除设备

+

可以直接擦除eMMC设备，而不是用零覆盖它。eMMC块管理算法将会擦除MLC存储单元或将这些块标记为丢弃。设备上的数据将丢失，并且读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.5.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 8M Plus 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.5.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

下表是 i.MX 8M Plus SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.6. SPI主设备

+

i.MX 8M Plus 控制器包含一个 FlexSPI 和一个 ECSPI IP 核。FlexSPI 主控制器支持两个 SPI 通道，最多可连接 4 个设备。每个通道支持单通道/双通道/四通道/八通道模式的数据传输（1/2/4/8 条数据线）。ECSPI 控制器支持 3 个 SPI 接口，每个接口都有一个专用的CS（chip select）引脚。由于CS也可通过 GPIO 实现，因此每个通道上可以连接多个设备。

+
+

7.6.1. SPI NOR 烧写

+

phyCORE-i.MX 8M Plus 配备有一个 QSPI NOR Flash，该 Flash 连接到 i.MX 8M Plus 的 FlexSPI 接口。QSPI NOR Flash 可用于启动。有关烧写和启动模式设置的详细信息，请参见不同的章节。由于 SPI NOR Flash 的空间有限，因此仅可存储bootloader。默认情况下，内核、设备树和根文件系统来自 eMMC。

+

bootloader程序通过EEPROM数据检测是否安装了SPI Flash。如果没有安装SPI Flash，则在启动期间应用设备树overlay，通过扩展命令禁用SPI Flash设备树节点。如果没有可用的EEPROM数据，SPI NOR Flash节点将始终启用。有关更多信息，请参阅设备树overlay部分。

+

bootloader程序还可以通过内核的mtdparts启动参数修改设备树，将SPI MTD分区表传递给Linux。BSP中的默认分区布局设置为：

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

这是一个预定义的bootloader环境变量，可以在运行时更改。从Linux用户空间，可以通过/dev/mtd<N>设备访问NOR Flash分区，其中<N>是与要访问的NOR Flash分区相关联的MTD设备编号。要找到分区的正确MTD设备编号，请在目标上运行：

+
root@phyboard-pollux-imx8mp-3:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

它列出了所有MTD设备及其对应的分区名称。闪存节点在模块DTS中的SPI主节点内定义。SPI节点包含连接到此SPI总线的所有设备，在这种情况下只有SPI NOR Flash。

+

设备树中SPI主节点的定义可以在这里找到：

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n72

+
+
+
+

7.7. GPIOs

+

phyBOARD-Pollux 具有一组专门用于GPIO的引脚。这些引脚直接连接到 i.MX 8M Plus 引脚，并被复用为 GPIO。它们可以直接在 Linux 用户空间中使用。处理器将其 GPIO 组织为5个GPIO组（GPIO1 – GPIO5），每个组包含 32 个GPIO。gpiochip0、gpiochip32、gpiochip64、gpiochip96 和 gpiochip128 是这些内部 i.MX 8M Plus GPIO 组 GPIO1 – GPIO5 的 sysfs 表示。

+

GPIO被标识为GPIO<X>_<Y>（例如：GPIO5_07）。<X>表示GPIO Bank，从1计数到5，而<Y>表示该Bank内的GPIO。<Y>从0计数到31（每个bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如从gpiochip0的GPIO 20）：

    +
    target:~$ gpioget gpiochip0 20
+
    +
    +
    • +

  • 将gpiochip0上的GPIO 20的值设置为0并退出工具：

    +
    target:~$ gpioset --mode=exit gpiochip0 20=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.7.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用 CONFIG_GPIO_SYSFS 后才能支持。要在menuconfig中使 CONFIG_GPIO_SYSFS 可见，必须首先启用选项 CONFIG_EXPERT 。

+

您也可以将此选项添加到您在 Linux 内核源代码 arch/arm64/configs/ 目录下使用的 defconfig 中。例如，我们基于 NXP 的BSP版本，这个defconfig可以是 imx8_phytec_distro.config

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

您也可以创建一个新的config片段。有关详细信息，请参阅我们的《Yocto参考手册<yocto-ref-manual-kernel-and-bootloader-config>》。

+
+
+
+

7.8. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+mmc1::@    mmc2::@    user-led1@ user-led2@ user-led3@
+
+
+

这里的 LED 灯包括蓝色的 mmc、绿色的 心跳和红色的 emmc，它们都在 phyBOARD-Pollux 上。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 255 > /sys/class/leds/user-led1/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/user-led1/brightness
+
    +
    +
    • +
+

GPIO的设备树配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n216

+
+
+

7.9. I²C总线

+

该 i.MX 8M Plus 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 8M Plus 的I²C模块。 本节描述了我们 phyBOARD-Pollux 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

I²C1总线DT配置（例如 imx8mp-phycore-som.dtsi）： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n105

+

I²C2总线DT配置（例如 imx8mp-phyboard-pollux-rdk.dts）: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n201

+
+
+

7.10. EEPROM

+

在 phyCORE-i.MX8MP 上有一个i2c EEPROM闪存。它有两个地址。主EEPROM空间（总线：I2C-0 地址：0x51）和ID页（总线：I2C-0 地址：0x59）可以通过Linux中的sysfs接口进行访问。主EEPROM和ID页的前256个字节用于板检测，不可被覆盖。覆盖保留的空间将导致启动问题。

+
+

7.10.1. phyCORE-i.MX8MP 上的I2C EEPROM

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

phyCORE-i.MX8MP SoM上的I2C EEPROM连接到I2C-0总线的I2C地址0x51。可以直接对该设备进行读写操作：

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

要用零填充4KiB的EEPROM（总线：I2C-0 地址：0x51），并保留EEPROM数据，请使用：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM 检测

+

在 phyCORE-i.MX8MP 上配置的I2C EEPROM具有一个可通过I2C地址0x59在i2c0上寻址的独立ID页面，以及一个可通过I2C地址0x51在i2c0上寻址的正常区域。PHYTEC使用这个32字节的数据区域来存储关于SoM的信息，包括PCB版本和配置。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果EEPROM ID页面数据和正常区域的前256个字节被删除，bootloader程序将回退到 phyCORE-i.MX8MP Kit RAM设置，即 2GiB RAM。

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

使用API修订版2数据格式烧写的核心板将在早期启动阶段打印出有关模块的信息。

+
+
+

7.10.3. 恢复EEPROM数据

+

硬件数据已预先写入两个EEPROM数据空间。如果您不小心删除或覆盖了Normal区域，可以将ID区域的硬件检查数据复制到正常区域。

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1
+
+
+
+

备注

+

如果您删除了两个EEPROM空间，请联系我们的支持团队！

+
+

phyCORE-i.MX 8M Plus 核心板的设备树imx8mp-phycore-som.dtsi可以在PHYTEC git中找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n201

+
+
+
+

7.11. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC唤醒alarm

+

可以从实时时钟（RTC）发出中断以唤醒系统。该格式使用Unix纪元时间，即自1970年1月1日UTC午夜以来的秒数。要在从挂起到RAM状态后的4分钟唤醒系统，请输入：

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

备注

+

内部唤醒alarm时间将被向上舍入到下一个分钟，因为alarm功能不支持秒。

+
+

I²C RTC的设备树表示：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy17#n207

+
+
+
+

7.12. USB主控制器

+

i.MX 8M Plus SoC的USB控制器为众多消费类便携设备提供了一种低成本的连接解决方案，实现USB设备之间的数据传输，传输速度可达4 Gbit/s（超高速'SS'）。USB子系统具有两个独立的USB控制器。这两个控制器都能够作为USBDevice或USB Host使用。每个核心都连接到一个USB 3.0物理层（PHY）。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+

USB Host的DT配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n341

+
+
+

7.13. CAN FD

+

The phyBOARD-Pollux has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。两个CAN接口显示为can0和can1。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    can0的信息将如下所示：

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+
+

警告

+

mcp2518fd SPI到CAN FD只支持从125kB/s开始的波特率。可以选择更慢的速率，但可能无法正常工作。

+
+

imx8mp-phyboard-pollux.dtsi的CAN设备树配置： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n165

+
+
+

7.14. PCIe

+

phyCORE-i.MX 8M Plus 具有一个 Mini-PCIe 插槽。一般来说，PCIe 会自动检测总线上的新设备。在连接设备并启动系统后，您可以使用命令 lspci 查看所有被识别的 PCIe 设备。

+
    +

  • 输入：

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • 你将收到：

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

在这个例子中，PCIe设备是 英特尔 WiFi Link 5100 。

+

对于PCIe设备，您必须在内核配置中启用正确的驱动程序。例如，这款WLAN卡是由英特尔制造的。必须启用的驱动程序选项名为 CONFIG_IWLWIFI ，可以在内核配置中的 Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimate 下找到。

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • linux-imx的表示为：virtual/kernel

      • +
    +
    • +
+

对于某些设备，如WLAN卡，需要额外的二进制固件文件。这些固件文件必须放置在 /lib/firmware/ 目录中，才能使用该设备。

+
    +

  • 输入：

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • 例如，如果您尝试启动网络接口：

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • 您将在串口控制台上获得以下输出：

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

小技巧

+

某些PCIe设备，例如以太网卡，即使没有从 /lib/firmware/ 加载固件文件，也可能正常工作，而你收到了如上输出第一行所示的错误消息。这是因为一些制造商在板卡本身提供了固件作为后备。在这种情况下，设备的行为和输出在很大程度上依赖于制造商的固件。

+
+

imx8mm-phyboard-polis.dtsi的PCIe设备树配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n277

+
+
+

7.15. 音频

+

支持的播放设备包括HDMI和PEB-AV-10连接器上的TI TLV320AIC3007音频编解码器（CODEC）IC。在AV连接器上，有一个符合OMTP标准的3.5mm耳机插孔和一个8针排针。8针排针包含单声道扬声器、耳机和line-in信号。

+
+

备注

+

使用PEB-AV-10连接器进行显示输出时，不支持通过HDMI作为音频输出。音频输出设备必须与视频输出设备匹配。

+
+

要检查您的声卡驱动程序是否正确加载以及设备名称，请输入以下命令以查看播放设备：

+
target:~$ aplay -L
+
+
+

或输入录音设备：

+
target:~$ arecord -L
+
+
+
+

7.15.1. Alsamixer

+

要检查声卡的功能，请输入：

+
target:~$ alsamixer
+
+
+

您应该会看到很多选项，因为音频IC具有许多可以配置的功能选项。通过SSH打开alsamixer可能比通过串口控制台更好，因为控制台的图形效果更佳。您可以为所有混合点使用单声道或立体声增益控制。“MM”表示该功能被静音（左右输出均为静音），可以通过按 m 键切换。您还可以通过按'<'键切换左声道和'>'键切换右声道。使用 tab 键，您可以在播放和录音的控制之间切换。

+
+
+

7.15.2. ALSA配置

+

我们的BSP附带一个ALSA配置文件 /etc/asound.conf 。

+

ALSA配置文件可以根据需要进行编辑或删除，它并不是ALSA正常工作所必需的。

+
target:~$ vi /etc/asound.conf
+
+
+

要将PEB-AV-10设置为输出，请将 playback.pcm 从 "dummy" 设置为 "pebav10":

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

如果听不到声音，请将播放设备更改为软件音量控制播放设备，将 playback.pcm 设置为相应的软音量播放设备，选择 "softvol_hdmi" 或 "softvol_pebav10"。使用 alsamixer 控件来调整音量水平。

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_hdmi"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.15.3. PulseAudio 配置

+

对于使用Pulseaudio的应用程序，请检查可用的输出设备：

+
target:~$ pactl list short sinks
+0   alsa_output.platform-snd_dummy.0.stereo-fallback    module-alsa-card.c  s16le 2ch 44100Hz   SUSPENDED
+1   alsa_output.platform-sound-peb-av-10.stereo-fallback    module-alsa-card.c  s16le 2ch 44100Hz   SUSPENDED
+
+
+

要选择PEB-AV-10，请输入：

+
target:~$ pactl set-default-sink 1
+
+
+
+
+

7.15.4. 播放

+

运行speaker-test以检查播放功能：

+
target:~$ speaker-test -c 2 -t wav
+
+
+

要播放简单的音频流，您可以使用aplay。例如，要播放ALSA测试音频：

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

要播放其他格式，例如mp3，您可以使用Gstreamer：

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.15.5. 录音

+

arecord 是一个命令行工具，用于录制音频流，默认输入源为线路输入。要选择不同的音频源，可以使用 alsamixer。例如，打开 右侧 PGA 混音器 Mic3R 和 左侧 PGA 混音器 Mic3R，以便通过 3.5mm 插孔录制来自 TLV320 编解码器的麦克风输入音频。

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

提示

+

由于播放和录音共享硬件接口，因此无法在同时进行播放和录音操作时使用不同的采样率和格式。

+
+

音频的设备树配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.10.72_2.2.0-phy17#n57

+
+
+
+

7.16. 视频

+
+

7.16.1. 视频与Gstreamer

+

这个视频在BSP中默认安装：

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/phytec-qtdemo/videos/caminandes.webm
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=<video.mp4> \
+\! qtdemux  \! h264parse \! queue \! vpudec \! waylandsink async=false enable-last-sample=false \
+qos=false sync=false
+
+
+
    +

  • 或者：

    • +
+
target:~$ gplay-1.0 /usr/share/phytec-qtdemo/videos/caminandes.webm
+
+
+
+
+

7.16.2. kmssink 插件 ID 确认

+

kmssink插件需要一个连接器ID。要获取连接器ID，您可以使用工具modetest。

+
target:~$ modetest -c imx-drm
+
+
+

输出如：

+
Connectors:
+id  encoder status      name        size (mm)   modes   encoders
+35  34  connected   LVDS-1          216x135     1   34
+  modes:
+    index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
+  #0 1280x800 59.07 1280 1380 1399 1440 800 804 808 823 70000 flags: phsync, pvsync; type: preferred, driver
+  props:
+    1 EDID:
+        flags: immutable blob
+        blobs:
+
+        value:
+    2 DPMS:
+        flags: enum
+        enums: On=0 Standby=1 Suspend=2 Off=3
+        value: 0
+    5 link-status:
+        flags: enum
+        enums: Good=0 Bad=1
+        value: 0
+    6 non-desktop:
+        flags: immutable range
+        values: 0 1
+        value: 0
+    4 TILE:
+        flags: immutable blob
+        blobs:
+
+        value:
+
+
+
+
+
+

7.17. 显示

+

该 phyBOARD-Pollux 支持多达4种不同的显示输出。可以同时使用三种。下表显示了不同接口所需的扩展板和设备树overlay。

+ + + + + + + + + + + + + + + + + + + + + + + + + +

接口

扩展板

设备树overlay

HDMI

phyBOARD-Pollux

不需要overlay（默认启用）

LVDS0

PEB-AV-10

imx8mp-phyboard-pollux-peb-av-010.dtbo（默认加载）

LVDS1

phyBOARD-Pollux

如果使用PEB-AV-10 overlay，则禁用

MIPI

PEB-AV-12 (MIPI到LVDS)

imx8mp-phyboard-pollux-peb-av-012.dtbo

+
+

备注

+
    +

  • 如果启用了LVDS1（板载），HDMI将无法工作。

    • +

  • 在更改Weston输出时，请确保音频输出也相匹配。

    • +

  • LVDS0 (使用PEB-AV-10扩展) 和 LVDS1 (板载) 不能同时使用。

    • +
+
+

HDMI在设备树中始终启用。其他接口可以通过设备树overlay进行启用。

+

默认启用的接口是HDMI和LVDS0（PEB-AV-010）。我们的PEB-AV-10和PEB-AV-12扩展板支持10英寸edt,etml1010g0dka显示屏。

+
+

备注

+

当前的显示驱动程序将连接到LVDS的LCD的像素时钟限制为74.25MHz（或其分频）。如果这满足不了您的需求，请联系支持团队以获得进一步的帮助。

+
+
+

7.17.1. Weston 配置

+

为了让Weston正确的显示，需要进行正确的配置。这将在/etc/xdg/weston/weston.ini中完成。

+
+

7.17.1.1. 单一显示器

+

在我们的BSP中，默认的Weston输出设置为HDMI.

+
[output]
+name=HDMI-A-1
+mode=current
+
+
+
+
+
+

7.17.2. Qt Demo

+

使用phytec-qt5demo-image时，Weston会在启动时启动。可以通过以下命令停止phytec-qt5demo：

+
target:~$ systemctl stop phytec-qtdemo
+
+
+
    +

  • 要重新开始Demo，请运行：

    +
    target:~$ systemctl start phytec-qtdemo
+
    +
    +
    • +

  • 要禁用Demo的自动启动，请运行：

    +
    target:~$ systemctl disable phytec-qtdemo
+
    +
    +
    • +

  • 要启用Demo的自动启动，请运行：

    +
    target:~$ systemctl enable phytec-qtdemo
+
    +
    +
    • +

  • Weston可以通过以下方式停止：

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

备注

+

在关闭Weston之前，必须先关闭Qt Demo。

+
+
+
+

7.17.3. 背光控制

+

如果LCD连接到PHYTEC开发板，可以通过Linux内核的sysfs接口控制其背光。系统中所有可用的背光设备可以在文件夹/sys/class/backlight中找到。读取相应的文件并向其写入数据可以控制背光。

+
+

备注

+

一些具有多显示的开发板在 /sys/class/backlight 有多个背光控制。比如：backlight0和backlight1

+
+
    +

  • 例如，要获取最大亮度级别（max_brightness），请执行：

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    有效的亮度值范围是 0 到 <max_brightness>。

    +
    • +

  • 要获取当前亮度级别，请输入：

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • 写入文件brightness以更改亮度：

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    例如，关闭背光。

    +

    有关所有文件的文档，请参见 https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight。

    +
    • +
+

LVDS-1和HDMI的设备树： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n255 https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n180

+

PEB-AV-10上LVDS-0的设备树配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.10.72_2.2.0-phy17#n132

+
+
+
+

7.18. 电源管理

+
+

7.18.1. CPU核心频率调节

+

i.MX 8M Plus SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。调整频率和电压被称为“动态电压和频率调整”（DVFS）。i.MX 8M Plus BSP支持DVFS功能。Linux内核提供了一个DVFS框架，允许每个CPU核心设置最小或最大频率和一个管理其运行的governor。根据使用的 i.MX 8 型号，支持几种不同的频率。

+
+

小技巧

+

尽管DVFS框架为每个CPU核心提供了频率设置，但一个CPU核心的频率更改会影响其他CPU核心。因此，所有CPU核心始终共享相同的DVFS设置。每个核心的单独DVFS设置是不可能的。

+
+
    +

  • 要获取完整列表，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    例如 i.MX 8MPlus CPU，最高可达约 1.6 GHz，则结果将是：

    +
    1200000 1600000
+
    +
    +
    • +

  • 要查询当前的频率输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

governor 会根据它们的目标自动选择这些频率中的一个。

+
    +

  • 列出所有可用的 governor，使用以下命令：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    结果是：

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative governor 与 ondemand governor 非常相似。只是它的行为有所不同，它会更保守地增减CPU速度，而不是在CPU有任何负载的瞬间就跳到最大速度。

    • +

  • ondemand （默认）根据当前系统负载在可能的CPU核心频率之间切换。当系统负载超过特定值时，它会立即提高CPU核心频率。

    • +

  • powersave 始终选择最低的CPU核心频率。

    • +

  • performance 始终选择最高的CPU核心频率。

    • +

  • userspace 允许以root身份运行的用户或用户空间程序设置特定频率（例如，设置为1600000）。输入：

    • +

  • 要查询当前的 governor，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    您通常会得到：

    +
    ondemand
+
    +
    +
    • +

  • 切换到另一个governor（例如，userspace）可以通过以下方式完成：

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • 现在你可以设置频率：

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

有关governor的更详细信息，请参阅Linux内核代码库中的Linux内核文档，路径为 Documentation/admin-guide/pm/cpufreq.rst 。

+
+
+

7.18.2. CPU核心管理

+

该 i.MX 8M Plus SoC 芯片上可以有多个处理器核心。例如，该 i.MX 8M Plus 具有 4 个 ARM 核心，可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    这里系统有四个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.18.3. 挂起到RAM

+

phyCORE-i.MX8MP 支持基本的挂起和恢复。可以使用不同的唤醒源。挂起/恢复可以通过以下方式实现：

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

要通过串行控制台唤醒，请运行

+
target:~$ echo enabled > /sys/class/tty/ttymxc0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.19. 热管理

+
+

7.19.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.19.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 8M Plus SoC 平台上使用热管理内核 API。 i.MX 8 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个触发点。这些触发点根据CPU型号的不同而有所不同。主要区分工业版和商业版。

+ + + + + + + + + + + + + + + + + +

商业

工业

被动（警告）

85°C

95°C

严重（关机）

90°C

100°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并实施冷却措施。内核中可用的热政策（也称为thermal governor）包括：Step Wise、Fair Share、Bang Bang和Userspace。BSP中使用的默认策略是Step Wise。如果sysfs文件temp中的SoC温度值高于 trip_point_0 ，则CPU频率将设置为最低CPU频率。当SoC温度降到 trip_point_0 以下时，限制将被解除。

+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+

7.19.3. GPIO风扇

+
+

备注

+

Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan +to GPIO fan due to availability. The PWM fan will not be supported +anymore and will not function with the new release.

+
+

一个GPIO控制的风扇可以连接到 phyBOARD-Pollux-i.MX 8M Plus。该SoC包含一个温度传感器，该传感器被用于热频率调节。风扇无法通过内核进行控制。我们使用lmsensors和hwmon来实现这一点。lmsensors定期读取温度，并在可配置的阈值下启用或禁用风扇。对于 phyBOARD-Pollux-i.MX 8M Plus，这个阈值是60°C。

+

设置可以在配置文件中进行配置：

+
/etc/fancontrol
+
+
+

风扇控制在启动时由systemd服务启动。可以通过以下方式禁用它：

+
target:~$ systemctl disable fancontrol
+
+
+

GPIO风扇的设备树配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy17#n26

+
+
+
+

7.20. 看门狗

+

PHYTEC i.MX 8M Plus 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.20.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.21. snvs电源按键

+

连接到开关按钮的 X_ONOFF 引脚可以长按以触发关机，而无需软件干预，或用于唤醒系统以退出挂起状态。使用 snvs_pwrkey 驱动程序时，当按下按钮时，KEY_POWER 事件也会报告给用户空间。默认情况下，systemd 被配置为忽略此类事件。关机而无需软件干预的功能以及从挂起状态唤醒的功能未被配置。可以在 /etc/systemd/logind.conf 中配置按下开/关按钮时通过 systemd 触发关机，配置方法如下：

+
HandlePowerKey=poweroff
+
+
+
+
+

7.22. NPU

+

i.MX 8M Plus SoC包含一个NPU，其运算能力达到 2.3 TOPS，专用于人工智能操作。有关 NPU 的信息，请参考我们最新的 phyCORE-i.MX 8M Plus AI 套件指南，您可以在 phyCORE-i.MX 8M Plus 下载部分找到：L-1015e.A0 phyCORE-i.MX 8M Plus AI Kit Guide

+
+

7.22.1. NXP eIQ 示例

+

NXP提供了一组使用Python3的针对eIQ的机器学习示例，。要添加一个预配置的机器学习软件包，请将其添加到你的local.conf中并编译你的BSP:

+
IMAGE_INSTALL_append = " packagegroup-imx-ml python3-pip python3-requests opencv"
+
+
+

这将需要在SD卡上有大约1GB的空间。有关如何安装和使用NXP示例的说明，请访问 https://community.nxp.com/t5/Blogs/PyeIQ-3-x-Release-User-Guide/ba-p/1305998。

+
+

提示

+

使用pip3安装eiq示例需要互联网连接。

+
+
+

备注

+

在某些Ubuntu 20.04主机上，cmake在编译python3-pybind11时使用主机的Python 3，而不是Yocto中的Python 3.7。（参见：https://community.nxp.com/t5/i-MX-Processors/Yocto-L5-4-70-2-3-0-build-image-failed/m-p/1219619）

+

可以用以下方法解决，修改python3-pybind11的recipe：

+
$ devtool edit-recipe python3-pybind11
+
+
+

并将以下内容加入文件:

+
EXTRA_OECMAKE += "-DPYTHON_EXECUTABLE=${RECIPE_SYSROOT_NATIVE}/usr/bin/python3-native/python3.7"
+
+
+
+
+
+
+

7.23. ISP

+

i.MX 8M Plus SoC包含一个图像信号处理器（ISP）。有关更多信息，请参阅|sbc| i.MX 8M Plus 文档中的使用ISP部分。

+
+
+

7.24. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 8M Plus 提供一次性可编程fuse，用于存储信息，例如 MAC 地址、启动配置和其他永久设置（在 i.MX 8M Plus reference manual中称为“片上 OTP 控制器 (OCOTP_CTRL)”）。以下列表摘自 i.MX 8M Plus reference manual，包括 OCOTP_CTRL 中的一些有用寄存器（基地址为0x30350000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为0x30350000

描述

OCOTP_MAC_ADDR0

9

0

0x640

包含ENET0 MAC地址的低32位

OCOTP_MAC_ADDR1

9

1

0x650

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

OCOTP_MAC_ADDR2

9

2

0x660

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 8M Plus Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.24.1. 在uBoot中读取fuse的值

+

您可以使用内存映射的shadow寄存器读取fuse寄存器。要计算内存地址，请使用以下公式计算：

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.24.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+

除非*ocotp_root_clk*已启用，否则使用``/dev/mem``读取寄存器会导致系统挂起。要永久启用此时钟，请在设备树中添加：

+
&clk {
+        init-on-array = <IMX8MP_CLK_OCOTP_ROOT>;
+};
+
+
+
+
+
+
+

8. i.MX 8M Plus M7 Core

+

除了Cortex-A53核心外，SoC中还集成了一个Cortex-M7 Core 作为MCU。我们的Yocto-Linux-BSP在A53核心上运行，而 M7 Core 可以作为辅助CPU，用于使用裸机或RTOS固件执行额外任务。两种核心都可以访问相同的外设，因此外设的使用需要在 M7 Core 的固件或Linux操作系统的设备树中进行限制。本节将描述如何编译固件示例以及如何在 phyBOARD-Pollux 上运行它们。

+

phyBOARD-Pollux 目前由 NXP MCUXpresso SDK 和 Zephyr 项目支持。本节仅描述 NXP MCUXpresso SDK，因为目前 MCUXpresso SDK 支持的功能更多。

+

如果您想在Zephyr项目中使用 M7 Core ，请参考Zephyr项目文档：

+ +
+

8.1. 获取固件示例

+

固件可以使用NXP MCUxpresso SDK和兼容的编译工具链通过命令行工具进行编译。

+
+

8.1.1. 获取源代码

+

MCUX SDK以及 i.MX 8M Plus 的示例可以从PHYTEC的GitHub页面获取：

+ +
    +

  1. 通过west初始化MCUX SDK：

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    这将创建一个 mcuxsdk 目录，并在其中包含 mcux-sdk 仓库。mcux-sdk-phytec-examples 仓库将自动克隆到 mcuxsdk 目录中。给定的参数 <VERSION> 是 mcux-sdk 仓库的分支名称，代表 MCUX SDK 版本。要获取最新的测试版本，您可以使用 2.13.0。

    +
    +

    备注

    +

    west 是一个仓库管理工具，也是 Zephyr 项目的一部分。要安装 west，您可以使用 pip。在这个示例中，west 被安装在一个 Python 虚拟环境中:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. 更新依赖项：

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    目录 examples-phytec 包含了所有移植并测试过的示例，适用于 phyBOARD-Pollux 和版本为 2.13.0 的 MCUX。

    +

    要编译固件，需要一个编译器工具链和make/cmake。GNU ARM 嵌入式工具链可能在您的主机linux发行版的仓库中可用，例如Ubuntu。

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    编译器工具链也可以直接从 https://developer.arm.com/ 获取。在解压缩文件后，必须将 ARMGCC_DIR 添加到环境变量中，例如，对于位于主目录中的 ARM toolchain 10-2020-q4-major 版本：

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. 编译固件

+

要编译PHYTEC示例，需要先设置环境

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

编译固件的脚本位于 <sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc。每个可运行的内存位置都有相应的编译脚本，例如：

+
host:~$ ./build_release.sh
+
+
+

要编译运行在 M7 Core 的 TCM 上的固件。输出将放置在 armgcc 目录下的 release/ 中。.bin 文件可以在 U-Boot 中运行，而 .elf 文件可以在 Linux 中运行。

+

要编译在DRAM上运行的固件，请运行脚本build_ddr_release。例如。

+
host:~$ ./build_ddr_release.sh
+
+
+

输出将放置在armgcc目录下的ddr_release/中。.bin文件可以在U-Boot中运行，而.elf文件可以在Linux中运行。

+
+
+
+

8.2. 运行 M7 Core 示例

+

有两种方法可以运行 M7 Core 的固件，在Linux中使用Remoteproc以及在U-Boot。

+

要接收调试信息，请在您的主机PC上启动您喜欢的终端软件（例如Minicom、Tio或Tera Term），并将其配置为115200波特率、8个数据位、无奇偶校验和1个停止位（8n1），且不使用握手。

+

一旦Micro USB电缆连接到 phyBOARD-Pollux 上的USB调试端口，就会注册两个ttyUSB设备。一个打印来自A53核心的调试UART的消息，另一个打印来自 M7 Core 的调试UART的消息。

+
+

8.2.1. 从U-Boot运行示例

+

要使用bootloader U-Boot加载固件，可以使用bootaux命令：

+
    +

  1. 准备一张烧写了BSP镜像的SD卡

    2. +

  2. 将生成的 .bin 文件复制到 SD 卡的第一个分区

    3. +

  3. 通过按任意键停止自动启动

    4. +

  4. 根据固件类型输入命令：

    5. +
+

对于在 M7 Core 的TCM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

用于在DRAM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

程序的输出应显示在 M7 Core 的调试UART上。

+
+
+

8.2.2. 通过Remoteproc在Linux上运行示例

+

Remoteproc是一个模块，允许您在运行时从Linux控制 M7 Core 。可以加载为TCM编译的固件，并可以启动或停止执行。要使用Remoteproc，需要设置设备树Overlay：

+

在开发板的/boot目录中编辑bootenv.txt文件，添加 imx8mp-phycore-rpmsg.dtbo ：

+
overlays=imx8mp-phycore-rpmsg.dtbo
+
+
+

重启目标并在U-Boot中执行:

+
u-boot=> run prepare_mcore
+
+
+

M7 Core 的固件 .elf 文件可以在 /lib/firmware 下找到。要加载固件，请输入：

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

要加载不同的固件，M7 Core 需要停止：

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

备注

+

在开发板上找到的 /lib/firmware 中的例子来自NXP的Yocto层meta-imx。要使用您通过MCUX SDK自己编译的样本，请在编译后将它们复制到开发板的 /lib/firmware 中。

+
+
+ +
+
+
+

9. BSP扩展

+
+

9.1. Chromium

+

我们的BSP支持Chromium。您只需几个步骤即可将其包含在 phytec-qt5demo-image 中。

+
+

9.1.1. 将Chromium添加到您的local.conf文件中

+

要包含Chromium，您需要在您的local.conf中添加以下行。您可以在<yocto_dir>/build/conf/local.conf中找到这个配置文件。这将把Chromium添加到您下一个镜像编译中。:

+
IMAGE_INSTALL_append = " chromium-ozone-wayland"
+
+
+
+

备注

+

编译Chromium需要很长时间。

+
+
+
+

9.1.2. 在开发板上运行Chromium

+

要运行Chromium，需要一些参数来使用硬件图形加速：

+
target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox
+
+
+

如果您想通过SSH启动Chromium，您必须首先定义运行Chromium的显示器。例如：

+
target$ DISPLAY=:0
+
+
+

在您定义完这个之后，您可以通过上述所示的Weston虚拟终端启动它。

+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mp/pd22.1.2.html b/previews/271/zh_CN/bsp/imx8/imx8mp/pd22.1.2.html new file mode 100644 index 000000000..a038b36b0 --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mp/pd22.1.2.html @@ -0,0 +1,3715 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + +

i.MX 8M Plus BSP手册

文档标题

i.MX 8M Plus BSP手册

文档类型

BSP 手册

Yocto 手册

发布日期

2024/08/05

母文档

i.MX 8M Plus BSP手册

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP 发布日期

BSP 状态

BSP-Yocto-NXP-i.MX8MP-PD22.1.2

小更新

2024/08/05

已发布

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 phyCORE-i.MX8M Plus Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads 中找到。

+
+

1.1. 支持的硬件

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-NXP-i.MX8MP-PD22.1.2 的所有Machine及其对应的Article Numbers(产品型号)： 网页.

+

如果您在“Supported Machines”一栏选择了特定的 Machine Name ，您可以查看该machine下可用的 Article Numbers 以及硬件信息的简短描述。如果您只有硬件的 Article Numbers ，您可以将 Machine Name 下拉菜单留空，仅选择您的 Article Numbers 。现在，它应该会显示您特定硬件所需的 Machine Name

+
+

备注

+

当PCM-070开发板没有安装X1扩展连接器时，此处描述的一些软件功能将无法使用。这些功能包括无线局域网、PCIe、CSI（摄像头）、PEB-AV-12、CAN和USB-OTG。

+
+
+

1.1.1. phyBOARD-Pollux 器件

+
+../../../_images/phyBOARD-Pollux-front-components.jpg + +
+

phyBOARD-Pollux 器件图（顶部）

+
+
+
+../../../_images/phyBOARD-Pollux-back-components.jpg + +
+

phyBOARD-Pollux 器件图（底部）

+
+
+
+
+
+
+

2. 开始使用

+

该 phyCORE-i.MX8M Plus Kit 包含预先烧写好的SD卡。它包含 phytec-qt5demo-image ，可以直接用作启动盘。默认情况下，核心板的eMMC仅烧写了U-boot。您可以从 PHYTEC下载服务器 获取所有源代码。本章解释了如何将BSP镜像烧录到SD卡以及如何启动开发板。

+
+

2.1. 下载镜像

+

WIC镜像包含预先格式化的分区信息以及分区中包含的BSP文件，可以使用单个Linux命令 dd 轻松写入到SD卡上。WIC镜像可以通过Yocto编译或从PHYTEC下载服务器下载。

+

从下载服务器获取WIC文件：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.2/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要使用 dd 命令创建SD卡启动盘，您必须具有root权限。在使用 dd 指定目标设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行该命令：

    +
    host$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+
    +

  • 卸载所有分区，例如：

    +
    host$ sudo umount /dev/sde1
+
    +
    +
    • +

  • 在卸载所有分区后，您可以创建SD卡启动盘：

    +
    host$ sudo dd if=<IMAGENAME>-<MACHINE>.wic of=/dev/sdX bs=1M conv=fsync status=progress
+
    +
    +

    再次确保将 /dev/sdX 替换为之前找到的设备名称。

    +

    参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

    +
    • +
+

准备SD卡启动盘的另一种更快的方法是使用Intel的 bmap-tools 。Yocto会自动为WIC镜像创建一个block map文件（ <IMAGENAME>-<MACHINE>.wic.bmap ），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host$ bmaptool copy <IMAGENAME>-<MACHINE>.wic /dev/<your_device>
+
+
+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.3. 首次启动

+ +../../../_images/SD_Card_Boot1.png +
    +

  • 插入SD卡

    • +

  • 使用 micro USB 线将开发板的 (X1) 调试USB口和主机连接起来

    • +

  • 给开发板通电

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: L-813e.A12 Yocto Reference Manual (Hardknott).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +L-813e.A12 Yocto Reference Manual (Hardknott).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-IMX8MP ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-xwayland MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD22.1.2
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-qt5demo-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 phyboard-pollux-imx8mp-3 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx8mp.bin: ARM可信固件二进制文件

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY固件镜像

    • +

  • imx-boot：由imx-mkimage编译的bootloader镜像，包括SPL、U-Boot、ARM可信固件和DDR固件。这是最终的可引导bootloader镜像。

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx8mp-phyboard-pollux-rdk*.dtb: 内核设备树文件

    • +

  • imx8mp-phy*.dtbo: 内核设备树overlay文件

    • +

  • phytec-qt5demo-image*.tar.gz: 根文件系统

    • +

  • phytec-qt5demo-image*.wic: SD卡镜像

    • +
+
+
+
+
+

4. 安装操作系统

+
+

4.1. 启动模式开关 (S3)

+
+

小技巧

+

硬件修订版底板：1552.2

+
+

该 phyBOARD-Pollux 具有一个（启动源配置）开关，配有四个可单独切换的位，用于选择phyCORE-i.MX 8M Plus 默认的启动源。

+ + + + + + + + + + + +
+../../../_images/eMMC1.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses1.png +
+

内部fuse

+
+
+
+../../../_images/SPI_NOR.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download1.png +
+

USB

+
+
+
+../../../_images/SD_Card_Boot1.png +
+

SD卡

+
+
+
+../../../_images/Test_Mode.png +
+

测试模式

+
+
+
+
+
+

4.2. 烧写eMMC

+

要从eMMC启动，请确保BSP镜像已正确烧录到eMMC，并且 bootmode switch (S3) 设置为 默认SOM启动 。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行上述命令来检查系统启动在这种条件下是否会到影响。如果 mmcblk2p1 和 mmcblk1p1 具有相同的UUID，则会影响系统正确启动。

+
+
+

4.2.1. 从网络烧写 eMMC

+

i.MX 8M Plus 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

4.2.1.1. 在开发板的u-boot环境中从网络烧写eMMC

+

这些步骤将展示如何通过网络更新eMMC。然而，此步骤仅在镜像文件小于1GB的情况下会被执行成功。如果镜像文件更大，请转到“格式化SD卡”一节。配置 bootmode switch (S3) 以从SD卡启动，并插入一张SD卡。给开发板上电并进入U-Boot环境。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+
    +

  • 通过网络将您的镜像加载到内存中：

    +
    u-boot=> tftp ${loadaddr} phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • 将镜像写入eMMC：

    +
    u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +
+
+
+

4.2.1.2. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！设置主机网络。

+
+

使用一条命令，通过网络ssh协议将带有块映射的压缩或未压缩的镜像发送到开发板的eMMC上使用,执行：

+
target:~$ ssh <USER>@192.168.3.10 "dd if=<path_to_file>/phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic" | dd of=/dev/mmcblk2
+
+
+
+
+

4.2.1.3. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！设置主机网络。

+
+

查看主机上可用的镜像文件：

+
host:~$ ls
+phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
+
+

通过网络使用ssh将镜像用dd命令发送到您设备的eMMC：

+
host:~$ dd if=phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2"
+
+
+
+
+
+

4.2.2. 在u-boot中通过网络烧写eMMC u-boot镜像

+

如果eMMC上的bootloader位于eMMC的User区，从u-boot中更新独立的u-boot镜像imx-boot也是可能的。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！设置主机网络。

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.3. 从USB烧写eMMC

+
+

4.2.3.1. 在u-boot上从USB烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1GB时有效，因为在启用OPTEE后，Bootloader中可用的RAM大小有限。

+
+

下面这些步骤展示如何通过USB设备更新eMMC。将启动模式开关配置为 bootmode switch (S3) 并插入SD卡。给开发板上电并进入U-Boot环境。将已存储了未压缩WIC镜像的优盘插入开发板USB接口。

+

将镜像从USB设备加载到RAM中：

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} *.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. 在运行的Linux系统中从USB烧写eMMC

+

下面这些步骤展示如何在Linux系统上使用USB大容量存储设备烧写eMMC。您需要一个保存了完整镜像的U盘和一个可从SD卡启动的核心板（例如 phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic）。将引导模式开关设置为 bootmode switch (S3)。

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ cd /mnt
+target:~$ ls
+phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
    +
    +
    • +

  • 显示可用的MMC设备列表：

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • eMMC设备的特征是它包含两个boot分区：(mmcblk2boot0; mmcblk2boot1)

    • +

  • 将镜像写入 phyCORE-i.MX 8M Plus eMMC（无分区的 MMC 设备 2）：

    +
    target:~$ dd if=phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic of=/dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    • +
+
+

警告

+

在此之前，您需要将启动配置开关配置 bootmode switch (S3) 设置为 默认SOM启动。

+
+
+
+
+

4.2.4. 从SD卡烧写eMMC

+

即使没有可用的网络，您也可以更新eMMC。为此，您需要一个位于SD卡上的镜像文件（*.wic）。由于镜像文件相当大，您需要扩展SD卡以使用其全部空间（如果之前没有扩展的话）。有关如何扩展SD卡，请参阅调整 ext4 根文件系统的大小一节。

+
+

4.2.4.1. 在u-boot上从SD卡烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1GB的情况下有效，因为在启用OPTEE后，Bootloader中可用的RAM大小有限。如果镜像文件太大，请使用“在目标上使用Linux从SD卡更新eMMC”一节。

+
+
    +

  • 将一个可用的镜像烧写到SD卡，并创建一个FAT格式的第三分区。将WIC镜像（例如 phytec-qt5demo-image.wic）复制到该分区。

    • +

  • 将启动模式开关配置为从SD卡启动，并插入SD卡。

    • +

  • 给开发板上电并进入u-boot环境。

    • +

  • 将您的WIC镜像（例如 phytec-qt5demo-image.wic）从SD卡烧写到eMMC。这将对卡进行分区，并将imx-boot、Image、dtb、dtbo和根文件系统复制到eMMC。

    • +

  • 加载镜像：

    +
    u-boot=> fatload mmc 1:3 ${loadaddr} phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • 切换mmc设备：

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc0(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • 关闭电源，将启动模式开关切换到默认SOM启动，以从eMMC启动。

    • +
+
+
+

4.2.4.2. 在开发板的linux环境中通过SD卡烧写eMMC

+

您也可以在Linux上烧写eMMC。您只需在SD卡上保存一个完整的镜像（例如 phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic）。

+
    +

  • 查看您在SD卡上保存的镜像文件：

    +
    target:~$ ls
+phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
    +
    +
    • +

  • 显示可用的MMC设备列表：

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • eMMC设备的特征是它包含两个boot分区：(mmcblk2 boot0; mmcblk2 boot1)

    • +

  • 将镜像写入 phyCORE-i.MX 8M Plus 的 eMMC (MMC 设备 2 不带 分区)：

    +
    target:~$ dd if=phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic of=/dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    • +
+
+

警告

+

在此之前，您需要将 bootmode switch (S3) 配置为默认SOM启动，以从eMMC启动。

+
+
+
+
+
+

4.3. 烧写 SPI NOR Flash

+

phyCORE-i.MX8MP 模块可选配SPI NOR Flash。要从SPI Flash启动，请将 bootmode switch (S3) 设置为 QSPI启动 以从QSPI启动。SPI Flash通常容量较小。phyBOARD-Pollux-i.MX8MP套件仅配备32MB SPI NOR Flash。只能存储bootloader及其环境。内核、设备树和文件系统默认保存在eMMC。

+

SPI NOR Flash分区表在U-Boot环境变量中定义。可以通过以下命令打印：

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. 通过网络烧写SPI NOR Flash

+

SPI NOR可以包含bootloader及其环境变量。arm64的linux内核无法自行解压缩，内核镜像大小超出了phyCORE-i.MX 8M Plus 上的SPI NOR Flash的容量。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！设置主机网络。

+
+
+

4.3.1.1. 在开发板的u-boot环境中从网络烧写SPI NOR

+

与通过网络更新eMMC类似，请确保正确设置开发主机。IP需要设置为192.168.3.10，子网掩码设置为255.255.255.0，并且需要有一个TFTP服务器。在进行读写操作之前，需要对SPI-NOR Flash进行probe：

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • 需要用特殊格式的SPI NOR Flash u-boot镜像。请确保使用正确的镜像文件。通过tftp加载镜像，擦除并将bootloader写入flash：

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+

警告

+

在写满后擦除整个SPI NOR Flash将需要相当长的时间。这可能会触发看门狗复位。因此，请在Linux中擦除整个闪存。

+
+
+
+

4.3.1.2. 在开发板linux环境中通过网络烧写SPI NOR Flash

+
    +

  • 将镜像从主机复制到开发板：

    +
    host:~$ scp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • 找到U-boot分区的擦除块数量：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除u-boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+

4.3.2. 从SD卡烧写SPI NOR Flash

+

SPI NOR Flash上的bootloader也可以通过SD卡进行烧写。

+
+

4.3.2.1. 在开发板的u-boot环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi复制到SD卡的FAT分区。在进行读写操作之前，需要对SPI-NOR flash进行probe：

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像，请确保使用正确的镜像文件。从SD卡加载镜像，擦除并将bootloader写入flash：

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+

警告

+

在写满后擦除整个SPI NOR Flash将需要相当长的时间。这可能会触发看门狗复位。因此，请在Linux中擦除整个闪存。

+
+
+
+

4.3.2.2. 在开发板的linux环境中从SD卡烧写SPI NOR

+
    +

  • 挂载SD卡：

    +
    host:~$ mount /dev/mmcblkp1 /mnt
+
    +
    +
    • +

  • 查找u-boot分区的擦除块数量：

    +
    target:~$  mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除u-boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC：L-1006e.A3 RAUC 更新与设备管理手册。

+
+
+
+

5. 开发

+
+

5.1. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.1.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.2. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.2.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核镜像复制到您的tftp目录中：

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • 将设备树复制到您的tftp目录：

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • 将您想要使用的所有overlay文件复制到您的tftp目录中：

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-qt5demo-image-phyboard-pollux-imx8mp-3.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.2.2. 设置网络启动的bootenv.txt文件

+

在您的tftp目录中创建一个bootenv.txt文件，并将以下变量写入其中。

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> 必须替换为您想要使用的overlay设备树文件名。用空格分隔文件名。例如：

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

小技巧

+

所有支持的设备树overlay在 device tree 章节中。

+
+
+
+

5.2.3. 开发板上的网络设置

+

如果要自定义开发板上的以太网配置，请按照此处的说明进行操作： Network Environment Customization

+
+
+

5.2.4. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.3.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. 获取镜像

+

可以从我们的服务器下载imx-boot，或者从Yocto编译目录中的build/deploy/images/phyboard-pollux-imx8mp-3/获取它。要将wic镜像烧写到eMMC，你还需要 phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic。

+
+
+

5.3.3. 开发板准备

+

将 bootmode switch (S3) 设置为 USB串行下载。同时，将 USB 端口 X5 (upper connector) 连接到主机。

+
+
+

5.3.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 (X1) 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.3.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic
+
+
+
+
+
+

5.4. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone git://git.phytec.de/u-boot-imx）

+
+
+

5.4.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-imx 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • 我们的 i.MX 8M Plus 内核是基于 linux-imx 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. 获取SDK

+

您可以在此处下载SDK 这里，或者使用Yocto去编译生成SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt5demo-image # or another image
+
    +
    +
    • +
+

在成功编译后，SDK安装包保存在 build/deploy*/sdk。

+
+
+

5.4.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt5demo-image-cortexa53-crypto-toolchain-BSP-Yocto-NXP-i.MX8MP-PD22.1.2.sh
+host:~$ ./phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt5demo-image-cortexa53-crypto-toolchain-BSP-Yocto-NXP-i.MX8MP-PD22.1.2.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.2):
+You are about to install the SDK to "/opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.2". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.2/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. 单独编译U-Boot

+
+

5.5.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本的 tag 称为 v2021.04_2.2.0-phy17

    • +

  • 查看所需的 U-Boot tag：

    • +
+
host:~$ cd ~/u-boot-imx/
+host:~$ git fetch --all --tags
+host:~$ git checkout tags/v2021.04_2.2.0-phy17
+
+
+
    +

  • 从技术上讲，您现在可以编译U-Boot，但实际上还需要一些进一步的步骤：

    +
      +

    • 创建您自己的开发分支：

      +
      host:~$ git switch --create <new-branch>
+
      +
      +
      +

      备注

      +

      您可以根据您的需要自行命名您的开发分支，这只是一个示例。

      +
      +
      • +
    +
    • +

  • 设置编译环境：

    +
    host:~$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.2/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +

  • 在编译镜像之前，请设置此环境变量：

    +
    host:~$ export ATF_LOAD_ADDR=0x970000
+
    +
    +
    • +
+
+
+

5.5.2. 获取所需的二进制文件

+

要编译bootloader，您需要将这些文件复制到您的 u-boot-imx 编译目录，并将其重命名以适应 mkimage 脚本：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx8mp.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以在yocto工程目录中获取 bl31-imx8mp.bin、tee.bin和lpddr4_*.bin：BSP Images

+

或者你可以在这里下载文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD22.1.2/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/

+
+

警告

+

确保您重命名所需的文件，以和 mkimage tool 兼容。

+
+
+
+

5.5.3. 编译bootloader

+
    +

  • 编译 flash.bin (imx-boot):

    +
    host:~$ make phycore-imx8mp_defconfig
+host:~$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. 将bootloader烧写到块设备上

+

flash.bin 文件可以在 u-boot-imx/ 目录中找到。需要一个特定于芯片的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

例如，烧写SD卡：

+
host:~$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+

5.5.5. 使用固定内存大小编译U-Boot

+

如果您的系统因为EEPROM中的硬件信息损坏或丢失而无法启动，您可以创建一个具有固定RAM大小的flash.bin。但您仍应联系我们支持部门以烧写正确的EEPROM数据。

+

按照步骤获取U-boot源代码，并切换到 Build U-Boot 章节说明的分支。

+

编辑文件 configs/phycore-imx8mp_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB_2GHZ=y
+
+
+

选择与板上配置匹配的正确RAM大小，并取消注释该RAM大小的行。对于型号0F8443I，请使用 [...]_4GB_2GHZ；对于0F5443I，请使用 [...]_4GB。保存更改后，请按照 Build U-Boot 进行操作。

+
+
+
+

5.6. 单独编译内核

+
+

5.6.1. 配置源代码

+
    +

  • 使用的 linux-imx 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v5.10.72_2.2.0-phy18

    • +

  • Check out 所需的 linux-imx 标签：

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v5.10.72_2.2.0-phy18
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor-xwayland/BSP-Yocto-NXP-i.MX8MP-PD22.1.2/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-imx$ make imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-imx/arch/arm64/boot/Image 找到

    • +

  • dtb文件可以在 ~/linux-imx/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. 将内核复制到SD卡

+

内核及module和对应的设备树二进制文件可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. 获取BSP开发中版本

+
+

5.7.1. 当前release的开发中版本

+

这些release manifest文件是为了让您访问 Yocto BSP的开发版本。它们不会在phyLinux选择菜单中显示，需要手动选择。可以使用以下命令行来完成此操作：

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD22.1.y
+
+
+

这将初始化一个BSP，用于跟踪当前版本（ BSP-Yocto-NXP-i.MX8MP-PD22.1.2 ）的最新开发版本。从现在开始，在此文件夹中执行 repo sync 将从我们的Git仓库中拉取所有最新的更改：

+
host:~$ repo sync
+
+
+
+
+

5.7.2. 即将发布版本的开发中版本

+

即将发布版本的开发中版本可以通过这种方式访问。请执行以下命令，并查找一个比最新版本（ BSP-Yocto-NXP-i.MX8MP-PD22.1.2 ）的PDXX.Y数字更高的版本，并且以 .y 结尾：

+
host:~$ ./phyLinux init -p imx8mp
+
+
+
+
+
+

5.8. 获取最新的Upstream支持

+

我们有一个使用Yocto主分支（不是NXP发布的）的manifest，他使用upstream的Linux和U-Boot。这可以用来测试最新的upstream kernel/U-Boot。

+
+

备注

+

master分支的manifest反映了最新的开发状态。有时会出现一些bug。我们会定期修复master分支。

+
+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.9.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将 phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将 phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic 镜像复制到其中。然后卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt5demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 8M Plus 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Carrierboard.dtsi - 包括来自于 i.MX 8M Plus SoC 的外设，在底板上使用的外设的设备树配置包含在这个 dtsi 中。

    • +

  • Board.dts - 包含底板和核心板的dtsi文件。以及使能一些底板或核心板上的器件和配置。例如，phyCORE-i.MX 8M Plus 核心板可能安装MIPI DSI到LVDS的转换器也可能没有，则Board.dts文件会根据安装情况来对该转换器进行使能配置。而不是在Module.dtsi中配置

    • +
+

在Linux内核的根目录下，我们的 i.MX 8 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。例如扩展板的硬件描述。对比源码中的include，overlay是用覆盖的方式来生效。overlay也可以根据节点是否连接来设置节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/overlays 中。

+

phyboard-pollux-imx8mp-3.conf 可用的overlay文件有：

+
imx8mp-isi-csi1.dtbo
+imx8mp-isi-csi2.dtbo
+imx8mp-isp-csi1.dtbo
+imx8mp-isp-csi2.dtbo
+imx8mp-phyboard-pollux-peb-av-010.dtbo
+imx8mp-phyboard-pollux-peb-av-012.dtbo
+imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+imx8mp-phycore-no-eth.dtbo
+imx8mp-phycore-no-rtc.dtbo
+imx8mp-phycore-no-spiflash.dtbo
+imx8mp-phycore-rpmsg.dtbo
+imx8mp-vm016-csi1.dtbo
+imx8mp-vm016-csi1-fpdlink.dtbo
+imx8mp-vm016-csi2.dtbo
+imx8mp-vm016-csi2-fpdlink.dtbo
+imx8mp-vm017-csi1.dtbo
+imx8mp-vm017-csi1-fpdlink.dtbo
+imx8mp-vm017-csi2.dtbo
+imx8mp-vm017-csi2-fpdlink.dtbo
+
+
+
+

提示

+

phyboard-pollux-imx8mp-2.conf还有一个可用的overlay文件：imx8mp-phyboard-pollux-1552.1.dtbo

+
+

可以在Linux或U-Boot环境下配置overlay。overlay是在引导命令调用后、内核加载之前生效。接下来的部分将更详细地解释配置方法。

+
+

6.2.2.1. 设置 ${overlays} 变量

+

${overlays} U-Boot 环境变量包含一个以空格分隔的overlay文件列表，这些overlay文件将在启动过程中应用。根据启动源，overlay文件必须放置在 eMMC/SD 卡的启动分区中，或者通过 tftp 加载。在 $KERNEL_DEVICETREE 这个 Yocto machine 变量中设置的 overlay 文件将自动添加到最终 WIC 镜像的启动分区中。

+

${overlays} 变量可以直接在U-Boot环境中设置，也可以作为外部 bootenv.txt 环境文件的一部分。默认情况下， ${overlays} 变量来自位于启动分区的 bootenv.txt 文件。您可以在已启动的开发板上从Linux读取和写入该文件：

+
target:~$ cat /boot/bootenv.txt
+overlays=imx8mp-phyboard-pollux-rdk-peb-eval-01.dtbo imx8mp-phyboard-pollux-peb-av-010.dtbo
+
+
+

更改将在下次重启后生效。如果没有可用的 bootenv.txt 文件，可以直接在U-Boot环境中设置overlay变量。

+
u-boot=> setenv overlays imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> printenv overlays
+overlays=imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> boot
+
+
+

如果用户定义了 ${overlays} 变量，同时存在 bootenv.txt 文件，则需要设置 ${no_bootenv} 变量：

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> boot
+
+
+

有关环境的更多信息，请参见 U-boot External Environment subsection of the +device tree overlay section。

+

我们使用 ${overlays} 变量来描述在运行时无法自动检测的扩展板和摄像头。如果想禁用 ${overlays} 变量中列出的overlay，可以在U-Boot的环境中将 ${no_overlays} 变量设置为 1。

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+

6.2.2.2. 扩展命令

+

使用U-Boot扩展命令能够轻松加载由回调函数 extension_board_scan() 检测并添加到列表中的overlay。以这种方式应用的overlay会禁用核心板上未贴装的组件。检测是通过读取出厂EEPROM数据（EEPROM SoM Detection）来实现的。

+

这取决于核心板型号是否会应用任何设备树overlay。要检查在U-Boot中运行的SoM是否会应用overlay，请运行：

+
u-boot=> extension scan
+Found 1 extension board(s).
+u-boot=> extension list
+Extension 0: phyCORE-i.MX8MP no SPI flash
+        Manufacturer:           PHYTEC
+        Version:
+        Devicetree overlay:     imx8mp-phycore-no-spiflash.dtbo
+        Other information:      SPI flash not populated on SoM
+
+
+

如果没有可用的EEPROM数据，则不加载任何设备树overlay。

+

为了禁止在启动时自动运行扩展命令，可以在bootloader环境中将 ${no_extensions} 变量设置为 1 ：

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot外部环境

+

在Linux内核启动时，外部环境 bootenv.txt 文本文件将从MMC设备的boot分区或通过TFTP加载。该文件的主要目的是存储 ${overlays} 变量。这可以针对不同的machine在Yocto中预定义不同的overlay配置。文件的内容在meta-phytec中的Yocto recipe中的bootenv中定义： https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=hardknott

+

该文件中也可以设置其他变量。这些变量将覆盖环境中现有的设置。但只有对boot命令后进行计算的变量生效，例如 ${nfsroot} 或 ${mmcargs}。在文件中更改其他变量将不会有作用。以网络启动的用法作为示例。

+

如果无法加载外部环境，启动过程将继续进行，并使用自带的环境变量值。

+
+
+

6.2.4. 在Linux环境下更改开发板上的U-boot环境变量

+

Libubootenv是我们镜像中包含的一个工具，用于在开发板linux上修改U-Boot环境。

+

使用以下命令打印U-Boot环境：

+
target:~$ fw_printenv
+
+
+

使用以下命令修改U-Boot环境：

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

小心

+

Libubootenv会读取配置文件中配置的环境变量。要修改的环境变量会被插入到该文件中，默认情况下使用eMMC中存储环境变量。

+

如果eMMC没有被烧写过或者eMMC环境被擦除，libubootenv将无法工作。您应该修改 /etc/fw_env.config 文件，以匹配您想要使用的环境源。

+
+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 8M Plus BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 8M Plus BSP设备树概念部分，以了解我们的 i.MX 8 BSP设备树模型。

+

以下部分概述了 i.MX 8 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 8M Plus 引脚复用

+

该 i.MX 8M Plus Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 8M Plus 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 8M Plus 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是imx8mp-phyboard-pollux.dtsi中UART1的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x49
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x49
+        >;
+};
+
+
+

字符串的第一部分 MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 指定了引脚（在这个例子中是 UART1_RXD）。字符串的第二部分（UART1_DCE_RX）是该引脚所选的复用项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部拉电阻是否被激活。在当前情况下，内部拉电阻被禁用。

+
+
+

7.2. RS232/RS485

+

phyCORE-i.MX 8M Plus 支持最多 4 个 UART 单元。在 phyBOARD-Pollux 上，UART1（调试串口）和 UART4 的 TTL 电平信号被连接到 Silicon Labs CP2105 UART 到 USB 转换IC。这个 USB 信号通过 Micro-USB 连接器 X1 输出。UART3 位于 X6（扩展连接器），为 TTL 电平信号。UART2 连接到一个多协议收发器IC，可转换为 RS-232 或 RS-485，RS-232 和 RS-485 信号位于连接器 X2 。多协议配置通过主板上的跳线 JP3 和 JP4 完成。更多信息，请参阅 phyCORE-i.MX 8M Plus/phyBOARD-Pollux 硬件手册中的 UARTs 部分。

+

对于RS-232和RS-485，使用相同的设备树节点。RS485模式可以通过ioctl TIOCSRS485 来启用。双向通讯支持也可以通过ioctl进行配置。请查看我们的小示例应用程序rs485test，该程序也包含在BSP中。需要设置跳线 JP3 和 JP4 。

+
+

7.2.1. RS232

+
    +

  • 以人类可读的格式显示终端的当前设置：

    +
    target:~$ stty -a
+
    +
    +
    • +

  • UART接口的配置可以通过stty命令完成。例如：

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • 通过简单的echo和cat，可以测试基本的通信。示例：

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

主机应打印出 "123"。

+
+
+

7.2.2. RS485

+
+

提示

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

为了方便测试，请查看linux-serial-test。这个工具会通过调用RS485的IOCTL，发送恒定的数据流。

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

有关linux-serial-test工具及其参数的更多信息，请访问此链接：linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Linux kernel文档描述了如何在C代码中调用IOCTL： https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+

RS232和RS485的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n331

+
+
+
+

7.3. 网络

+

phyBOARD-Pollux-i.MX 8M Plus 提供两个以太网接口。我们的核心板和底板各提供一个千兆以太网接口。

+
+

警告

+

硬件中的以太网接口命名约定（ethernet0 和 ethernet1）与Linux中的网络接口（eth0 和 eth1）不一致。因此，请注意这些差异：

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n41。

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Pollux can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n141.

+
+

7.3.1. 网络配置

+
+

7.3.1.1. U-boot网络环境

+
    +

  • 要在bootloader中查找以太网设置：

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • 在将主机设置为IP 192.168.3.10和子网掩码255.255.255.0的情况下，开发板应该返回：

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • 如果您需要进行任何更改：

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> 应该是 ipaddr、netmask、gatewayip 或 serverip 中的一个。<value> 将是所选参数的设定值。

    +
    • +

  • 您所做的更改目前是临时的。要保存这些更改：

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

在这里，您也可以将IP地址更改为DHCP，而不是使用静态IP地址。

+
    +

  • 配置：

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • 设置 TFTP 和 NFS 的路径。修改可以如下所示：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+

小技巧

+

像nfsroot和netargs这样的变量可以被U-boot外部环境重新赋值。对于网络启动，外部环境将通过tftp加载。例如，要在 bootenv.txt 文件中设置nfsroot变量，请在tftproot目录修改：

+
nfsroot=/home/user/nfssrc
+
+
+

无需在开发板上存储这些信息。请注意，U-boot外部环境对于像 ipaddr 或 serveraddr 这样的变量不起作用，因为它们在加载外部环境之前已经被设置完成。

+
+
+
+

7.3.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. 无线局域网

+

在 phyBOARD-Pollux 上，WLAN和蓝牙由PEB-WLBT-05扩展板提供。PEB-WLBT-05的 phyBOARD-Pollux 快速入门指南向您展示了如何安装PEB-WLBT-05。

+
+

小技巧

+

对于BSP版本PD22.1及更新版本，需要先激活PEB-WLBT-05 Overlay，否则PEB-WLBT-05将无法被识别。

+
target:~$ vi /boot/bootenv.txt
+
+
+

之后，bootenv.txt 文件应该如下所示（它还可以包含其他设备树overlay！）：

+
overlays=imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+
+
+

更改将在重启后应用：

+
target:~$ reboot
+
+
+

有关设备树overlay的更多信息，请阅读 device tree 章节。

+
+

为了支持WLAN和蓝牙，我们使用来自LSR的Sterling-LWB模块。该模块支持2.4 GHz，并且可以在多种模式下运行，如客户端模式、使用WEP、WPA、WPA2加密的接入点（AP）模式等。有关该模块的更多信息，请访问 https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. 连接到WLAN网络

+

首先设置您所在国家的正确监管域：

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

你将会看到：

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

设置无线接口：

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

现在您可以扫描可用的网络：

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

您可以使用一个跨平台的客户端，名为wpa_supplicant，支持WEP、WPA和WPA2，以建立加密连接。

+

为此，请将网络凭据添加到文件 /etc/wpa_supplicant.conf 中：

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

现在可以建立连接：

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

这会得到如下输出：

+
...
+ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

要完成配置，您可以配置DHCP以接收IP地址（大多数WLAN接入点都支持）。有关其他可能的IP配置，请参阅 L-813e.A12 Yocto Reference Manual (Hardknott) 中的“更改网络配置”部分。

+

首先，创建目录：

+
target:~$ mkdir -p /etc/systemd/network/
+
+
+

然后在 /etc/systemd/network/10-wlan0.network 中添加以下配置片段：

+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+

现在，请重启网络守护进程以使配置生效：

+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+
+

7.3.3. 蓝牙

+

Bluetooth is supported on phyBOARD-Pollux with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section.

+

Bluetooth is connected to UART3 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

现在您可以扫描环境中的可见蓝牙设备。在默认配置下，蓝牙是不可见的。

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. 可见性

+

要激活可见性：

+
target:~$ hciconfig hci0 piscan
+
+
+

要禁用可见性：

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. 连接

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

备注

+

如果连接失败并出现错误信息：“连接失败：org.bluez.Error.Failed”，请尝试使用以下命令重新启动PulseAudio：

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC 卡

+

该 i.MX 8M Plus 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

MMC（SD卡插槽）接口的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n367

+

eMMC接口的DT配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n220

+
+
+

7.5. eMMC设备

+

PHYTEC模块，如phyCORE-i.MX 8M Plus，配备了一个eMMC存储芯片作为主要存储。eMMC设备包含MLC存储单元，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 8M Plus，并在Linux内核中被表示为块设备，类似于SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.5.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），负责处理原始MLC单元的磨损平衡、块管理和错误纠正码（ECC）。这需要定期进行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+

mmc这个linux工具目前不支持启用自动BKOPS功能。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops enable /dev/mmcblk2
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.5.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 8M Plus SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n> <partition> <device>
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.5.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
    +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+
+
+

7.5.5. 启用伪SLC模式

+

eMMC设备使用 多层单元内存（MLC） 来存储数据。与NAND Flash中使用的单层单元（SLC）内存单元相比，MLC内存单元具有更低的可靠性和更高的错误率，但成本更低。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. 擦除设备

+

可以直接擦除eMMC设备，而不是用零覆盖它。eMMC块管理算法将会擦除MLC存储单元或将这些块标记为丢弃。设备上的数据将丢失，并且读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.5.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 8M Plus 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.5.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

下表是 i.MX 8M Plus SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.6. SPI主设备

+

i.MX 8M Plus 控制器包含一个 FlexSPI 和一个 ECSPI IP 核。FlexSPI 主控制器支持两个 SPI 通道，最多可连接 4 个设备。每个通道支持单通道/双通道/四通道/八通道模式的数据传输（1/2/4/8 条数据线）。ECSPI 控制器支持 3 个 SPI 接口，每个接口都有一个专用的CS（chip select）引脚。由于CS也可通过 GPIO 实现，因此每个通道上可以连接多个设备。

+
+

7.6.1. SPI NOR 烧写

+

phyCORE-i.MX 8M Plus 配备有一个 QSPI NOR Flash，该 Flash 连接到 i.MX 8M Plus 的 FlexSPI 接口。QSPI NOR Flash 可用于启动。有关烧写和启动模式设置的详细信息，请参见不同的章节。由于 SPI NOR Flash 的空间有限，因此仅可存储bootloader。默认情况下，内核、设备树和根文件系统来自 eMMC。

+

bootloader程序通过EEPROM数据检测是否安装了SPI Flash。如果没有安装SPI Flash，则在启动期间应用设备树overlay，通过扩展命令禁用SPI Flash设备树节点。如果没有可用的EEPROM数据，SPI NOR Flash节点将始终启用。有关更多信息，请参阅设备树overlay部分。

+

bootloader程序还可以通过内核的mtdparts启动参数修改设备树，将SPI MTD分区表传递给Linux。BSP中的默认分区布局设置为：

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

这是一个预定义的bootloader环境变量，可以在运行时更改。从Linux用户空间，可以通过/dev/mtd<N>设备访问NOR Flash分区，其中<N>是与要访问的NOR Flash分区相关联的MTD设备编号。要找到分区的正确MTD设备编号，请在目标上运行：

+
root@phyboard-pollux-imx8mp-3:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

它列出了所有MTD设备及其对应的分区名称。闪存节点在模块DTS中的SPI主节点内定义。SPI节点包含连接到此SPI总线的所有设备，在这种情况下只有SPI NOR Flash。

+

设备树中SPI主节点的定义可以在这里找到：

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n72

+
+
+
+

7.7. GPIOs

+

phyBOARD-Pollux 具有一组专门用于GPIO的引脚。这些引脚直接连接到 i.MX 8M Plus 引脚，并被复用为 GPIO。它们可以直接在 Linux 用户空间中使用。处理器将其 GPIO 组织为5个GPIO组（GPIO1 – GPIO5），每个组包含 32 个GPIO。gpiochip0、gpiochip32、gpiochip64、gpiochip96 和 gpiochip128 是这些内部 i.MX 8M Plus GPIO 组 GPIO1 – GPIO5 的 sysfs 表示。

+

GPIO被标识为GPIO<X>_<Y>（例如：GPIO5_07）。<X>表示GPIO Bank，从1计数到5，而<Y>表示该Bank内的GPIO。<Y>从0计数到31（每个bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如从gpiochip0的GPIO 20）：

    +
    target:~$ gpioget gpiochip0 20
+
    +
    +
    • +

  • 将gpiochip0上的GPIO 20的值设置为0并退出工具：

    +
    target:~$ gpioset --mode=exit gpiochip0 20=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.7.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用 CONFIG_GPIO_SYSFS 后才能支持。要在menuconfig中使 CONFIG_GPIO_SYSFS 可见，必须首先启用选项 CONFIG_EXPERT 。

+

您也可以将此选项添加到您在 Linux 内核源代码 arch/arm64/configs/ 目录下使用的 defconfig 中。例如，我们基于 NXP 的BSP版本，这个defconfig可以是 imx8_phytec_distro.config

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

您也可以创建一个新的config片段。有关详细信息，请参阅我们的《Yocto参考手册<yocto-ref-manual-kernel-and-bootloader-config>》。

+
+
+
+

7.8. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+mmc1::@    mmc2::@    user-led1@ user-led2@ user-led3@
+
+
+

这里的 LED 灯包括蓝色的 mmc、绿色的 心跳和红色的 emmc，它们都在 phyBOARD-Pollux 上。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 255 > /sys/class/leds/user-led1/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/user-led1/brightness
+
    +
    +
    • +
+

GPIO配置的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n216

+
+
+

7.9. I²C总线

+

该 i.MX 8M Plus 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 8M Plus 的I²C模块。 本节描述了我们 phyBOARD-Pollux 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

I²C1 总线DT配置（例如 imx8mp-phycore-som.dtsi）：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n105

+

I²C2总线DT配置（例如 imx8mp-phyboard-pollux-rdk.dts）：imx-dt:imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n201

+
+
+

7.10. EEPROM

+

在 phyCORE-i.MX8MP 上有一个i2c EEPROM闪存。它有两个地址。主EEPROM空间（总线：I2C-0 地址：0x51）和ID页（总线：I2C-0 地址：0x59）可以通过Linux中的sysfs接口进行访问。主EEPROM和ID页的前256个字节用于板检测，不可被覆盖。覆盖保留的空间将导致启动问题。

+
+

7.10.1. phyCORE-i.MX8MP 上的I2C EEPROM

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

phyCORE-i.MX8MP SoM上的I2C EEPROM连接到I2C-0总线的I2C地址0x51。可以直接对该设备进行读写操作：

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

要用零填充4KiB的EEPROM（总线：I2C-0 地址：0x51），并保留EEPROM数据，请使用：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM 检测

+

在 phyCORE-i.MX8MP 上配置的I2C EEPROM具有一个可通过I2C地址0x59在i2c0上寻址的独立ID页面，以及一个可通过I2C地址0x51在i2c0上寻址的正常区域。PHYTEC使用这个32字节的数据区域来存储关于SoM的信息，包括PCB版本和配置。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果EEPROM ID页面数据和正常区域的前256个字节被删除，bootloader程序将回退到 phyCORE-i.MX8MP Kit RAM设置，即 2GiB RAM。

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

使用API修订版2数据格式烧写的核心板将在早期启动阶段打印出有关模块的信息。

+
+
+

7.10.3. 恢复EEPROM数据

+

硬件数据已预先写入两个EEPROM数据空间。如果您不小心删除或覆盖了Normal区域，可以将ID区域的硬件检查数据复制到正常区域。

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1
+
+
+
+

备注

+

如果您删除了两个EEPROM空间，请联系我们的支持团队！

+
+

核心板phyCORE-i.MX 8M Plus 的设备树文件 imx8mp-phycore-som.dtsi 可以在我们的 PHYTEC git 中找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n201

+
+
+
+

7.11. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC唤醒alarm

+

可以从实时时钟（RTC）发出中断以唤醒系统。该格式使用Unix纪元时间，即自1970年1月1日UTC午夜以来的秒数。要在从挂起到RAM状态后的4分钟唤醒系统，请输入：

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

备注

+

内部唤醒alarm时间将被向上舍入到下一个分钟，因为alarm功能不支持秒。

+
+

I²C RTC的DT表示： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.10.72_2.2.0-phy18#n207

+
+
+
+

7.12. USB主控制器

+

i.MX 8M Plus SoC的USB控制器为众多消费类便携设备提供了一种低成本的连接解决方案，实现USB设备之间的数据传输，传输速度可达4 Gbit/s（超高速'SS'）。USB子系统具有两个独立的USB控制器。这两个控制器都能够作为USBDevice或USB Host使用。每个核心都连接到一个USB 3.0物理层（PHY）。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+

USB Host的DT表示：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n341

+
+
+

7.13. CAN FD

+

The phyBOARD-Pollux has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。两个CAN接口显示为can0和can1。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    can0的信息将如下所示：

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+
+

警告

+

mcp2518fd SPI到CAN FD只支持从125kB/s开始的波特率。可以选择更慢的速率，但可能无法正常工作。

+
+

imx8mp-phyboard-pollux.dtsi的设备树CAN配置： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n165

+
+
+

7.14. PCIe

+

phyCORE-i.MX 8M Plus 具有一个 Mini-PCIe 插槽。一般来说，PCIe 会自动检测总线上的新设备。在连接设备并启动系统后，您可以使用命令 lspci 查看所有被识别的 PCIe 设备。

+
    +

  • 输入：

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • 你将收到：

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

在这个例子中，PCIe设备是 英特尔 WiFi Link 5100 。

+

对于PCIe设备，您必须在内核配置中启用正确的驱动程序。例如，这款WLAN卡是由英特尔制造的。必须启用的驱动程序选项名为 CONFIG_IWLWIFI ，可以在内核配置中的 Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimate 下找到。

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • linux-imx的表示为：virtual/kernel

      • +
    +
    • +
+

对于某些设备，如WLAN卡，需要额外的二进制固件文件。这些固件文件必须放置在 /lib/firmware/ 目录中，才能使用该设备。

+
    +

  • 输入：

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • 例如，如果您尝试启动网络接口：

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • 您将在串口控制台上获得以下输出：

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

小技巧

+

某些PCIe设备，例如以太网卡，即使没有从 /lib/firmware/ 加载固件文件，也可能正常工作，而你收到了如上输出第一行所示的错误消息。这是因为一些制造商在板卡本身提供了固件作为后备。在这种情况下，设备的行为和输出在很大程度上依赖于制造商的固件。

+
+

imx8mm-phyboard-polis.dtsi的设备树PCIe配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n277

+
+
+

7.15. 音频

+

支持的播放设备包括HDMI和PEB-AV-10连接器上的TI TLV320AIC3007音频编解码器（CODEC）IC。在AV连接器上，有一个符合OMTP标准的3.5mm耳机插孔和一个8针排针。8针排针包含单声道扬声器、耳机和line-in信号。

+
+

备注

+

使用PEB-AV-10连接器进行显示输出时，不支持通过HDMI作为音频输出。音频输出设备必须与视频输出设备匹配。

+
+

要检查您的声卡驱动程序是否正确加载以及设备名称，请输入以下命令以查看播放设备：

+
target:~$ aplay -L
+
+
+

或输入录音设备：

+
target:~$ arecord -L
+
+
+
+

7.15.1. Alsamixer

+

要检查声卡的功能，请输入：

+
target:~$ alsamixer
+
+
+

您应该会看到很多选项，因为音频IC具有许多可以配置的功能选项。通过SSH打开alsamixer可能比通过串口控制台更好，因为控制台的图形效果更佳。您可以为所有混合点使用单声道或立体声增益控制。“MM”表示该功能被静音（左右输出均为静音），可以通过按 m 键切换。您还可以通过按'<'键切换左声道和'>'键切换右声道。使用 tab 键，您可以在播放和录音的控制之间切换。

+
+
+

7.15.2. ALSA配置

+

我们的BSP附带一个ALSA配置文件 /etc/asound.conf 。

+

ALSA配置文件可以根据需要进行编辑或删除，它并不是ALSA正常工作所必需的。

+
target:~$ vi /etc/asound.conf
+
+
+

要将PEB-AV-10设置为输出，请将 playback.pcm 从 "dummy" 设置为 "pebav10":

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

如果听不到声音，请将播放设备更改为软件音量控制播放设备，将 playback.pcm 设置为相应的软音量播放设备，选择 "softvol_hdmi" 或 "softvol_pebav10"。使用 alsamixer 控件来调整音量水平。

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_hdmi"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.15.3. PulseAudio 配置

+

对于使用Pulseaudio的应用程序，请检查可用的输出设备：

+
target:~$ pactl list short sinks
+0   alsa_output.platform-snd_dummy.0.stereo-fallback    module-alsa-card.c  s16le 2ch 44100Hz   SUSPENDED
+1   alsa_output.platform-sound-peb-av-10.stereo-fallback    module-alsa-card.c  s16le 2ch 44100Hz   SUSPENDED
+
+
+

要选择PEB-AV-10，请输入：

+
target:~$ pactl set-default-sink 1
+
+
+
+
+

7.15.4. 播放

+

运行speaker-test以检查播放功能：

+
target:~$ speaker-test -c 2 -t wav
+
+
+

要播放简单的音频流，您可以使用aplay。例如，要播放ALSA测试音频：

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

要播放其他格式，例如mp3，您可以使用Gstreamer：

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.15.5. 录音

+

arecord 是一个命令行工具，用于录制音频流，默认输入源为线路输入。要选择不同的音频源，可以使用 alsamixer。例如，打开 右侧 PGA 混音器 Mic3R 和 左侧 PGA 混音器 Mic3R，以便通过 3.5mm 插孔录制来自 TLV320 编解码器的麦克风输入音频。

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

提示

+

由于播放和录音共享硬件接口，因此无法在同时进行播放和录音操作时使用不同的采样率和格式。

+
+

设备树音频DT配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.10.72_2.2.0-phy18#n57

+
+
+
+

7.16. 视频

+
+

7.16.1. 视频与Gstreamer

+

这个视频在BSP中默认安装：

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/phytec-qtdemo/videos/caminandes.webm
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=<video.mp4> \
+\! qtdemux  \! h264parse \! queue \! vpudec \! waylandsink async=false enable-last-sample=false \
+qos=false sync=false
+
+
+
    +

  • 或者：

    • +
+
target:~$ gplay-1.0 /usr/share/phytec-qtdemo/videos/caminandes.webm
+
+
+
+
+

7.16.2. kmssink 插件 ID 确认

+

kmssink插件需要一个连接器ID。要获取连接器ID，您可以使用工具modetest。

+
target:~$ modetest -c imx-drm
+
+
+

输出如：

+
Connectors:
+id  encoder status      name        size (mm)   modes   encoders
+35  34  connected   LVDS-1          216x135     1   34
+  modes:
+    index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
+  #0 1280x800 59.07 1280 1380 1399 1440 800 804 808 823 70000 flags: phsync, pvsync; type: preferred, driver
+  props:
+    1 EDID:
+        flags: immutable blob
+        blobs:
+
+        value:
+    2 DPMS:
+        flags: enum
+        enums: On=0 Standby=1 Suspend=2 Off=3
+        value: 0
+    5 link-status:
+        flags: enum
+        enums: Good=0 Bad=1
+        value: 0
+    6 non-desktop:
+        flags: immutable range
+        values: 0 1
+        value: 0
+    4 TILE:
+        flags: immutable blob
+        blobs:
+
+        value:
+
+
+
+
+
+

7.17. 显示

+

该 phyBOARD-Pollux 支持多达4种不同的显示输出。可以同时使用三种。下表显示了不同接口所需的扩展板和设备树overlay。

+ + + + + + + + + + + + + + + + + + + + + + + + + +

接口

扩展板

设备树overlay

HDMI

phyBOARD-Pollux

不需要overlay（默认启用）

LVDS0

PEB-AV-10

imx8mp-phyboard-pollux-peb-av-010.dtbo（默认加载）

LVDS1

phyBOARD-Pollux

如果使用PEB-AV-10 overlay，则禁用

MIPI

PEB-AV-12 (MIPI到LVDS)

imx8mp-phyboard-pollux-peb-av-012.dtbo

+
+

备注

+
    +

  • 如果启用了LVDS1（板载），HDMI将无法工作。

    • +

  • 在更改Weston输出时，请确保音频输出也相匹配。

    • +

  • LVDS0 (使用PEB-AV-10扩展) 和 LVDS1 (板载) 不能同时使用。

    • +
+
+

HDMI在设备树中始终启用。其他接口可以通过设备树overlay进行启用。

+

默认启用的接口是HDMI和LVDS0（PEB-AV-010）。我们的PEB-AV-10和PEB-AV-12扩展板支持10英寸edt,etml1010g0dka显示屏。

+
+

备注

+

当前的显示驱动程序将连接到LVDS的LCD的像素时钟限制为74.25MHz（或其分频）。如果这满足不了您的需求，请联系支持团队以获得进一步的帮助。

+
+
+

7.17.1. Weston 配置

+

为了让Weston正确的显示，需要进行正确的配置。这将在/etc/xdg/weston/weston.ini中完成。

+
+

7.17.1.1. 单一显示器

+

在我们的BSP中，默认的Weston输出设置为HDMI.

+
[output]
+name=HDMI-A-1
+mode=current
+
+
+
+
+
+

7.17.2. Qt Demo

+

使用phytec-qt5demo-image时，Weston会在启动时启动。可以通过以下命令停止phytec-qt5demo：

+
target:~$ systemctl stop phytec-qtdemo
+
+
+
    +

  • 要重新开始Demo，请运行：

    +
    target:~$ systemctl start phytec-qtdemo
+
    +
    +
    • +

  • 要禁用Demo的自动启动，请运行：

    +
    target:~$ systemctl disable phytec-qtdemo
+
    +
    +
    • +

  • 要启用Demo的自动启动，请运行：

    +
    target:~$ systemctl enable phytec-qtdemo
+
    +
    +
    • +

  • Weston可以通过以下方式停止：

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

备注

+

在关闭Weston之前，必须先关闭Qt Demo。

+
+
+
+

7.17.3. 背光控制

+

如果LCD连接到PHYTEC开发板，可以通过Linux内核的sysfs接口控制其背光。系统中所有可用的背光设备可以在文件夹/sys/class/backlight中找到。读取相应的文件并向其写入数据可以控制背光。

+
+

备注

+

一些具有多显示的开发板在 /sys/class/backlight 有多个背光控制。比如：backlight0和backlight1

+
+
    +

  • 例如，要获取最大亮度级别（max_brightness），请执行：

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    有效的亮度值范围是 0 到 <max_brightness>。

    +
    • +

  • 要获取当前亮度级别，请输入：

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • 写入文件brightness以更改亮度：

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    例如，关闭背光。

    +

    有关所有文件的文档，请参见 https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight。

    +
    • +
+

LVDS-1和HDMI的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n255 https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n180

+

PEB-AV-10上LVDS-0的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.10.72_2.2.0-phy18#n132

+
+
+
+

7.18. 电源管理

+
+

7.18.1. CPU核心频率调节

+

i.MX 8M Plus SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。调整频率和电压被称为“动态电压和频率调整”（DVFS）。i.MX 8M Plus BSP支持DVFS功能。Linux内核提供了一个DVFS框架，允许每个CPU核心设置最小或最大频率和一个管理其运行的governor。根据使用的 i.MX 8 型号，支持几种不同的频率。

+
+

小技巧

+

尽管DVFS框架为每个CPU核心提供了频率设置，但一个CPU核心的频率更改会影响其他CPU核心。因此，所有CPU核心始终共享相同的DVFS设置。每个核心的单独DVFS设置是不可能的。

+
+
    +

  • 要获取完整列表，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    例如 i.MX 8MPlus CPU，最高可达约 1.6 GHz，则结果将是：

    +
    1200000 1600000
+
    +
    +
    • +

  • 要查询当前的频率输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

governor 会根据它们的目标自动选择这些频率中的一个。

+
    +

  • 列出所有可用的 governor，使用以下命令：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    结果是：

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative governor 与 ondemand governor 非常相似。只是它的行为有所不同，它会更保守地增减CPU速度，而不是在CPU有任何负载的瞬间就跳到最大速度。

    • +

  • ondemand （默认）根据当前系统负载在可能的CPU核心频率之间切换。当系统负载超过特定值时，它会立即提高CPU核心频率。

    • +

  • powersave 始终选择最低的CPU核心频率。

    • +

  • performance 始终选择最高的CPU核心频率。

    • +

  • userspace 允许以root身份运行的用户或用户空间程序设置特定频率（例如，设置为1600000）。输入：

    • +

  • 要查询当前的 governor，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    您通常会得到：

    +
    ondemand
+
    +
    +
    • +

  • 切换到另一个governor（例如，userspace）可以通过以下方式完成：

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • 现在你可以设置频率：

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

有关governor的更详细信息，请参阅Linux内核代码库中的Linux内核文档，路径为 Documentation/admin-guide/pm/cpufreq.rst 。

+
+
+

7.18.2. CPU核心管理

+

该 i.MX 8M Plus SoC 芯片上可以有多个处理器核心。例如，该 i.MX 8M Plus 具有 4 个 ARM 核心，可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    这里系统有四个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.18.3. 挂起到RAM

+

phyCORE-i.MX8MP 支持基本的挂起和恢复。可以使用不同的唤醒源。挂起/恢复可以通过以下方式实现：

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

要通过串行控制台唤醒，请运行

+
target:~$ echo enabled > /sys/class/tty/ttymxc0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.19. 热管理

+
+

7.19.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.19.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 8M Plus SoC 平台上使用热管理内核 API。 i.MX 8 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个触发点。这些触发点根据CPU型号的不同而有所不同。主要区分工业版和商业版。

+ + + + + + + + + + + + + + + + + +

商业

工业

被动（警告）

85°C

95°C

严重（关机）

90°C

100°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并实施冷却措施。内核中可用的热政策（也称为thermal governor）包括：Step Wise、Fair Share、Bang Bang和Userspace。BSP中使用的默认策略是Step Wise。如果sysfs文件temp中的SoC温度值高于 trip_point_0 ，则CPU频率将设置为最低CPU频率。当SoC温度降到 trip_point_0 以下时，限制将被解除。

+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+

7.19.3. GPIO风扇

+
+

备注

+

Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan +to GPIO fan due to availability. The PWM fan will not be supported +anymore and will not function with the new release.

+
+

一个GPIO控制的风扇可以连接到 phyBOARD-Pollux-i.MX 8M Plus。该SoC包含一个温度传感器，该传感器被用于热频率调节。风扇无法通过内核进行控制。我们使用lmsensors和hwmon来实现这一点。lmsensors定期读取温度，并在可配置的阈值下启用或禁用风扇。对于 phyBOARD-Pollux-i.MX 8M Plus，这个阈值是60°C。

+

设置可以在配置文件中进行配置：

+
/etc/fancontrol
+
+
+

风扇控制在启动时由systemd服务启动。可以通过以下方式禁用它：

+
target:~$ systemctl disable fancontrol
+
+
+

GPIO风扇的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux.dtsi?h=v5.10.72_2.2.0-phy18#n26

+
+
+
+

7.20. 看门狗

+

PHYTEC i.MX 8M Plus 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.20.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.21. snvs电源按键

+

连接到开关按钮的 X_ONOFF 引脚可以长按以触发关机，而无需软件干预，或用于唤醒系统以退出挂起状态。使用 snvs_pwrkey 驱动程序时，当按下按钮时，KEY_POWER 事件也会报告给用户空间。默认情况下，systemd 被配置为忽略此类事件。关机而无需软件干预的功能以及从挂起状态唤醒的功能未被配置。可以在 /etc/systemd/logind.conf 中配置按下开/关按钮时通过 systemd 触发关机，配置方法如下：

+
HandlePowerKey=poweroff
+
+
+
+
+

7.22. NPU

+

i.MX 8M Plus SoC包含一个NPU，其运算能力达到 2.3 TOPS，专用于人工智能操作。有关 NPU 的信息，请参考我们最新的 phyCORE-i.MX 8M Plus AI 套件指南，您可以在 phyCORE-i.MX 8M Plus 下载部分找到：L-1015e.A0 phyCORE-i.MX 8M Plus AI Kit Guide

+
+

7.22.1. NXP eIQ 示例

+

NXP提供了一组使用Python3的针对eIQ的机器学习示例，。要添加一个预配置的机器学习软件包，请将其添加到你的local.conf中并编译你的BSP:

+
IMAGE_INSTALL_append = " packagegroup-imx-ml python3-pip python3-requests opencv"
+
+
+

这将需要在SD卡上有大约1GB的空间。有关如何安装和使用NXP示例的说明，请访问 https://community.nxp.com/t5/Blogs/PyeIQ-3-x-Release-User-Guide/ba-p/1305998。

+
+

提示

+

使用pip3安装eiq示例需要互联网连接。

+
+
+

备注

+

在某些Ubuntu 20.04主机上，cmake在编译python3-pybind11时使用主机的Python 3，而不是Yocto中的Python 3.7。（参见：https://community.nxp.com/t5/i-MX-Processors/Yocto-L5-4-70-2-3-0-build-image-failed/m-p/1219619）

+

可以用以下方法解决，修改python3-pybind11的recipe：

+
$ devtool edit-recipe python3-pybind11
+
+
+

并将以下内容加入文件:

+
EXTRA_OECMAKE += "-DPYTHON_EXECUTABLE=${RECIPE_SYSROOT_NATIVE}/usr/bin/python3-native/python3.7"
+
+
+
+
+
+
+

7.23. ISP

+

i.MX 8M Plus SoC包含一个图像信号处理器（ISP）。有关更多信息，请参阅|sbc| i.MX 8M Plus 文档中的使用ISP部分。

+
+
+

7.24. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 8M Plus 提供一次性可编程fuse，用于存储信息，例如 MAC 地址、启动配置和其他永久设置（在 i.MX 8M Plus reference manual中称为“片上 OTP 控制器 (OCOTP_CTRL)”）。以下列表摘自 i.MX 8M Plus reference manual，包括 OCOTP_CTRL 中的一些有用寄存器（基地址为0x30350000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为0x30350000

描述

OCOTP_MAC_ADDR0

9

0

0x640

包含ENET0 MAC地址的低32位

OCOTP_MAC_ADDR1

9

1

0x650

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

OCOTP_MAC_ADDR2

9

2

0x660

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 8M Plus Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.24.1. 在uBoot中读取fuse的值

+

您可以使用内存映射的shadow寄存器读取fuse寄存器。要计算内存地址，请使用以下公式计算：

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.24.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+

除非*ocotp_root_clk*已启用，否则使用``/dev/mem``读取寄存器会导致系统挂起。要永久启用此时钟，请在设备树中添加：

+
&clk {
+        init-on-array = <IMX8MP_CLK_OCOTP_ROOT>;
+};
+
+
+
+
+
+
+

8. i.MX 8M Plus M7 Core

+

除了Cortex-A53核心外，SoC中还集成了一个Cortex-M7 Core 作为MCU。我们的Yocto-Linux-BSP在A53核心上运行，而 M7 Core 可以作为辅助CPU，用于使用裸机或RTOS固件执行额外任务。两种核心都可以访问相同的外设，因此外设的使用需要在 M7 Core 的固件或Linux操作系统的设备树中进行限制。本节将描述如何编译固件示例以及如何在 phyBOARD-Pollux 上运行它们。

+

phyBOARD-Pollux 目前由 NXP MCUXpresso SDK 和 Zephyr 项目支持。本节仅描述 NXP MCUXpresso SDK，因为目前 MCUXpresso SDK 支持的功能更多。

+

如果您想在Zephyr项目中使用 M7 Core ，请参考Zephyr项目文档：

+ +
+

8.1. 获取固件示例

+

固件可以使用NXP MCUxpresso SDK和兼容的编译工具链通过命令行工具进行编译。

+
+

8.1.1. 获取源代码

+

MCUX SDK以及 i.MX 8M Plus 的示例可以从PHYTEC的GitHub页面获取：

+ +
    +

  1. 通过west初始化MCUX SDK：

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    这将创建一个 mcuxsdk 目录，并在其中包含 mcux-sdk 仓库。mcux-sdk-phytec-examples 仓库将自动克隆到 mcuxsdk 目录中。给定的参数 <VERSION> 是 mcux-sdk 仓库的分支名称，代表 MCUX SDK 版本。要获取最新的测试版本，您可以使用 2.13.0。

    +
    +

    备注

    +

    west 是一个仓库管理工具，也是 Zephyr 项目的一部分。要安装 west，您可以使用 pip。在这个示例中，west 被安装在一个 Python 虚拟环境中:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. 更新依赖项：

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    目录 examples-phytec 包含了所有移植并测试过的示例，适用于 phyBOARD-Pollux 和版本为 2.13.0 的 MCUX。

    +

    要编译固件，需要一个编译器工具链和make/cmake。GNU ARM 嵌入式工具链可能在您的主机linux发行版的仓库中可用，例如Ubuntu。

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    编译器工具链也可以直接从 https://developer.arm.com/ 获取。在解压缩文件后，必须将 ARMGCC_DIR 添加到环境变量中，例如，对于位于主目录中的 ARM toolchain 10-2020-q4-major 版本：

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. 编译固件

+

要编译PHYTEC示例，需要先设置环境

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

编译固件的脚本位于 <sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc。每个可运行的内存位置都有相应的编译脚本，例如：

+
host:~$ ./build_release.sh
+
+
+

要编译运行在 M7 Core 的 TCM 上的固件。输出将放置在 armgcc 目录下的 release/ 中。.bin 文件可以在 U-Boot 中运行，而 .elf 文件可以在 Linux 中运行。

+

要编译在DRAM上运行的固件，请运行脚本build_ddr_release。例如。

+
host:~$ ./build_ddr_release.sh
+
+
+

输出将放置在armgcc目录下的ddr_release/中。.bin文件可以在U-Boot中运行，而.elf文件可以在Linux中运行。

+
+
+
+

8.2. 运行 M7 Core 示例

+

有两种方法可以运行 M7 Core 的固件，在Linux中使用Remoteproc以及在U-Boot。

+

要接收调试信息，请在您的主机PC上启动您喜欢的终端软件（例如Minicom、Tio或Tera Term），并将其配置为115200波特率、8个数据位、无奇偶校验和1个停止位（8n1），且不使用握手。

+

一旦Micro USB电缆连接到 phyBOARD-Pollux 上的USB调试端口，就会注册两个ttyUSB设备。一个打印来自A53核心的调试UART的消息，另一个打印来自 M7 Core 的调试UART的消息。

+
+

8.2.1. 从U-Boot运行示例

+

要使用bootloader U-Boot加载固件，可以使用bootaux命令：

+
    +

  1. 准备一张烧写了BSP镜像的SD卡

    2. +

  2. 将生成的 .bin 文件复制到 SD 卡的第一个分区

    3. +

  3. 通过按任意键停止自动启动

    4. +

  4. 根据固件类型输入命令：

    5. +
+

对于在 M7 Core 的TCM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

用于在DRAM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

程序的输出应显示在 M7 Core 的调试UART上。

+
+
+

8.2.2. 通过Remoteproc在Linux上运行示例

+

Remoteproc是一个模块，允许您在运行时从Linux控制 M7 Core 。可以加载为TCM编译的固件，并可以启动或停止执行。要使用Remoteproc，需要设置设备树Overlay：

+

在开发板的/boot目录中编辑bootenv.txt文件，添加 imx8mp-phycore-rpmsg.dtbo ：

+
overlays=imx8mp-phycore-rpmsg.dtbo
+
+
+

重启目标并在U-Boot中执行:

+
u-boot=> run prepare_mcore
+
+
+

M7 Core 的固件 .elf 文件可以在 /lib/firmware 下找到。要加载固件，请输入：

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

要加载不同的固件，M7 Core 需要停止：

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

备注

+

在开发板上找到的 /lib/firmware 中的例子来自NXP的Yocto层meta-imx。要使用您通过MCUX SDK自己编译的样本，请在编译后将它们复制到开发板的 /lib/firmware 中。

+
+
+ +
+
+
+

9. BSP扩展

+
+

9.1. Chromium

+

我们的BSP支持Chromium。您只需几个步骤即可将其包含在 phytec-qt5demo-image 中。

+
+

9.1.1. 将Chromium添加到您的local.conf文件中

+

要包含Chromium，您需要在您的local.conf中添加以下行。您可以在<yocto_dir>/build/conf/local.conf中找到这个配置文件。这将把Chromium添加到您下一个镜像编译中。:

+
IMAGE_INSTALL_append = " chromium-ozone-wayland"
+
+
+
+

备注

+

编译Chromium需要很长时间。

+
+
+
+

9.1.2. 在开发板上运行Chromium

+

要运行Chromium，需要一些参数来使用硬件图形加速：

+
target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox
+
+
+

如果您想通过SSH启动Chromium，您必须首先定义运行Chromium的显示器。例如：

+
target$ DISPLAY=:0
+
+
+

在您定义完这个之后，您可以通过上述所示的Weston虚拟终端启动它。

+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mp/pd23.1.0.html b/previews/271/zh_CN/bsp/imx8/imx8mp/pd23.1.0.html new file mode 100644 index 000000000..7867be1b1 --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mp/pd23.1.0.html @@ -0,0 +1,3893 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 8M Plus BSP手册

文档标题

i.MX 8M Plus BSP手册

文档类型

BSP 手册

Yocto 手册

Kirkstone

发布日期

2024/01/10

母文档

i.MX 8M Plus BSP手册

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP发布日期

BSP 状态

BSP-Yocto-NXP-i.MX8MP-PD23.1.0

大版本

2023/12/12

已发布

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 phyCORE-i.MX8M Plus Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads 中找到。

+
+

1.1. 支持的硬件

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-NXP-i.MX8MP-PD23.1.0 的所有Machine及其对应的Article Numbers(产品型号)： 网页.

+

如果您在“Supported Machines”一栏选择了特定的 Machine Name ，您可以查看该machine下可用的 Article Numbers 以及硬件信息的简短描述。如果您只有硬件的 Article Numbers ，您可以将 Machine Name 下拉菜单留空，仅选择您的 Article Numbers 。现在，它应该会显示您特定硬件所需的 Machine Name

+
+

1.1.1. phyBOARD-Pollux 器件

+
+../../../_images/phyBOARD-Pollux-front-components.jpg + +
+

phyBOARD-Pollux 器件图（顶部）

+
+
+
+../../../_images/phyBOARD-Pollux-back-components.jpg + +
+

phyBOARD-Pollux 器件图（底部）

+
+
+
+
+
+
+

2. 开始使用

+

该 phyCORE-i.MX8M Plus Kit 包含预先烧写好的SD卡。它包含 phytec-qt6demo-image 镜像，可以直接用作启动盘。默认情况下，核心板上的eMMC仅烧写了U-Boot。您可以从 PHYTEC下载服务器 获取所有镜像资源。本章将解释如何将BSP镜像烧写到SD卡以及如何启动开发板。

+

有几种方法可以将镜像写入SD卡或eMMC。最为人熟知的方式是使用Linux命令行工具 dd 进行简单的顺序写入。另一种方法是使用PHYTEC的自研程序 partup ，它可以让格式化复杂系统的过程变得简单。您可以从其发布页面获取 预编译的Linux partup 二进制文件 。请阅读 partup的readme文件 来获取安装指导。

+
+

2.1. 下载镜像

+

phytec-qt6demo-image 镜像包含完整系统所需的所有必要文件，您需确保镜像中各个分区以及裸数据都会被正确写入启动盘。可以从 PHYTEC 下载服务器 下载 partup 镜像文件或者是可以使用 dd 进行烧写的 WIC 镜像。

+

从下载服务器获取 partup 镜像文件或WIC镜像：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic
+
+
+
+

备注

+

针对eMMC，我们建议使用partup去烧写比较大的或者是有复杂分区配置的镜像，因为它在写入速度上比 dd 更快，并且可以对闪存设备进行更灵活的配置。

+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要创建SD卡启动盘，必须要拥有Linux PC上的root权限。在选择烧写设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+
+

2.2.1. 寻找正确的设备

+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行命令：

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+

卸载所有这些分区，例如：

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

现在，SD卡已经准备好可以使用 partup 、 dd 或 bmap-tools 来写入镜像。

+
+
+

2.2.2. 使用partup

+

使用partup烧写SD卡只需一个命令：

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3.partup /dev/<your_device>
+
+
+

确保将 <your_device> 替换为您之前找到的设备名称。

+

关于partup的进一步使用说明，请参阅其 官方文档 。

+
+

备注

+

partup 的优点在于能够清除 MMC 用户区中的特定区域，这在我们的应用场景中用于擦除 U-Boot 环境。这是一个 bmaptool 无法解决的已知问题，如下所述。

+

partup相较于其他烧写工具的一个主要优势是，它可以配置MMC的特定部分，比如他可以直接写入eMMCboot分区，无需调用其他命令。

+
+
+
+

2.2.3. 使用bmap-tools

+

准备SD卡的另一种方法是使用 bmap-tools。Yocto会自动为WIC镜像创建一个映射文件（<IMAGENAME>-<MACHINE>.wic.bmap），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host:~$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /dev/<your_device>
+
+
+

将 <your_device> 替换为您之前找到的SD卡设备名称，并确保将文件 <IMAGENAME>-<MACHINE>.wic.bmap 与WIC镜像文件放在一起，以便bmaptool知道哪些块需要写入，哪些块需要跳过。

+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.2.4. 使用 dd

+

在卸载所有SD卡的挂载分区后，您可以烧写SD卡。

+

一些PHYTEC BSP会生成未压缩的镜像（文件名扩展名为*.wic），而另一些则生成压缩的镜像（文件名扩展名为*.wic.xz）。

+

要写入未压缩的镜像（*.wic），请使用以下命令：

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

或者要写入压缩后的镜像（*.wic.xz），请使用以下命令：

+
host:~$ xzcat phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

再次确保将 <your_device> 替换为之前找到的设备名称。

+

参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

+
+
+
+

2.3. 首次启动

+ +../../../_images/SD_Card_Boot1.png +
    +

  • 插入SD卡

    • +

  • 使用 micro USB 线将开发板的 (X1) 调试USB口和主机连接起来

    • +

  • 给开发板通电

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (kirkstone).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (kirkstone).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-IMX8MP ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-xwayland MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD23.1.0
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 phyboard-pollux-imx8mp-3 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx8mp.bin: ARM可信固件二进制文件

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY固件镜像

    • +

  • imx-boot：由imx-mkimage编译的bootloader镜像，包括SPL、U-Boot、ARM可信固件和DDR固件。这是最终的可引导bootloader镜像。

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx8mp-phyboard-pollux-rdk*.dtb: 内核设备树文件

    • +

  • imx8mp-phy*.dtbo: 内核设备树overlay文件

    • +

  • phytec-qt6demo-image*.tar.gz: 根文件系统

    • +

  • phytec-qt6demo-image*.wic: SD卡镜像

    • +
+
+
+
+
+

4. 安装操作系统

+
+

4.1. 启动模式开关 (S3)

+
+

小技巧

+

硬件修订版底板：1552.2

+
+

该 phyBOARD-Pollux 具有一个（启动源配置）开关，配有四个可单独切换的位，用于选择phyCORE-i.MX 8M Plus 默认的启动源。

+ + + + + + + + + + + +
+../../../_images/eMMC1.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses1.png +
+

内部fuse

+
+
+
+../../../_images/SPI_NOR.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download1.png +
+

USB

+
+
+
+../../../_images/SD_Card_Boot1.png +
+

SD卡

+
+
+
+../../../_images/Test_Mode.png +
+

测试模式

+
+
+
+
+
+

4.2. 烧写eMMC

+

为了保持文档的一致性和简洁性，假设已经配置好了TFTP服务器；所有生成的镜像（如上所列）都被复制到默认的/srv/tftp目录。如果您没有进行设置，您需要修改路径到包含镜像的目录。有关如何设置TFTP服务器和目录的说明，请参见 Setup Network Host 。

+

要从 eMMC 启动，请确保 BSP 镜像已正确烧写到 eMMC，并且 bootmode switch (S3) 设置为 eMMC。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行上述命令来检查系统启动在这种条件下是否会到影响。如果 mmcblk2p1 和 mmcblk1p1 具有相同的UUID，则会影响系统正确启动。

+
+
+

4.2.1. 从网络烧写 eMMC

+

i.MX 8M Plus 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

4.2.1.1. 在开发板的U-Boot中通过网络烧写eMMC

+

这些步骤将展示如何通过网络更新eMMC。

+
+

小技巧

+

此步骤仅在镜像文件小于1GB的情况下会被执行成功，因为在启用OPTEE后，Bootloader中可用的RAM大小有限，不足以加载超过1GB的镜像

+
+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

通过网络将您的镜像加载到内存中：

+
    +

  • 使用DHCP

    +
    u-boot=> dhcp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.1 (1 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.1
+Filename 'phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • 使用静态IP地址（必须先设置serverip和ipaddr）。

    +
    u-boot=> tftp ${loadaddr} phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
+
+
+
+

4.2.1.2. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

使用一条命令，通过网络ssh协议将带有块映射的压缩或未压缩的镜像发送到开发板的eMMC上使用，执行：

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic.* /tmp && bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /dev/mmcblk2
+
+
+
+
+

4.2.1.3. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

查看主机上可用的镜像文件：

+
host:~$ ls /srv/tftp
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic.bmap
+
+
+

通过网络ssh协议使用 bmaptool 命令将镜像发送到开发板的eMMC：

+
host:~$ scp /srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /dev/mmcblk2"
+
+
+
+
+
+

4.2.2. 在运行的U-Boot中通过网络烧写eMMC U-Boot镜像

+

可以在U-Boot中更新U-Boot镜像imx-boot，eMMC上的U-Boot需要位于eMMC的user区域。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.3. 从USB大容量存储设备烧写eMMC

+
+

4.2.3.1. 在开发板上通过U-Boot从USB烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件小于1GB的情况下会被执行成功，因为在启用OPTEE后，Bootloader中可用的RAM大小有限，不足以加载超过1GB的镜像

+
+

下面这些步骤展示如何通过USB设备更新eMMC。将|ref-bootswitch| 配置为SD卡启动，并插入SD卡。给开发板上电并进入U-Boot环境。将已存储了未压缩WIC镜像的优盘插入开发板USB接口。

+

将镜像从USB设备加载到RAM中：

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} *.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. 在运行的Linux系统中从USB烧写eMMC

+

下面这些步骤展示如何在Linux系统上使用USB大容量存储设备烧写eMMC。您需要一个保存了完整镜像的U盘和一个可从SD卡启动的核心板（例如 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic）。将 bootmode switch (S3) 设置为SD卡启动。

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ ls /mnt
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic.bmap
+
    +
    +
    • +

  • 将镜像写入 phyCORE-i.MX 8M Plus eMMC（无分区的 MMC 设备 2）：

    +
    target:~$ bmaptool copy /mnt/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    小技巧

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+
+

4.2.4. 从SD卡烧写eMMC

+

即使没有可用的网络，您也可以更新eMMC。为此，您需要一个位于SD卡上的镜像文件（ *.wic ）。由于镜像文件相当大，您需要在SD卡创建第三个分区。要创建新分区或扩展您的SD卡，请参见 Resizing ext4 Root Filesystem 。

+

或者，使用partup包烧写SD卡，如 Getting Started 中所述。这样就可使用SD卡的全部容量。

+
+

4.2.4.1. 在开发板的uboot环境中通过SD卡烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1GB的情况下有效，因为在启用OPTEE后，Bootloader中可用的RAM大小有限。如果镜像文件过大，请阅读 在开发板上通过SD卡更新eMMC 一节

+
+
    +

  • 将一个可用的镜像烧写到SD卡，并创建一个EXT4格式的第三分区。将WIC镜像（例如 phytec-qt6demo-image.wic）复制到该分区。

    • +

  • 将 bootmode switch (S3) 配置为 SD 卡并插入 SD 卡。

    • +

  • 打开电源并进入U-Boot。

    • +

  • 加载镜像：

    +
    u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • 将当前mmc设备切换到eMMC：

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • 将您的WIC镜像（例如 phytec-qt6demo-image.wic）从SD卡烧写到eMMC。这将对卡进行分区，并将imx-boot、Image、dtb、dtbo和根文件系统复制到eMMC。

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • 关闭电源并将 bootmode switch (S3) 更改为 eMMC。

    • +
+
+
+

4.2.4.2. 在开发板的linux环境中通过SD卡烧写eMMC

+

您也可以在Linux系统中烧写eMMC。您只需要一个partup包或保存在SD卡上的WIC镜像。

+
    +

  • 检查在SD卡上保存的partup包或WIC镜像文件：

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.partup
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic.bmap
+
    +
    +
    • +

  • 使用 partup 将镜像写入 phyCORE-i.MX 8M Plus 的 eMMC（MMC 设备 2 不带 分区字样）：

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3.partup /dev/mmcblk2
+
    +
    +

    使用partup烧写的优点是可以充分利用eMMC设备的全部容量，会相应自动调整分区大小。

    +
    +

    备注

    +

    另外，也可以使用 bmaptool 工具：

    +
    target:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /dev/mmcblk2
+
    +
    +

    请注意，在使用 bmaptool 烧写时，根文件系统分区并不会使用eMMC的最大容量。

    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    警告

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+
+
+

4.3. 烧写 SPI NOR Flash

+

phyCORE-i.MX8MP 模块可选配SPI NOR Flash。要从SPI Flash启动，请将 bootmode switch (S3) 设置为 SPI NOR 。SPI Flash通常比较小。phyBOARD-Pollux-i.MX8MP开发套件仅配备32MB的SPI NOR Flash。只能存储bootloader及其环境变量。默认情况下，内核、设备树和文件系统会从eMMC加载。

+

SPI NOR Flash分区表在U-Boot环境变量中定义。可以通过以下命令打印：

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. 通过网络烧写SPI NOR Flash

+

SPI NOR可以包含bootloader及其环境变量。arm64的linux内核无法自行解压缩，内核镜像大小超出了phyCORE-i.MX 8M Plus 上的SPI NOR Flash的容量。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+
+

4.3.1.1. 在开发板的U-Boot环境中通过网络烧写SPI NOR

+

类似于通过网络更新eMMC，请确保正确设置主机PC。IP地址需要设置为192.168.3.10，子网掩码设置为255.255.255.0，并且需要有一个可用的TFTP服务。在进行读写之前，需要对SPI NOR Flash进行枚举：

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像。确保您使用了正确的镜像文件。通过tftp加载镜像，然后将bootloader写入Flash：

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+

4.3.1.2. 在开发板linux环境中通过网络烧写SPI NOR Flash

+
    +

  • 将镜像从主机复制到开发板：

    +
    host:~$ scp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • 查找要擦除的U-boot分区的块数：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除U-Boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+

4.3.2. 从SD卡烧写SPI NOR Flash

+

SPI NOR Flash上的bootloader也可以通过SD卡进行烧写。

+
+

4.3.2.1. 在开发板的U-Boot环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi复制到SD卡的第一个分区。

    • +

  • 在进行读写操作之前，需要对SPI-NOR Flash进行枚举：

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像，请确保使用正确的镜像文件。从SD卡加载镜像，擦除并将bootloader写入flash：

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+

4.3.2.2. 在开发板的linux环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi复制到SD卡的第一个分区。

    • +

  • 挂载SD卡：

    +
    target:~$ mount /dev/mmcblk1p1 /mnt
+
    +
    +
    • +

  • 查找要擦除的U-Boot分区的块数：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除u-boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC： L-1006e.A5 RAUC Update & Device Management Manual 。

+
+
+
+

5. 开发

+
+

5.1. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.1.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.2. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.2.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核镜像复制到您的tftp目录中：

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • 将设备树复制到您的tftp目录：

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • 将您想要使用的所有overlay文件复制到您的tftp目录中：

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-pollux-imx8mp-3.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.2.2. 设置网络启动的bootenv.txt文件

+

在您的tftp目录中创建一个bootenv.txt文件，并将以下变量写入其中。

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> 必须替换为您想要使用的overlay设备树文件名。用空格分隔文件名。例如：

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

小技巧

+

所有支持的设备树overlay在 device tree 章节中。

+
+
+
+

5.2.3. 开发板上的网络设置

+

如果要自定义开发板上的以太网配置，请按照此处的说明进行操作： Network Environment Customization

+
+
+

5.2.4. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.3.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. 获取镜像

+

可以从我们的服务器下载imx-boot，或者从Yocto编译目录中的build/deploy/images/phyboard-pollux-imx8mp-3/获取它。要将wic镜像烧写到eMMC，你还需要 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic。

+
+
+

5.3.3. 开发板准备

+

将 bootmode switch (S3) 设置为 USB串行下载。同时，将 USB 端口 X5 (upper connector) 连接到主机。

+
+
+

5.3.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 (X1) 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.3.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic
+
+
+
+
+
+

5.4. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone git://git.phytec.de/u-boot-imx）

+
+
+

5.4.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-imx 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • 我们的 i.MX 8M Plus 内核是基于 linux-imx 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. 获取SDK

+

您可以在此处下载SDK 这里，或者使用Yocto去编译生成SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

在成功编译后，SDK安装包保存在 build/deploy*/sdk。

+
+
+

5.4.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-4.0.13.sh
+host:~$ ./phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-4.0.13.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-xwayland/4.0.13):
+You are about to install the SDK to "/opt/ampliphy-vendor-xwayland/4.0.13". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-vendor-xwayland/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. 单独编译U-Boot

+
+

5.5.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本中使用的**tag**称为 v2022.04_2.2.2-phy5

    • +

  • 查看所需的 U-Boot tag：

    +
    host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2022.04_2.2.2-phy5
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor-xwayland/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. 获取所需的二进制文件

+

要编译bootloader，您需要将这些文件复制到您的 u-boot-imx 编译目录，并将其重命名以适应 mkimage 脚本：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx8mp.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以在yocto工程目录中获取 bl31-imx8mp.bin、tee.bin和lpddr4_*.bin：BSP Images

+

或者你可以在这里下载文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD23.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/

+
+

警告

+

确保您重命名所需的文件，以和 mkimage tool 兼容。

+
+
+
+

5.5.3. 编译bootloader

+
    +

  • 编译 flash.bin (imx-boot):

    +
    host:~/u-boot-imx$ make phycore-imx8mp_defconfig
+host:~/u-boot-imx$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. 将bootloader烧写到块设备上

+

flash.bin 文件可以在 u-boot-imx/ 目录下找到，现在可以进行烧写。需要指定芯片特定的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

例如，烧写SD卡：

+
host:~/u-boot-imx$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+

5.5.5. 使用固定内存大小编译U-Boot

+

如果您的系统因为EEPROM中的硬件信息损坏或丢失而无法启动，您可以创建一个具有固定RAM大小的flash.bin。但您仍应联系我们支持部门以烧写正确的EEPROM数据。

+

按照步骤获取U-boot源代码，并切换到 Build U-Boot 章节说明的分支。

+

Edit the file configs/phycore-imx8mp_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+
+
+

选择正确的RAM大小，确保与核心板上的贴装的器件一致，取消注释该RAM大小的行。保存更改后，按照 Build U-Boot 章节的剩余步骤进行操作。

+

从PD23.1.0版本开始，带有1549.3及更高版本的phyCORE-i.MX 8M Plus SoM也支持2GHz的RAM时序。这将在支持的核心板上自动启用，但也可以手动启用或禁用。

+

编辑文件 configs/phycore-imx8mp_defconfig。将使用固定的2GHz时序的RAM大小：

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+
+
+

选择正确的RAM大小，根据板上的配置取消该RAM大小的注释。当不指定 CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS 选项时，默认将选择1.5GHz的时序。保存更改后，按照 Build U-Boot 中的剩余步骤进行操作。

+
+
+
+

5.6. 单独编译内核

+
+

5.6.1. 配置源代码

+
    +

  • 使用的 linux-imx 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v5.15.71_2.2.2-phy3

    • +

  • Check out 所需的 linux-imx 标签：

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v5.15.71_2.2.2-phy3
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor-xwayland/4.0.13/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-imx$ make imx_v8_defconfig imx8_phytec_distro.config imx8_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-imx/arch/arm64/boot/Image 找到

    • +

  • dtb文件可以在 ~/linux-imx/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. 将内核复制到SD卡

+

内核及module和对应的设备树二进制文件可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. 获取BSP开发中版本

+
+

5.7.1. 当前release的开发中版本

+

这些release manifest文件是为了让您访问 Yocto BSP的开发版本。它们不会在phyLinux选择菜单中显示，需要手动选择。可以使用以下命令行来完成此操作：

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD23.1.y
+
+
+

这将初始化一个BSP，用于跟踪当前版本（ BSP-Yocto-NXP-i.MX8MP-PD23.1.0 ）的最新开发版本。从现在开始，在此文件夹中执行 repo sync 将从我们的Git仓库中拉取所有最新的更改：

+
host:~$ repo sync
+
+
+
+
+

5.7.2. 即将发布版本的开发中版本

+

即将发布版本的开发中版本可以通过这种方式访问。请执行以下命令，并查找一个比最新版本（ BSP-Yocto-NXP-i.MX8MP-PD23.1.0 ）的PDXX.Y数字更高的版本，并且以 .y 结尾：

+
host:~$ ./phyLinux init -p imx8mp
+
+
+
+
+
+

5.8. 获取最新的Upstream支持

+

我们有一个使用Yocto主分支（不是NXP发布的）的manifest，他使用upstream的Linux和U-Boot。这可以用来测试最新的upstream kernel/U-Boot。

+
+

备注

+

master分支的manifest反映了最新的开发状态。有时会出现一些bug。我们会定期修复master分支。

+
+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.9.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic 镜像复制到其中。然后卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 8M Plus 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Board.dts - 包含module dtsi 文件。从SoC i.MX 8M Plus 引出并在底板使用的设备也包含在此 dts 中。

    • +

  • Overlay.dtso - 根据核心板或底板上可选硬件（例如 SPI 闪存或 PEB-AV-10）的情况来启用/禁用一些功能。

    • +
+

在Linux内核的根目录下，我们的 i.MX 8 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。例如扩展板的硬件描述。对比源码中的include，overlay是用覆盖的方式来生效。overlay也可以根据节点是否连接来设置节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/overlays 中。

+

phyboard-pollux-imx8mp-3.conf 可用的overlay文件有：

+
imx8mp-isi-csi1.dtbo
+imx8mp-isi-csi2.dtbo
+imx8mp-isp-csi1.dtbo
+imx8mp-isp-csi2.dtbo
+imx8mp-phyboard-pollux-peb-av-010.dtbo
+imx8mp-phyboard-pollux-peb-av-012.dtbo
+imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+imx8mp-phycore-no-eth.dtbo
+imx8mp-phycore-no-rtc.dtbo
+imx8mp-phycore-no-spiflash.dtbo
+imx8mp-phycore-rpmsg.dtbo
+imx8mp-vm016-csi1.dtbo
+imx8mp-vm016-csi1-fpdlink.dtbo
+imx8mp-vm016-csi2.dtbo
+imx8mp-vm016-csi2-fpdlink.dtbo
+imx8mp-vm017-csi1.dtbo
+imx8mp-vm017-csi1-fpdlink.dtbo
+imx8mp-vm017-csi2.dtbo
+imx8mp-vm017-csi2-fpdlink.dtbo
+
+
+

可以在Linux或U-Boot环境下配置overlay。overlay是在引导命令调用后、内核加载之前生效。接下来的部分将更详细地解释配置方法。

+
+

6.2.2.1. 设置 ${overlays} 变量

+

${overlays} U-Boot 环境变量包含一个以空格分隔的overlay文件列表，这些overlay文件将在启动过程中应用。根据启动源，overlay文件必须放置在 eMMC/SD 卡的启动分区中，或者通过 tftp 加载。在 $KERNEL_DEVICETREE 这个 Yocto machine 变量中设置的 overlay 文件将自动添加到最终 WIC 镜像的启动分区中。

+

${overlays} 变量可以直接在U-Boot环境中设置，也可以作为外部 bootenv.txt 环境文件的一部分。默认情况下， ${overlays} 变量来自位于启动分区的 bootenv.txt 文件。您可以在已启动的开发板上从Linux读取和写入该文件：

+
target:~$ cat /boot/bootenv.txt
+overlays=imx8mp-phyboard-pollux-rdk-peb-eval-01.dtbo imx8mp-phyboard-pollux-peb-av-010.dtbo
+
+
+

更改将在下次重启后生效。如果没有可用的 bootenv.txt 文件，可以直接在U-Boot环境中设置overlay变量。

+
u-boot=> setenv overlays imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> printenv overlays
+overlays=imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> boot
+
+
+

如果用户定义了 ${overlays} 变量，同时存在 bootenv.txt 文件，则需要设置 ${no_bootenv} 变量：

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx8mp-phyboard-pollux-peb-av-010.dtbo
+u-boot=> boot
+
+
+

有关环境的更多信息，请参见 U-boot External Environment subsection of the +device tree overlay section。

+

我们使用 ${overlays} 变量来描述在运行时无法自动检测的扩展板和摄像头。如果想禁用 ${overlays} 变量中列出的overlay，可以在U-Boot的环境中将 ${no_overlays} 变量设置为 1。

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+

6.2.2.2. 扩展命令

+

使用U-Boot扩展命令能够轻松加载由回调函数 extension_board_scan() 检测并添加到列表中的overlay。以这种方式应用的overlay会禁用核心板上未贴装的组件。检测是通过读取出厂EEPROM数据（EEPROM SoM Detection）来实现的。

+

这取决于核心板型号是否会应用任何设备树overlay。要检查在U-Boot中运行的SoM是否会应用overlay，请运行：

+
u-boot=> extension scan
+Found 1 extension board(s).
+u-boot=> extension list
+Extension 0: phyCORE-i.MX8MP no SPI flash
+        Manufacturer:           PHYTEC
+        Version:
+        Devicetree overlay:     imx8mp-phycore-no-spiflash.dtbo
+        Other information:      SPI flash not populated on SoM
+
+
+

如果没有可用的EEPROM数据，则不加载任何设备树overlay。

+

为了禁止在启动时自动运行扩展命令，可以在bootloader环境中将 ${no_extensions} 变量设置为 1 ：

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot外部环境

+

在Linux内核启动时，外部环境 bootenv.txt 文本文件将从MMC设备的boot分区或通过TFTP加载。该文件的主要目的是存储 ${overlays} 变量。这可以针对不同的machine在Yocto中预定义不同的overlay配置。文件的内容在meta-phytec中的Yocto recipe中的bootenv中定义： https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=kirkstone

+

该文件中也可以设置其他变量。这些变量将覆盖环境中现有的设置。但只有对boot命令后进行计算的变量生效，例如 ${nfsroot} 或 ${mmcargs}。在文件中更改其他变量将不会有作用。以网络启动的用法作为示例。

+

如果无法加载外部环境，启动过程将继续进行，并使用自带的环境变量值。

+
+
+

6.2.4. 在Linux环境下更改开发板上的U-boot环境变量

+

Libubootenv是我们镜像中包含的一个工具，用于在开发板linux上修改U-Boot环境。

+

使用以下命令打印U-Boot环境：

+
target:~$ fw_printenv
+
+
+

使用以下命令修改U-Boot环境：

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

小心

+

Libubootenv会读取配置文件中配置的环境变量。要修改的环境变量会被插入到该文件中，默认情况下使用eMMC中存储环境变量。

+

如果eMMC没有被烧写过或者eMMC环境被擦除，libubootenv将无法工作。您应该修改 /etc/fw_env.config 文件，以匹配您想要使用的环境源。

+
+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 8M Plus BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 8M Plus BSP设备树概念部分，以了解我们的 i.MX 8 BSP设备树模型。

+

以下部分概述了 i.MX 8 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 8M Plus 引脚复用

+

该 i.MX 8M Plus Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 8M Plus 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 8M Plus 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是 imx8mp-phyboard-pollux-rdk.dts中UART1设备的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x140
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x140
+        >;
+};
+
+
+

字符串的第一部分 MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 指定了引脚（在这个例子中是 UART1_RXD）。字符串的第二部分（UART1_DCE_RX）是该引脚所选的复用项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部拉电阻是否被激活。在当前情况下，内部拉电阻被禁用。

+

UART1引脚复用的设备树表示： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n536

+
+
+

7.2. RS232/RS485

+

phyCORE-i.MX 8M Plus 支持最多 4 个 UART 单元。在 phyBOARD-Pollux 上，UART1（调试串口）和 UART4 的 TTL 电平信号被连接到 Silicon Labs CP2105 UART 到 USB 转换IC。这个 USB 信号通过 Micro-USB 连接器 X1 输出。UART3 位于 X6（扩展连接器），为 TTL 电平信号。UART2 连接到一个多协议收发器IC，可转换为 RS-232 或 RS-485，RS-232 和 RS-485 信号位于连接器 X2 。多协议配置通过主板上的跳线 JP3 和 JP4 完成。更多信息，请参阅 phyCORE-i.MX 8M Plus/phyBOARD-Pollux 硬件手册中的 UARTs 部分。

+

对于RS-232和RS-485，使用相同的设备树节点。RS485模式可以通过ioctl TIOCSRS485 来启用。双向通讯支持也可以通过ioctl进行配置。请查看我们的小示例应用程序rs485test，该程序也包含在BSP中。需要设置跳线 JP3 和 JP4 。

+
+

7.2.1. RS232

+
    +

  • 以人类可读的格式显示终端的当前设置：

    +
    target:~$ stty -a
+
    +
    +
    • +

  • UART接口的配置可以通过stty命令完成。例如：

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • 通过简单的echo和cat，可以测试基本的通信。示例：

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

主机应打印出 "123"。

+
+
+

7.2.2. RS485

+
+

提示

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

为了方便测试，请查看linux-serial-test。这个工具会通过调用RS485的IOCTL，发送恒定的数据流。

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

有关linux-serial-test工具及其参数的更多信息，请访问此链接：linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Linux kernel文档描述了如何在C代码中调用IOCTL： https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see "test" printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final "count for this session". There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+
+
+

7.2.2.2. RS485 full-duplex

+

For full-duplex mode your connection setup should look like this:

+../../../_images/RS485_fullduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For full-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 1
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  true
+Bus termination enabled:  false
+
+
+

Also here you can do the echo test to see if sending and receiving works:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see "test" printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

To check if the full-duplex operation works, you need to use the +linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=114660, tx=118755, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=118755, tx=114660, rx err=0
+
+
+

In this example both targets will send and receive simultaneously. They will +receive for 15sec and send for 10sec. The receiver needs to receive a bit +longer, so that all sent messages will get received. Remember to start both +targets almost simultaneously. A small difference in start time is accounted +for with the -W 2 option. At the end the program will print the final +"count for this session". There you can check that all transmitted frames were +received.

+

All the test examples are target to target, but can also be done with host to +target with a USB to rs485 converter. You may need to adjust the interfaces for +commands to work on the host then.

+

RS232和RS485的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n341

+
+
+
+
+

7.3. 网络

+

phyBOARD-Pollux-i.MX 8M Plus 提供两个以太网接口。我们的核心板和底板各提供一个千兆以太网接口。

+
+

警告

+

硬件中的以太网接口命名约定（ethernet0 和 ethernet1）与Linux中的网络接口（eth0 和 eth1）不一致。因此，请注意这些差异：

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n50。

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Pollux can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n150.

+
+

7.3.1. 网络配置

+
+

7.3.1.1. U-boot网络环境

+
    +

  • 要在bootloader中查找以太网设置：

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • 在将主机设置为IP 192.168.3.10和子网掩码255.255.255.0的情况下，开发板应该返回：

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • 如果您需要进行任何更改：

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> 应该是 ipaddr、netmask、gatewayip 或 serverip 中的一个。<value> 将是所选参数的设定值。

    +
    • +

  • 您所做的更改目前是临时的。要保存这些更改：

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

在这里，您也可以将IP地址更改为DHCP，而不是使用静态IP地址。

+
    +

  • 配置：

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • 设置 TFTP 和 NFS 的路径。修改可以如下所示：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+

小技巧

+

像nfsroot和netargs这样的变量可以被U-boot外部环境重新赋值。对于网络启动，外部环境将通过tftp加载。例如，要在 bootenv.txt 文件中设置nfsroot变量，请在tftproot目录修改：

+
nfsroot=/home/user/nfssrc
+
+
+

无需在开发板上存储这些信息。请注意，U-boot外部环境对于像 ipaddr 或 serveraddr 这样的变量不起作用，因为它们在加载外部环境之前已经被设置完成。

+
+
+
+

7.3.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. 无线局域网

+

在 phyBOARD-Pollux 上，WLAN和蓝牙由PEB-WLBT-05扩展板提供。PEB-WLBT-05的 phyBOARD-Pollux 快速入门指南向您展示了如何安装PEB-WLBT-05。

+
+

小技巧

+

对于BSP版本PD22.1及更新版本，需要先激活PEB-WLBT-05 Overlay，否则PEB-WLBT-05将无法被识别。

+
target:~$ vi /boot/bootenv.txt
+
+
+

之后，bootenv.txt 文件应该如下所示（它还可以包含其他设备树overlay！）：

+
overlays=imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+
+
+

更改将在重启后应用：

+
target:~$ reboot
+
+
+

有关设备树overlay的更多信息，请阅读 device tree 章节。

+
+

为了支持WLAN和蓝牙，我们使用来自LSR的Sterling-LWB模块。该模块支持2.4 GHz，并且可以在多种模式下运行，如客户端模式、使用WEP、WPA、WPA2加密的接入点（AP）模式等。有关该模块的更多信息，请访问 https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. 连接到WLAN网络

+

首先设置您所在国家的正确监管域：

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

你将会看到：

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

设置无线接口：

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

现在您可以扫描可用的网络：

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

您可以使用一个跨平台的客户端，名为wpa_supplicant，支持WEP、WPA和WPA2，以建立加密连接。

+

为此，请将网络凭据添加到文件 /etc/wpa_supplicant.conf 中：

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

现在可以建立连接：

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

这会得到如下输出：

+
...
+ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

To finish the configuration you can configure DHCP to receive an IP address +(supported by most WLAN access points). For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (kirkstone).

+

首先，创建目录：

+
target:~$ mkdir -p /etc/systemd/network/
+
+
+

然后在 /etc/systemd/network/10-wlan0.network 中添加以下配置片段：

+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+

现在，请重启网络守护进程以使配置生效：

+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+
+

7.3.3. 蓝牙

+

Bluetooth is supported on phyBOARD-Pollux with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section.

+

Bluetooth is connected to UART3 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

现在您可以扫描环境中的可见蓝牙设备。在默认配置下，蓝牙是不可见的。

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. 可见性

+

要激活可见性：

+
target:~$ hciconfig hci0 piscan
+
+
+

要禁用可见性：

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. 连接

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

备注

+

如果连接失败并出现错误信息：“连接失败：org.bluez.Error.Failed”，请尝试使用以下命令重新启动PulseAudio：

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC 卡

+

该 i.MX 8M Plus 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

MMC（SD卡槽）接口的DT配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n380

+

eMMC接口的DT配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n223

+
+
+

7.5. eMMC设备

+

PHYTEC模块如phyCORE-i.MX 8M Plus 配备了eMMC存储芯片作为主要存储。eMMC设备使用多层单元（MLC）或三层单元（TLC）技术来实现存储，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 8M Plus ，并在Linux内核中作为块设备表示，如SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.5.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），该层负责处理原始MLC或TLC的磨损均衡、块管理和错误更正码（ECC）。这需要定期执行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 通过以下命令使能BKOPS_EN：

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.5.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 8M Plus SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.5.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
+
+

7.5.5. 启用伪SLC模式

+

eMMC设备使用 MLC或TLC 来存储数据。与NAND Flash中使用的SLC相比，MLC或TLC在成本更低的情况下，可靠性较低且错误率较高。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. 擦除设备

+

可以直接擦除eMMC设备，而不是通过写零覆盖。eMMC块管理算法将擦除底层的MLC或TLC，或者将这些块标记为可丢弃。设备上的数据将丢失，并将被读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.5.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 8M Plus 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.5.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

下表是 i.MX 8M Plus SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.6. SPI主设备

+

i.MX 8M Plus 控制器包含一个 FlexSPI 和一个 ECSPI IP 核。FlexSPI 主控制器支持两个 SPI 通道，最多可连接 4 个设备。每个通道支持单通道/双通道/四通道/八通道模式的数据传输（1/2/4/8 条数据线）。ECSPI 控制器支持 3 个 SPI 接口，每个接口都有一个专用的CS（chip select）引脚。由于CS也可通过 GPIO 实现，因此每个通道上可以连接多个设备。

+
+

7.6.1. SPI NOR 烧写

+

phyCORE-i.MX 8M Plus 配备有一个 QSPI NOR Flash，该 Flash 连接到 i.MX 8M Plus 的 FlexSPI 接口。QSPI NOR Flash 可用于启动。有关烧写和启动模式设置的详细信息，请参见不同的章节。由于 SPI NOR Flash 的空间有限，因此仅可存储bootloader。默认情况下，内核、设备树和根文件系统来自 eMMC。

+

bootloader程序通过EEPROM数据检测是否安装了SPI Flash。如果没有安装SPI Flash，则在启动期间应用设备树overlay，通过扩展命令禁用SPI Flash设备树节点。如果没有可用的EEPROM数据，SPI NOR Flash节点将始终启用。有关更多信息，请参阅设备树overlay部分。

+

bootloader程序还可以通过内核的mtdparts启动参数修改设备树，将SPI MTD分区表传递给Linux。BSP中的默认分区布局设置为：

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

这是一个预定义的bootloader环境变量，可以在运行时更改。从Linux用户空间，可以通过/dev/mtd<N>设备访问NOR Flash分区，其中<N>是与要访问的NOR Flash分区相关联的MTD设备编号。要找到分区的正确MTD设备编号，请在目标上运行：

+
root@phyboard-pollux-imx8mp-3:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

它列出了所有MTD设备及其对应的分区名称。闪存节点在模块DTS中的SPI主节点内定义。SPI节点包含连接到此SPI总线的所有设备，在这种情况下只有SPI NOR Flash。

+

设备树中SPI主节点的定义可以在这里找到：

+

https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n76

+
+
+
+

7.7. GPIOs

+

phyBOARD-Pollux 具有一组专门用于GPIO的引脚。这些引脚直接连接到 i.MX 8M Plus 引脚，并被复用为 GPIO。它们可以直接在 Linux 用户空间中使用。处理器将其 GPIO 组织为5个GPIO组（GPIO1 – GPIO5），每个组包含 32 个GPIO。gpiochip0、gpiochip32、gpiochip64、gpiochip96 和 gpiochip128 是这些内部 i.MX 8M Plus GPIO 组 GPIO1 – GPIO5 的 sysfs 表示。

+

GPIO被标识为GPIO<X>_<Y>（例如：GPIO5_07）。<X>表示GPIO Bank，从1计数到5，而<Y>表示该Bank内的GPIO。<Y>从0计数到31（每个bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如从gpiochip0的GPIO 20）：

    +
    target:~$ gpioget gpiochip0 20
+
    +
    +
    • +

  • 将gpiochip0上的GPIO 20的值设置为0并退出工具：

    +
    target:~$ gpioset --mode=exit gpiochip0 20=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.7.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用 CONFIG_GPIO_SYSFS 后才能支持。要在menuconfig中使 CONFIG_GPIO_SYSFS 可见，必须首先启用选项 CONFIG_EXPERT 。

+

您也可以将此选项添加到您在 Linux 内核源代码 arch/arm64/configs/ 目录下使用的 defconfig 中。例如，我们基于 NXP 的BSP版本，这个defconfig可以是 imx8_phytec_distro.config

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+
+
+
+

7.8. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

这里的 LED 灯包括蓝色的 mmc、绿色的 心跳和红色的 emmc，它们都在 phyBOARD-Pollux 上。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

GPIO的设备树配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n229

+
+
+

7.9. I²C总线

+

该 i.MX 8M Plus 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 8M Plus 的I²C模块。 本节描述了我们 phyBOARD-Pollux 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

I²C1 总线DT配置（例如 imx8mp-phycore-som.dtsi）：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n110

+

I²C2总线DT配置（例如 imx8mp-phyboard-pollux-rdk.dts ）: imx-dt:imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n212

+
+
+

7.10. EEPROM

+

在 phyCORE-i.MX8MP 上有一个i2c EEPROM闪存。它有两个地址。主EEPROM空间（总线：I2C-0 地址：0x51）和ID页（总线：I2C-0 地址：0x59）可以通过Linux中的sysfs接口访问。主EEPROM和ID页的前256个字节用于板检测，不可被覆盖。覆盖这些保留的空间将导致启动问题。

+
+

7.10.1. phyCORE-i.MX8MP 上的I2C EEPROM

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

phyCORE-i.MX8MP SoM上的I2C EEPROM连接到I2C-0总线的I2C地址0x51。可以直接对该设备进行读写操作：

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

要用零填充4KiB的EEPROM（总线：I2C-0 地址：0x51），并保留EEPROM数据，请使用：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM 检测

+

在 phyCORE-i.MX8MP 上配置的I2C EEPROM具有一个可通过I2C地址0x59在i2c0上寻址的独立ID页面，以及一个可通过I2C地址0x51在i2c0上寻址的正常区域。PHYTEC使用这个32字节的数据区域来存储关于SoM的信息，包括PCB版本和配置。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果EEPROM ID页面数据和正常区域的前256个字节被删除，bootloader程序将回退到 phyCORE-i.MX8MP Kit RAM设置，即 2GiB RAM。

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

使用API修订版2数据格式烧写的核心板将在早期启动阶段打印出有关模块的信息。

+
+
+

7.10.3. 恢复EEPROM数据

+

硬件数据已预先写入两个EEPROM数据空间。如果您不小心删除或覆盖了Normal区域，可以将ID区域的硬件检查数据复制到正常区域。

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0059/eeprom of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1
+
+
+
+

备注

+

如果您删除了两个EEPROM空间，请联系我们的支持团队！

+
+

phyCORE-i.MX 8M Plus 核心板的设备树 imx8mp-phycore-som.dtsi 可以在 PHYTEC git 中找到： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n199

+
+
+
+

7.11. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC唤醒alarm

+

可以从实时时钟（RTC）发出中断以唤醒系统。该格式使用Unix纪元时间，即自1970年1月1日UTC午夜以来的秒数。要在从挂起到RAM状态后的4分钟唤醒系统，请输入：

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

备注

+

内部唤醒alarm时间将被向上舍入到下一个分钟，因为alarm功能不支持秒。

+
+
+
+

7.11.2. RTC参数

+

实时时钟（RTC）具有一些功能，可以通过 hwclock 工具进行读取和设置。

+
    +

  • 我们可以通过以下方式检查RTC支持的功能：

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x11.
+
    +
    +

    这个值的含义在内核中进行了编码，每个位的定义为：

    +
    #define RTC_FEATURE_ALARM              0
+#define RTC_FEATURE_ALARM_RES_MINUTE   1
+#define RTC_FEATURE_NEED_WEEK_DAY      2
+#define RTC_FEATURE_ALARM_RES_2S       3
+#define RTC_FEATURE_UPDATE_INTERRUPT   4
+#define RTC_FEATURE_CORRECTION         5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE 6
+#define RTC_FEATURE_CNT                7
+
    +
    +
    • +

  • 我们可以通过以下方式检查RTC BSM（Backup Switchover Mode 备份切换模式）：

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • 我们可以通过以下方式设置RTC BSM：

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    BSM位的定义为：

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    小技巧

    +

    您应该将BSM模式设置为DSM或LSM，以便在初始电源不可用时，RTC可以切换到备用电源。请查看 RV-3028 RTC的Datasheet，以了解LSM（电平切换模式）和DSM（直接切换模式）这两个定义的工作模式。

    +
    +
    • +
+

I²C RTCs的DT表示： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi?h=v5.15.71_2.2.2-phy3#n207

+
+
+
+

7.12. USB主控制器

+

i.MX 8M Plus SoC的USB控制器为众多消费类便携设备提供了一种低成本的连接解决方案，实现USB设备之间的数据传输，传输速度可达4 Gbit/s（超高速'SS'）。USB子系统具有两个独立的USB控制器。这两个控制器都能够作为USBDevice或USB Host使用。每个核心都连接到一个USB 3.0物理层（PHY）。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+

USB主机的DT表示：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n351

+
+
+

7.13. CAN FD

+

The phyBOARD-Pollux has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。两个CAN接口显示为can0和can1。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    can0的信息将如下所示：

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+
+

警告

+

mcp2518fd SPI到CAN FD只支持从125kB/s开始的波特率。可以选择更慢的速率，但可能无法正常工作。

+
+

Device Tree CAN configuration of imx8mp-phyboard-pollux-rdk.dts: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n175

+
+
+

7.14. PCIe

+

phyCORE-i.MX 8M Plus 具有一个 Mini-PCIe 插槽。一般来说，PCIe 会自动检测总线上的新设备。在连接设备并启动系统后，您可以使用命令 lspci 查看所有被识别的 PCIe 设备。

+
    +

  • 输入：

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • 你将收到：

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

在这个例子中，PCIe设备是 英特尔 WiFi Link 5100 。

+

对于PCIe设备，您必须在内核配置中启用正确的驱动程序。例如，这款WLAN卡是由英特尔制造的。必须启用的驱动程序选项名为 CONFIG_IWLWIFI ，可以在内核配置中的 Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimate 下找到。

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • linux-imx的表示为：virtual/kernel

      • +
    +
    • +
+

对于某些设备，如WLAN卡，需要额外的二进制固件文件。这些固件文件必须放置在 /lib/firmware/ 目录中，才能使用该设备。

+
    +

  • 输入：

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • 例如，如果您尝试启动网络接口：

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • 您将在串口控制台上获得以下输出：

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

小技巧

+

某些PCIe设备，例如以太网卡，即使没有从 /lib/firmware/ 加载固件文件，也可能正常工作，而你收到了如上输出第一行所示的错误消息。这是因为一些制造商在板卡本身提供了固件作为后备。在这种情况下，设备的行为和输出在很大程度上依赖于制造商的固件。

+
+

Device Tree PCIe configuration of imx8mp-phyboard-pollux-rdk.dts: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n287

+
+
+

7.15. 音频

+

支持的播放设备包括HDMI和PEB-AV-10连接器上的TI TLV320AIC3007音频编解码器（CODEC）IC。在AV连接器上，有一个符合OMTP标准的3.5mm耳机插孔和一个8针排针。8针排针包含单声道扬声器、耳机和line-in信号。

+
+

备注

+

使用PEB-AV-10连接器进行显示输出时，不支持通过HDMI作为音频输出。音频输出设备必须与视频输出设备匹配。

+
+

要检查您的声卡驱动程序是否正确加载以及设备名称，请输入以下命令以查看播放设备：

+
target:~$ aplay -L
+
+
+

或输入录音设备：

+
target:~$ arecord -L
+
+
+
+

7.15.1. Alsamixer

+

要检查声卡的功能，请输入：

+
target:~$ alsamixer
+
+
+

您应该会看到很多选项，因为音频IC具有许多可以测试的功能。通过SSH打开alsamixer的图形界面比通过调试串口打开更易于使用。所有混音点都有单声道或立体声增益控制。"MM"表示该功能被静音（左右输出均为静音），可以通过按' m '切换。您还可以通过按' < ' 左和 ' > '切换右声道输出。使用 tab 键，您可以在播放和录音控制之间切换。

+
+
+

7.15.2. 恢复默认音量

+

一些默认设置存储在 /var/lib/alsa/asound.state 中。您可以使用以下命令保存当前的alsa设置：

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

您可以通过以下方式恢复已保存的alsa设置：

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.15.3. ALSA配置

+

我们的BSP附带一个ALSA配置文件 /etc/asound.conf 。

+

ALSA配置文件可以根据需要进行编辑或删除，它并不是ALSA正常工作所必需的。

+
target:~$ vi /etc/asound.conf
+
+
+

要将PEB-AV-10设置为输出，请将 playback.pcm 从 "dummy" 设置为 "pebav10":

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

如果听不到声音，请将播放设备更改为软件音量控制播放设备，将 playback.pcm 设置为相应的软音量播放设备，例如“softvol_pebav10”。使用alsamixer控制来调整音量级别。

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.15.4. PulseAudio 配置

+

对于使用 Pulseaudio 的应用程序，请检查可用的音频输出设备：

+
target:~$ pactl list short sinks
+
+
+

要选择输出设备，请输入：

+
target:~$ pactl set-default-sink <sink_number>
+
+
+
+
+

7.15.5. 播放

+

运行speaker-test以检查播放功能：

+
target:~$ speaker-test -c 2 -t wav
+
+
+

要播放简单的音频流，您可以使用aplay。例如，要播放ALSA测试音频：

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

要播放其他格式，例如mp3，您可以使用Gstreamer：

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.15.6. 录音

+

arecord 是一个命令行工具，用于录制音频流，默认输入源为线路输入。要选择不同的音频源，可以使用 alsamixer。例如，打开 右侧 PGA 混音器 Mic3R 和 左侧 PGA 混音器 Mic3R，以便通过 3.5mm 插孔录制来自 TLV320 编解码器的麦克风输入音频。

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

提示

+

由于播放和录音共享硬件接口，因此无法在同时进行播放和录音操作时使用不同的采样率和格式。

+
+

音频DT配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.15.71_2.2.2-phy3#n58

+
+
+
+

7.16. 视频

+
+

7.16.1. 视频与Gstreamer

+

默认情况下，BSP安装了一个示例视频，路径为 /usr/share/qtphy/videos/ 。可以使用以下命令之一开始视频播放：

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.17. 显示

+

该 phyBOARD-Pollux 支持多达4种不同的显示输出。可以同时使用三种。下表显示了不同接口所需的扩展板和设备树overlay。

+ + + + + + + + + + + + + + + + + + + + + + + + + +

接口

扩展板

设备树overlay

HDMI

phyBOARD-Pollux

不需要overlay（默认启用）

LVDS0

PEB-AV-10

imx8mp-phyboard-pollux-peb-av-010.dtbo （默认加载）

LVDS1

phyBOARD-Pollux

如果使用PEB-AV-10 overlay，则禁用

MIPI

PEB-AV-12 (MIPI到LVDS)

imx8mp-phyboard-pollux-peb-av-012.dtbo

+
+

备注

+
    +

  • 在更改Weston输出时，请确保音频输出也相匹配。

    • +

  • LVDS0 (使用PEB-AV-10扩展) 和 LVDS1 (板载) 不能同时使用。

    • +
+
+

HDMI在设备树中始终启用。其他接口可以通过设备树overlay进行启用。

+

默认启用的接口是HDMI和LVDS0（PEB-AV-010）。我们的 PEB-AV-10 and PEB-AV-012 支持10英寸edt,etml1010g0dka显示屏。

+
+

备注

+

当前的显示驱动程序将连接到LVDS的LCD的像素时钟限制为74.25MHz（或其分频）。如果这满足不了您的需求，请联系支持团队以获得进一步的帮助。

+
+
+

7.17.1. Weston 配置

+

为了让Weston正确的显示，需要进行正确的配置。这将在/etc/xdg/weston/weston.ini中完成。

+
+

7.17.1.1. 单一显示器

+

在我们的BSP中，默认的Weston输出设置为HDMI。

+
[output]
+name=HDMI-A-1
+mode=current
+
+[output]
+name=LVDS-1
+mode=off
+
+
+

当使用LVDS0（PEB-AV-10）作为输出时，将HDMI-A-1的输出模式设置为off，将LVDS-1的输出模式设置为current。

+
[output]
+name=HDMI-A-1
+mode=off
+
+[output]
+name=LVDS-1
+mode=current
+
+
+

如果您想使用LVDS1（板载），则需要去掉overlay。请从bootenv.txt中移除imx8mp-phyboard-pollux-peb-av-xxx.dtbo。

+
+
+

7.17.1.2. 双显示器

+
+

备注

+

对于双显示和三显示输出，您无法同时使用LVDS1（板载）和HDMI。

+
+

在HDMI和LVDS0（PEB-AV-10）的双屏模式下进行双显示时，两个模式必须设置为：

+
[output]
+name=HDMI-A-1
+mode=current
+
+[output]
+name=LVDS-1
+mode=current
+
+
+

对于LVDS0 (PEB-AV-010)和MIPI (PEB-AV-012)的双显示，bootenv.txt中需要加载两个dtbo，weston.ini应如下所示：

+
[output]
+name=HDMI-A-1
+mode=off
+
+[output]
+name=LVDS-1
+mode=current
+
+
+
+
+

7.17.1.3. 三屏显示

+

三个输出：HDMI、LVDS-1（PEB-AV-10）和LVDS-2（PEB-AV-12）。请记得为LVDS接口加载两个dtbo。

+
[output]
+name=HDMI-A-1
+mode=current
+
+[output]
+name=LVDS-1
+mode=current
+
+[output]
+name=LVDS-2
+mode=current
+
+
+
+
+
+

7.17.2. Qt Demo

+

使用 phytec-qt6demo-image 时，Weston会在启动时启动。我们的Qt6 DEMO应用程序名为“qtphy”，可以通过以下方式停止：

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • 要重新开始Demo，请运行：

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • 要禁用Demo的自动启动，请运行：

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • 要启用Demo的自动启动，请运行：

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston可以通过以下方式停止：

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

备注

+

在关闭Weston之前，必须先关闭Qt Demo。

+
+
+
+

7.17.3. 背光控制

+

如果LCD连接到PHYTEC开发板，可以通过Linux内核的sysfs接口控制其背光。系统中所有可用的背光设备可以在文件夹/sys/class/backlight中找到。读取相应的文件并向其写入数据可以控制背光。

+
+

备注

+

一些具有多显示的开发板在 /sys/class/backlight 有多个背光控制。比如：backlight0和backlight1

+
+
    +

  • 例如，要获取最大亮度级别（max_brightness），请执行：

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    有效的亮度值范围是 0 到 <max_brightness>。

    +
    • +

  • 要获取当前亮度级别，请输入：

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • 写入文件brightness以更改亮度：

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    例如，关闭背光。

    +

    有关所有文件的文档，请参见 https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight。

    +
    • +
+

LVDS-1和HDMI的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n264 https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n191

+

PEB-AV-10上的LVDS-0设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/overlays/imx8mp-phyboard-pollux-peb-av-010.dtso?h=v5.15.71_2.2.2-phy3#n133

+
+
+
+

7.18. 电源管理

+
+

7.18.1. CPU核心频率调节

+

i.MX 8M Plus SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。调整频率和电压被称为“动态电压和频率调整”（DVFS）。i.MX 8M Plus BSP支持DVFS功能。Linux内核提供了一个DVFS框架，允许每个CPU核心设置最小或最大频率和一个管理其运行的governor。根据使用的 i.MX 8 型号，支持几种不同的频率。

+
+

小技巧

+

尽管DVFS框架为每个CPU核心提供了频率设置，但一个CPU核心的频率更改会影响其他CPU核心。因此，所有CPU核心始终共享相同的DVFS设置。每个核心的单独DVFS设置是不可能的。

+
+
    +

  • 要获取完整列表，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    例如 i.MX 8MPlus CPU，最高可达约 1.6 GHz，则结果将是：

    +
    1200000 1600000
+
    +
    +
    • +

  • 要查询当前的频率输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

governor 会根据它们的目标自动选择这些频率中的一个。

+
    +

  • 列出所有可用的 governor，使用以下命令：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    结果是：

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative governor 与 ondemand governor 非常相似。只是它的行为有所不同，它会更保守地增减CPU速度，而不是在CPU有任何负载的瞬间就跳到最大速度。

    • +

  • ondemand （默认）根据当前系统负载在可能的CPU核心频率之间切换。当系统负载超过特定值时，它会立即提高CPU核心频率。

    • +

  • powersave 始终选择最低的CPU核心频率。

    • +

  • performance 始终选择最高的CPU核心频率。

    • +

  • userspace 允许以root身份运行的用户或用户空间程序设置特定频率（例如，设置为1600000）。输入：

    • +

  • 要查询当前的 governor，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    您通常会得到：

    +
    ondemand
+
    +
    +
    • +

  • 切换到另一个governor（例如，userspace）可以通过以下方式完成：

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • 现在你可以设置频率：

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

有关governor的更详细信息，请参阅Linux内核代码库中的Linux内核文档，路径为 Documentation/admin-guide/pm/cpufreq.rst 。

+
+
+

7.18.2. CPU核心管理

+

该 i.MX 8M Plus SoC 芯片上可以有多个处理器核心。例如，该 i.MX 8M Plus 具有 4 个 ARM 核心，可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    这里系统有四个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.18.3. 挂起到RAM

+

phyCORE-i.MX8MP 支持基本的挂起和恢复。可以使用不同的唤醒源。挂起/恢复可以通过以下方式实现：

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

要通过串行控制台唤醒，请运行

+
target:~$ echo enabled > /sys/class/tty/ttymxc0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.19. 热管理

+
+

7.19.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.19.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 8M Plus SoC 平台上使用热管理内核 API。 i.MX 8 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个触发点。这些触发点根据CPU型号的不同而有所不同。主要区分工业版和商业版。

+ + + + + + + + + + + + + + + + + +

商业

工业

被动（警告）

85°C

95°C

严重（关机）

90°C

100°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并实施冷却措施。内核中可用的热政策（也称为thermal governor）包括：Step Wise、Fair Share、Bang Bang和Userspace。BSP中使用的默认策略是Step Wise。如果sysfs文件temp中的SoC温度值高于 trip_point_0 ，则CPU频率将设置为最低CPU频率。当SoC温度降到 trip_point_0 以下时，限制将被解除。

+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+

7.19.3. GPIO风扇

+
+

备注

+

Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan +to GPIO fan due to availability. The PWM fan will not be supported +anymore and will not function with the new release.

+
+

一个GPIO控制的风扇可以连接到 phyBOARD-Pollux-i.MX 8M Plus。该SoC包含一个温度传感器，该传感器被用于热频率调节。风扇无法通过内核进行控制。我们使用lmsensors和hwmon来实现这一点。lmsensors定期读取温度，并在可配置的阈值下启用或禁用风扇。对于 phyBOARD-Pollux-i.MX 8M Plus，这个阈值是60°C。

+

设置可以在配置文件中进行配置：

+
/etc/fancontrol
+
+
+

风扇控制在启动时由systemd服务启动。可以通过以下方式禁用它：

+
target:~$ systemctl disable fancontrol
+
+
+

GPIO风扇的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts?h=v5.15.71_2.2.2-phy3#n33

+
+
+
+

7.20. 看门狗

+

PHYTEC i.MX 8M Plus 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.20.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.21. snvs电源按键

+

连接到开关按钮的 X_ONOFF 引脚可以长按以触发关机，而无需软件干预，或用于唤醒系统以退出挂起状态。使用 snvs_pwrkey 驱动程序时，当按下按钮时，KEY_POWER 事件也会报告给用户空间。默认情况下，systemd 被配置为忽略此类事件。关机而无需软件干预的功能以及从挂起状态唤醒的功能未被配置。可以在 /etc/systemd/logind.conf 中配置按下开/关按钮时通过 systemd 触发关机，配置方法如下：

+
HandlePowerKey=poweroff
+
+
+
+
+

7.22. NPU

+

i.MX 8M Plus SoC包含一个高达2.3 TOPS的人工智能运算加速器。有关NPU的信息，请参考我们最新的phyCORE-i.MX 8M Plus AI套件指南，该指南可以在phyCORE-i.MX 8M Plus 下载部分找到：L-1015e.A1 phyCORE-i.MX 8M Plus AI Kit Guide

+
+
+

7.23. ISP

+

i.MX 8M Plus SoC包含一个图像信号处理器（ISP）。有关更多信息，请参阅|sbc| i.MX 8M Plus 文档中的使用ISP部分。

+
+
+

7.24. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 8M Plus 提供一次性可编程fuse，用于存储信息，例如 MAC 地址、启动配置和其他永久设置（在 i.MX 8M Plus reference manual中称为“片上 OTP 控制器 (OCOTP_CTRL)”）。以下列表摘自 i.MX 8M Plus reference manual，包括 OCOTP_CTRL 中的一些有用寄存器（基地址为0x30350000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为0x30350000

描述

OCOTP_MAC_ADDR0

9

0

0x640

包含ENET0 MAC地址的低32位

OCOTP_MAC_ADDR1

9

1

0x650

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

OCOTP_MAC_ADDR2

9

2

0x660

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 8M Plus Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.24.1. 在uBoot中读取fuse的值

+

您可以使用内存映射的shadow寄存器读取fuse寄存器。要计算内存地址，请使用以下公式计算：

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.24.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+
+

8. i.MX 8M Plus M7 Core

+

除了Cortex-A53核心外，SoC中还集成了一个Cortex-M7 Core 作为MCU。我们的Yocto-Linux-BSP在A53核心上运行，而 M7 Core 可以作为辅助CPU，用于使用裸机或RTOS固件执行额外任务。两种核心都可以访问相同的外设，因此外设的使用需要在 M7 Core 的固件或Linux操作系统的设备树中进行限制。本节将描述如何编译固件示例以及如何在 phyBOARD-Pollux 上运行它们。

+

phyBOARD-Pollux 目前由 NXP MCUXpresso SDK 和 Zephyr 项目支持。本节仅描述 NXP MCUXpresso SDK，因为目前 MCUXpresso SDK 支持的功能更多。

+

如果您想在Zephyr项目中使用 M7 Core ，请参考Zephyr项目文档：

+ +
+

8.1. 获取固件示例

+

固件可以使用NXP MCUxpresso SDK和兼容的编译工具链通过命令行工具进行编译。

+
+

8.1.1. 获取源代码

+

MCUX SDK以及 i.MX 8M Plus 的示例可以从PHYTEC的GitHub页面获取：

+ +
    +

  1. 通过west初始化MCUX SDK：

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    这将创建一个 mcuxsdk 目录，并在其中包含 mcux-sdk 仓库。mcux-sdk-phytec-examples 仓库将自动克隆到 mcuxsdk 目录中。给定的参数 <VERSION> 是 mcux-sdk 仓库的分支名称，代表 MCUX SDK 版本。要获取最新的测试版本，您可以使用 2.13.0。

    +
    +

    备注

    +

    west 是一个仓库管理工具，也是 Zephyr 项目的一部分。要安装 west，您可以使用 pip。在这个示例中，west 被安装在一个 Python 虚拟环境中:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. 更新依赖项：

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    目录 examples-phytec 包含了所有移植并测试过的示例，适用于 phyBOARD-Pollux 和版本为 2.13.0 的 MCUX。

    +

    要编译固件，需要一个编译器工具链和make/cmake。GNU ARM 嵌入式工具链可能在您的主机linux发行版的仓库中可用，例如Ubuntu。

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    编译器工具链也可以直接从 https://developer.arm.com/ 获取。在解压缩文件后，必须将 ARMGCC_DIR 添加到环境变量中，例如，对于位于主目录中的 ARM toolchain 10-2020-q4-major 版本：

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. 编译固件

+

要编译PHYTEC示例，需要先设置环境

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

编译固件的脚本位于 <sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc。每个可运行的内存位置都有相应的编译脚本，例如：

+
host:~$ ./build_release.sh
+
+
+

要编译运行在 M7 Core 的 TCM 上的固件。输出将放置在 armgcc 目录下的 release/ 中。.bin 文件可以在 U-Boot 中运行，而 .elf 文件可以在 Linux 中运行。

+

要编译在DRAM上运行的固件，请运行脚本build_ddr_release。例如。

+
host:~$ ./build_ddr_release.sh
+
+
+

输出将放置在armgcc目录下的ddr_release/中。.bin文件可以在U-Boot中运行，而.elf文件可以在Linux中运行。

+
+
+
+

8.2. 运行 M7 Core 示例

+

有两种方法可以运行 M7 Core 的固件，在Linux中使用Remoteproc以及在U-Boot。

+

要接收调试信息，请在您的主机PC上启动您喜欢的终端软件（例如Minicom、Tio或Tera Term），并将其配置为115200波特率、8个数据位、无奇偶校验和1个停止位（8n1），且不使用握手。

+

一旦Micro USB电缆连接到 phyBOARD-Pollux 上的USB调试端口，就会注册两个ttyUSB设备。一个打印来自A53核心的调试UART的消息，另一个打印来自 M7 Core 的调试UART的消息。

+
+

8.2.1. 从U-Boot运行示例

+

要使用bootloader U-Boot加载固件，可以使用bootaux命令：

+
    +

  1. 准备一张烧写了BSP镜像的SD卡

    2. +

  2. 将生成的 .bin 文件复制到 SD 卡的第一个分区

    3. +

  3. 通过按任意键停止自动启动

    4. +

  4. 根据固件类型输入命令：

    5. +
+

对于在 M7 Core 的TCM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

用于在DRAM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

程序的输出应显示在 M7 Core 的调试UART上。

+
+
+

8.2.2. 通过Remoteproc在Linux上运行示例

+

Remoteproc是一个模块，允许您在运行时从Linux控制 M7 Core 。可以加载为TCM编译的固件，并可以启动或停止执行。要使用Remoteproc，需要设置设备树Overlay：

+

在开发板的/boot目录中编辑bootenv.txt文件，添加 imx8mp-phycore-rpmsg.dtbo ：

+
overlays=imx8mp-phycore-rpmsg.dtbo
+
+
+

重启目标并在U-Boot中执行:

+
u-boot=> run prepare_mcore
+
+
+

M7 Core 的固件 .elf 文件可以在 /lib/firmware 下找到。要加载固件，请输入：

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

要加载不同的固件，M7 Core 需要停止：

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

备注

+

在开发板上找到的 /lib/firmware 中的例子来自NXP的Yocto层meta-imx。要使用您通过MCUX SDK自己编译的样本，请在编译后将它们复制到开发板的 /lib/firmware 中。

+
+
+ +
+
+
+

9. BSP扩展

+
+

9.1. Chromium

+

我们的BSP支持Chromium。您只需几个步骤即可将其包含在 phytec-qt6demo-image 中。

+
+

9.1.1. 将Chromium添加到您的local.conf文件中

+

要包含Chromium，您需要在您的local.conf中添加以下行。您可以在<yocto_dir>/build/conf/local.conf中找到这个配置文件。这将把Chromium添加到您下一个镜像编译中。:

+
IMAGE_INSTALL:append = " chromium-ozone-wayland"
+
+
+
+

备注

+

编译Chromium需要很长时间。

+
+
+
+

9.1.2. 在开发板上运行Chromium

+

要运行Chromium，需要一些参数来使用硬件图形加速：

+
target$ chromium --use-gl=desktop --enable-features=VaapiVideoDecoder --no-sandbox
+
+
+

如果您想通过SSH启动Chromium，您必须首先定义运行Chromium的显示器。例如：

+
target$ DISPLAY=:0
+
+
+

在您定义完这个之后，您可以通过上述所示的Weston虚拟终端启动它。

+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mp/pd24.1.0_nxp.html b/previews/271/zh_CN/bsp/imx8/imx8mp/pd24.1.0_nxp.html new file mode 100644 index 000000000..4dd1601b3 --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mp/pd24.1.0_nxp.html @@ -0,0 +1,4075 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + + + + + +

PD24.1.0 NXP i.MX 8M Plus BSP手册

文档标题

PD24.1.0 NXP i.MX 8M Plus BSP手册

文档类型

BSP 手册

型号

PD24.1.0 NXP

Yocto 手册

Scarthgap

发布日期

2024/11/08

母文档

PD24.1.0 NXP i.MX 8M Plus BSP手册

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP 发布日期

BSP 状态

BSP-Yocto-NXP-i.MX8MP-PD24.1.0

大版本

2024/11/06

已发布

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 phyCORE-i.MX8M Plus Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads 中找到。

+
+

1.1. 支持的硬件

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-NXP-i.MX8MP-PD24.1.0 的所有Machine及其对应的Article Numbers(产品型号)： 网页.

+

如果您在“Supported Machines”一栏选择了特定的 Machine Name ，您可以查看该machine下可用的 Article Numbers 以及硬件信息的简短描述。如果您只有硬件的 Article Numbers ，您可以将 Machine Name 下拉菜单留空，仅选择您的 Article Numbers 。现在，它应该会显示您特定硬件所需的 Machine Name

+
+

1.1.1. phyBOARD-Pollux 器件

+
+../../../_images/phyBOARD-Pollux-front-components.jpg + +
+

phyBOARD-Pollux 器件图（顶部）

+
+
+
+../../../_images/phyBOARD-Pollux-back-components.jpg + +
+

phyBOARD-Pollux 器件图（底部）

+
+
+
+
+
+
+

2. 开始使用

+

该 phyCORE-i.MX8M Plus Kit 包含预先烧写好的SD卡。它包含 phytec-qt6demo-image 镜像，可以直接用作启动盘。默认情况下，核心板上的eMMC仅烧写了U-Boot。您可以从 PHYTEC下载服务器 获取所有镜像资源。本章将解释如何将BSP镜像烧写到SD卡以及如何启动开发板。

+

有几种方法可以将镜像写入SD卡或eMMC。最为人熟知的方式是使用Linux命令行工具 dd 进行简单的顺序写入。另一种方法是使用PHYTEC的自研程序 partup ，它可以让格式化复杂系统的过程变得简单。您可以从其发布页面获取 预编译的Linux partup 二进制文件 。请阅读 partup的readme文件 来获取安装指导。

+
+

2.1. 下载镜像

+

phytec-qt6demo-image 镜像包含完整系统所需的所有必要文件，您需确保镜像中各个分区以及裸数据都会被正确写入启动盘。可以从 PHYTEC 下载服务器 下载 partup 镜像文件或者是可以使用 dd 进行烧写的 WIC 镜像。

+

从下载服务器获取 partup 镜像文件或WIC镜像：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+
+

备注

+

针对eMMC，我们建议使用partup去烧写比较大的或者是有复杂分区配置的镜像，因为它在写入速度上比 dd 更快，并且可以对闪存设备进行更灵活的配置。

+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要创建SD卡启动盘，必须要拥有Linux PC上的root权限。在选择烧写设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+
+

2.2.1. 寻找正确的设备

+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行命令：

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+

卸载所有这些分区，例如：

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

现在，SD卡已经准备好可以使用 partup 、 dd 或 bmap-tools 来写入镜像。

+
+
+

2.2.2. 使用bmap-tools

+

烧写SD卡的其中一种方法是使用 bmap-tools 。Yocto会自动为WIC镜像创建一个block map文件（ <IMAGENAME>-<MACHINE>.wic.bmap ），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host:~$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

将 <your_device> 替换为您之前找到的SD卡设备名称，并确保将文件 <IMAGENAME>-<MACHINE>.wic.bmap 与WIC镜像文件放在一起，以便bmaptool知道哪些块需要写入，哪些块需要跳过。

+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.2.3. 使用partup

+

使用partup烧写SD卡只需一个命令：

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).partup /dev/<your_device>
+
+
+

确保将 <your_device> 替换为您之前找到的设备名称。

+

关于partup的进一步使用说明，请参阅其 官方文档 。

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 release notes 。

+
+
+

备注

+

partup 具有清除eMMC user区域中特定区域的功能，我们提供的partup程序中用该功能擦除U-Boot环境变量。这是 bmaptool 工具所无法完成的一点，如前一部分所提到的。

+

partup相较于其他烧写工具的一个主要优势是，它可以配置MMC的特定部分，比如他可以直接写入eMMCboot分区，无需调用其他命令。

+
+
+
+

2.2.4. 使用 dd

+

在卸载所有SD卡的挂载分区后，您可以烧写SD卡。

+

一些PHYTEC BSP会生成未压缩的镜像（文件名扩展名为*.wic），而另一些则生成压缩的镜像（文件名扩展名为*.wic.xz）。

+

要写入未压缩的镜像（*.wic），请使用以下命令：

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

或者要写入压缩后的镜像（*.wic.xz），请使用以下命令：

+
host:~$ xzcat phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

再次确保将 <your_device> 替换为之前找到的设备名称。

+

参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

+
+
+
+

2.3. 首次启动

+ +../../../_images/SD_Card_Boot1.png +
    +

  • 插入SD卡

    • +

  • 使用 micro USB 线将开发板的 (X1) 调试USB口和主机连接起来

    • +

  • 给开发板通电

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (scarthgap).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (scarthgap).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-IMX8MP ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-xwayland MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD24.1.0
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 phyboard-pollux-imx8mp-3 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx8mp.bin: ARM可信固件二进制文件

    • +

  • lpddr4_pmu_train_2d_dmem_202006.bin, lpddr4_pmu_train_2d_imem_202006.bin: DDR PHY固件镜像

    • +

  • imx-boot：由imx-mkimage编译的bootloader镜像，包括SPL、U-Boot、ARM可信固件和DDR固件。这是最终的可引导bootloader镜像。

    • +

  • fitImage: Linux内核FIT镜像

    • +

  • fitImage-its*.its

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx8mp-phyboard-pollux-rdk*.dtb: 内核设备树文件

    • +

  • imx8mp-phy*.dtbo: 内核设备树overlay文件

    • +

  • phytec-qt6demo-image*.tar.gz: 根文件系统

    • +

  • phytec-qt6demo-image*.rootfs.wic.xz: 压缩的SD卡镜像

    • +
+
+
+
+
+

4. 安装操作系统

+
+

4.1. 启动模式开关 (S3)

+
+

小技巧

+

硬件修订版底板：1552.2

+
+

该 phyBOARD-Pollux 具有一个（启动源配置）开关，配有四个可单独切换的位，用于选择phyCORE-i.MX 8M Plus 默认的启动源。

+ + + + + + + + + + + +
+../../../_images/eMMC1.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses1.png +
+

内部fuse

+
+
+
+../../../_images/SPI_NOR.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download1.png +
+

USB

+
+
+
+../../../_images/SD_Card_Boot1.png +
+

SD卡

+
+
+
+../../../_images/Test_Mode.png +
+

测试模式

+
+
+
+
+
+

4.2. 烧写eMMC

+

为了保持文档的一致性和简洁性，假设已经配置好了TFTP服务器；所有生成的镜像（如上所列）都被复制到默认的/srv/tftp目录。如果您没有进行设置，您需要修改路径到包含镜像的目录。有关如何设置TFTP服务器和目录的说明，请参见 Setup Network Host 。

+

要从 eMMC 启动，请确保 BSP 镜像已正确烧写到 eMMC，并且 bootmode switch (S3) 设置为 eMMC。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行上述命令来检查系统启动在这种条件下是否会到影响。如果 mmcblk2p1 和 mmcblk1p1 具有相同的UUID，则会影响系统正确启动。

+
+
+

4.2.1. 从网络烧写 eMMC

+

i.MX 8M Plus 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

4.2.1.1. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

查看主机上可用的镜像文件：

+
host:~$ ls /srv/tftp
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
+
+

通过网络ssh协议使用 bmaptool 命令将镜像发送到开发板的eMMC：

+
host:~$ scp /srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2"
+
+
+
+
+

4.2.1.2. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

使用以下命令，通过网络将压缩或未压缩的镜像和配套的 *.bmap 文件传送到核心板并写入 eMMC：

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.* /tmp && bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
+
+
+
+

4.2.1.3. 在开发板的U-Boot中通过网络烧写eMMC

+

这些步骤将展示如何通过网络更新eMMC。

+
+

小技巧

+

此步骤仅在镜像文件小于1GB的情况下会被执行成功，因为在启用OPTEE后，Bootloader中可用的RAM大小有限，不足以加载超过1GB的镜像

+
+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

解压缩您的镜像

+
host:~$ unxz /srv/tftp/phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+

通过网络将您的镜像加载到内存中：

+
    +

  • 使用DHCP

    +
    u-boot=> dhcp phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.1 (1 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.1
+Filename 'phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • 使用静态IP地址（必须先设置serverip和ipaddr）。

    +
    u-boot=> tftp ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
+
+
+
+
+

4.2.2. 在运行的U-Boot中通过网络烧写eMMC U-Boot镜像

+

可以在U-Boot中更新U-Boot镜像imx-boot，eMMC上的U-Boot需要位于eMMC的user区域。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.3. 从USB大容量存储设备烧写eMMC

+
+

4.2.3.1. 在运行的Linux系统中从USB烧写eMMC

+

下面这些步骤展示如何在Linux系统上使用USB大容量存储设备烧写eMMC。您需要一个保存了完整镜像的U盘和一个可从SD卡启动的核心板。（例如： phytec-qt6demo-image-phyboard-pollux-imx8mp-3.|yocto-imageext| ）。将 bootmode switch (S3) 设置为SD卡。

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ ls /mnt
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
    +
    +
    • +

  • 将镜像写入 phyCORE-i.MX 8M Plus eMMC（无分区的 MMC 设备 2）：

    +
    target:~$ bmaptool copy /mnt/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    小技巧

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+

4.2.3.2. 在开发板上通过U-Boot从USB烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件小于1GB的情况下会被执行成功，因为在启用OPTEE后，Bootloader中可用的RAM大小有限，不足以加载超过1GB的镜像

+
+

下面这些步骤展示如何通过USB设备更新eMMC。将 bootmode switch (S3) 配置为SD卡并插入SD卡。给开发板上电并进入U-Boot环境。将已存储了未压缩WIC镜像的优盘插入开发板USB接口。

+

将镜像从USB设备加载到RAM中：

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 0x58000000 phytec-headless-image-|yocto-machinename|.rootfs.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write 0x58000000 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+
+

4.2.4. 从SD卡烧写eMMC

+

即使没有可用的网络，您也可以更新eMMC。为此，您需要一个位于SD卡上的镜像文件（ *.wic ）。由于镜像文件相当大，您需要在SD卡创建第三个分区。要创建新分区或扩展您的SD卡，请参见 Resizing ext4 Root Filesystem 。

+

或者，使用partup包烧写SD卡，如 Getting Started 中所述。这样就可使用SD卡的全部容量。

+
+

4.2.4.1. 在开发板的linux环境中通过SD卡烧写eMMC

+

您也可以在Linux系统中烧写eMMC。您只需要一个partup包或保存在SD卡上的WIC镜像。

+
    +

  • 检查在SD卡上保存的partup包或WIC镜像文件：

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
    +
    +
    • +

  • 使用 partup 将镜像写入 phyCORE-i.MX 8M Plus 的 eMMC（MMC 设备 2 不带 分区字样）：

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup /dev/mmcblk2
+
    +
    +

    使用partup烧写的优点是可以充分利用eMMC设备的全部容量，会相应自动调整分区大小。

    +
    +

    备注

    +

    另外，也可以使用 bmaptool 工具：

    +
    target:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
    +
    +

    请注意，在使用 bmaptool 烧写时，根文件系统分区并不会使用eMMC的最大容量。

    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    警告

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+

4.2.4.2. 在开发板的uboot环境中通过SD卡烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1GB的情况下有效，因为在启用OPTEE后，Bootloader中可用的RAM大小有限。如果镜像文件过大，请阅读 在开发板上通过SD卡更新eMMC 一节

+
+
    +

  • 将一个可用的镜像烧写到SD卡，并创建一个EXT4格式的第三分区。将WIC镜像（例如 phytec-qt6demo-image.rootfs.wic）复制到该分区。

    • +

  • 将 bootmode switch (S3) 配置为 SD 卡并插入 SD 卡。

    • +

  • 打开电源并进入U-Boot。

    • +

  • 加载镜像：

    +
    u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • 将当前mmc设备切换到eMMC：

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • 将您的WIC镜像（例如 phytec-qt6demo-image.rootfs.wic）从SD卡烧写到eMMC。这将对emmc进行分区，并将imx-boot、Image、dtb、dtbo和根文件系统复制到eMMC。

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • 关闭电源并将 bootmode switch (S3) 更改为 eMMC。

    • +
+
+
+
+
+

4.3. 烧写 SPI NOR Flash

+

phyCORE-i.MX8MP 模块可选配SPI NOR Flash。要从SPI Flash启动，请将 bootmode switch (S3) 设置为 SPI NOR 。SPI Flash通常比较小。phyBOARD-Pollux-i.MX8MP开发套件仅配备32MB的SPI NOR Flash。只能存储bootloader及其环境变量。默认情况下，内核、设备树和文件系统会从eMMC加载。

+

SPI NOR Flash分区表在U-Boot环境变量中定义。可以通过以下命令打印：

+
u-boot=> printenv mtdparts
+mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env:redund),-(none)
+
+
+
+

4.3.1. 通过网络烧写SPI NOR Flash

+

SPI NOR可以包含bootloader及其环境变量。arm64的linux内核无法自行解压缩，内核镜像大小超出了phyCORE-i.MX 8M Plus 上的SPI NOR Flash的容量。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+
+

4.3.1.1. 在开发板linux环境中通过网络烧写SPI NOR Flash

+
    +

  • 将镜像从主机复制到开发板：

    +
    host:~$ scp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi root@192.168.3.11:/root
+
    +
    +
    • +

  • 查找要擦除的U-boot分区的块数：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除U-Boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.1.2. 在开发板的U-Boot环境中通过网络烧写SPI NOR

+

类似于通过网络更新eMMC，请确保正确设置主机PC。IP地址需要设置为192.168.3.10，子网掩码设置为255.255.255.0，并且需要有一个可用的TFTP服务。在进行读写之前，需要对SPI NOR Flash进行枚举：

+
u-boot=> sf probe
+SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB, total 64 MiB
+
+
+
    +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像。确保您使用了正确的镜像文件。通过tftp加载镜像，然后将bootloader写入Flash：

    +
    u-boot=> tftp ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+device 0 offset 0x0, size 0x1c0b20
+1641248 bytes written, 196608 bytes skipped in 4.768s, speed 394459 B/s
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+

4.3.2. 从SD卡烧写SPI NOR Flash

+

SPI NOR Flash上的bootloader也可以通过SD卡进行烧写。

+
+

4.3.2.1. 在开发板的linux环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi复制到SD卡的第一个分区。

    • +

  • 挂载SD卡：

    +
    target:~$ mount /dev/mmcblk1p1 /mnt
+
    +
    +
    • +

  • 查找要擦除的U-Boot分区的块数：

    +
    target:~$ mtdinfo /dev/mtd0
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
    +
    +
    • +

  • 擦除u-boot分区并烧写：

    +
    target:~$ flash_erase /dev/mtd0 0x0 60
+target:~$ flashcp /mnt/imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi /dev/mtd0
+
    +
    +
    • +
+
+
+

4.3.2.2. 在开发板的U-Boot环境中从SD卡烧写SPI NOR

+
    +

  • 将SPI NOR Flash的U-boot镜像imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi复制到SD卡的第一个分区。

    • +

  • 在进行读写操作之前，需要对SPI-NOR Flash进行枚举：

    +
    u-boot=> sf probe
+SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+
    +
    +
    • +

  • SPI NOR Flash需要使用特殊格式的U-Boot镜像，请确保使用正确的镜像文件。从SD卡加载镜像，擦除并将bootloader写入flash：

    +
    u-boot=> mmc dev 1
+u-boot=> fatload mmc 1:1 ${loadaddr} imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+u-boot=> sf update ${loadaddr} 0 ${filesize}
+
    +
    +
    • +

  • 同时需要擦除环境分区。这样，环境变量可以在从SPI NOR Flash启动后写入：

    +
    u-boot=> sf erase 0x400000 0x100000
+
    +
    +
    • +
+
+
+
+
+

4.4. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC： L-1006e.A6 RAUC Update & Device Management Manual 。

+
+
+

4.5. EFI Boot

+

Standardboot in U-Boot also supports booting distros over efi. By default the +U-Boot will search for a bootscript first, which is used to boot our Ampliphy +distro. If it does not find any bootscript, it will search for bootable efi +applications. So for booting over efi just make sure you don't have our distro +installed.

+
+

4.5.1. Disable booting with efi

+

To disable booting with efi you have to set the doefiboot variable to 0. +Also make sure you do not have efi or efi_mgr specified in the +bootmeths environment variable.

+
u-boot=> setenv doefiboot 0
+u-boot=> env save; env save;
+
+
+
+
+

4.5.2. Switch to only efi boot

+

If you want to only boot with efi, you can set the bootmeths environment +variable to efi. Also make sure you have the doefiboot environment variable +set to 1.

+
u-boot=> setenv bootmeths efi
+u-boot=> env save; env save;
+
+
+
+
+

4.5.3. Installing a distro

+

With efi you can install and boot different distros like openSUSE, Fedora or +Debian. First you have to get the iso Image from their website. For example:

+

https://cdimage.debian.org/debian-cd/current/arm64/iso-dvd/

+

Then copy the .iso file to a usb stick for example. Make sure you select the +correct device:

+
sudo dd if=file.iso of=/dev/sdx bs=1M conv=fsync status=progress
+
+
+

Insert the USB stick into the board and boot it. GRUB will then prompt you with +a menu where you can select what to do. Here select install. Then you have to +click through the installation menu. This is relatively straightforward and +differs a bit for every distro. You can install the distro for example to emmc +(mmc 2) or sdcard (mmc 1). Make sure you do not overwrite +your U-Boot during the install. Best to choose a different medium to install to +than the U-Boot is stored on. Otherwise manual partitioning will be required. +The automatic partitioning will start at the beginning of the disk. To not +overwrite the U-Boot, use an offset of 4MiB at the beginning of the disk.

+

During the Installation of Debian you will be asked, if you want to Force the +GRUB installation to the EFI removable media path. Select no. Also select no, +when you will be asked if you want to update the NVRAM variables. Otherwise the +grub-dummy installation step will fail and you will be sent back to the +"Force GRUB installation" prompt.

+

After the installation is complete, reboot the board and remove the +installation medium (USB-stick). The board should then boot the distro you +installed.

+

If that does not happen, check if there is a boot option set for the distro. +The easiest way is with the eficonfig command.

+
u-boot=> eficonfig
+
+
+

That will open a menu. Then you can select Edit Boot Option. It will show +you the current boot options. If this is empty or you don't find your distro, +select Add Boot Option to add a new one. For debian for example you only +need to set the description and the file. You can enter whatever you want into +the description field. When you select the file field, you can select the disc +you installed the distro on and partition number one. For example +"mmc 2:1" for emmc, or "mmc 1:1" for sdcard. The file you +need to select is at EFI/debian/grubaa64.efi. After that save, quit and +reset the board. The board should then boot into debian.

+
+
+
+
+

5. 开发

+

从这个版本开始，U-Boot中的启动行为发生了变化。之前，内核和设备树是作为单独的二进制文件提供的。现在，二者将被包含在一个单一的FIT镜像二进制文件中。此外，PHYTEC ampliphy发行版的启动逻辑被移到了一个启动脚本中，该脚本本身是一个单独的FIT镜像二进制文件的一部分。要恢复到旧的启动方式，您可以执行

+
run legacyboot
+
+
+
+

备注

+

这种启动方式已被弃用，并将在下一个版本中移除。默认情况下，通过此命令启动将返回错误，因为启动分区中缺少内核和设备树。

+
+
+

5.1. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone git://git.phytec.de/u-boot-imx）

+
+
+

5.1.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-imx 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    https://github.com/phytec/linux-phytec-imx
+
    +
    +
    • +

  • 我们的 i.MX 8M Plus 内核是基于 linux-phytec-imx 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.1.2. 获取SDK

+

您可以在此处下载SDK 这里，或者使用Yocto去编译生成SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

在成功编译后，SDK安装包保存在 build/deploy*/sdk。

+
+
+

5.1.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.x.sh
+host:~$ ./phytec-ampliphy-vendor-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.x.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-xwayland/5.0.x):
+You are about to install the SDK to "/opt/ampliphy-vendor-xwayland/5.0.x". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.1.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.1.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.2. 单独编译U-Boot

+
+

5.2.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本中使用的**tag**称为 v2024.04_2.0.0-phy7

    • +

  • 查看所需的 U-Boot tag：

    +
    host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2024.04_2.0.0-phy7
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.2.2. 获取所需的二进制文件

+

要编译bootloader，您需要将这些文件复制到您的 u-boot-imx 编译目录，并将其重命名以适应 mkimage 脚本：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx8mp.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以在yocto工程目录中获取 bl31-imx8mp.bin、tee.bin和lpddr4_*.bin：BSP Images

+

或者你可以在这里下载文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/imx-boot-tools/

+
+

警告

+

确保您重命名所需的文件，以和 mkimage tool 兼容。

+
+
+
+

5.2.3. 编译bootloader

+
    +

  • 编译 flash.bin (imx-boot):

    +
    host:~/u-boot-imx$ make phycore-imx8mp_defconfig
+host:~/u-boot-imx$ make flash.bin
+
    +
    +
    • +
+
+
+

5.2.4. 将bootloader烧写到块设备上

+

flash.bin 文件可以在 u-boot-imx/ 目录下找到，现在可以进行烧写。需要指定芯片特定的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

例如，烧写SD卡：

+
host:~/u-boot-imx$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+

5.2.5. 使用固定内存大小编译U-Boot

+

如果您的系统因为EEPROM中的硬件信息损坏或丢失而无法启动，您可以创建一个具有固定RAM大小的flash.bin。但您仍应联系我们支持部门以烧写正确的EEPROM数据。

+

按照步骤获取U-boot源代码，并切换到 Build U-Boot 章节说明的分支。

+

Edit the file configs/phycore-imx8mp_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+
+
+

选择正确的RAM大小，确保与核心板上的贴装的器件一致，取消注释该RAM大小的行。保存更改后，按照 Build U-Boot 章节的剩余步骤进行操作。

+
+
+

5.2.6. 编译支持固定RAM大小与频率的U-Boot

+

从PD23.1.0 NXP或PD24.1.2 Mainline 版本开始，PCB为1549.3版本的核心板及更新版本的phyCORE-i.MX 8M Plus SoM支持2GHz内存时序。这些将在支持的板上自动启用，但也可以手动启用或禁用。

+

Edit the file configs/phycore-imx8mp_defconfig. +The fixed RAM size with 2GHz timings will be used:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+CONFIG_PHYCORE_IMX8MP_RAM_FREQ_FIX=y
+CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+
+
+

在保存更改后，按照 Build U-Boot 中剩下的步骤操作。

+
+
+

5.2.7. 编译固定的RAM频率的U-Boot

+

从PD24.1.2 Mainline版本或者 PD24.1.0 NXP 版本开始，U-Boot可以编译成只固定RAM频率，RAM大小还是保持从EEPROM读取。

+

Edit the file configs/phycore-imx8mp_defconfig. +The RAM size from EEPROM with fixed frequency will be used:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_FREQ_FIX=y
+# CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+# CONFIG_PHYCORE_IMX8MP_USE_1_5GHZ_RAM_TIMINGS=y
+
+
+

在保存更改后，按照 Build U-Boot 中剩下的步骤操作。

+
+
+
+

5.3. 单独编译内核

+

内核与设备树一起打包在FIT镜像中。U-Boot已被配置为能够加载FIT镜像并引导其中包含的内核。因此，内核镜像必须打包在FIT镜像中。

+
+

5.3.1. 配置源代码

+
    +

  • 使用的 linux-phytec-imx 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v6.6.23-2.0.0-phy10

    • +

  • Check out 所需的 linux-phytec-imx 标签：

    +
    host:~$ git clone https://github.com/phytec/linux-phytec-imx
+host:~$ cd ~/linux-phytec-imx/
+host:~/linux-phytec-imx$ git fetch --all --tags
+host:~/linux-phytec-imx$ git checkout tags/v6.6.23-2.0.0-phy10
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-phytec-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-phytec-imx$ source /opt/ampliphy-vendor-xwayland/5.0.x/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.3.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-phytec-imx$ make imx8_phytec_defconfig
+host:~/linux-phytec-imx$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-phytec-imx/arch/arm64/boot/Image.gz 找到

    • +

  • dtb文件可以在 ~/linux-phytec-imx/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-phytec-imx$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.3.3. 将内核打包成FIT镜像

+

要简单地替换内核，您需要一个 image tree source (.its)文件。如果您已经使用Yocto编译了我们的BSP，可以从此处提到的目录获取its文件： BSP Images 或者您可以在这里下载该文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-NXP-i.MX8MP-PD24.1.0/images/ampliphy-vendor-xwayland/phyboard-pollux-imx8mp-3/

+

将 .its 文件复制到当前工作目录，创建一个指向内核镜像的链接，并使用 mkimage 创建最终的 fitImage。

+
host:~/linux-phytec-imx$ cp /path/to/yocto/deploydir/fitimage-its*.its .
+                  && ln -s arch/arm64/boot/Image.gz linux.bin
+                  && uboot-mkimage -f fitImage-its*.its fitImage
+
+
+
+
+

5.3.4. 将FIT镜像和内核模块复制到SD卡

+

FIT镜像以及内核module可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-phytec-imx$ cp fitImage /path/to/sdcard/boot/
+host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.4. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.4.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.4.2. 获取镜像

+

从我们的服务器下载imx-boot，或者从您Yocto工程中的build/deploy-ampliphy-vendor-xwayland/images/phyboard-pollux-imx8mp-3/路径获取。要将wic镜像烧写到eMMC，你还需要 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic。

+
+
+

5.4.3. 开发板准备

+

将 bootmode switch (S3) 设置为 USB串行下载。同时，将 USB 端口 X5 (upper connector) 连接到主机。

+
+
+

5.4.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 (X1) 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.4.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.4.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
+
+
+
+

5.4.7. 通过UUU工具烧写SPI NOR Flash

+

执行并给开发板上电：

+
host:~$ sudo uuu -b qspi imx-boot-phyboard-pollux-imx8mp-3-fspi.bin-flash_evk_flexspi
+
+
+

这将更新SPI NOR Flash上的U-Boot，但不会更新环境。您可能需要擦除旧环境，以便加载新U-Boot的默认环境：

+
u-boot=> env erase
+u-boot=> reset
+
+
+
+
+
+

5.5. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.5.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.5.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.5.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.6. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.6.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核fitimage复制到您的tftp目录中：

    +
    host:~$ cp fitImage /srv/tftp
+
    +
    +
    • +

  • 将启动脚本复制到您的tftp目录中：

    +
    host:~$ cp boot.scr.uimg /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.6.2. 设置网络启动的bootenv.txt文件

+

在您的tftp目录中创建一个bootenv.txt文件，并将以下变量写入其中。

+
nfsroot=/srv/nfs
+overlays=<overlayconfignames>
+
+
+

<overlayconfignames> 替换为您想要使用的设备树overlay配置名称。用#号分隔配置名称。例如：

+
overlays=conf-example-overlay1.dtbo#conf-example-overlay2.dtbo
+
+
+
+

小技巧

+

所有支持的设备树overlay文件都在 device tree 章节中。或者可以通过以下命令打印：

+
host:~$ dumpimage -l fitImage
+
+
+
+
+
+

5.6.3. 开发板上的网络设置

+

如果要自定义开发板上的以太网配置，请按照此处的说明进行操作： Network Environment Customization

+
+
+

5.6.4. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> setenv boot_targets ethernet
+u-boot=> bootflow scan -lb
+
    +
    +
    • +
+
+
+
+

5.7. 获取BSP开发中版本

+
+

5.7.1. 当前release的开发中版本

+

这些release manifest文件是为了让您访问 Yocto BSP的开发版本。它们不会在phyLinux选择菜单中显示，需要手动选择。可以使用以下命令行来完成此操作：

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-NXP-i.MX8MP-PD24.1.y
+
+
+

这将初始化一个BSP，用于跟踪当前版本（ BSP-Yocto-NXP-i.MX8MP-PD24.1.0 ）的最新开发版本。从现在开始，在此文件夹中执行 repo sync 将从我们的Git仓库中拉取所有最新的更改：

+
host:~$ repo sync
+
+
+
+
+

5.7.2. 即将发布版本的开发中版本

+

即将发布版本的开发中版本可以通过这种方式访问。请执行以下命令，并查找一个比最新版本（ BSP-Yocto-NXP-i.MX8MP-PD24.1.0 ）的PDXX.Y数字更高的版本，并且以 .y 结尾：

+
host:~$ ./phyLinux init -p imx8mp
+
+
+
+
+
+

5.8. 获取最新的Upstream支持

+

我们有一个使用Yocto主分支（不是NXP发布的）的manifest，他使用upstream的Linux和U-Boot。这可以用来测试最新的upstream kernel/U-Boot。

+
+

备注

+

master分支的manifest反映了最新的开发状态。有时会出现一些bug。我们会定期修复master分支。

+
+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.9.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic 镜像复制到其中。然后卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+

5.10. Switch back to legacyboot

+
+

警告

+

As we switched to standardboot with fitimage as default, legacyboot is +deprecated. We kept the option to switch back to legacyboot for this +release, but it will be removed in the future.

+
+
+

5.10.1. Changes in Yocto

+

By default, the fitImage and bootscript will be deployed into the wic.xz Image. +To switch back to legacyboot, you need to replace the fitImage and bootscript +for the kernel image and the devicetrees. They are still in the deploy +folder from the Yocto build, so you can manually copy them to the boot +partition on your device. Otherwise you can do the following changes in Yocto +to get the kernel and devicetrees deployed in the Image again.

+

First create the variable KERNEL_DEVICETREE_DEPLOY. This can be done for +example in the local.conf file in your build directory conf/local.conf. +The variable is basically a copy of the KERNEL_DEVICETREE variable that is +set in conf/machine/phyboard-pollux-imx8mp-3.conf in meta-phytec but the freescale +at the beginning needs to be removed, so that only the devicetree filename are +left. In the end it should look something like this:

+
KERNEL_DEVICETREE_DEPLOY = " \
+     imx8mp-phyboard-pollux-rdk.dtb \
+     imx8mp-phyboard-pollux-isp-csi1.dtbo \
+     imx8mp-phyboard-pollux-isp-csi2.dtbo \
+     imx8mp-phyboard-pollux-isi-csi1.dtbo \
+     imx8mp-phyboard-pollux-isi-csi2.dtbo \
+     imx8mp-phyboard-pollux-peb-av-10.dtbo \
+     imx8mp-phyboard-pollux-peb-wlbt-05.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm016-csi2-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm017-csi2-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi1-fpdlink-port1.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2-fpdlink-port0.dtbo \
+     imx8mp-phyboard-pollux-vm020-csi2-fpdlink-port1.dtbo \
+     imx8mp-phycore-no-eth.dtbo \
+     imx8mp-phycore-no-rtc.dtbo \
+     imx8mp-phycore-no-spiflash.dtbo \
+     imx8mp-phycore-rpmsg.dtbo \
+"
+
+
+

Then add this line:

+
IMAGE_BOOT_FILES:mx8m-nxp-bsp:append = " Image oftree ${KERNEL_DEVICETREE_DEPLOY}"
+
+
+
+

备注

+

A clean might be required for this to work.

+
bitbake -c cleanall phytec-qt6demo-image
+
+
+
+

Then start the build:

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

5.10.2. Changes in U-Boot environment

+

To re-enable legacyboot set the following variable:

+
uboot=> setenv dolegacyboot 1
+uboot=> env save; env save;
+uboot=> boot
+
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 8M Plus 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Board.dts - 包含module dtsi 文件。从SoC i.MX 8M Plus 引出并在底板使用的设备也包含在此 dts 中。

    • +

  • Overlay.dtso - 根据核心板或底板上可选硬件（例如 SPI 闪存或 PEB-AV-10）的情况来启用/禁用一些功能。

    • +
+

在Linux内核的根目录下，我们的 i.MX 8 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。下面是扩展板的硬件描述。对比源码中的include，overlay通过覆盖的方式来生效。overlay也可以根据实际开发板的硬件配置来设置设备树节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/ 中。

+

phyboard-pollux-imx8mp-3.conf 可用的overlay文件有：

+
imx8mp-isi-csi1.dtbo
+imx8mp-isi-csi2.dtbo
+imx8mp-isp-csi1.dtbo
+imx8mp-isp-csi2.dtbo
+imx8mp-phyboard-pollux-peb-av-10.dtbo
+imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+imx8mp-phycore-no-eth.dtbo
+imx8mp-phycore-no-rtc.dtbo
+imx8mp-phycore-no-spiflash.dtbo
+imx8mp-phycore-rpmsg.dtbo
+imx8mp-vm016-csi1.dtbo
+imx8mp-vm016-csi1-fpdlink.dtbo
+imx8mp-vm016-csi2.dtbo
+imx8mp-vm016-csi2-fpdlink.dtbo
+imx8mp-vm017-csi1.dtbo
+imx8mp-vm017-csi1-fpdlink.dtbo
+imx8mp-vm017-csi2.dtbo
+imx8mp-vm017-csi2-fpdlink.dtbo
+
+
+

Otherwise you can show the content of a FIT image including all overlay +configs in the FIT image with this command in Linux:

+
host:~$ dumpimage -l /boot/fitImage
+
+
+

or in U-Boot:

+
u-boot=> load mmc ${mmcdev}:1 ${loadaddr} fitImage
+u-boot=> iminfo
+
+
+

可以在Linux或U-Boot环境下配置overlay。overlay是在引导命令调用后、内核加载之前生效。接下来的部分将更详细地解释配置方法。

+
+

6.2.2.1. 设置 ${overlays} 变量

+

The ${overlays} U-Boot environment variable contains a number-sign (#) +separated list of overlays that will be applied during boot. The overlays +listed in the overlays variable must be included in the FIT image. Overlays set +in the $KERNEL_DEVICETREE Yocto machine variable will automatically be added to +the FIT image.

+

The ${overlays} variable can either be set directly in the U-Boot +environment or can be part of the external bootenv.txt environment file. +When desired to use the overlays variable as set manually in the U-Boot +environment, disable bootenv by setting env set no_bootenv 1 as the overlays +variable may be overwritten during the execution of the boot script. +By default, the ${overlays} variable comes from the external bootenv.txt +environment file which is located in the boot partition. +You can read and write the file on booted target from linux:

+
target:~$ cat /boot/bootenv.txt
+overlays=conf-imx8mp-phyboard-pollux-rdk-peb-eval-01.dtbo#conf-imx8mp-phyboard-pollux-peb-av-10.dtbo
+
+
+

更改将在下次重启后生效。如果没有可用的 bootenv.txt 文件，可以直接在U-Boot环境中设置overlay变量。

+
u-boot=> setenv overlays conf-imx8mp-phyboard-pollux-peb-av-10.dtbo
+u-boot=> printenv overlays
+overlays=conf-imx8mp-phyboard-pollux-peb-av-10.dtbo
+u-boot=> boot
+
+
+

如果用户定义了 ${overlays} 变量，同时存在 bootenv.txt 文件，则需要设置 ${no_bootenv} 变量：

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays conf-imx8mp-phyboard-pollux-peb-av-10.dtbo
+u-boot=> boot
+
+
+

有关环境的更多信息，请参见 U-boot External Environment subsection of the +device tree overlay section。

+

We use the ${overlays} variable for overlays describing expansion boards and +cameras that can not be detected during run time. To prevent applying overlays +unset the overlays variable and set no_bootenv to anything other than 0.

+
u-boot=> env delete overlays
+u-boot=> env set no_bootenv 1
+
+
+

If desired to use the bootenv.txt file for setting U-Boot variables other than +overlays and having overlays disabled, remove the overlays definition line from +the bootenv.txt file instead of setting no_bootenv.

+
+
+

6.2.2.2. SoM Variants

+

Additional overlays are applied automatically to disable components that are not +populated on the SoM. The detection is done with the EEPROM data (EEPROM SoM +Detection) found on the SoM i2c EEPROM.

+

这取决于核心板型号是否会应用任何设备树overlay。要检查在U-Boot中运行的SoM是否会应用overlay，请运行：

+
u-boot=> env print fit_extensions
+
+
+

如果没有可用的EEPROM数据，则不加载任何设备树overlay。

+

To prevent application of the SoM variant related overlays the +${no_extensions} variable can be set to 1 in the bootloader environment:

+
u-boot=> setenv no_extensions 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot外部环境

+

在Linux内核启动时，外部环境 bootenv.txt 文本文件将从MMC设备的boot分区或通过TFTP加载。该文件的主要目的是存储 ${overlays} 变量。这可以针对不同的machine在Yocto中预定义不同的overlay配置。文件的内容在meta-phytec中的Yocto recipe中的bootenv中定义： https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=scarthgap

+

该文件中也可以设置其他变量。这些变量将覆盖环境中现有的设置。但只有对boot命令后进行计算的变量生效，例如 ${nfsroot} 或 ${mmcargs}。在文件中更改其他变量将不会有作用。以网络启动的用法作为示例。

+

如果无法加载外部环境，启动过程将继续进行，并使用自带的环境变量值。

+
+
+

6.2.4. 在Linux环境下更改开发板上的U-boot环境变量

+

Libubootenv是我们镜像中包含的一个工具，用于在开发板linux上修改U-Boot环境。

+

使用以下命令打印U-Boot环境：

+
target:~$ fw_printenv
+
+
+

使用以下命令修改U-Boot环境：

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

小心

+

Libubootenv会读取配置文件中配置的环境变量。要修改的环境变量会被插入到该文件中，默认情况下使用eMMC中存储环境变量。

+

如果eMMC没有被烧写过或者eMMC环境被擦除，libubootenv将无法工作。您应该修改 /etc/fw_env.config 文件，以匹配您想要使用的环境源。

+
+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 8M Plus BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 8M Plus BSP设备树概念部分，以了解我们的 i.MX 8 BSP设备树模型。

+

以下部分概述了 i.MX 8 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 8M Plus 引脚复用

+

该 i.MX 8M Plus Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 8M Plus 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 8M Plus 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是 imx8mp-phyboard-pollux-rdk.dts中UART1设备的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x140
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x140
+        >;
+};
+
+
+

字符串的第一部分 MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 指定了引脚（在这个例子中是 UART1_RXD）。字符串的第二部分（UART1_DCE_RX）是该引脚所选的复用项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部拉电阻是否被激活。在当前情况下，内部拉电阻被禁用。

+

The device tree representation for UART1 pinmuxing: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L373

+
+
+

7.2. RS232/RS485

+

phyCORE-i.MX 8M Plus 支持最多 4 个 UART 单元。在 phyBOARD-Pollux 上，UART1（调试串口）和 UART4 的 TTL 电平信号被连接到 Silicon Labs CP2105 UART 到 USB 转换IC。这个 USB 信号通过 Micro-USB 连接器 X1 输出。UART3 位于 X6（扩展连接器），为 TTL 电平信号。UART2 连接到一个多协议收发器IC，可转换为 RS-232 或 RS-485，RS-232 和 RS-485 信号位于连接器 X2 。多协议配置通过主板上的跳线 JP3 和 JP4 完成。更多信息，请参阅 phyCORE-i.MX 8M Plus/phyBOARD-Pollux 硬件手册中的 UARTs 部分。

+

对于RS-232和RS-485，使用相同的设备树节点。RS485模式可以通过ioctl TIOCSRS485 来启用。双向通讯支持也可以通过ioctl进行配置。请查看我们的小示例应用程序rs485test，该程序也包含在BSP中。需要设置跳线 JP3 和 JP4 。

+
+

7.2.1. RS232

+
    +

  • 以人类可读的格式显示终端的当前设置：

    +
    target:~$ stty -a
+
    +
    +
    • +

  • UART接口的配置可以通过stty命令完成。例如：

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • 通过简单的echo和cat，可以测试基本的通信。示例：

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

主机应打印出 "123"。

+
+
+

7.2.2. RS485

+
+

提示

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

为了方便测试，请查看linux-serial-test。这个工具会通过调用RS485的IOCTL，发送恒定的数据流。

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

有关linux-serial-test工具及其参数的更多信息，请访问此链接：linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Linux kernel文档描述了如何在C代码中调用IOCTL： https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see "test" printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final "count for this session". There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+
+
+

7.2.2.2. RS485 full-duplex

+

For full-duplex mode your connection setup should look like this:

+../../../_images/RS485_fullduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For full-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 1
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  true
+Bus termination enabled:  false
+
+
+

Also here you can do the echo test to see if sending and receiving works:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see "test" printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

To check if the full-duplex operation works, you need to use the +linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=114660, tx=118755, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=118755, tx=114660, rx err=0
+
+
+

In this example both targets will send and receive simultaneously. They will +receive for 15sec and send for 10sec. The receiver needs to receive a bit +longer, so that all sent messages will get received. Remember to start both +targets almost simultaneously. A small difference in start time is accounted +for with the -W 2 option. At the end the program will print the final +"count for this session". There you can check that all transmitted frames were +received.

+

All the test examples are target to target, but can also be done with host to +target with a USB to rs485 converter. You may need to adjust the interfaces for +commands to work on the host then.

+

The device tree representation for RS232 and RS485: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L412

+
+
+
+
+

7.3. 网络

+

phyBOARD-Pollux-i.MX 8M Plus 提供两个以太网接口。我们的核心板和底板各提供一个千兆以太网接口。

+
+

警告

+

硬件中的以太网接口命名约定（ethernet0 和 ethernet1）与Linux中的网络接口（eth0 和 eth1）不一致。因此，请注意这些差异：

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L50。

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Pollux can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L179.

+
+

7.3.1. 网络配置

+
+

7.3.1.1. U-boot网络环境

+
    +

  • 要在bootloader中查找以太网设置：

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • 在将主机设置为IP 192.168.3.10和子网掩码255.255.255.0的情况下，开发板应该返回：

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • 如果您需要进行任何更改：

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> 应该是 ipaddr、netmask、gatewayip 或 serverip 中的一个。<value> 将是所选参数的设定值。

    +
    • +

  • 您所做的更改目前是临时的。要保存这些更改：

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

在这里，您也可以将IP地址更改为DHCP，而不是使用静态IP地址。

+
    +

  • 配置：

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • 设置 TFTP 和 NFS 的路径。修改可以如下所示：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+

小技巧

+

像nfsroot和netargs这样的变量可以被U-boot外部环境重新赋值。对于网络启动，外部环境将通过tftp加载。例如，要在 bootenv.txt 文件中设置nfsroot变量，请在tftproot目录修改：

+
nfsroot=/home/user/nfssrc
+
+
+

无需在开发板上存储这些信息。请注意，U-boot外部环境对于像 ipaddr 或 serveraddr 这样的变量不起作用，因为它们在加载外部环境之前已经被设置完成。

+
+
+
+

7.3.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.3.2. 无线局域网

+

在 phyBOARD-Pollux 上，WLAN和蓝牙由PEB-WLBT-05扩展板提供。PEB-WLBT-05的 phyBOARD-Pollux 快速入门指南向您展示了如何安装PEB-WLBT-05。

+
+

小技巧

+

对于BSP版本PD22.1及更新版本，需要先激活PEB-WLBT-05 Overlay，否则PEB-WLBT-05将无法被识别。

+
target:~$ vi /boot/bootenv.txt
+
+
+

之后，bootenv.txt 文件应该如下所示（它还可以包含其他设备树overlay！）：

+
overlays=conf-imx8mp-phyboard-pollux-peb-wlbt-05.dtbo
+
+
+

更改将在重启后应用：

+
target:~$ reboot
+
+
+

有关设备树overlay的更多信息，请阅读 device tree 章节。

+
+

为了支持WLAN和蓝牙，我们使用来自LSR的Sterling-LWB模块。该模块支持2.4 GHz，并且可以在多种模式下运行，如客户端模式、使用WEP、WPA、WPA2加密的接入点（AP）模式等。有关该模块的更多信息，请访问 https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

7.3.2.1. 连接到WLAN网络

+

首先设置您所在国家的正确监管域：

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

你将会看到：

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

设置无线接口：

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

现在您可以扫描可用的网络：

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

您可以使用一个跨平台的客户端，名为wpa_supplicant，支持WEP、WPA和WPA2，以建立加密连接。

+

为此，请将网络凭据添加到文件 /etc/wpa_supplicant.conf 中：

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

现在可以建立连接：

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

这会得到如下输出：

+
Successfully initialized wpa_supplicant
+
+
+

The ip address is automatically configured over DHCP. For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (scarthgap).

+
+
+
+

7.3.3. 蓝牙

+

Bluetooth is supported on phyBOARD-Pollux with the PEB-WLBT-05 expansion card. How this can be activated +is described in the WLAN section.

+

Bluetooth is connected to UART3 interface. More information about the module can +be found at +https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf. +The Bluetooth device needs to be set up manually:

+
target:~$ hciconfig hci0 up
+
+target:~$ hciconfig -a
+
+hci0:   Type: Primary  Bus: UART
+        BD Address: 00:25:CA:2F:39:96  ACL MTU: 1021:8  SCO MTU: 64:1
+        UP RUNNING PSCAN
+        RX bytes:1392 acl:0 sco:0 events:76 errors:0
+        TX bytes:1198 acl:0 sco:0 commands:76 errors:0
+        ...
+
+
+

现在您可以扫描环境中的可见蓝牙设备。在默认配置下，蓝牙是不可见的。

+
target:~$ hcitool scan
+Scanning ...
+       XX:XX:XX:XX:XX:XX       <SSID>
+
+
+
+

7.3.3.1. 可见性

+

要激活可见性：

+
target:~$ hciconfig hci0 piscan
+
+
+

要禁用可见性：

+
target:~$ hciconfig hci0 noscan
+
+
+
+
+

7.3.3.2. 连接

+
target:~$ bluetoothctl
+[bluetooth]# discoverable on
+Changing discoverable on succeeded
+[bluetooth]# pairable on
+Changing pairable on succeeded
+[bluetooth]# agent on
+Agent registered
+[bluetooth]# default-agent
+Default agent request successful
+[bluetooth]# scan on
+[NEW] Device XX:XX:XX:XX:XX:XX <name>
+[bluetooth]# connect XX:XX:XX:XX:XX:XX
+
+
+
+

备注

+

如果连接失败并出现错误信息：“连接失败：org.bluez.Error.Failed”，请尝试使用以下命令重新启动PulseAudio：

+
target:~$ pulseaudio --start
+
+
+
+
+
+
+
+

7.4. SD/MMC 卡

+

该 i.MX 8M Plus 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L422

+

DT configuration for the eMMC interface can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L214

+
+
+

7.5. eMMC设备

+

PHYTEC模块如phyCORE-i.MX 8M Plus 配备了eMMC存储芯片作为主要存储。eMMC设备使用多层单元（MLC）或三层单元（TLC）技术来实现存储，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 8M Plus ，并在Linux内核中作为块设备表示，如SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.5.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），该层负责处理原始MLC或TLC的磨损均衡、块管理和错误更正码（ECC）。这需要定期执行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 通过以下命令使能BKOPS_EN：

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.5.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 8M Plus SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.5.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
+
+

7.5.5. 启用伪SLC模式

+

eMMC设备使用 MLC或TLC 来存储数据。与NAND Flash中使用的SLC相比，MLC或TLC在成本更低的情况下，可靠性较低且错误率较高。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. 擦除设备

+

可以直接擦除eMMC设备，而不是通过写零覆盖。eMMC块管理算法将擦除底层的MLC或TLC，或者将这些块标记为可丢弃。设备上的数据将丢失，并将被读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.5.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 8M Plus 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.5.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

下表是 i.MX 8M Plus SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.6. SPI主设备

+

i.MX 8M Plus 控制器包含一个 FlexSPI 和一个 ECSPI IP 核。FlexSPI 主控制器支持两个 SPI 通道，最多可连接 4 个设备。每个通道支持单通道/双通道/四通道/八通道模式的数据传输（1/2/4/8 条数据线）。ECSPI 控制器支持 3 个 SPI 接口，每个接口都有一个专用的CS（chip select）引脚。由于CS也可通过 GPIO 实现，因此每个通道上可以连接多个设备。

+
+

7.6.1. SPI NOR 烧写

+

phyCORE-i.MX 8M Plus 配备有一个 QSPI NOR Flash，该 Flash 连接到 i.MX 8M Plus 的 FlexSPI 接口。QSPI NOR Flash 可用于启动。有关烧写和启动模式设置的详细信息，请参见不同的章节。由于 SPI NOR Flash 的空间有限，因此仅可存储bootloader。默认情况下，内核、设备树和根文件系统来自 eMMC。

+

bootloader程序通过EEPROM数据检测是否安装了SPI Flash。如果没有安装SPI Flash，则在启动期间应用设备树overlay，通过扩展命令禁用SPI Flash设备树节点。如果没有可用的EEPROM数据，SPI NOR Flash节点将始终启用。有关更多信息，请参阅设备树overlay部分。

+

bootloader程序还可以通过内核的mtdparts启动参数修改设备树，将SPI MTD分区表传递给Linux。BSP中的默认分区布局设置为：

+
mtdparts=30bb0000.spi:3840k(u-boot),128k(env),128k(env_redund),-(none)
+
+
+

这是一个预定义的bootloader环境变量，可以在运行时更改。从Linux用户空间，可以通过/dev/mtd<N>设备访问NOR Flash分区，其中<N>是与要访问的NOR Flash分区相关联的MTD设备编号。要找到分区的正确MTD设备编号，请在目标上运行：

+
root@phyboard-pollux-imx8mp-3:~$ mtdinfo --all
+Count of MTD devices:           4
+Present MTD devices:            mtd0, mtd1, mtd2, mtd3
+Sysfs interface supported:      yes
+
+mtd0
+Name:                           u-boot
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          60 (3932160 bytes, 3.7 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:0
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd1
+Name:                           env
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:2
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd2
+Name:                           env_redund
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:4
+Bad blocks are allowed:         false
+Device is writable:             true
+
+mtd3
+Name:                           none
+Type:                           nor
+Eraseblock size:                65536 bytes, 64.0 KiB
+Amount of eraseblocks:          448 (29360128 bytes, 28.0 MiB)
+Minimum input/output unit size: 1 byte
+Sub-page size:                  1 byte
+Character device major/minor:   90:6
+Bad blocks are allowed:         false
+Device is writable:             true
+
+
+

它列出了所有MTD设备及其对应的分区名称。闪存节点在模块DTS中的SPI主节点内定义。SPI节点包含连接到此SPI总线的所有设备，在这种情况下只有SPI NOR Flash。

+

设备树中SPI主节点的定义可以在这里找到：

+

https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L76

+
+
+
+

7.7. GPIOs

+

phyBOARD-Pollux 具有一组专门用于GPIO的引脚。这些引脚直接连接到 i.MX 8M Plus 引脚，并被复用为 GPIO。它们可以直接在 Linux 用户空间中使用。处理器将其 GPIO 组织为5个GPIO组（GPIO1 – GPIO5），每个组包含 32 个GPIO。gpiochip0、gpiochip32、gpiochip64、gpiochip96 和 gpiochip128 是这些内部 i.MX 8M Plus GPIO 组 GPIO1 – GPIO5 的 sysfs 表示。

+

GPIO被标识为GPIO<X>_<Y>（例如：GPIO5_07）。<X>表示GPIO Bank，从1计数到5，而<Y>表示该Bank内的GPIO。<Y>从0计数到31（每个bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo -c gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如从gpiochip0的GPIO 20）：

    +
    target:~$ gpioget -c gpiochip0 20
+
    +
    +
    • +

  • 将gpiochip0上的GPIO 20的值设置为0并退出工具：

    +
    target:~$ gpioset -z -c gpiochip0 20=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <line=value>...
+
+Set values of GPIO lines.
+
+Lines are specified by name, or optionally by offset if the chip option
+is provided.
+Values may be '1' or '0', or equivalently 'active'/'inactive' or 'on'/'off'.
+
+The line output state is maintained until the process exits, but after that
+is not guaranteed.
+
+Options:
+      --banner            display a banner on successful startup
+  -b, --bias <bias>       specify the line bias
+                  Possible values: 'pull-down', 'pull-up', 'disabled'.
+                  (default is to leave bias unchanged)
+      --by-name           treat lines as names even if they would parse as an offset
+  -c, --chip <chip>       restrict scope to a particular chip
+  -C, --consumer <name>   consumer name applied to requested lines (default is 'gpioset')
+  -d, --drive <drive>     specify the line drive mode
+                  Possible values: 'push-pull', 'open-drain', 'open-source'.
+                  (default is 'push-pull')
+  -h, --help              display this help and exit
+  -l, --active-low        treat the line as active low
+  -p, --hold-period <period>
+                  the minimum time period to hold lines at the requested values
+  -s, --strict            abort if requested line names are not unique
+  -t, --toggle <period>[,period]...
+                  toggle the line(s) after the specified period(s)
+                  If the last period is non-zero then the sequence repeats.
+      --unquoted  don't quote line names
+  -v, --version           output version information and exit
+  -z, --daemonize set values then detach from the controlling terminal
+
+Chips:
+    A GPIO chip may be identified by number, name, or path.
+    e.g. '0', 'gpiochip0', and '/dev/gpiochip0' all refer to the same chip.
+
+Periods:
+    Periods are taken as milliseconds unless units are specified. e.g. 10us.
+    Supported units are 's', 'ms', and 'us'.
+
+*Note*
+    The state of a GPIO line controlled over the character device reverts to default
+    when the last process referencing the file descriptor representing the device file exits.
+    This means that it's wrong to run gpioset, have it exit and expect the line to continue
+    being driven high or low. It may happen if given pin is floating but it must be interpreted
+    as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.7.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用 CONFIG_GPIO_SYSFS 后才能支持。要在menuconfig中使 CONFIG_GPIO_SYSFS 可见，必须首先启用选项 CONFIG_EXPERT 。

+

您也可以将此选项添加到您在 Linux 内核源代码 arch/arm64/configs/ 目录下使用的 defconfig 中。例如，我们基于 NXP 的BSP版本，这个defconfig可以是 imx8_phytec_distro.config

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+
+
+
+

7.8. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

这里的 LED 灯包括蓝色的 mmc、绿色的 心跳和红色的 emmc，它们都在 phyBOARD-Pollux 上。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L255

+
+
+

7.9. I²C总线

+

该 i.MX 8M Plus 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 8M Plus 的I²C模块。 本节描述了我们 phyBOARD-Pollux 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

General I²C1 bus configuration (e.g. imx8mp-phycore-som.dtsi): +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L113

+

General I²C2 bus configuration (e.g. imx8mp-phyboard-pollux-rdk.dts) +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L239

+
+
+

7.10. EEPROM

+

在 phyCORE-i.MX8MP 上贴了一个 i2c 接口的 EEPROM 存储。它有两个地址。主 EEPROM 空间（总线：I2C-0 地址：0x51）可以通过 Linux 中的 sysfs 接口访问。主 EEPROM 的前 256 字节和 ID 页（总线：I2C-0 地址：0x59）用于板检测，不可修改。因此，ID 页不能通过 sysfs 接口访问。覆盖保留空间将导致启动问题。

+
+

备注

+

如果您删除了保留的EEPROM空间数据，请联系我们的支持团队！

+
+
+

7.10.1. phyCORE-i.MX8MP 上的I2C EEPROM

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

phyCORE-i.MX8MP SoM上的I2C EEPROM连接到I2C-0总线的I2C地址0x51。可以直接对该设备进行读写操作：

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

要用零填充4KiB的EEPROM（总线：I2C-0 地址：0x51），并保留EEPROM数据，请使用：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM 检测

+

在 phyCORE-i.MX8MP 上配置的I2C EEPROM具有一个可通过I2C地址0x59在i2c0上寻址的独立ID页面，以及一个可通过I2C地址0x51在i2c0上寻址的正常区域。PHYTEC使用这个32字节的数据区域来存储关于SoM的信息，包括PCB版本和配置。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果EEPROM ID页面数据和正常区域的前256个字节被删除，bootloader程序将回退到 phyCORE-i.MX8MP Kit RAM设置，即 2GiB RAM。

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

使用API修订版2数据格式烧写的核心板将在早期启动阶段打印出有关模块的信息。

+

DT representation, e.g. in phyCORE-i.MX 8M Plus file imx8mp-phycore-som.dtsi can be +found in our PHYTEC git: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L201

+
+
+
+

7.11. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC唤醒alarm

+

可以从实时时钟（RTC）发出中断以唤醒系统。该格式使用Unix纪元时间，即自1970年1月1日UTC午夜以来的秒数。要在从挂起到RAM状态后的4分钟唤醒系统，请输入：

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

备注

+

内部唤醒alarm时间将被向上舍入到下一个分钟，因为alarm功能不支持秒。

+
+
+
+

7.11.2. RTC参数

+

实时时钟（RTC）具有一些功能，可以通过 hwclock 工具进行读取和设置。

+
    +

  • 我们可以通过以下方式检查RTC支持的功能：

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    这个值的含义在内核中进行了编码，每个位的定义为：

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • 我们可以通过以下方式检查RTC BSM（Backup Switchover Mode 备份切换模式）：

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • 我们可以通过以下方式设置RTC BSM：

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    BSM位的定义为：

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    小技巧

    +

    您应该将BSM模式设置为DSM或LSM，以便在初始电源不可用时，RTC可以切换到备用电源。请查看 RV-3028 RTC的Datasheet，以了解LSM（电平切换模式）和DSM（直接切换模式）这两个定义的工作模式。

    +
    +
    • +
+

DT representation for I²C RTCs: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L208

+
+
+
+

7.12. USB主控制器

+

i.MX 8M Plus SoC的USB控制器为众多消费类便携设备提供了一种低成本的连接解决方案，实现USB设备之间的数据传输，传输速度可达4 Gbit/s（超高速'SS'）。USB子系统具有两个独立的USB控制器。这两个控制器都能够作为USBDevice或USB Host使用。每个核心都连接到一个USB 3.0物理层（PHY）。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+

DT representation for USB Host: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L380

+
+
+

7.13. CAN FD

+

The phyBOARD-Pollux has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。两个CAN接口显示为can0和can1。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    can0的信息将如下所示：

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+
+

警告

+

mcp2518fd SPI到CAN FD只支持从125kB/s开始的波特率。可以选择更慢的速率，但可能无法正常工作。

+
+

Device Tree CAN configuration of imx8mp-phyboard-pollux-rdk.dts: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L203

+
+
+

7.14. PCIe

+

phyCORE-i.MX 8M Plus 具有一个 Mini-PCIe 插槽。一般来说，PCIe 会自动检测总线上的新设备。在连接设备并启动系统后，您可以使用命令 lspci 查看所有被识别的 PCIe 设备。

+
    +

  • 输入：

    +
    target:~$ lspci -v
+
    +
    +
    • +

  • 你将收到：

    +
    00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
+        Flags: bus master, fast devsel, latency 0, IRQ 218
+        Memory at 18000000 (64-bit, non-prefetchable) [size=1M]
+        Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
+        I/O behind bridge: None
+        Memory behind bridge: 18100000-181fffff [size=1M]
+        Prefetchable memory behind bridge: None
+        [virtual] Expansion ROM at 18200000 [disabled] [size=64K]
+        Capabilities: [40] Power Management version 3
+        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
+        Capabilities: [70] Express Root Port (Slot-), MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [148] L1 PM Substates
+        Kernel driver in use: dwc3-haps
+
+01:00.0 Network controller: Intel Corporation WiFi Link 5100
+        Subsystem: Intel Corporation WiFi Link 5100 AGN
+        Flags: fast devsel
+        Memory at 18100000 (64-bit, non-prefetchable) [disabled] [size=8K]
+        Capabilities: [c8] Power Management version 3
+        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
+        Capabilities: [e0] Express Endpoint, MSI 00
+        Capabilities: [100] Advanced Error Reporting
+        Capabilities: [140] Device Serial Number 00-24-d6-ff-ff-84-0d-1e
+        Kernel modules: iwlwifi
+
    +
    +
    • +
+

在这个例子中，PCIe设备是 英特尔 WiFi Link 5100 。

+

对于PCIe设备，您必须在内核配置中启用正确的驱动程序。例如，这款WLAN卡是由英特尔制造的。必须启用的驱动程序选项名为 CONFIG_IWLWIFI ，可以在内核配置中的 Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimate 下找到。

+
    +

  • In order to activate the driver, follow the instructions from our +Yocto Reference Manual.

    +
      +

    • linux-imx的表示为：virtual/kernel

      • +
    +
    • +
+

对于某些设备，如WLAN卡，需要额外的二进制固件文件。这些固件文件必须放置在 /lib/firmware/ 目录中，才能使用该设备。

+
    +

  • 输入：

    +
    host:~$ scp -r <firmware> root@192.168.3.11:/lib/firmware
+
    +
    +
    • +

  • 例如，如果您尝试启动网络接口：

    +
    target:~$ ip link set up wlp1s0
+
    +
    +
    • +

  • 您将在串口控制台上获得以下输出：

    +
    [   58.682104] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.690822] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.696577] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.831022] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.839679] iwlwifi 0000:01:00.0: L1 Disabled - LTR Disabled
+[   58.845435] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
+[   58.902797] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
+
    +
    +
    • +
+
+

小技巧

+

某些PCIe设备，例如以太网卡，即使没有从 /lib/firmware/ 加载固件文件，也可能正常工作，而你收到了如上输出第一行所示的错误消息。这是因为一些制造商在板卡本身提供了固件作为后备。在这种情况下，设备的行为和输出在很大程度上依赖于制造商的固件。

+
+

Device Tree PCIe configuration of imx8mp-phyboard-pollux-rdk.dts: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L345

+
+
+

7.15. 音频

+

支持的播放设备包括HDMI和PEB-AV-10连接器上的TI TLV320AIC3007音频编解码器（CODEC）IC。在AV连接器上，有一个符合OMTP标准的3.5mm耳机插孔和一个8针排针。8针排针包含单声道扬声器、耳机和line-in信号。

+
+

备注

+

使用PEB-AV-10连接器进行显示输出时，不支持通过HDMI作为音频输出。音频输出设备必须与视频输出设备匹配。

+
+

要检查您的声卡驱动程序是否正确加载以及设备名称，请输入以下命令以查看播放设备：

+
target:~$ aplay -L
+
+
+

或输入录音设备：

+
target:~$ arecord -L
+
+
+
+

7.15.1. Alsamixer

+

要检查声卡的功能，请输入：

+
target:~$ alsamixer
+
+
+

您应该会看到很多选项，因为音频IC具有许多可以测试的功能。通过SSH打开alsamixer的图形界面比通过调试串口打开更易于使用。所有混音点都有单声道或立体声增益控制。"MM"表示该功能被静音（左右输出均为静音），可以通过按' m '切换。您还可以通过按' < ' 左和 ' > '切换右声道输出。使用 tab 键，您可以在播放和录音控制之间切换。

+
+
+

7.15.2. 恢复默认音量

+

一些默认设置存储在 /var/lib/alsa/asound.state 中。您可以使用以下命令保存当前的alsa设置：

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

您可以通过以下方式恢复已保存的alsa设置：

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.15.3. ALSA配置

+

我们的BSP附带一个ALSA配置文件 /etc/asound.conf 。

+

ALSA配置文件可以根据需要进行编辑或删除，它并不是ALSA正常工作所必需的。

+
target:~$ vi /etc/asound.conf
+
+
+

要将PEB-AV-10设置为输出，请将 playback.pcm 从 "dummy" 设置为 "pebav10":

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

如果听不到声音，请将播放设备更改为软件音量控制播放设备，将 playback.pcm 设置为相应的软音量播放设备，例如“softvol_pebav10”。使用alsamixer控制来调整音量级别。

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.15.4. PulseAudio 配置

+

对于使用 Pulseaudio 的应用程序，请检查可用的音频输出设备：

+
target:~$ pactl list short sinks
+
+
+

要选择输出设备，请输入：

+
target:~$ pactl set-default-sink <sink_number>
+
+
+
+
+

7.15.5. 播放

+

运行speaker-test以检查播放功能：

+
target:~$ speaker-test -c 2 -t wav
+
+
+

要播放简单的音频流，您可以使用aplay。例如，要播放ALSA测试音频：

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

要播放其他格式，例如mp3，您可以使用Gstreamer：

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.15.6. 录音

+

arecord 是一个命令行工具，用于录制音频流，默认输入源为线路输入。要选择不同的音频源，可以使用 alsamixer。例如，打开 右侧 PGA 混音器 Mic3R 和 左侧 PGA 混音器 Mic3R，以便通过 3.5mm 插孔录制来自 TLV320 编解码器的麦克风输入音频。

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

提示

+

由于播放和录音共享硬件接口，因此无法在同时进行播放和录音操作时使用不同的采样率和格式。

+
+

Device Tree Audio configuration: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L58

+
+
+
+

7.16. 视频

+
+

7.16.1. 视频与Gstreamer

+

默认情况下，BSP安装了一个示例视频，路径为 /usr/share/qtphy/videos/ 。可以使用以下命令之一开始视频播放：

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.17. 显示

+

该 phyBOARD-Pollux 支持多达3种不同的显示输出。可以同时使用两种。下表显示了不同接口所需的扩展板和设备树overlay。

+ + + + + + + + + + + + + + + + + + + + + +

接口

扩展板

设备树overlay

HDMI

phyBOARD-Pollux

不需要overlay（默认启用）

LVDS0

PEB-AV-10

imx8mp-phyboard-pollux-peb-av-10.dtbo （默认加载）

LVDS1

phyBOARD-Pollux

如果使用PEB-AV-10 overlay，则禁用

+
+

备注

+
    +

  • 在更改Weston输出时，请确保音频输出也相匹配。

    • +

  • LVDS0 (使用PEB-AV-10扩展) 和 LVDS1 (板载) 不能同时使用。

    • +
+
+

HDMI在设备树中始终启用。其他接口可以通过设备树overlay进行启用。

+

默认启用的接口是HDMI和LVDS0（PEB-AV-010）。我们的 PEB-AV-10 支持10英寸edt,etml1010g0dka显示屏。

+
+

备注

+

当前的显示驱动程序将连接到LVDS的LCD的像素时钟限制为74.25MHz（或其分频）。如果这满足不了您的需求，请联系支持团队以获得进一步的帮助。

+
+
+

7.17.1. Weston 配置

+

为了让Weston正确的显示，需要进行正确的配置。这将在/etc/xdg/weston/weston.ini中完成。

+
+

7.17.1.1. 单一显示器

+

在我们的BSP中，默认的Weston输出设置为HDMI。

+
[output]
+name=HDMI-A-1
+mode=preferred
+
+[output]
+name=LVDS-1
+mode=off
+
+
+

当使用LVDS0（PEB-AV-10）作为输出时，将HDMI-A-1的输出模式设置为off，将LVDS-1的输出模式设置为current。

+
[output]
+name=HDMI-A-1
+mode=off
+
+[output]
+name=LVDS-1
+mode=current
+
+
+

如果您想使用LVDS1（板载），则需要去掉overlay。请从bootenv.txt中移除imx8mp-phyboard-pollux-peb-av-xxx.dtbo。

+
+
+

7.17.1.2. 双显示器

+
+

备注

+

对于双显示和三显示输出，您无法同时使用LVDS1（板载）和HDMI。

+
+

在HDMI和LVDS0（PEB-AV-10）的双屏模式下进行双显示时，两个模式必须设置为：

+
[output]
+name=HDMI-A-1
+mode=preferred
+
+[output]
+name=LVDS-1
+mode=current
+
+
+
+
+
+

7.17.2. Qt Demo

+

使用 phytec-qt6demo-image 时，Weston会在启动时启动。我们的Qt6 DEMO应用程序名为“qtphy”，可以通过以下方式停止：

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • 要重新开始Demo，请运行：

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • 要禁用Demo的自动启动，请运行：

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • 要启用Demo的自动启动，请运行：

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston可以通过以下方式停止：

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

备注

+

在关闭Weston之前，必须先关闭Qt Demo。

+
+
+
+

7.17.3. 背光控制

+

如果LCD连接到PHYTEC开发板，可以通过Linux内核的sysfs接口控制其背光。系统中所有可用的背光设备可以在文件夹/sys/class/backlight中找到。读取相应的文件并向其写入数据可以控制背光。

+
+

备注

+

一些具有多显示的开发板在 /sys/class/backlight 有多个背光控制。比如：backlight0和backlight1

+
+
    +

  • 例如，要获取最大亮度级别（max_brightness），请执行：

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    有效的亮度值范围是 0 到 <max_brightness>。

    +
    • +

  • 要获取当前亮度级别，请输入：

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • 写入文件brightness以更改亮度：

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    例如，关闭背光。

    +

    有关所有文件的文档，请参见 https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight。

    +
    • +
+

Device tree description of LVDS-1 and HDMI can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L294 +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L218

+

The device tree of LVDS-0 on PEB-AV-10 can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-peb-av-10.dtso#L133

+
+
+
+

7.18. 电源管理

+
+

7.18.1. CPU核心频率调节

+

i.MX 8M Plus SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。调整频率和电压被称为“动态电压和频率调整”（DVFS）。i.MX 8M Plus BSP支持DVFS功能。Linux内核提供了一个DVFS框架，允许每个CPU核心设置最小或最大频率和一个管理其运行的governor。根据使用的 i.MX 8 型号，支持几种不同的频率。

+
+

小技巧

+

尽管DVFS框架为每个CPU核心提供了频率设置，但一个CPU核心的频率更改会影响其他CPU核心。因此，所有CPU核心始终共享相同的DVFS设置。每个核心的单独DVFS设置是不可能的。

+
+
    +

  • 要获取完整列表，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    例如 i.MX 8MPlus CPU，最高可达约 1.6 GHz，则结果将是：

    +
    1200000 1600000
+
    +
    +
    • +

  • 要查询当前的频率输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

governor 会根据它们的目标自动选择这些频率中的一个。

+
    +

  • 列出所有可用的 governor，使用以下命令：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    结果是：

    +
    conservative ondemand userspace powersave performance schedutil
+
    +
    +
    • +

  • conservative governor 与 ondemand governor 非常相似。只是它的行为有所不同，它会更保守地增减CPU速度，而不是在CPU有任何负载的瞬间就跳到最大速度。

    • +

  • ondemand （默认）根据当前系统负载在可能的CPU核心频率之间切换。当系统负载超过特定值时，它会立即提高CPU核心频率。

    • +

  • powersave 始终选择最低的CPU核心频率。

    • +

  • performance 始终选择最高的CPU核心频率。

    • +

  • userspace 允许以root身份运行的用户或用户空间程序设置特定频率（例如，设置为1600000）。输入：

    • +

  • 要查询当前的 governor，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    您通常会得到：

    +
    ondemand
+
    +
    +
    • +

  • 切换到另一个governor（例如，userspace）可以通过以下方式完成：

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • 现在你可以设置频率：

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

有关governor的更详细信息，请参阅Linux内核代码库中的Linux内核文档，路径为 Documentation/admin-guide/pm/cpufreq.rst 。

+
+
+

7.18.2. CPU核心管理

+

该 i.MX 8M Plus SoC 芯片上可以有多个处理器核心。例如，该 i.MX 8M Plus 具有 4 个 ARM 核心，可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    这里系统有四个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+

7.18.3. 挂起到RAM

+

phyCORE-i.MX8MP 支持基本的挂起和恢复。可以使用不同的唤醒源。挂起/恢复可以通过以下方式实现：

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

要通过串行控制台唤醒，请运行

+
target:~$ echo enabled > /sys/class/tty/ttymxc0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+
+
+
+

7.19. 热管理

+
+

7.19.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.19.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 8M Plus SoC 平台上使用热管理内核 API。 i.MX 8 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个触发点。这些触发点根据CPU型号的不同而有所不同。主要区分工业版和商业版。

+ + + + + + + + + + + + + + + + + +

商业

工业

被动（警告）

85°C

95°C

严重（关机）

90°C

100°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并实施冷却措施。内核中可用的热政策（也称为thermal governor）包括：Step Wise、Fair Share、Bang Bang和Userspace。BSP中使用的默认策略是Step Wise。如果sysfs文件temp中的SoC温度值高于 trip_point_0 ，则CPU频率将设置为最低CPU频率。当SoC温度降到 trip_point_0 以下时，限制将被解除。

+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+

7.19.3. GPIO风扇

+
+

备注

+

Starting with BSP-Yocto-i.MX8MP-PD22.1.1 we have to switch from PWM fan +to GPIO fan due to availability. The PWM fan will not be supported +anymore and will not function with the new release.

+
+

一个GPIO控制的风扇可以连接到 phyBOARD-Pollux-i.MX 8M Plus。该SoC包含一个温度传感器，该传感器被用于热频率调节。风扇无法通过内核进行控制。我们使用lmsensors和hwmon来实现这一点。lmsensors定期读取温度，并在可配置的阈值下启用或禁用风扇。对于 phyBOARD-Pollux-i.MX 8M Plus，这个阈值是60°C。

+

设置可以在配置文件中进行配置：

+
/etc/fancontrol
+
+
+

风扇控制在启动时由systemd服务启动。可以通过以下方式禁用它：

+
target:~$ systemctl disable fancontrol
+
+
+

The device tree description of GPIO Fan can be found here: +https://github.com/phytec/linux-phytec-imx/tree/v6.6.23-2.0.0-phy10/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L35

+
+
+
+

7.20. 看门狗

+

PHYTEC i.MX 8M Plus 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.20.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.21. snvs电源按键

+

连接到开关按钮的 X_ONOFF 引脚可以长按以触发关机，而无需软件干预，或用于唤醒系统以退出挂起状态。使用 snvs_pwrkey 驱动程序时，当按下按钮时，KEY_POWER 事件也会报告给用户空间。默认情况下，systemd 被配置为忽略此类事件。关机而无需软件干预的功能以及从挂起状态唤醒的功能未被配置。可以在 /etc/systemd/logind.conf 中配置按下开/关按钮时通过 systemd 触发关机，配置方法如下：

+
HandlePowerKey=poweroff
+
+
+
+
+

7.22. NPU

+

i.MX 8M Plus SoC包含一个高达2.3 TOPS的人工智能运算加速器。有关NPU的信息，请参考我们最新的phyCORE-i.MX 8M Plus AI套件指南，该指南可以在phyCORE-i.MX 8M Plus 下载部分找到：L-1015e.A1 phyCORE-i.MX 8M Plus AI Kit Guide

+
+
+

7.23. ISP

+

i.MX 8M Plus SoC包含一个图像信号处理器（ISP）。有关更多信息，请参阅|sbc| i.MX 8M Plus 文档中的使用ISP部分。

+
+
+

7.24. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 8M Plus 提供一次性可编程fuse，用于存储信息，例如 MAC 地址、启动配置和其他永久设置（在 i.MX 8M Plus reference manual中称为“片上 OTP 控制器 (OCOTP_CTRL)”）。以下列表摘自 i.MX 8M Plus reference manual，包括 OCOTP_CTRL 中的一些有用寄存器（基地址为0x30350000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为0x30350000

描述

OCOTP_MAC_ADDR0

9

0

0x640

包含ENET0 MAC地址的低32位

OCOTP_MAC_ADDR1

9

1

0x650

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

OCOTP_MAC_ADDR2

9

2

0x660

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 8M Plus Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.24.1. 在uBoot中读取fuse的值

+

您可以使用内存映射的shadow寄存器读取fuse寄存器。要计算内存地址，请使用以下公式计算：

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.24.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+
+

8. i.MX 8M Plus M7 Core

+

除了Cortex-A53核心外，SoC中还集成了一个Cortex-M7 Core 作为MCU。我们的Yocto-Linux-BSP在A53核心上运行，而 M7 Core 可以作为辅助CPU，用于使用裸机或RTOS固件执行额外任务。两种核心都可以访问相同的外设，因此外设的使用需要在 M7 Core 的固件或Linux操作系统的设备树中进行限制。本节将描述如何编译固件示例以及如何在 phyBOARD-Pollux 上运行它们。

+

phyBOARD-Pollux 目前由 NXP MCUXpresso SDK 和 Zephyr 项目支持。本节仅描述 NXP MCUXpresso SDK，因为目前 MCUXpresso SDK 支持的功能更多。

+

如果您想在Zephyr项目中使用 M7 Core ，请参考Zephyr项目文档：

+ +
+

8.1. 获取固件示例

+

固件可以使用NXP MCUxpresso SDK和兼容的编译工具链通过命令行工具进行编译。

+
+

8.1.1. 获取源代码

+

MCUX SDK以及 i.MX 8M Plus 的示例可以从PHYTEC的GitHub页面获取：

+ +
    +

  1. 通过west初始化MCUX SDK：

    +
    host:~$ west init -m https://github.com/phytec/mcux-sdk/ --mr <VERSION> mcuxsdk
+
    +
    +

    这将创建一个 mcuxsdk 目录，并在其中包含 mcux-sdk 仓库。mcux-sdk-phytec-examples 仓库将自动克隆到 mcuxsdk 目录中。给定的参数 <VERSION> 是 mcux-sdk 仓库的分支名称，代表 MCUX SDK 版本。要获取最新的测试版本，您可以使用 2.13.0。

    +
    +

    备注

    +

    west 是一个仓库管理工具，也是 Zephyr 项目的一部分。要安装 west，您可以使用 pip。在这个示例中，west 被安装在一个 Python 虚拟环境中:

    +
    host:~$ sudo apt install python3-venv python3-pip
+host:~$ python3 -m venv west-env
+host:~$ source west-env/bin/activate
+(west-env) host:~$ pip3 install west
+
    +
    +
    +
    2. +

  2. 更新依赖项：

    +
    host:~$ cd mcuxsdk
+host:~/mcuxsdk$ west update
+
    +
    +

    目录 examples-phytec 包含了所有移植并测试过的示例，适用于 phyBOARD-Pollux 和版本为 2.13.0 的 MCUX。

    +

    要编译固件，需要一个编译器工具链和make/cmake。GNU ARM 嵌入式工具链可能在您的主机linux发行版的仓库中可用，例如Ubuntu。

    +
    host:~$ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi make cmake
+
    +
    +

    编译器工具链也可以直接从 https://developer.arm.com/ 获取。在解压缩文件后，必须将 ARMGCC_DIR 添加到环境变量中，例如，对于位于主目录中的 ARM toolchain 10-2020-q4-major 版本：

    +
    host:~$ export ARMGCC_DIR=~/gcc-arm-none-eabi-10-2020-q4-major
+
    +
    +
    3. +
+
+
+

8.1.2. 编译固件

+

要编译PHYTEC示例，需要先设置环境

+
host:~/mcuxsdk$ source scripts/setenv
+
+
+

编译固件的脚本位于 <sdk-directory>/phytec-mcux-boards/phyboard-pollux/<example_category>/<example>/armgcc。每个可运行的内存位置都有相应的编译脚本，例如：

+
host:~$ ./build_release.sh
+
+
+

要编译运行在 M7 Core 的 TCM 上的固件。输出将放置在 armgcc 目录下的 release/ 中。.bin 文件可以在 U-Boot 中运行，而 .elf 文件可以在 Linux 中运行。

+

要编译在DRAM上运行的固件，请运行脚本build_ddr_release。例如。

+
host:~$ ./build_ddr_release.sh
+
+
+

输出将放置在armgcc目录下的ddr_release/中。.bin文件可以在U-Boot中运行，而.elf文件可以在Linux中运行。

+
+
+
+

8.2. 运行 M7 Core 示例

+

有两种方法可以运行 M7 Core 的固件，在Linux中使用Remoteproc以及在U-Boot。

+

要接收调试信息，请在您的主机PC上启动您喜欢的终端软件（例如Minicom、Tio或Tera Term），并将其配置为115200波特率、8个数据位、无奇偶校验和1个停止位（8n1），且不使用握手。

+

一旦Micro USB电缆连接到 phyBOARD-Pollux 上的USB调试端口，就会注册两个ttyUSB设备。一个打印来自A53核心的调试UART的消息，另一个打印来自 M7 Core 的调试UART的消息。

+
+

8.2.1. 从U-Boot运行示例

+

要使用bootloader U-Boot加载固件，可以使用bootaux命令：

+
    +

  1. 准备一张烧写了BSP镜像的SD卡

    2. +

  2. 将生成的 .bin 文件复制到 SD 卡的第一个分区

    3. +

  3. 通过按任意键停止自动启动

    4. +

  4. 根据固件类型输入命令：

    5. +
+

对于在 M7 Core 的TCM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x48000000 firmware.bin;cp.b 0x48000000 0x7e0000 20000;
+u-boot=> bootaux 0x7e0000
+## Starting auxiliary core stack = 0x20020000, pc = 0x000004CD...
+
+
+

用于在DRAM中运行的固件：

+
u-boot=> fatload mmc 1:1 0x80000000 firmware.bin
+u-boot=> dcache flush
+u-boot=> bootaux 0x80000000
+## Starting auxiliary core stack = 0x80400000, pc = 0x80000539...
+
+
+

程序的输出应显示在 M7 Core 的调试UART上。

+
+
+

8.2.2. 通过Remoteproc在Linux上运行示例

+

Remoteproc是一个模块，允许您在运行时从Linux控制 M7 Core 。可以加载为TCM编译的固件，并可以启动或停止执行。要使用Remoteproc，需要设置设备树Overlay：

+

在开发板的/boot目录中编辑bootenv.txt文件，添加 conf-imx8mp-phycore-rpmsg.dtbo ：

+
overlays=conf-imx8mp-phycore-rpmsg.dtbo
+
+
+

重启目标并在U-Boot中执行:

+
u-boot=> run prepare_mcore
+
+
+

M7 Core 的固件 .elf 文件可以在 /lib/firmware 下找到。要加载固件，请输入：

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

要加载不同的固件，M7 Core 需要停止：

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

备注

+

在开发板上找到的 /lib/firmware 中的例子来自NXP的Yocto层meta-imx。要使用您通过MCUX SDK自己编译的样本，请在编译后将它们复制到开发板的 /lib/firmware 中。

+
+
+ +
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mp/pd24.1.1.html b/previews/271/zh_CN/bsp/imx8/imx8mp/pd24.1.1.html new file mode 100644 index 000000000..5de7d5e1c --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mp/pd24.1.1.html @@ -0,0 +1,2768 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + + + + + +

PD24.1.1 i.MX 8M Plus BSP手册

文档标题

PD24.1.1 i.MX 8M Plus BSP手册

文档类型

BSP 手册

型号

PD24.1.1

Yocto 手册

Scarthgap

发布日期

2024/04/08

母文档

PD24.1.1 i.MX 8M Plus BSP手册

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP 发布日期

BSP 状态

PD24.1.1

大版本

2024/04/08

已发布

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 phyCORE-i.MX8M Plus Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads 中找到。

+
+

1.1. 支持的硬件

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 的所有Machine及其对应的Article Numbers(产品型号)： 网页.

+

如果您在“Supported Machines”一栏选择了特定的 Machine Name ，您可以查看该machine下可用的 Article Numbers 以及硬件信息的简短描述。如果您只有硬件的 Article Numbers ，您可以将 Machine Name 下拉菜单留空，仅选择您的 Article Numbers 。现在，它应该会显示您特定硬件所需的 Machine Name

+
+

1.1.1. phyBOARD-Pollux 器件

+
+../../../_images/phyBOARD-Pollux-front-components.jpg + +
+

phyBOARD-Pollux 器件图（顶部）

+
+
+
+../../../_images/phyBOARD-Pollux-back-components.jpg + +
+

phyBOARD-Pollux 器件图（底部）

+
+
+
+
+
+
+

2. 开始使用

+

该 phyCORE-i.MX8M Plus Kit 包含预先烧写好的SD卡。它包含 phytec-qt6demo-image 镜像，可以直接用作启动盘。默认情况下，核心板上的eMMC仅烧写了U-Boot。您可以从 PHYTEC下载服务器 获取所有镜像资源。本章将解释如何将BSP镜像烧写到SD卡以及如何启动开发板。

+

有几种方法可以将镜像写入SD卡或eMMC。最为人熟知的方式是使用Linux命令行工具 dd 进行简单的顺序写入。另一种方法是使用PHYTEC的自研程序 partup ，它可以让格式化复杂系统的过程变得简单。您可以从其发布页面获取 预编译的Linux partup 二进制文件 。请阅读 partup的readme文件 来获取安装指导。

+
+

2.1. 下载镜像

+

phytec-qt6demo-image 镜像包含完整系统所需的所有必要文件，您需确保镜像中各个分区以及裸数据都会被正确写入启动盘。可以从 PHYTEC 下载服务器 下载 partup 镜像文件或者是可以使用 dd 进行烧写的 WIC 镜像。

+

从下载服务器获取 partup 镜像文件或WIC镜像：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
+
+
+

备注

+

针对eMMC，我们建议使用partup去烧写比较大的或者是有复杂分区配置的镜像，因为它在写入速度上比 dd 更快，并且可以对闪存设备进行更灵活的配置。

+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要创建SD卡启动盘，必须要拥有Linux PC上的root权限。在选择烧写设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+
+

2.2.1. 寻找正确的设备

+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行命令：

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+

卸载所有这些分区，例如：

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

现在，SD卡已经准备好可以使用 partup 、 dd 或 bmap-tools 来写入镜像。

+
+
+

2.2.2. 使用bmap-tools

+

烧写SD卡的其中一种方法是使用 bmap-tools 。Yocto会自动为WIC镜像创建一个block map文件（ <IMAGENAME>-<MACHINE>.wic.bmap ），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host:~$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic /dev/<your_device>
+
+
+

将 <your_device> 替换为您之前找到的SD卡设备名称，并确保将文件 <IMAGENAME>-<MACHINE>.wic.bmap 与WIC镜像文件放在一起，以便bmaptool知道哪些块需要写入，哪些块需要跳过。

+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.2.3. 使用partup

+

使用partup烧写SD卡只需一个命令：

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup /dev/<your_device>
+
+
+

确保将 <your_device> 替换为您之前找到的设备名称。

+

关于partup的进一步使用说明，请参阅其 官方文档 。

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 release notes 。

+
+
+

备注

+

partup 具有清除eMMC user区域中特定区域的功能，我们提供的partup程序中用该功能擦除U-Boot环境变量。这是 bmaptool 工具所无法完成的一点，如前一部分所提到的。

+

partup相较于其他烧写工具的一个主要优势是，它可以配置MMC的特定部分，比如他可以直接写入eMMCboot分区，无需调用其他命令。

+
+
+
+

2.2.4. 使用 dd

+

在卸载所有SD卡的挂载分区后，您可以烧写SD卡。

+

一些PHYTEC BSP会生成未压缩的镜像（文件名扩展名为*.wic），而另一些则生成压缩的镜像（文件名扩展名为*.wic.xz）。

+

要写入未压缩的镜像（*.wic），请使用以下命令：

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

或者要写入压缩后的镜像（*.wic.xz），请使用以下命令：

+
host:~$ xzcat phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

再次确保将 <your_device> 替换为之前找到的设备名称。

+

参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

+
+
+
+

2.3. 首次启动

+ +../../../_images/SD_Card_Boot1.png +
    +

  • 插入SD卡

    • +

  • 使用 micro USB 线将开发板的 (X1) 调试USB口和主机连接起来

    • +

  • 给开发板通电

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (scarthgap).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (scarthgap).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-IMX8MP ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-xwayland MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 phyboard-pollux-imx8mp-3 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx8mp.bin: ARM可信固件二进制文件

    • +

  • lpddr4_pmu_train_1d_dmem_202006.bin, lpddr4_pmu_train_1d_imem_202006.bin, lpddr4_pmu_train_2d_dmem_202006.bin, lpddr4_pmu_train_2d_imem_202006.bin：DDR PHY固件镜像

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx8mp-phyboard-pollux-rdk*.dtb: 内核设备树文件

    • +

  • phytec-qt6demo-image*.tar.gz: 根文件系统

    • +

  • phytec-qt6demo-image*.wic: SD卡镜像

    • +
+
+
+
+
+

4. 安装操作系统

+
+

4.1. 启动模式开关 (S3)

+
+

小技巧

+

硬件修订版底板：1552.2

+
+

该 phyBOARD-Pollux 具有一个（启动源配置）开关，配有四个可单独切换的位，用于选择phyCORE-i.MX 8M Plus 默认的启动源。

+ + + + + + + + + + + +
+../../../_images/eMMC1.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses1.png +
+

内部fuse

+
+
+
+../../../_images/SPI_NOR.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download1.png +
+

USB

+
+
+
+../../../_images/SD_Card_Boot1.png +
+

SD卡

+
+
+
+../../../_images/Test_Mode.png +
+

测试模式

+
+
+
+
+
+

4.2. 烧写eMMC

+

要从 eMMC 启动，请确保 BSP 镜像已正确烧写到 eMMC，并且 bootmode switch (S3) 设置为 eMMC。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行上述命令来检查系统启动在这种条件下是否会到影响。如果 mmcblk2p1 和 mmcblk1p1 具有相同的UUID，则会影响系统正确启动。

+
+
+

4.2.1. 从网络烧写 eMMC

+

i.MX 8M Plus 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

4.2.1.1. 在开发板的U-Boot中通过网络烧写eMMC

+

这些步骤将展示如何通过网络更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+
    +

  • 通过网络将您的镜像加载到内存中：

    +
    u-boot=> dhcp ${loadaddr} phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.11 (101 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • 将镜像写入eMMC：

    +
    u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +
+
+
+

4.2.1.2. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

使用一条命令，通过网络ssh协议将带有块映射的压缩或未压缩的镜像发送到开发板的eMMC上使用,执行：

+
target:~$ ssh <USER>@192.168.3.10 "dd if=<path_to_file>/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic" | dd of=/dev/mmcblk2 conv=fsync
+
+
+
+
+

4.2.1.3. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

查看主机上可用的镜像文件：

+
host:~$ ls
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
+
+

通过网络使用 dd 命令结合ssh将镜像发送到您设备的eMMC：

+
host:~$ dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk2 conv=fsync"
+
+
+
+
+
+

4.2.2. 在运行的U-Boot中通过网络烧写eMMC U-Boot镜像

+

可以在U-Boot中更新U-Boot镜像imx-boot，eMMC上的U-Boot需要位于eMMC的user区域。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> dhcp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.3. 从USB烧写eMMC

+
+

4.2.3.1. 在开发板的U-Boot环境中从USB烧写eMMC

+
+

备注

+

在U-Boot中只能使用下方的USB-A端口来连接优盘。

+
+
+

小技巧

+

此步骤仅在镜像文件小于1GB的情况下会被执行成功，因为在启用OPTEE后，Bootloader中可用的RAM大小有限，不足以加载超过1GB的镜像

+
+

下面这些步骤展示如何通过USB设备更新eMMC。将|ref-bootswitch| 配置为SD卡启动，并插入SD卡。给开发板上电并进入U-Boot环境。将已存储了未压缩WIC镜像的优盘插入开发板USB接口。

+

将镜像从USB设备加载到RAM中：

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} *.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. 在运行的Linux系统中从USB烧写eMMC

+

下面这些步骤展示如何在Linux系统上使用USB大容量存储设备烧写eMMC。您只需要一个保存在USB优盘上的完整镜像和一个可引导的WIC镜像。（例如：phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic）。将 bootmode switch (S3) 设置为SD卡。

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ cd /mnt
+target:~$ ls
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
    +
    +
    • +

  • 显示可用的MMC设备列表：

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • eMMC设备的特征是它包含两个boot分区：(mmcblk2boot0; mmcblk2boot1)

    • +

  • 将镜像写入 phyCORE-i.MX 8M Plus eMMC（无分区的 MMC 设备 2）：

    +
    target:~$ dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic of=/dev/mmcblk2 conv=fsync
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    小技巧

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+
+

4.2.4. 从SD卡烧写eMMC

+

即使没有可用的网络，您也可以更新eMMC。为此，您需要一个位于SD卡上的镜像文件（ *.wic ）。由于镜像文件相当大，您需要在SD卡创建第三个分区。要创建新分区或扩展您的SD卡，请参见 Resizing ext4 Root Filesystem 。

+

或者，使用partup包烧写SD卡，如 Getting Started 中所述。这样就可使用SD卡的全部容量。

+
+

4.2.4.1. 在开发板的uboot环境中通过SD卡烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1GB的情况下有效，因为在启用OPTEE后，Bootloader中可用的RAM大小有限。如果镜像文件过大，请阅读 在开发板上通过SD卡更新eMMC 一节

+
+
    +

  • 将一个可用的镜像烧写到SD卡，并创建一个FAT格式的第三分区。将WIC镜像（例如 phytec-qt6demo-image.rootfs.wic）复制到该分区。

    • +

  • 将 bootmode switch (S3) 配置为 SD 卡并插入 SD 卡。

    • +

  • 打开电源并进入U-Boot。

    • +

  • 加载镜像：

    +
    u-boot=> fatload mmc 1:3 ${loadaddr} phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • 将当前mmc设备切换到eMMC：

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • 将您的WIC镜像（例如 phytec-qt6demo-image.rootfs.wic）从SD卡烧写到eMMC。这将对卡进行分区，并将imx-boot、Image、dtb、dtbo和根文件系统复制到eMMC。

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • 关闭电源并将 bootmode switch (S3) 更改为 eMMC。

    • +
+
+
+

4.2.4.2. 在开发板的linux环境中通过SD卡烧写eMMC

+

您也可以在Linux系统中烧写eMMC。您只需要一个partup包或保存在SD卡上的WIC镜像。

+
    +

  • 检查在SD卡上保存的partup包或WIC镜像文件：

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
    +
    +
    • +

  • 显示可用的MMC设备列表：

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk2
+mmcblk2boot0
+mmcblk2boot1
+mmcblk2p1
+mmcblk2p2
+mmcblk2rpmb
+
    +
    +
    • +

  • eMMC设备的特征是它包含两个boot分区：(mmcblk2 boot0; mmcblk2 boot1)

    • +

  • 使用 partup 将镜像写入 phyCORE-i.MX 8M Plus 的 eMMC（MMC 设备 2 不带 分区字样）：

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup /dev/mmcblk2
+
    +
    +

    使用partup烧写的优点是可以充分利用eMMC设备的全部容量，会相应自动调整分区大小。

    +
    +

    备注

    +

    另外，也可以使用 dd 命令：

    +
    target:~$ dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic of=/dev/mmcblk2 conv=fsync
+
    +
    +

    请注意，在使用 dd 进行烧写时，root分区并没有使用全部存储容量。

    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    警告

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+
+
+

4.3. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC：L-1006e.A6 RAUC更新与设备管理手册。

+
+
+
+

5. 开发

+
+

5.1. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.1.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.2. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.2.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核镜像复制到您的tftp目录中：

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • 将设备树复制到您的tftp目录：

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.2.2. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.3.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. 获取镜像

+

从我们的服务器下载imx-boot，或者从你的Yocto编译目录中的build/deploy/images/phyboard-pollux-imx8mp-3/获取它。为了将wic镜像烧写到eMMC，你还需要 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic

+
+
+

5.3.3. 开发板准备

+

将 bootmode switch (S3) 设置为 USB串行下载。同时，将 USB 端口 X5 (upper connector) 连接到主机。

+
+
+

5.3.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 (X1) 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.3.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
+
+
+
+
+

5.4. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone https://github.com/phytec/u-boot-phytec.git）

+
+
+

5.4.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    https://github.com/phytec/u-boot-phytec.git
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-phytec 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    https://github.com/phytec/linux-phytec.git
+
    +
    +
    • +

  • 我们的 i.MX 8M Plus 内核是基于 linux-phytec 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
recipes-kernel/linux/linux-phytec_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-phytec_*.bb
+
+
+
+
+
+

5.4.2. 编译SDK

+

您可以使用Yocto自行编译SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+
+
+

5.4.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-4.3.sh
+host:~$ ./phytec-ampliphy-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-4.3.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-xwayland/4.3):
+You are about to install the SDK to "/opt/ampliphy-xwayland/4.3". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-xwayland/4.3/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. 单独编译U-Boot

+
+

5.5.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone https://github.com/phytec/u-boot-phytec.git
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本中使用的**tag**称为 v2024.01-phy3

    • +

  • 查看所需的 U-Boot tag：

    +
    host:~$ cd ~/u-boot-phytec/
+host:~/u-boot-phytec$ git fetch --all --tags
+host:~/u-boot-phytec$ git checkout tags/v2024.01-phy3
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/u-boot-phytec$ source /opt/ampliphy-xwayland/4.3/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. 获取所需的二进制文件

+

要编译bootloader，您需要将这些文件复制到您的 u-boot-phytec 编译目录，并将其重命名以适应 mkimage 脚本：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx8mp.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以在yocto工程目录中获取 bl31-imx8mp.bin、tee.bin和lpddr4_*.bin：BSP Images

+

或者你可以在这里下载文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/

+
+

警告

+

确保您重命名所需的文件，以和 mkimage tool 兼容。

+
+
+
+

5.5.3. 编译bootloader

+
    +

  • 编译 flash.bin (imx-boot):

    +
    host:~/u-boot-phytec$ make phycore-imx8mp_defconfig
+host:~/u-boot-phytec$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. 将bootloader烧写到块设备上

+

flash.bin 文件可以在 u-boot-phytec/ 目录下找到，现在可以进行烧写。需要指定芯片特定的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

例如，烧写SD卡：

+
host:~/u-boot-phytec$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+
+

5.6. 单独编译内核

+
+

5.6.1. 配置源代码

+
    +

  • 使用的 linux-phytec 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v6.6.21-phy1

    • +

  • Check out 所需的 linux-phytec 标签：

    +
    host:~$ git clone https://github.com/phytec/linux-phytec.git
+host:~$ cd ~/linux-phytec/
+host:~/linux-phytec$ git fetch --all --tags
+host:~/linux-phytec$ git checkout tags/v6.6.21-phy1
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-phytec$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-phytec$ source /opt/ampliphy-xwayland/4.3/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-phytec$ make defconfig
+host:~/linux-phytec$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-phytec$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-phytec/arch/arm64/boot/Image 找到

    • +

  • dtb文件可以在 ~/linux-phytec/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-phytec$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. 将内核复制到SD卡

+

内核及module和对应的设备树二进制文件可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-phytec$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-phytec$ cp arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb /path/to/sdcard/boot/oftree
+host:~/linux-phytec$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. 获取BSP开发中版本

+
+

5.7.1. 当前release的开发中版本

+

这些release manifest文件是为了让您访问 Yocto BSP的开发版本。它们不会在phyLinux选择菜单中显示，需要手动选择。可以使用以下命令行来完成此操作：

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1
+
+
+

这将初始化一个BSP，用于跟踪当前版本（ BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 ）的最新开发版本。从现在开始，在此文件夹中执行 repo sync 将从我们的Git仓库中拉取所有最新的更改：

+
host:~$ repo sync
+
+
+
+
+

5.7.2. 即将发布版本的开发中版本

+

即将发布版本的开发中版本可以通过这种方式访问。请执行以下命令，并查找一个比最新版本（ BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1 ）的PDXX.Y数字更高的版本，并且以 .y 结尾：

+
host:~$ ./phyLinux init -p imx8mp
+
+
+
+
+
+

5.8. 获取最新的Upstream支持

+

我们有一个使用Yocto主分支（不是NXP发布的）的manifest，他使用upstream的Linux和U-Boot。这可以用来测试最新的upstream kernel/U-Boot。

+
+

备注

+

master分支的manifest反映了最新的开发状态。有时会出现一些bug。我们会定期修复master分支。

+
+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.9.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将例如 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将例如 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic 镜像复制到其中。然后再次卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 8M Plus 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Board.dts - 包含module dtsi 文件。从SoC i.MX 8M Plus 引出并在底板使用的设备也包含在此 dts 中。

    • +

  • Overlay.dtso - 根据核心板或底板上可选硬件（例如 SPI 闪存或 PEB-AV-10）的情况来启用/禁用一些功能。

    • +
+

在Linux内核的根目录下，我们的 i.MX 8 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。下面是扩展板的硬件描述。对比源码中的include，overlay通过覆盖的方式来生效。overlay也可以根据实际开发板的硬件配置来设置设备树节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/ 中。

+

phyboard-pollux-imx8mp-3.conf 可用的overlay文件有：

+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 8M Plus BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 8M Plus BSP设备树概念部分，以了解我们的 i.MX 8 BSP设备树模型。

+

以下部分概述了 i.MX 8 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 8M Plus 引脚复用

+

该 i.MX 8M Plus Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 8M Plus 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 8M Plus 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是 imx8mp-phyboard-pollux-rdk.dts中UART1设备的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x140
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x140
+        >;
+};
+
+
+

字符串的第一部分 MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 指定了引脚（在这个例子中是 UART1_RXD）。字符串的第二部分（UART1_DCE_RX）是该引脚所选的复用项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部拉电阻是否被激活。在当前情况下，内部拉电阻被禁用。

+

UART1引脚复用的设备树：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L387

+
+
+

7.2. RS232/RS485

+

phyCORE-i.MX 8M Plus 支持最多 4 个 UART 单元。在 phyBOARD-Pollux 上，UART1（调试串口）和 UART4 的 TTL 电平信号被连接到 Silicon Labs CP2105 UART 到 USB 转换IC。这个 USB 信号通过 Micro-USB 连接器 X1 输出。UART3 位于 X6（扩展连接器），为 TTL 电平信号。UART2 连接到一个多协议收发器IC，可转换为 RS-232 或 RS-485，RS-232 和 RS-485 信号位于连接器 X2 。多协议配置通过主板上的跳线 JP3 和 JP4 完成。更多信息，请参阅 phyCORE-i.MX 8M Plus/phyBOARD-Pollux 硬件手册中的 UARTs 部分。

+

对于RS-232和RS-485，使用相同的设备树节点。RS485模式可以通过ioctl TIOCSRS485 来启用。双向通讯支持也可以通过ioctl进行配置。请查看我们的小示例应用程序rs485test，该程序也包含在BSP中。需要设置跳线 JP3 和 JP4 。

+
+

7.2.1. RS232

+
    +

  • 以人类可读的格式显示终端的当前设置：

    +
    target:~$ stty -a
+
    +
    +
    • +

  • UART接口的配置可以通过stty命令完成。例如：

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • 通过简单的echo和cat，可以测试基本的通信。示例：

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

主机应打印出 "123"。

+
+
+

7.2.2. RS485

+
+

提示

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

为了方便测试，请查看linux-serial-test。这个工具会通过调用RS485的IOCTL，发送恒定的数据流。

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

有关linux-serial-test工具及其参数的更多信息，请访问此链接：linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Linux kernel文档描述了如何在C代码中调用IOCTL： https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+

RS232和RS485的设备树： https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L251

+
+
+
+

7.3. 网络

+

phyBOARD-Pollux-i.MX 8M Plus 提供两个以太网接口。我们的核心板和底板各提供一个千兆以太网接口。

+
+

警告

+

硬件中的以太网接口命名约定（ethernet0 和 ethernet1）与Linux中的网络接口（eth0 和 eth1）不一致。因此，请注意这些差异：

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L41。

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Pollux can be found here: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L106

+
+

7.3.1. 网络配置

+
+

7.3.1.1. U-boot网络环境

+
    +

  • 我们目前在U-Boot中使用动态IP地址。这是通过以下这个变量启用的：

    +
    +
    u-boot=> printenv ip_dyn
+ip_dyn=yes
+
    +
    +
    +
    • +

  • 设置NFS的路径。一个示例如下：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+
+

7.3.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+
+

7.4. SD/MMC 卡

+

该 i.MX 8M Plus 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

MMC（SD卡插槽）接口的设备树：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L261

+

eMMC接口的DT配置：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L181

+
+
+

7.5. eMMC设备

+

PHYTEC模块如phyCORE-i.MX 8M Plus 配备了eMMC存储芯片作为主要存储。eMMC设备使用多层单元（MLC）或三层单元（TLC）技术来实现存储，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 8M Plus ，并在Linux内核中作为块设备表示，如SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.5.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），该层负责处理原始MLC或TLC的磨损均衡、块管理和错误更正码（ECC）。这需要定期执行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 通过以下命令使能BKOPS_EN：

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.5.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 8M Plus SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.5.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
+
+

7.5.5. 启用伪SLC模式

+

eMMC设备使用 MLC或TLC 来存储数据。与NAND Flash中使用的SLC相比，MLC或TLC在成本更低的情况下，可靠性较低且错误率较高。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. 擦除设备

+

可以直接擦除eMMC设备，而不是通过写零覆盖。eMMC块管理算法将擦除底层的MLC或TLC，或者将这些块标记为可丢弃。设备上的数据将丢失，并将被读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.5.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 8M Plus 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.5.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

下表是 i.MX 8M Plus SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.6. SPI主设备

+

i.MX 8M Plus 控制器包含一个 FlexSPI 和一个 ECSPI IP 核。FlexSPI 主控制器支持两个 SPI 通道，最多可连接 4 个设备。每个通道支持单通道/双通道/四通道/八通道模式的数据传输（1/2/4/8 条数据线）。ECSPI 控制器支持 3 个 SPI 接口，每个接口都有一个专用的CS（chip select）引脚。由于CS也可通过 GPIO 实现，因此每个通道上可以连接多个设备。

+

在设备树中，SPI主节点的定义：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L67

+
+
+

7.7. GPIOs

+

phyBOARD-Pollux 具有一组专门用于GPIO的引脚。这些引脚直接连接到 i.MX 8M Plus 引脚，并被复用为 GPIO。它们可以直接在 Linux 用户空间中使用。处理器将其 GPIO 组织为5个GPIO组（GPIO1 – GPIO5），每个组包含 32 个GPIO。gpiochip0、gpiochip32、gpiochip64、gpiochip96 和 gpiochip128 是这些内部 i.MX 8M Plus GPIO 组 GPIO1 – GPIO5 的 sysfs 表示。

+

GPIO被标识为GPIO<X>_<Y>（例如：GPIO5_07）。<X>表示GPIO Bank，从1计数到5，而<Y>表示该Bank内的GPIO。<Y>从0计数到31（每个bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo -c gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如从gpiochip0的GPIO 20）：

    +
    target:~$ gpioget -c gpiochip0 20
+
    +
    +
    • +

  • 将gpiochip0上的GPIO 20的值设置为0并退出工具：

    +
    target:~$ gpioset -z -c gpiochip0 20=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <line=value>...
+
+Set values of GPIO lines.
+
+Lines are specified by name, or optionally by offset if the chip option
+is provided.
+Values may be '1' or '0', or equivalently 'active'/'inactive' or 'on'/'off'.
+
+The line output state is maintained until the process exits, but after that
+is not guaranteed.
+
+Options:
+      --banner            display a banner on successful startup
+  -b, --bias <bias>       specify the line bias
+                  Possible values: 'pull-down', 'pull-up', 'disabled'.
+                  (default is to leave bias unchanged)
+      --by-name           treat lines as names even if they would parse as an offset
+  -c, --chip <chip>       restrict scope to a particular chip
+  -C, --consumer <name>   consumer name applied to requested lines (default is 'gpioset')
+  -d, --drive <drive>     specify the line drive mode
+                  Possible values: 'push-pull', 'open-drain', 'open-source'.
+                  (default is 'push-pull')
+  -h, --help              display this help and exit
+  -l, --active-low        treat the line as active low
+  -p, --hold-period <period>
+                  the minimum time period to hold lines at the requested values
+  -s, --strict            abort if requested line names are not unique
+  -t, --toggle <period>[,period]...
+                  toggle the line(s) after the specified period(s)
+                  If the last period is non-zero then the sequence repeats.
+      --unquoted  don't quote line names
+  -v, --version           output version information and exit
+  -z, --daemonize set values then detach from the controlling terminal
+
+Chips:
+    A GPIO chip may be identified by number, name, or path.
+    e.g. '0', 'gpiochip0', and '/dev/gpiochip0' all refer to the same chip.
+
+Periods:
+    Periods are taken as milliseconds unless units are specified. e.g. 10us.
+    Supported units are 's', 'ms', and 'us'.
+
+*Note*
+    The state of a GPIO line controlled over the character device reverts to default
+    when the last process referencing the file descriptor representing the device file exits.
+    This means that it's wrong to run gpioset, have it exit and expect the line to continue
+    being driven high or low. It may happen if given pin is floating but it must be interpreted
+    as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.7.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用 CONFIG_GPIO_SYSFS 后才能支持。要在menuconfig中使 CONFIG_GPIO_SYSFS 可见，必须首先启用选项 CONFIG_EXPERT 。

+

您也可以将此选项添加到您在 Linux 内核源代码 arch/arm64/configs/ 目录下使用的 defconfig 中。例如，我们基于 NXP 的BSP版本，这个defconfig可以是 imx8_phytec_distro.config

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+
+
+
+

7.8. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

这里的 LED 灯包括蓝色的 mmc、绿色的 心跳和红色的 emmc，它们都在 phyBOARD-Pollux 上。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

GPIO的设备树配置：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L160

+
+
+

7.9. I²C总线

+

该 i.MX 8M Plus 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 8M Plus 的I²C模块。 本节描述了我们 phyBOARD-Pollux 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

I²C1 总线DT配置（例如 imx8mp-phycore-som.dtsi）： https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L81

+

I²C2总线DT配置（例如 imx8mp-phyboard-pollux-rdk.dts）： https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L145

+
+
+

7.10. EEPROM

+

在 phyCORE-i.MX8MP 上贴了一个 i2c 接口的 EEPROM 存储。它有两个地址。主 EEPROM 空间（总线：I2C-0 地址：0x51）可以通过 Linux 中的 sysfs 接口访问。主 EEPROM 的前 256 字节和 ID 页（总线：I2C-0 地址：0x59）用于板检测，不可修改。因此，ID 页不能通过 sysfs 接口访问。覆盖保留空间将导致启动问题。

+
+

备注

+

如果您删除了保留的EEPROM空间数据，请联系我们的支持团队！

+
+
+

7.10.1. phyCORE-i.MX8MP 上的I2C EEPROM

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

phyCORE-i.MX8MP SoM上的I2C EEPROM连接到I2C-0总线的I2C地址0x51。可以直接对该设备进行读写操作：

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

要用零填充4KiB的EEPROM（总线：I2C-0 地址：0x51），并保留EEPROM数据，请使用：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM 检测

+

在 phyCORE-i.MX8MP 上配置的I2C EEPROM具有一个可通过I2C地址0x59在i2c0上寻址的独立ID页面，以及一个可通过I2C地址0x51在i2c0上寻址的正常区域。PHYTEC使用这个32字节的数据区域来存储关于SoM的信息，包括PCB版本和配置。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果EEPROM ID页面数据和正常区域的前256个字节被删除，bootloader程序将回退到 phyCORE-i.MX8MP Kit RAM设置，即 2GiB RAM。

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

使用API修订版2数据格式烧写的核心板将在早期启动阶段打印出有关模块的信息。

+

核心板 phyCORE-i.MX 8M Plus 的设备树imx8mp-phycore-som.dtsi可以在PHYTEC git中找到： https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L169

+
+
+
+

7.11. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC参数

+

实时时钟（RTC）具有一些功能，可以通过 hwclock 工具进行读取和设置。

+
    +

  • 我们可以通过以下方式检查RTC支持的功能：

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    这个值的含义在内核中进行了编码，每个位的定义为：

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • 我们可以通过以下方式检查RTC BSM（Backup Switchover Mode 备份切换模式）：

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • 我们可以通过以下方式设置RTC BSM：

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    BSM位的定义为：

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    小技巧

    +

    您应该将BSM模式设置为DSM或LSM，以便在初始电源不可用时，RTC可以切换到备用电源。请查看 RV-3028 RTC的Datasheet，以了解LSM（电平切换模式）和DSM（直接切换模式）这两个定义的工作模式。

    +
    +
    • +
+

I²C RTCs 的设备树：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L175

+
+
+
+

7.12. USB主控制器

+

i.MX 8M Plus SoC的USB控制器为众多消费类便携设备提供了一种低成本的连接解决方案，实现USB设备之间的数据传输，传输速度可达4 Gbit/s（超高速'SS'）。USB子系统具有两个独立的USB控制器。这两个控制器都能够作为USBDevice或USB Host使用。每个核心都连接到一个USB 3.0物理层（PHY）。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+

USB Host的设备树：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L220

+
+
+

7.13. CAN FD

+

The phyBOARD-Pollux has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。两个CAN接口显示为can0和can1。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    can0的信息将如下所示：

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+
+

警告

+

mcp2518fd SPI到CAN FD只支持从125kB/s开始的波特率。可以选择更慢的速率，但可能无法正常工作。

+
+

Device Tree CAN configuration of imx8mp-phyboard-pollux-rdk.dts: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L130

+
+
+

7.14. 视频

+
+

7.14.1. 视频与Gstreamer

+

默认情况下，BSP安装了一个示例视频，路径为 /usr/share/qtphy/videos/ 。可以使用以下命令之一开始视频播放：

+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink fullscreen=true
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+

备注

+

Mainline BSP目前仅支持软件渲染。

+
+
+
+
+

7.15. 显示

+

phyBOARD-Pollux 通过开发板上的LVDS1连接器支持LVDS输出。LVDS接口默认启用。

+
+

7.15.1. Weston 配置

+

Weston可以在无需额外配置的情况下运行。配置选项位于 /etc/xdg/weston/weston.ini。

+

LVDS的设备树：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L182

+
+
+

7.15.2. Qt Demo

+

使用 phytec-qt6demo-image 时，Weston会在启动时启动。我们的Qt6 DEMO应用程序名为“qtphy”，可以通过以下方式停止：

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • 要重新开始Demo，请运行：

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • 要禁用Demo的自动启动，请运行：

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • 要启用Demo的自动启动，请运行：

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston可以通过以下方式停止：

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

备注

+

在关闭Weston之前，必须先关闭Qt Demo。

+
+
+
+

7.15.3. 背光控制

+

如果LCD连接到PHYTEC开发板，可以通过Linux内核的sysfs接口控制其背光。系统中所有可用的背光设备可以在文件夹/sys/class/backlight中找到。读取相应的文件并向其写入数据可以控制背光。

+
+

备注

+

一些具有多显示的开发板在 /sys/class/backlight 有多个背光控制。比如：backlight0和backlight1

+
+
    +

  • 例如，要获取最大亮度级别（max_brightness），请执行：

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    有效的亮度值范围是 0 到 <max_brightness>。

    +
    • +

  • 要获取当前亮度级别，请输入：

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • 写入文件brightness以更改亮度：

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    例如，关闭背光。

    +

    有关所有文件的文档，请参见 https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight。

    +
    • +
+
+

备注

+

我们注意到在亮度级别1上有一些明显的背光闪烁（可能是由于硬件频率问题导致的）。

+
+
+
+
+

7.16. 电源管理

+
+

7.16.1. CPU核心频率调节

+

i.MX 8M Plus SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。调整频率和电压被称为“动态电压和频率调整”（DVFS）。i.MX 8M Plus BSP支持DVFS功能。Linux内核提供了一个DVFS框架，允许每个CPU核心设置最小或最大频率和一个管理其运行的governor。根据使用的 i.MX 8 型号，支持几种不同的频率。

+
+

小技巧

+

尽管DVFS框架为每个CPU核心提供了频率设置，但一个CPU核心的频率更改会影响其他CPU核心。因此，所有CPU核心始终共享相同的DVFS设置。每个核心的单独DVFS设置是不可能的。

+
+
    +

  • 要获取完整列表，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    例如 i.MX 8MPlus CPU，最高可达约 1.6 GHz，则结果将是：

    +
    1200000 1600000
+
    +
    +
    • +

  • 要查询当前的频率输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

governor 会根据它们的目标自动选择这些频率中的一个。

+
    +

  • 列出所有可用的 governor，使用以下命令：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    结果是：

    +
    ondemand userspace performance schedutil
+
    +
    +
    • +

  • ondemand （默认）根据当前系统负载在可能的CPU核心频率之间切换。当系统负载超过特定值时，它会立即提高CPU核心频率。

    • +

  • performance 始终选择最高的CPU核心频率。

    • +

  • userspace 允许以root身份运行的用户或用户空间程序设置特定频率（例如，设置为1600000）。输入：

    • +

  • 要查询当前的 governor，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    您通常会得到：

    +
    schedutil
+
    +
    +
    • +

  • 切换到另一个governor（例如，userspace）可以通过以下方式完成：

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • 现在你可以设置频率：

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

有关governor的更详细信息，请参阅Linux内核代码库中的Linux内核文档，路径为 Documentation/admin-guide/pm/cpufreq.rst 。

+
+
+

7.16.2. CPU核心管理

+

该 i.MX 8M Plus SoC 芯片上可以有多个处理器核心。例如，该 i.MX 8M Plus 具有 4 个 ARM 核心，可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    这里系统有四个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+
+

7.17. 热管理

+
+

7.17.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.17.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 8M Plus SoC 平台上使用热管理内核 API。 i.MX 8 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个触发点。这些触发点根据CPU型号的不同而有所不同。主要区分工业版和商业版。

+ + + + + + + + + + + + + + + + + +

商业

工业

被动（警告）

85°C

95°C

严重（关机）

90°C

100°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并实施冷却措施。内核中可用的热政策（也称为thermal governor）包括：Step Wise、Fair Share、Bang Bang和Userspace。BSP中使用的默认策略是Step Wise。如果sysfs文件temp中的SoC温度值高于 trip_point_0 ，则CPU频率将设置为最低CPU频率。当SoC温度降到 trip_point_0 以下时，限制将被解除。

+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+
+

7.18. 看门狗

+

PHYTEC i.MX 8M Plus 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.18.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.19. snvs电源按键

+

连接到开/关按钮的 X_ONOFF 引脚可以长按以触发关机，而无需软件干预。使用 snvs_pwrkey 驱动程序时，当按下按钮时，KEY_POWER 事件也会报告给用户空间。默认情况下，systemd 被配置为忽略此类事件。无软件干预的关机功能没有配置。可以在 /etc/systemd/logind.conf 中配置在按下开/关按钮时通过 systemd 触发关机：

+
HandlePowerKey=poweroff
+
+
+
+
+

7.20. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 8M Plus 提供一次性可编程fuse，用于存储信息，例如 MAC 地址、启动配置和其他永久设置（在 i.MX 8M Plus reference manual中称为“片上 OTP 控制器 (OCOTP_CTRL)”）。以下列表摘自 i.MX 8M Plus reference manual，包括 OCOTP_CTRL 中的一些有用寄存器（基地址为0x30350000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为0x30350000

描述

OCOTP_MAC_ADDR0

9

0

0x640

包含ENET0 MAC地址的低32位

OCOTP_MAC_ADDR1

9

1

0x650

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

OCOTP_MAC_ADDR2

9

2

0x660

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 8M Plus Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.20.1. 在uBoot中读取fuse的值

+

您可以使用内存映射的shadow寄存器读取fuse寄存器。要计算内存地址，请使用以下公式计算：

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.20.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx8/imx8mp/pd24.1.2.html b/previews/271/zh_CN/bsp/imx8/imx8mp/pd24.1.2.html new file mode 100644 index 000000000..77f27982d --- /dev/null +++ b/previews/271/zh_CN/bsp/imx8/imx8mp/pd24.1.2.html @@ -0,0 +1,2886 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + + + + + +

PD24.1.2 i.MX 8M Plus BSP手册

文档标题

PD24.1.2 i.MX 8M Plus BSP Mainline 手册

文档类型

BSP 手册

型号

PD24.1.2

Yocto 手册

Scarthgap

发布日期

2024/06/26

母文档

PD24.1.2 i.MX 8M Plus BSP Mainline 手册

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP发布日期

BSP 状态

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2

小更新

2024/06/26

已发布

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 phyCORE-i.MX8M Plus Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-8m-plus/#downloads 中找到。

+
+

1.1. 支持的硬件

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 的所有Machine及其对应的Article Numbers(产品型号)： 网页.

+

如果您在“Supported Machines”一栏选择了特定的 Machine Name ，您可以查看该machine下可用的 Article Numbers 以及硬件信息的简短描述。如果您只有硬件的 Article Numbers ，您可以将 Machine Name 下拉菜单留空，仅选择您的 Article Numbers 。现在，它应该会显示您特定硬件所需的 Machine Name

+
+

1.1.1. phyBOARD-Pollux 器件

+
+../../../_images/phyBOARD-Pollux-front-components.jpg + +
+

phyBOARD-Pollux 器件图（顶部）

+
+
+
+../../../_images/phyBOARD-Pollux-back-components.jpg + +
+

phyBOARD-Pollux 器件图（底部）

+
+
+
+
+
+
+

2. 开始使用

+

该 phyCORE-i.MX8M Plus Kit 包含预先烧写好的SD卡。它包含 phytec-qt6demo-image 镜像，可以直接用作启动盘。默认情况下，核心板上的eMMC仅烧写了U-Boot。您可以从 PHYTEC下载服务器 获取所有镜像资源。本章将解释如何将BSP镜像烧写到SD卡以及如何启动开发板。

+

有几种方法可以将镜像写入SD卡或eMMC。最为人熟知的方式是使用Linux命令行工具 dd 进行简单的顺序写入。另一种方法是使用PHYTEC的自研程序 partup ，它可以让格式化复杂系统的过程变得简单。您可以从其发布页面获取 预编译的Linux partup 二进制文件 。请阅读 partup的readme文件 来获取安装指导。

+
+

2.1. 下载镜像

+

phytec-qt6demo-image 镜像包含完整系统所需的所有必要文件，您需确保镜像中各个分区以及裸数据都会被正确写入启动盘。可以从 PHYTEC 下载服务器 下载 partup 镜像文件或者是可以使用 dd 进行烧写的 WIC 镜像。

+

从下载服务器获取 partup 镜像文件或WIC镜像：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+
+

备注

+

针对eMMC，我们建议使用partup去烧写比较大的或者是有复杂分区配置的镜像，因为它在写入速度上比 dd 更快，并且可以对闪存设备进行更灵活的配置。

+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要创建SD卡启动盘，必须要拥有Linux PC上的root权限。在选择烧写设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+
+

2.2.1. 寻找正确的设备

+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行命令：

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+

卸载所有这些分区，例如：

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

现在，SD卡已经准备好可以使用 partup 、 dd 或 bmap-tools 来写入镜像。

+
+
+

2.2.2. 使用bmap-tools

+

烧写SD卡的其中一种方法是使用 bmap-tools 。Yocto会自动为WIC镜像创建一个block map文件（ <IMAGENAME>-<MACHINE>.wic.bmap ），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host:~$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

将 <your_device> 替换为您之前找到的SD卡设备名称，并确保将文件 <IMAGENAME>-<MACHINE>.wic.bmap 与WIC镜像文件放在一起，以便bmaptool知道哪些块需要写入，哪些块需要跳过。

+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.2.3. 使用partup

+

使用partup烧写SD卡只需一个命令：

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).partup /dev/<your_device>
+
+
+

确保将 <your_device> 替换为您之前找到的设备名称。

+

关于partup的进一步使用说明，请参阅其 官方文档 。

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 release notes 。

+
+
+

备注

+

partup 具有清除eMMC user区域中特定区域的功能，我们提供的partup程序中用该功能擦除U-Boot环境变量。这是 bmaptool 工具所无法完成的一点，如前一部分所提到的。

+

partup相较于其他烧写工具的一个主要优势是，它可以配置MMC的特定部分，比如他可以直接写入eMMCboot分区，无需调用其他命令。

+
+
+
+

2.2.4. 使用 dd

+

在卸载所有SD卡的挂载分区后，您可以烧写SD卡。

+

一些PHYTEC BSP会生成未压缩的镜像（文件名扩展名为*.wic），而另一些则生成压缩的镜像（文件名扩展名为*.wic.xz）。

+

要写入未压缩的镜像（*.wic），请使用以下命令：

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

或者要写入压缩后的镜像（*.wic.xz），请使用以下命令：

+
host:~$ xzcat phytec-qt6demo-image-phyboard-pollux-imx8mp-3?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

再次确保将 <your_device> 替换为之前找到的设备名称。

+

参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

+
+
+
+

2.3. 首次启动

+ +../../../_images/SD_Card_Boot1.png +
    +

  • 插入SD卡

    • +

  • 使用 micro USB 线将开发板的 (X1) 调试USB口和主机连接起来

    • +

  • 给开发板通电

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 8M Plus BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (scarthgap).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (scarthgap).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-IMX8MP ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-xwayland MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 phyboard-pollux-imx8mp-3 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx8mp.bin: ARM可信固件二进制文件

    • +

  • lpddr4_pmu_train_1d_dmem_202006.bin, lpddr4_pmu_train_1d_imem_202006.bin, lpddr4_pmu_train_2d_dmem_202006.bin, lpddr4_pmu_train_2d_imem_202006.bin：DDR PHY固件镜像

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx8mp-phyboard-pollux-rdk*.dtb: 内核设备树文件

    • +

  • phytec-qt6demo-image*.tar.gz: 根文件系统

    • +

  • phytec-qt6demo-image*.wic.xz: SD卡镜像

    • +
+
+
+
+
+

4. 安装操作系统

+

为了保持文档的一致性和简洁性，假设已经配置好了TFTP服务器；所有生成的镜像（如上所列）都被复制到默认的/srv/tftp目录。如果您没有进行设置，您需要修改路径到包含镜像的目录。有关如何设置TFTP服务器和目录的说明，请参见 Setup Network Host 。

+
+

4.1. 启动模式开关 (S3)

+
+

小技巧

+

硬件修订版底板：1552.2

+
+

该 phyBOARD-Pollux 具有一个（启动源配置）开关，配有四个可单独切换的位，用于选择phyCORE-i.MX 8M Plus 默认的启动源。

+ + + + + + + + + + + +
+../../../_images/eMMC1.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses1.png +
+

内部fuse

+
+
+
+../../../_images/SPI_NOR.png +
+

SPI NOR

+
+
+
+../../../_images/USB_Serial_Download1.png +
+

USB

+
+
+
+../../../_images/SD_Card_Boot1.png +
+

SD卡

+
+
+
+../../../_images/Test_Mode.png +
+

测试模式

+
+
+
+
+
+

4.2. 烧写eMMC

+

要从 eMMC 启动，请确保 BSP 镜像已正确烧写到 eMMC，并且 bootmode switch (S3) 设置为 eMMC。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行上述命令来检查系统启动在这种条件下是否会到影响。如果 mmcblk2p1 和 mmcblk1p1 具有相同的UUID，则会影响系统正确启动。

+
+
+

4.2.1. 从网络烧写 eMMC

+

i.MX 8M Plus 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

4.2.1.1. 在开发板的U-Boot中通过网络烧写eMMC

+

这些步骤将展示如何通过网络更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+
+

小技巧

+

此步骤仅在镜像文件大小小于1.28GB时有效，因为Bootloader可用的RAM空间有限。

+
+
    +

  • 解压缩镜像：

    • +
+
host:~$ unxz /srv/tftp/phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+
+
+
    +

  • 通过网络将您的镜像加载到内存中：

    +
    u-boot=> dhcp ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+BOOTP broadcast 1
+DHCP client bound to address 192.168.3.11 (101 ms)
+Using ethernet@30be0000 device
+TFTP from server 192.168.3.10; our IP address is 192.168.3.11
+Filename 'phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic'.
+Load address: 0x40480000
+Loading: ######################################
+         ######################################
+         ######################################
+         ...
+         ...
+         ...
+         ######################################
+         #############
+         11.2 MiB/s
+done
+Bytes transferred = 911842304 (36599c00 hex)
+
    +
    +
    • +

  • 将镜像写入eMMC：

    +
    u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +
+
+
+

4.2.1.2. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

使用以下命令，通过网络将压缩或未压缩的镜像和配套的 *.bmap 文件传送到核心板并写入 eMMC：

+
target:~$ scp <USER>@192.168.3.10:/srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.* /tmp && bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
+
+
+
+

4.2.1.3. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

查看主机上可用的镜像文件：

+
host:~$ ls /srv/tftp
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
+
+

通过网络ssh协议使用 bmaptool 命令将镜像发送到开发板的eMMC：

+
host:~$ scp /srv/tftp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.* root@192.168.3.11:/tmp && ssh root@192.168.3.11 "bmaptool copy /tmp/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2"
+
+
+
+
+
+

4.2.2. 在运行的U-Boot中通过网络烧写eMMC U-Boot镜像

+

可以在U-Boot中更新U-Boot镜像imx-boot，eMMC上的U-Boot需要位于eMMC的user区域。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> dhcp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 2
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.3. 从USB大容量存储设备烧写eMMC

+
+

4.2.3.1. 在开发板上通过U-Boot从USB烧写eMMC

+
+

备注

+

在U-Boot中只能使用下方的USB-A端口来连接优盘。

+
+
+

小技巧

+

此步骤仅在镜像文件大小小于1.28GB时有效，因为Bootloader可用的RAM空间有限。

+
+

下面这些步骤展示如何通过USB设备更新eMMC。将 bootmode switch (S3) 配置为SD卡并插入SD卡。给开发板上电并进入U-Boot环境。将已存储了未压缩WIC镜像的优盘插入开发板USB接口。

+

将镜像从USB设备加载到RAM中：

+
u-boot=> usb start
+starting USB...
+USB0:   USB EHCI 1.00
+scanning bus 0 for devices... 2 USB Device(s) found
+       scanning usb for storage devices... 1 Storage Device(s) found
+u-boot=> fatload usb 0:1 ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+497444864 bytes read in 31577 ms (15 MiB/s)
+
+
+

将镜像写入eMMC：

+
u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1024000 ... 1024000 blocks written: OK
+u-boot=> boot
+
+
+
+
+

4.2.3.2. 在运行的Linux系统中从USB烧写eMMC

+

下面这些步骤展示如何在Linux系统上使用USB大容量存储设备烧写eMMC。您只需要一个保存在USB优盘上的完整镜像和一个可引导的WIC镜像。（例如：phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz）。将 bootmode switch (S3) 设置为SD卡。

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ ls /mnt
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
    +
    +
    • +

  • 将镜像写入 phyCORE-i.MX 8M Plus eMMC（无分区的 MMC 设备 2）：

    +
    target:~$ bmaptool copy /mnt/phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    小技巧

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+
+

4.2.4. 从SD卡烧写eMMC

+

即使没有可用的网络，您也可以更新eMMC。为此，您需要一个位于SD卡上的镜像文件（ *.wic ）。由于镜像文件相当大，您需要在SD卡创建第三个分区。要创建新分区或扩展您的SD卡，请参见 Resizing ext4 Root Filesystem 。

+

或者，使用partup包烧写SD卡，如 Getting Started 中所述。这样就可使用SD卡的全部容量。

+
+

4.2.4.1. 在开发板的uboot环境中通过SD卡烧写eMMC

+
+

小技巧

+

此步骤仅在镜像文件大小小于1.28GB时有效，因为Bootloader可用的RAM空间有限。

+
+
    +

  • 将一个可用的镜像烧写到SD卡，并创建一个EXT4格式的第三分区。将WIC镜像（例如 phytec-qt6demo-image.rootfs.wic）复制到该分区。

    • +

  • 将 bootmode switch (S3) 配置为 SD 卡并插入 SD 卡。

    • +

  • 打开电源并进入U-Boot。

    • +

  • 加载镜像：

    +
    u-boot=> mmc dev 1
+u-boot=> ext4load mmc 1:3 ${loadaddr} phytec-headless-image-phyboard-pollux-imx8mp-3.rootfs.wic
+reading
+911842304 bytes read in 39253 ms (22.2 MiB/s)
+
    +
    +
    • +

  • 将当前mmc设备切换到eMMC：

    +
    u-boot=> mmc list
+FSL_SDHC: 1 (SD)
+FSL_SDHC: 2 (eMMC)
+u-boot=> mmc dev 2
+switch to partitions #0, OK
+mmc2(part 0) is current device
+
    +
    +
    • +

  • 将您保存在SD的WIC镜像（例如 phytec-qt6demo-image.roots.wic）烧写到eMMC。这将对卡进行分区，并将imx-boot、Image、dtb、dtbo和根文件系统复制到eMMC。

    +
    u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc write ${loadaddr} 0x0 ${nblk}
+
+MMC write: dev # 2, block # 0, count 1780942 ... 1780942 blocks written: OK
+
    +
    +
    • +

  • 关闭电源并将 bootmode switch (S3) 更改为 eMMC。

    • +
+
+
+

4.2.4.2. 在开发板的linux环境中通过SD卡烧写eMMC

+

您也可以在Linux系统中烧写eMMC。您只需要一个partup包或保存在SD卡上的WIC镜像。

+
    +

  • 检查在SD卡上保存的partup包或WIC镜像文件：

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz
+phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.bmap
+
    +
    +
    • +

  • 使用 partup 将镜像写入 phyCORE-i.MX 8M Plus 的 eMMC（MMC 设备 2 不带 分区字样）：

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.partup /dev/mmcblk2
+
    +
    +

    使用partup烧写的优点是可以充分利用eMMC设备的全部容量，会相应自动调整分区大小。

    +
    +

    备注

    +

    另外，也可以使用 bmaptool 工具：

    +
    target:~$ bmaptool copy phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /dev/mmcblk2
+
    +
    +

    请注意，在使用 bmaptool 烧写时，根文件系统分区并不会使用eMMC的最大容量。

    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    警告

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+
+
+

4.3. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC：L-1006e.A6 RAUC更新与设备管理手册。

+
+
+
+

5. 开发

+
+

5.1. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.1.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.2. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.2.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核镜像复制到您的tftp目录中：

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • 将设备树复制到您的tftp目录：

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.2.2. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.3.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. 获取镜像

+

从我们的服务器下载 imx-boot，或者从您的 Yocto 编译目录中的 build/deploy/images/phyboard-pollux-imx8mp-3/ 获取它。为了将 wic 镜像烧写到 eMMC，你还需要 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic

+
+
+

5.3.3. 开发板准备

+

将 bootmode switch (S3) 设置为 USB串行下载。同时，将 USB 端口 X5 (upper connector) 连接到主机。

+
+
+

5.3.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 (X1) 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.3.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 2 0 0 0
+u-boot=> mmc partconf 2
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic
+
+
+
+
+
+

5.4. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone https://github.com/phytec/u-boot-phytec.git）

+
+
+

5.4.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    https://github.com/phytec/u-boot-phytec.git
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-phytec 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    https://github.com/phytec/linux-phytec.git
+
    +
    +
    • +

  • 我们的 i.MX 8M Plus 内核是基于 linux-phytec 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
recipes-kernel/linux/linux-phytec_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-phytec_*.bb
+
+
+
+
+
+

5.4.2. 获取SDK

+

您可以在此处下载SDK 这里，或者使用Yocto去编译生成SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

在成功编译后，SDK安装包保存在 build/deploy*/sdk。

+
+
+

5.4.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.1.sh
+host:~$ ./phytec-ampliphy-xwayland-glibc-x86_64-phytec-qt6demo-image-cortexa53-crypto-toolchain-5.0.1.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-xwayland/5.0.1):
+You are about to install the SDK to "/opt/ampliphy-xwayland/5.0.1". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-xwayland/5.0.1/environment-setup-cortexa53-crypto-phytec-linux
+
+
+
+
+

5.4.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. 单独编译U-Boot

+
+

5.5.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone https://github.com/phytec/u-boot-phytec.git
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本中使用的**tag**称为 v2024.01-phy4

    • +

  • 查看所需的 U-Boot tag：

    +
    host:~$ cd ~/u-boot-phytec/
+host:~/u-boot-phytec$ git fetch --all --tags
+host:~/u-boot-phytec$ git checkout tags/v2024.01-phy4
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/u-boot-phytec$ source /opt/ampliphy-xwayland/5.0.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. 获取所需的二进制文件

+

要编译bootloader，您需要将这些文件复制到您的 u-boot-phytec 编译目录，并将其重命名以适应 mkimage 脚本：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx8mp.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以在yocto工程目录中获取 bl31-imx8mp.bin、tee.bin和lpddr4_*.bin：BSP Images

+

或者你可以在这里下载文件： https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/images/ampliphy-xwayland/phyboard-pollux-imx8mp-3/

+
+

警告

+

确保您重命名所需的文件，以和 mkimage tool 兼容。

+
+
+
+

5.5.3. 编译bootloader

+
    +

  • 编译 flash.bin (imx-boot):

    +
    host:~/u-boot-phytec$ make phycore-imx8mp_defconfig
+host:~/u-boot-phytec$ make flash.bin
+
    +
    +
    • +
+
+
+

5.5.4. 将bootloader烧写到块设备上

+

flash.bin 文件可以在 u-boot-phytec/ 目录下找到，现在可以进行烧写。需要指定芯片特定的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

+

例如，烧写SD卡：

+
host:~/u-boot-phytec$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync
+
+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+

5.5.5. 使用固定内存大小编译U-Boot

+

如果您的系统因为EEPROM中的硬件信息损坏或丢失而无法启动，您可以创建一个具有固定RAM大小的flash.bin。但您仍应联系我们支持部门以烧写正确的EEPROM数据。

+

按照步骤获取U-boot源代码，并切换到 Build U-Boot 章节说明的分支。

+

Edit the file configs/phycore-imx8mp_defconfig:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+
+
+

选择正确的RAM大小，确保与核心板上的贴装的器件一致，取消注释该RAM大小的行。保存更改后，按照 Build U-Boot 章节的剩余步骤进行操作。

+
+
+

5.5.6. 编译支持固定RAM大小与频率的U-Boot

+

从PD23.1.0 NXP或PD24.1.2 Mainline 版本开始，PCB为1549.3版本的核心板及更新版本的phyCORE-i.MX 8M Plus SoM支持2GHz内存时序。这些将在支持的板上自动启用，但也可以手动启用或禁用。

+

Edit the file configs/phycore-imx8mp_defconfig. +The fixed RAM size with 2GHz timings will be used:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_SIZE_FIX=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_1GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_2GB=y
+# CONFIG_PHYCORE_IMX8MP_RAM_SIZE_4GB=y
+CONFIG_PHYCORE_IMX8MP_RAM_FREQ_FIX=y
+CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+
+
+

在保存更改后，按照 Build U-Boot 中剩下的步骤操作。

+
+
+

5.5.7. 编译固定的RAM频率的U-Boot

+

从PD24.1.2 Mainline版本或者 PD24.1.0 NXP 版本开始，U-Boot可以编译成只固定RAM频率，RAM大小还是保持从EEPROM读取。

+

Edit the file configs/phycore-imx8mp_defconfig. +The RAM size from EEPROM with fixed frequency will be used:

+
CONFIG_TARGET_PHYCORE_IMX8MP=y
+CONFIG_PHYCORE_IMX8MP_RAM_FREQ_FIX=y
+# CONFIG_PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS=y
+# CONFIG_PHYCORE_IMX8MP_USE_1_5GHZ_RAM_TIMINGS=y
+
+
+

在保存更改后，按照 Build U-Boot 中剩下的步骤操作。

+
+
+
+

5.6. 单独编译内核

+
+

5.6.1. 配置源代码

+
    +

  • 使用的 linux-phytec 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v6.6.21-phy1

    • +

  • Check out 所需的 linux-phytec 标签：

    +
    host:~$ git clone https://github.com/phytec/linux-phytec.git
+host:~$ cd ~/linux-phytec/
+host:~/linux-phytec$ git fetch --all --tags
+host:~/linux-phytec$ git checkout tags/v6.6.21-phy1
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-phytec$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-phytec$ source /opt/ampliphy-xwayland/5.0.1/environment-setup-cortexa53-crypto-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-phytec$ make defconfig
+host:~/linux-phytec$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-phytec$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-phytec/arch/arm64/boot/Image 找到

    • +

  • dtb文件可以在 ~/linux-phytec/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-phytec$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. 将内核复制到SD卡

+

内核及module和对应的设备树二进制文件可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-phytec$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-phytec$ cp arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dtb /path/to/sdcard/boot/oftree
+host:~/linux-phytec$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. 获取BSP开发中版本

+
+

5.7.1. 当前release的开发中版本

+

这些release manifest文件是为了让您访问 Yocto BSP的开发版本。它们不会在phyLinux选择菜单中显示，需要手动选择。可以使用以下命令行来完成此操作：

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2
+
+
+

这将初始化一个BSP，用于跟踪当前版本（ BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 ）的最新开发版本。从现在开始，在此文件夹中执行 repo sync 将从我们的Git仓库中拉取所有最新的更改：

+
host:~$ repo sync
+
+
+
+
+

5.7.2. 即将发布版本的开发中版本

+

即将发布版本的开发中版本可以通过这种方式访问。请执行以下命令，并查找一个比最新版本（ BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 ）的PDXX.Y数字更高的版本，并且以 .y 结尾：

+
host:~$ ./phyLinux init -p imx8mp
+
+
+
+
+
+

5.8. 获取最新的Upstream支持

+

我们有一个使用Yocto主分支（不是NXP发布的）的manifest，他使用upstream的Linux和U-Boot。这可以用来测试最新的upstream kernel/U-Boot。

+
+

备注

+

master分支的manifest反映了最新的开发状态。有时会出现一些bug。我们会定期修复master分支。

+
+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-master
+
+
+
+
+

5.9. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.9.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.9.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将例如 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.9.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将例如 phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz 镜像复制到其中。然后再次卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-pollux-imx8mp-3.rootfs.wic.xz /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 8M Plus BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 8M Plus 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Board.dts - 包含module dtsi 文件。从SoC i.MX 8M Plus 引出并在底板使用的设备也包含在此 dts 中。

    • +

  • Overlay.dtso - 根据核心板或底板上可选硬件（例如 SPI 闪存或 PEB-AV-10）的情况来启用/禁用一些功能。

    • +
+

在Linux内核的根目录下，我们的 i.MX 8 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。下面是扩展板的硬件描述。对比源码中的include，overlay通过覆盖的方式来生效。overlay也可以根据实际开发板的硬件配置来设置设备树节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/ 中。

+

phyboard-pollux-imx8mp-3.conf 可用的overlay文件有：

+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 8M Plus BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 8M Plus BSP设备树概念部分，以了解我们的 i.MX 8 BSP设备树模型。

+

以下部分概述了 i.MX 8 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 8M Plus 引脚复用

+

该 i.MX 8M Plus Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 8M Plus 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 8M Plus 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是 imx8mp-phyboard-pollux-rdk.dts中UART1设备的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX     0x140
+                MX8MP_IOMUXC_UART1_TXD_UART1_DCE_TX     0x140
+        >;
+};
+
+
+

字符串的第一部分 MX8MP_IOMUXC_UART1_RXD_UART1_DCE_RX 指定了引脚（在这个例子中是 UART1_RXD）。字符串的第二部分（UART1_DCE_RX）是该引脚所选的复用项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部拉电阻是否被激活。在当前情况下，内部拉电阻被禁用。

+

UART1引脚复用的设备树：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L387

+
+
+

7.2. RS232/RS485

+

phyCORE-i.MX 8M Plus 支持最多 4 个 UART 单元。在 phyBOARD-Pollux 上，UART1（调试串口）和 UART4 的 TTL 电平信号被连接到 Silicon Labs CP2105 UART 到 USB 转换IC。这个 USB 信号通过 Micro-USB 连接器 X1 输出。UART3 位于 X6（扩展连接器），为 TTL 电平信号。UART2 连接到一个多协议收发器IC，可转换为 RS-232 或 RS-485，RS-232 和 RS-485 信号位于连接器 X2 。多协议配置通过主板上的跳线 JP3 和 JP4 完成。更多信息，请参阅 phyCORE-i.MX 8M Plus/phyBOARD-Pollux 硬件手册中的 UARTs 部分。

+

对于RS-232和RS-485，使用相同的设备树节点。RS485模式可以通过ioctl TIOCSRS485 来启用。双向通讯支持也可以通过ioctl进行配置。请查看我们的小示例应用程序rs485test，该程序也包含在BSP中。需要设置跳线 JP3 和 JP4 。

+
+

7.2.1. RS232

+
    +

  • 以人类可读的格式显示终端的当前设置：

    +
    target:~$ stty -a
+
    +
    +
    • +

  • UART接口的配置可以通过stty命令完成。例如：

    +
    target:~$ stty -F /dev/ttymxc1 115200 crtscts raw -echo
+
    +
    +
    • +

  • 通过简单的echo和cat，可以测试基本的通信。示例：

    +
    target:~$ echo 123 > /dev/ttymxc1
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

主机应打印出 "123"。

+
+
+

7.2.2. RS485

+
+

提示

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

为了方便测试，请查看linux-serial-test。这个工具会通过调用RS485的IOCTL，发送恒定的数据流。

+
target:~$ linux-serial-test -p /dev/ttymxc1 -b 115200 --rs485 0
+
+
+

有关linux-serial-test工具及其参数的更多信息，请访问此链接：linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Linux kernel文档描述了如何在C代码中调用IOCTL： https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+
+

7.2.2.1. RS485 half-duplex

+

For half-duplex mode your connection setup should look like this:

+../../../_images/RS485_halfduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For half-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 0
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  false
+Bus termination enabled:  false
+
+
+

Then you can test if sending and receiving works like this:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see "test" printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

Alternatively you can also test with the linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -t -i 8
+...
+/dev/ttymxc1: count for this session: rx=57330, tx=0, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -r -o 5
+...
+/dev/ttymxc1: count for this session: rx=0, tx=57330, rx err=0
+
+
+

In this example target1 will be the receiver and target2 will be the +transmitter. You should also be able to switch the roles. Remember to first +start the receiver and then the transmitter immediately after. The receiver +will receive for 8 sec and the transmitter will send for 5 sec. The receiver +needs to receive for a bit longer than the transmitter sends. At the end the +program will print the final "count for this session". There you can check, +that all transmitted frames were received.

+

All the tests are target to target, but can also be done with host to target +with a USB to rs485 converter. You may need to adjust the interfaces then.

+
+
+

7.2.2.2. RS485 full-duplex

+

For full-duplex mode your connection setup should look like this:

+../../../_images/RS485_fullduplex_connection.png +

Which function is on which pin is described in the hardware manual.

+

For full-duplex mode you can set the ioctls manually like this:

+
target:~$ rs485conf /dev/ttymxc1 -e 1 -r 1
+target:~$ rs485conf /dev/ttymxc1
+= Current configuration:
+RS485 enabled:                true
+RTS on send:                  high
+RTS after send:               low
+RTS delay before send:        0
+RTS delay after send:         0
+Receive during sending data:  true
+Bus termination enabled:  false
+
+
+

Also here you can do the echo test to see if sending and receiving works:

+
target1:~$ cat /dev/ttymxc1
+target2:~$ echo test > /dev/ttymxc1
+
+
+

You should see "test" printed out on target1. You can also switch the roles and +send on target2 and receive on target1.

+

To check if the full-duplex operation works, you need to use the +linux-serial-test tool:

+
target1:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=114660, tx=118755, rx err=0
+target2:~$ linux-serial-test -s -e -f -p /dev/ttymxc1 -b 115200 --rs485 0 -o 10 -i 15 -W 2
+...
+/dev/ttymxc1: count for this session: rx=118755, tx=114660, rx err=0
+
+
+

In this example both targets will send and receive simultaneously. They will +receive for 15sec and send for 10sec. The receiver needs to receive a bit +longer, so that all sent messages will get received. Remember to start both +targets almost simultaneously. A small difference in start time is accounted +for with the -W 2 option. At the end the program will print the final +"count for this session". There you can check that all transmitted frames were +received.

+

All the test examples are target to target, but can also be done with host to +target with a USB to rs485 converter. You may need to adjust the interfaces for +commands to work on the host then.

+

RS232和RS485的设备树： https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L251

+
+
+
+
+

7.3. 网络

+

phyBOARD-Pollux-i.MX 8M Plus 提供两个以太网接口。我们的核心板和底板各提供一个千兆以太网接口。

+
+

警告

+

硬件中的以太网接口命名约定（ethernet0 和 ethernet1）与Linux中的网络接口（eth0 和 eth1）不一致。因此，请注意这些差异：

+
+
ethernet1 = eth0
+
ethernet0 = eth1
+
+
+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L41。

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Pollux can be found here: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L106

+
+

7.3.1. 网络配置

+
+

7.3.1.1. U-boot网络环境

+
    +

  • 我们目前在U-Boot中使用动态IP地址。这是通过以下这个变量启用的：

    +
    +
    u-boot=> printenv ip_dyn
+ip_dyn=yes
+
    +
    +
    +
    • +

  • 设置NFS的路径。一个示例如下：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+
+

7.3.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+
+

7.4. SD/MMC 卡

+

该 i.MX 8M Plus 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

MMC（SD卡插槽）接口的DT配置：https://github.com/phytec/linux-phytec//blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L261

+

eMMC接口的DT配置：https://github.com/phytec/linux-phytec//blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L181

+
+
+

7.5. eMMC设备

+

PHYTEC模块如phyCORE-i.MX 8M Plus 配备了eMMC存储芯片作为主要存储。eMMC设备使用多层单元（MLC）或三层单元（TLC）技术来实现存储，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 8M Plus ，并在Linux内核中作为块设备表示，如SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.5.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk2
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.5.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），该层负责处理原始MLC或TLC的磨损均衡、块管理和错误更正码（ECC）。这需要定期执行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 通过以下命令使能BKOPS_EN：

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops_en manual /dev/mmcblk2
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.5.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 8M Plus SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk2 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.5.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk2 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sect[ 1799.850385]  mmcblk2: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk2 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk2 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk2: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk2: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk2p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk2p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk2p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk2p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk2p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
+
+

7.5.5. 启用伪SLC模式

+

eMMC设备使用 MLC或TLC 来存储数据。与NAND Flash中使用的SLC相比，MLC或TLC在成本更低的情况下，可靠性较低且错误率较高。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk2:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk2
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk2
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk2 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk2 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk2 unit B print
+BYT;
+/dev/mmcblk2:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.5.6. 擦除设备

+

可以直接擦除eMMC设备，而不是通过写零覆盖。eMMC块管理算法将擦除底层的MLC或TLC，或者将这些块标记为可丢弃。设备上的数据将丢失，并将被读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk2
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk2 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.5.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 8M Plus 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.5.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk2boot1
+
+
+

下表是 i.MX 8M Plus SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk2
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk2
+
+
+
+
+

7.5.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk2
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk2
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk2p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk2p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk2: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk2p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk2p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.6. SPI主设备

+

i.MX 8M Plus 控制器包含一个 FlexSPI 和一个 ECSPI IP 核。FlexSPI 主控制器支持两个 SPI 通道，最多可连接 4 个设备。每个通道支持单通道/双通道/四通道/八通道模式的数据传输（1/2/4/8 条数据线）。ECSPI 控制器支持 3 个 SPI 接口，每个接口都有一个专用的CS（chip select）引脚。由于CS也可通过 GPIO 实现，因此每个通道上可以连接多个设备。

+

在设备树中，SPI主节点的定义：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L67

+
+
+

7.7. GPIOs

+

phyBOARD-Pollux 具有一组专门用于GPIO的引脚。这些引脚直接连接到 i.MX 8M Plus 引脚，并被复用为 GPIO。它们可以直接在 Linux 用户空间中使用。处理器将其 GPIO 组织为5个GPIO组（GPIO1 – GPIO5），每个组包含 32 个GPIO。gpiochip0、gpiochip32、gpiochip64、gpiochip96 和 gpiochip128 是这些内部 i.MX 8M Plus GPIO 组 GPIO1 – GPIO5 的 sysfs 表示。

+

GPIO被标识为GPIO<X>_<Y>（例如：GPIO5_07）。<X>表示GPIO Bank，从1计数到5，而<Y>表示该Bank内的GPIO。<Y>从0计数到31（每个bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [30200000.gpio] (32 lines)
+gpiochip1 [30210000.gpio] (32 lines)
+gpiochip2 [30220000.gpio] (32 lines)
+gpiochip3 [30230000.gpio] (32 lines)
+gpiochip4 [30240000.gpio] (32 lines)
+
    +
    +
    • +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo -c gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如从gpiochip0的GPIO 20）：

    +
    target:~$ gpioget -c gpiochip0 20
+
    +
    +
    • +

  • 将gpiochip0上的GPIO 20的值设置为0并退出工具：

    +
    target:~$ gpioset -z -c gpiochip0 20=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <line=value>...
+
+Set values of GPIO lines.
+
+Lines are specified by name, or optionally by offset if the chip option
+is provided.
+Values may be '1' or '0', or equivalently 'active'/'inactive' or 'on'/'off'.
+
+The line output state is maintained until the process exits, but after that
+is not guaranteed.
+
+Options:
+      --banner            display a banner on successful startup
+  -b, --bias <bias>       specify the line bias
+                  Possible values: 'pull-down', 'pull-up', 'disabled'.
+                  (default is to leave bias unchanged)
+      --by-name           treat lines as names even if they would parse as an offset
+  -c, --chip <chip>       restrict scope to a particular chip
+  -C, --consumer <name>   consumer name applied to requested lines (default is 'gpioset')
+  -d, --drive <drive>     specify the line drive mode
+                  Possible values: 'push-pull', 'open-drain', 'open-source'.
+                  (default is 'push-pull')
+  -h, --help              display this help and exit
+  -l, --active-low        treat the line as active low
+  -p, --hold-period <period>
+                  the minimum time period to hold lines at the requested values
+  -s, --strict            abort if requested line names are not unique
+  -t, --toggle <period>[,period]...
+                  toggle the line(s) after the specified period(s)
+                  If the last period is non-zero then the sequence repeats.
+      --unquoted  don't quote line names
+  -v, --version           output version information and exit
+  -z, --daemonize set values then detach from the controlling terminal
+
+Chips:
+    A GPIO chip may be identified by number, name, or path.
+    e.g. '0', 'gpiochip0', and '/dev/gpiochip0' all refer to the same chip.
+
+Periods:
+    Periods are taken as milliseconds unless units are specified. e.g. 10us.
+    Supported units are 's', 'ms', and 'us'.
+
+*Note*
+    The state of a GPIO line controlled over the character device reverts to default
+    when the last process referencing the file descriptor representing the device file exits.
+    This means that it's wrong to run gpioset, have it exit and expect the line to continue
+    being driven high or low. It may happen if given pin is floating but it must be interpreted
+    as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.7.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用 CONFIG_GPIO_SYSFS 后才能支持。要在menuconfig中使 CONFIG_GPIO_SYSFS 可见，必须首先启用选项 CONFIG_EXPERT 。

+

您也可以将此选项添加到您在 Linux 内核源代码 arch/arm64/configs/ 目录下使用的 defconfig 中。例如，我们基于 NXP 的BSP版本，这个defconfig可以是 imx8_phytec_distro.config

+
..
+CONFIG_EXPERT=y
+CONFIG_GPIO_SYSFS=y
+..
+
+
+

Otherwise you can create a new config fragment. This is described in our +Yocto Reference Manual.

+
+
+
+

7.8. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+led-1@  led-2@  led-3@  mmc1::@  mmc2::@
+
+
+

这里的 LED 灯包括蓝色的 mmc、绿色的 心跳和红色的 emmc，它们都在 phyBOARD-Pollux 上。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 255 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/led-1/brightness
+
    +
    +
    • +
+

GPIO的设备树配置：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L160

+
+
+

7.9. I²C总线

+

该 i.MX 8M Plus 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 8M Plus 的I²C模块。 本节描述了我们 phyBOARD-Pollux 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

I²C1 总线DT配置（例如 imx8mp-phycore-som.dtsi）： https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L81

+

I²C2总线DT配置（例如 imx8mp-phyboard-pollux-rdk.dts）： https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L145

+
+
+

7.10. EEPROM

+

在 phyCORE-i.MX8MP 上贴了一个 i2c 接口的 EEPROM 存储。它有两个地址。主 EEPROM 空间（总线：I2C-0 地址：0x51）可以通过 Linux 中的 sysfs 接口访问。主 EEPROM 的前 256 字节和 ID 页（总线：I2C-0 地址：0x59）用于板检测，不可修改。因此，ID 页不能通过 sysfs 接口访问。覆盖保留空间将导致启动问题。

+
+

备注

+

如果您删除了保留的EEPROM空间数据，请联系我们的支持团队！

+
+
+

7.10.1. phyCORE-i.MX8MP 上的I2C EEPROM

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

phyCORE-i.MX8MP SoM上的I2C EEPROM连接到I2C-0总线的I2C地址0x51。可以直接对该设备进行读写操作：

+
target:~$ hexdump -c /sys/class/i2c-dev/i2c-0/device/0-0051/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x
+
+
+

要用零填充4KiB的EEPROM（总线：I2C-0 地址：0x51），并保留EEPROM数据，请使用：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom seek=1 bs=256 count=15
+
+
+
+
+

7.10.2. EEPROM SoM 检测

+

在 phyCORE-i.MX8MP 上配置的I2C EEPROM具有一个可通过I2C地址0x59在i2c0上寻址的独立ID页面，以及一个可通过I2C地址0x51在i2c0上寻址的正常区域。PHYTEC使用这个32字节的数据区域来存储关于SoM的信息，包括PCB版本和配置。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果EEPROM ID页面数据和正常区域的前256个字节被删除，bootloader程序将回退到 phyCORE-i.MX8MP Kit RAM设置，即 2GiB RAM。

+
+

警告

+

EEPROM ID页面（总线：I2C-0 地址：0x59）和正常EEPROM区域的前256个字节（总线：I2C-0 地址：0x51）不可被擦除或修改。这将影响bootloader的行为。板子可能无法正确启动。

+
+

使用API修订版2数据格式烧写的核心板将在早期启动阶段打印出有关模块的信息。

+

核心板 phyCORE-i.MX 8M Plus 的设备树imx8mp-phycore-som.dtsi可以在PHYTEC git中找到： https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L169

+
+
+
+

7.11. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.11.1. RTC参数

+

实时时钟（RTC）具有一些功能，可以通过 hwclock 工具进行读取和设置。

+
    +

  • 我们可以通过以下方式检查RTC支持的功能：

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    这个值的含义在内核中进行了编码，每个位的定义为：

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • 我们可以通过以下方式检查RTC BSM（Backup Switchover Mode 备份切换模式）：

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • 我们可以通过以下方式设置RTC BSM：

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    BSM位的定义为：

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    小技巧

    +

    您应该将BSM模式设置为DSM或LSM，以便在初始电源不可用时，RTC可以切换到备用电源。请查看 RV-3028 RTC的Datasheet，以了解LSM（电平切换模式）和DSM（直接切换模式）这两个定义的工作模式。

    +
    +
    • +
+

I²C RTCs 的设备树：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi#L175

+
+
+
+

7.12. USB主控制器

+

i.MX 8M Plus SoC的USB控制器为众多消费类便携设备提供了一种低成本的连接解决方案，实现USB设备之间的数据传输，传输速度可达4 Gbit/s（超高速'SS'）。USB子系统具有两个独立的USB控制器。这两个控制器都能够作为USBDevice或USB Host使用。每个核心都连接到一个USB 3.0物理层（PHY）。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+

USB Host的设备树：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L220

+
+
+

7.13. CAN FD

+

The phyBOARD-Pollux has two flexCAN interfaces supporting CAN FD. They are supported by the +Linux standard CAN framework which builds upon then the Linux network layer. +Using this framework, the CAN interfaces behave like an ordinary Linux network +device, with some additional features special to CAN. More information can be +found in the Linux Kernel +documentation: https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。两个CAN接口显示为can0和can1。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+
    +
    +

    can0的信息将如下所示：

    +
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
+    link/can  promiscuity 0 minmtu 0 maxmtu 0
+    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+          bitrate 500000 sample-point 0.875
+          tq 50 prop-seg 17 phase-seg1 17 phase-seg2 5 sjw 1
+          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
+          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
+          clock 20000000
+          re-started bus-errors arbit-lost error-warn error-pass bus-off
+          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
+    RX: bytes  packets  errors  dropped overrun mcast
+    0          0        0       0       0       0
+    TX: bytes  packets  errors  dropped carrier collsns
+    0          0        0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+
+

警告

+

mcp2518fd SPI到CAN FD只支持从125kB/s开始的波特率。可以选择更慢的速率，但可能无法正常工作。

+
+

Device Tree CAN configuration of imx8mp-phyboard-pollux-rdk.dts: +https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L130

+
+
+

7.14. 视频

+
+

7.14.1. 视频与Gstreamer

+

默认情况下，BSP安装了一个示例视频，路径为 /usr/share/qtphy/videos/ 。可以使用以下命令之一开始视频播放：

+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink fullscreen=true
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+

备注

+

Mainline BSP目前仅支持软件渲染。

+
+
+
+
+

7.15. 显示

+

phyBOARD-Pollux 通过开发板上的LVDS1连接器支持LVDS输出。LVDS接口默认启用。

+
+

7.15.1. Weston 配置

+

Weston可以在无需额外配置的情况下运行。配置选项位于 /etc/xdg/weston/weston.ini。

+

LVDS的设备树：https://github.com/phytec/linux-phytec/blob/v6.6.21-phy1/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts#L182

+
+
+

7.15.2. Qt Demo

+

使用 phytec-qt6demo-image 时，Weston会在启动时启动。我们的Qt6 DEMO应用程序名为“qtphy”，可以通过以下方式停止：

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • 要重新开始Demo，请运行：

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • 要禁用Demo的自动启动，请运行：

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • 要启用Demo的自动启动，请运行：

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston可以通过以下方式停止：

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

备注

+

在关闭Weston之前，必须先关闭Qt Demo。

+
+
+
+

7.15.3. 背光控制

+

如果LCD连接到PHYTEC开发板，可以通过Linux内核的sysfs接口控制其背光。系统中所有可用的背光设备可以在文件夹/sys/class/backlight中找到。读取相应的文件并向其写入数据可以控制背光。

+
+

备注

+

一些具有多显示的开发板在 /sys/class/backlight 有多个背光控制。比如：backlight0和backlight1

+
+
    +

  • 例如，要获取最大亮度级别（max_brightness），请执行：

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    有效的亮度值范围是 0 到 <max_brightness>。

    +
    • +

  • 要获取当前亮度级别，请输入：

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • 写入文件brightness以更改亮度：

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    例如，关闭背光。

    +

    有关所有文件的文档，请参见 https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight。

    +
    • +
+
+

备注

+

我们注意到在亮度级别1上有一些明显的背光闪烁（可能是由于硬件频率问题导致的）。

+
+
+
+
+

7.16. 电源管理

+
+

7.16.1. CPU核心频率调节

+

i.MX 8M Plus SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。调整频率和电压被称为“动态电压和频率调整”（DVFS）。i.MX 8M Plus BSP支持DVFS功能。Linux内核提供了一个DVFS框架，允许每个CPU核心设置最小或最大频率和一个管理其运行的governor。根据使用的 i.MX 8 型号，支持几种不同的频率。

+
+

小技巧

+

尽管DVFS框架为每个CPU核心提供了频率设置，但一个CPU核心的频率更改会影响其他CPU核心。因此，所有CPU核心始终共享相同的DVFS设置。每个核心的单独DVFS设置是不可能的。

+
+
    +

  • 要获取完整列表，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
+
    +
    +

    例如 i.MX 8MPlus CPU，最高可达约 1.6 GHz，则结果将是：

    +
    1200000 1600000
+
    +
    +
    • +

  • 要查询当前的频率输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
    +
    +
    • +
+

governor 会根据它们的目标自动选择这些频率中的一个。

+
    +

  • 列出所有可用的 governor，使用以下命令：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
+
    +
    +

    结果是：

    +
    ondemand userspace performance schedutil
+
    +
    +
    • +

  • ondemand （默认）根据当前系统负载在可能的CPU核心频率之间切换。当系统负载超过特定值时，它会立即提高CPU核心频率。

    • +

  • performance 始终选择最高的CPU核心频率。

    • +

  • userspace 允许以root身份运行的用户或用户空间程序设置特定频率（例如，设置为1600000）。输入：

    • +

  • 要查询当前的 governor，请输入：

    +
    target:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +

    您通常会得到：

    +
    schedutil
+
    +
    +
    • +

  • 切换到另一个governor（例如，userspace）可以通过以下方式完成：

    +
    target:~$ echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+
    +
    +
    • +

  • 现在你可以设置频率：

    +
    target:~$ echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
+
    +
    +
    • +
+

有关governor的更详细信息，请参阅Linux内核代码库中的Linux内核文档，路径为 Documentation/admin-guide/pm/cpufreq.rst 。

+
+
+

7.16.2. CPU核心管理

+

该 i.MX 8M Plus SoC 芯片上可以有多个处理器核心。例如，该 i.MX 8M Plus 具有 4 个 ARM 核心，可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0    cpu1   cpu2   cpu3   cpufreq
+[...]
+
    +
    +

    这里系统有四个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu3/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU3 killed
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu3/online
+
    +
    +
    • +
+
+
+
+

7.17. 热管理

+
+

7.17.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.17.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 8M Plus SoC 平台上使用热管理内核 API。 i.MX 8 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个触发点。这些触发点根据CPU型号的不同而有所不同。主要区分工业版和商业版。

+ + + + + + + + + + + + + + + + + +

商业

工业

被动（警告）

85°C

95°C

严重（关机）

90°C

100°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并实施冷却措施。内核中可用的热政策（也称为thermal governor）包括：Step Wise、Fair Share、Bang Bang和Userspace。BSP中使用的默认策略是Step Wise。如果sysfs文件temp中的SoC温度值高于 trip_point_0 ，则CPU频率将设置为最低CPU频率。当SoC温度降到 trip_point_0 以下时，限制将被解除。

+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+
+

7.18. 看门狗

+

PHYTEC i.MX 8M Plus 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.18.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.19. snvs电源按键

+

连接到开/关按钮的 X_ONOFF 引脚可以长按以触发关机，而无需软件干预。使用 snvs_pwrkey 驱动程序时，当按下按钮时，KEY_POWER 事件也会报告给用户空间。默认情况下，systemd 被配置为忽略此类事件。无软件干预的关机功能没有配置。可以在 /etc/systemd/logind.conf 中配置在按下开/关按钮时通过 systemd 触发关机：

+
HandlePowerKey=poweroff
+
+
+
+
+

7.20. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 8M Plus 提供一次性可编程fuse，用于存储信息，例如 MAC 地址、启动配置和其他永久设置（在 i.MX 8M Plus reference manual中称为“片上 OTP 控制器 (OCOTP_CTRL)”）。以下列表摘自 i.MX 8M Plus reference manual，包括 OCOTP_CTRL 中的一些有用寄存器（基地址为0x30350000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为0x30350000

描述

OCOTP_MAC_ADDR0

9

0

0x640

包含ENET0 MAC地址的低32位

OCOTP_MAC_ADDR1

9

1

0x650

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

OCOTP_MAC_ADDR2

9

2

0x660

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 8M Plus Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.20.1. 在uBoot中读取fuse的值

+

您可以使用内存映射的shadow寄存器读取fuse寄存器。要计算内存地址，请使用以下公式计算：

+

OCOTP_MAC_ADDR:

+
u-boot=> fuse read 9 0
+
+
+
+
+

7.20.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem
+
+
+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx9/imx9.html b/previews/271/zh_CN/bsp/imx9/imx9.html new file mode 100644 index 000000000..7e6dc6036 --- /dev/null +++ b/previews/271/zh_CN/bsp/imx9/imx9.html @@ -0,0 +1,156 @@ + + + + + + + + + i.MX 9 手册 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+ +
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx9/imx93/imx93.html b/previews/271/zh_CN/bsp/imx9/imx93/imx93.html new file mode 100644 index 000000000..d8c7722d2 --- /dev/null +++ b/previews/271/zh_CN/bsp/imx9/imx93/imx93.html @@ -0,0 +1,402 @@ + + + + + + + + + i.MX 93 手册 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

i.MX 93 手册

+
+

BSP-Yocto-NXP-i.MX93-PD24.2.0

+
+

目录

+ +
+
+
+

BSP-Yocto-NXP-i.MX93-PD24.1.1

+
+

目录

+ +
+
+
+

BSP-Yocto-NXP-i.MX93-PD24.1.0

+
+

目录

+ +
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx9/imx93/pd24.1.0.html b/previews/271/zh_CN/bsp/imx9/imx93/pd24.1.0.html new file mode 100644 index 000000000..4272d510b --- /dev/null +++ b/previews/271/zh_CN/bsp/imx9/imx93/pd24.1.0.html @@ -0,0 +1,3148 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 93 BSP手册

文档标题

i.MX 93 BSP手册

文档类型

BSP 手册

Yocto 手册

Mickledore

发布日期

2024/01/31

母文档

i.MX 93 BSP手册

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP发布日期

BSP 状态

BSP-Yocto-NXP-i.MX93-PD24.1.0

大版本

2024/01/31

已发布

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 phyBOARD-Segin i.MX 93 Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-91-93/#downloads 中找到。

+
+

1.1. 支持的硬件

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-NXP-i.MX93-PD24.1.0 的所有Machine及其对应的Article Numbers(产品型号)： 请参见 网页。

+

如果您在“Supported Machines”部分选择了特定的 Machine Name ，您可以查看该Machine下可用的 Article Number(产品型号) 以及硬件信息的简短描述。如果您只有硬件的 Article Number ，可以将 Machine Name 下拉菜单留空，仅选择您的 Article Number 。现在它会显示您特定硬件所需的 Machine Name 。

+
+

1.1.1. phyBOARD-Segin i.MX 93 器件

+
+../../../_images/phyBOARD-Segin-iMX93-top-components.jpg + +
+

phyBOARD-Segin i.MX 93 器件（顶部）

+
+
+
+../../../_images/phyBOARD-Segin-iMX93-bottom-components.jpg + +
+

phyBOARD-Segin i.MX 93 器件（底部）

+
+
+
+
+

1.1.2. phyBOARD-Nash i.MX 93 器件

+
+../../../_images/phyBOARD-Nash-iMX93-top-components.jpg + +
+

phyBOARD-Nash i.MX 93 器件（顶部）

+
+
+
+../../../_images/phyBOARD-Nash-iMX93-bottom-components.jpg + +
+

phyBOARD-Nash i.MX 93 器件（底部）

+
+
+
+
+
+
+

2. 开始使用

+

该 phyBOARD-Segin i.MX 93 Kit 包含预先烧写好的SD卡。它包含 phytec-qt6demo-image 镜像，可以直接用作启动盘。默认情况下，核心板上的eMMC仅烧写了U-Boot。您可以从 PHYTEC下载服务器 获取所有镜像资源。本章将解释如何将BSP镜像烧写到SD卡以及如何启动开发板。

+

有几种方法可以将镜像写入SD卡或eMMC。最为人熟知的方式是使用Linux命令行工具 dd 进行简单的顺序写入。另一种方法是使用PHYTEC的自研程序 partup ，它可以让格式化复杂系统的过程变得简单。您可以从其发布页面获取 预编译的Linux partup 二进制文件 。请阅读 partup的readme文件 来获取安装指导。

+
+

2.1. 下载镜像

+

phytec-qt6demo-image 镜像包含完整系统所需的所有必要文件，您需确保镜像中各个分区以及裸数据都会被正确写入启动盘。可以从 PHYTEC 下载服务器 下载 partup 镜像文件或者是可以使用 dd 进行烧写的 WIC 镜像。

+

从下载服务器获取 partup 镜像文件或WIC镜像：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz
+
+
+
+

备注

+

针对eMMC，我们建议使用partup去烧写比较大的或者是有复杂分区配置的镜像，因为它在写入速度上比 dd 更快，并且可以对闪存设备进行更灵活的配置。

+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要创建SD卡启动盘，必须要拥有Linux PC上的root权限。在选择烧写设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+
+

2.2.1. 寻找正确的设备

+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行命令：

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+

卸载所有这些分区，例如：

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

现在，SD卡已经准备好可以使用 partup 、 dd 或 bmap-tools 来写入镜像。

+
+
+

2.2.2. 使用bmap-tools

+

烧写SD卡的其中一种方法是使用 bmap-tools 。Yocto会自动为WIC镜像创建一个block map文件（ <IMAGENAME>-<MACHINE>.wic.bmap ），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host:~$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

将 <your_device> 替换为您之前找到的SD卡设备名称，并确保将文件 <IMAGENAME>-<MACHINE>.wic.bmap 与WIC镜像文件放在一起，以便bmaptool知道哪些块需要写入，哪些块需要跳过。

+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.2.3. 使用partup

+

使用partup烧写SD卡只需一个命令：

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).partup /dev/<your_device>
+
+
+

确保将 <your_device> 替换为您之前找到的设备名称。

+

关于partup的进一步使用说明，请参阅其 官方文档 。

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 release notes 。

+
+
+

备注

+

partup 具有清除eMMC user区域中特定区域的功能，我们提供的partup程序中用该功能擦除U-Boot环境变量。这是 bmaptool 工具所无法完成的一点，如前一部分所提到的。

+

partup相较于其他烧写工具的一个主要优势是，它可以配置MMC的特定部分，比如他可以直接写入eMMCboot分区，无需调用其他命令。

+
+
+
+

2.2.4. 使用 dd

+

在卸载所有SD卡的挂载分区后，您可以烧写SD卡。

+

一些PHYTEC BSP会生成未压缩的镜像（文件名扩展名为*.wic），而另一些则生成压缩的镜像（文件名扩展名为*.wic.xz）。

+

要写入未压缩的镜像（*.wic），请使用以下命令：

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

或者要写入压缩后的镜像（*.wic.xz），请使用以下命令：

+
host:~$ xzcat phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

再次确保将 <your_device> 替换为之前找到的设备名称。

+

参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

+
+
+
+

2.3. 首次启动

+ +../../../_images/SD_Card_Boot.png +
    +

  • 插入SD卡

    • +

  • 使用**RS232串口线**将开发板（serial connector on PEB-EVAL-01）和主机连接起来

    • +

  • 给开发板通电

    • +

  • 以115200波特率和8N1格式打开串口终端（您可以在终端上看到u-boot/linux启动信息）

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 93 BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (mickledore).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (mickledore).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-i.MX93 ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-wayland MACHINE=phyboard-segin-imx93-2 ./phyLinux init -p imx93 -r BSP-Yocto-NXP-i.MX93-PD24.1.0
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 phyboard-segin-imx93-2 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx93.bin: ARM可信固件二进制文件

    • +

  • lpddr4_dmem_1d_v202201.bin, lpddr4_dmem_2d_v202201.bin, lpddr4_imem_1d_v202201.bin, lpddr4_imem_2d_v202201.bin: DDR PHY 固件镜像

    • +

  • imx-boot：由imx-mkimage编译的bootloader镜像，包括SPL、U-Boot、ARM可信固件和DDR固件。这是最终的可引导bootloader镜像。

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx93-phyboard-segin.dtb: 内核设备树文件

    • +

  • imx93-phy*.dtbo: 内核设备树overlay文件

    • +

  • phytec-*.tar.gz: bitbake-image编译生成的root文件系统。

    +
      +

    • phytec-qt6demo-image-phyboard-segin-imx93-2.tar.gz：当bitbake-build的编译目标是``phytec-qt6demo-image``时

      • +

    • phytec-headless-image-phyboard-segin-imx93-2.tar.gz：当bibake-build的编译目标是``phytec-headless-image``时

      • +
    +
    • +

  • phytec-*.wic.xz：bitbake-image编译生成的压缩的可引导SD卡镜像，包括bootloader、设备树二进制文件（DTB）、内核和根文件系统。

    +
      +

    • phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz：当bitbake-build的编译目标是``phytec-qt6demo-image``时

      • +

    • phytec-headless-image-phyboard-segin-imx93-2.wic.xz：当bibake-build的编译目标是``phytec-headless-image``时

      • +
    +
    • +

  • imx93-11x11-evk_m33_*.bin，Cortex-M33 MCU的Demo应用程序的二进制文件；可以通过U-Boot或Linux手动加载和启动

    • +
+
+
+
+
+

4. 安装操作系统

+
+

4.1. 启动模式开关 (S3)

+
+

小技巧

+

底板硬件版本：1472.5

+
+

该 phyBOARD-Segin i.MX 93 具有一个（启动源配置）开关，配有四个可单独切换的位，用于选择phyCORE-i.MX 93 默认的启动源。

+ + + + + + + + + +
+../../../_images/eMMC.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses.png +
+

内部fuse

+
+
+
+../../../_images/USB_Serial_Download.png +
+

USB

+
+
+
+../../../_images/SD_Card_Boot.png +
+

SD卡

+
+
+
+
+
+

4.2. 烧写eMMC

+

要从 eMMC 启动，请确保 BSP 镜像已正确烧写到 eMMC，并且 bootmode switch (S3) 设置为 eMMC。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行以检查当前设置是否受到影响。如果 mmcblk0p1 和 mmcblk1p1 具有相同的 UUID，则该设置受到影响。

+
+
+

4.2.1. 从SD卡烧写eMMC

+

如果没有可用的网络，您可以通过SD卡更新eMMC。为此，您只需在SD卡上准备一个可用的镜像文件（*.wic）。由于镜像文件相当大，您需要扩展SD卡以使用其全部空间（如果之前没有扩展的话）。有关如何扩展SD卡，请参见“调整 ext4 根文件系统的大小”。

+

或者，使用partup包烧写SD卡，如 Getting Started 中所述。这样就可使用SD卡的全部容量。

+
+

4.2.1.1. 在开发板的linux环境中通过SD卡烧写eMMC

+

您可以在Linux上烧写eMMC。您只需在SD卡上保存一个partup包或WIC镜像即可。

+
    +

  • 在SD卡上查看您保存的partup包或WIC镜像或WIC.XZ镜像文件：

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.partup
+phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz
+
    +
    +
    • +

  • 显示可用的MMC设备列表：

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk0
+mmcblk0boot0
+mmcblk0boot1
+mmcblk0p1
+mmcblk0p2
+mmcblk0rpmb
+
    +
    +
    • +

  • eMMC设备的特征是它包含两个boot分区：(mmcblk0 boot0; mmcblk0 boot1)

    • +

  • 使用 partup 将镜像写入 phyCORE-i.MX 93 的 eMMC (/dev/mmcblk0 不带 分区)：

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-segin-imx93-2.partup /dev/mmcblk0
+
    +
    +
    +

    小技巧

    +

    强烈建议使用partup，因为它更易于使用，并且可以充分利用eMMC设备的容量，自动调整分区大小。

    +
    +
    +

    备注

    +

    或者，可以使用 dd 命令。

    +

    对于未压缩的WIC镜像（*.wic）：

    +
    target:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.wic of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +

    对于压缩的WIC镜像（*.wic.xz）：

    +
    target:~$ zstdcat phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz | sudo dd of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +

    请注意，在使用 dd 进行烧写时，root分区并没有使用全部存储容量。

    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    警告

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+
+

4.2.2. 从网络烧写 eMMC

+

i.MX 93 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

备注

+

一些PHYTEC的BSP会生成压缩的 .wic.xz 镜像。在这种情况下，必须先对压缩镜像进行解压缩。

+
host:~$ unxz phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz
+
+
+
+
+

4.2.2.1. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

在主机上获取一个未压缩的镜像，并通过网络使用ssh将其发送到开发板的eMMC，使用一行命令：

+
target:~$ ssh <USER>@192.168.3.10 "dd if=<path_to_file>/phytec-qt6demo-image-phyboard-segin-imx93-2.wic" | dd of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
+
+
+
+

4.2.2.2. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

查看主机上可用的镜像文件：

+
host:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.wic
+
+
+

通过网络使用 dd 命令结合ssh将镜像发送到您设备的eMMC：

+
host:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.wic bs=1M status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk0 conv=fsync"
+
+
+
+
+
+

4.2.3. 在运行的U-Boot中通过网络烧写eMMC U-Boot镜像

+

可以在U-Boot中更新U-Boot镜像imx-boot，eMMC上的U-Boot需要位于eMMC的user区域。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 0
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.4. 从USB烧写eMMC

+
+

4.2.4.1. 在运行的Linux系统中从USB烧写eMMC

+

下面这些步骤展示如何在Linux系统上使用USB大容量存储设备烧写eMMC。您需要一个保存了完整镜像的U盘和一个可从SD卡启动的核心板（例如 phytec-qt6demo-image-phyboard-segin-imx93-2.wic）。将 bootmode switch (S3) 设置为SD卡启动。

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ cd /mnt
+target:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.wic
+
    +
    +
    • +

  • 显示可用的MMC设备列表：

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk0
+mmcblk0boot0
+mmcblk0boot1
+mmcblk0p1
+mmcblk0p2
+mmcblk0rpmb
+
    +
    +
    • +

  • eMMC设备的特征是它包含两个boot分区：(mmcblk0 boot0; mmcblk0 boot1)

    • +

  • 将镜像写入 phyCORE-i.MX 93 eMMC (/dev/mmcblk0，无分区)：

    +
    target:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.wic of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    小技巧

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+
+
+

4.3. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC：L-1006e.A5 RAUC更新与设备管理手册。

+
+
+
+

5. 开发

+
+

5.1. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.1.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.2. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.2.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核镜像复制到您的tftp目录中：

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • 将设备树复制到您的tftp目录：

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • 将您想要使用的所有overlay文件复制到您的tftp目录中：

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-segin-imx93-2.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.2.2. 设置网络启动的bootenv.txt文件

+

在您的tftp目录中创建一个bootenv.txt文件，并将以下变量写入其中。

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> 必须替换为您想要使用的overlay设备树文件名。用空格分隔文件名。例如：

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

小技巧

+

所有支持的设备树overlay在 device tree 章节中。

+
+
+
+

5.2.3. 开发板上的网络设置

+

如果要自定义开发板上的以太网配置，请按照此处的说明进行操作： Network Environment Customization

+
+
+

5.2.4. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.3.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. 获取镜像

+

可以从我们的服务器下载imx-boot，或者从Yocto编译目录中的build/deploy/images/phyboard-segin-imx93-2/获取它。要将wic镜像烧写到eMMC，你还需要 phytec-qt6demo-image-phyboard-segin-imx93-2.wic。

+
+
+

5.3.3. 开发板准备

+

将 bootmode switch (S3) 设置为 USB串行下载。同时，将 USB 端口 X8 (USB micro/OTG connector) 连接到主机。

+
+
+

5.3.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 serial connector on PEB-EVAL-01 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.3.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 0 0 0 0
+u-boot=> mmc partconf 0
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-segin-imx93-2.wic
+
+
+
+
+
+

5.4. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone git://git.phytec.de/u-boot-imx）

+
+
+

5.4.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-imx 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • 我们的 i.MX 93 内核是基于 linux-imx 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. 获取SDK

+

您可以在此处下载SDK 这里，或者使用Yocto去编译生成SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

在成功编译后，SDK安装包保存在 build/deploy*/sdk。

+
+
+

5.4.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-vendor-wayland-glibc-x86_64-phytec-qt6demo-image-cortexa55-toolchain-4.2.2.sh
+host:~$ ./phytec-ampliphy-vendor-wayland-glibc-x86_64-phytec-qt6demo-image-cortexa55-toolchain-4.2.2.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-wayland/4.2.2):
+You are about to install the SDK to "/opt/ampliphy-vendor-wayland/4.2.2". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-vendor-wayland/4.2.2/environment-setup-cortexa55-phytec-linux
+
+
+
+
+

5.4.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. 单独编译U-Boot

+
+

5.5.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本的 tag 称为 v2023.04_2.1.0-phy1

    • +

  • 查看所需的 U-Boot tag：

    • +
+
host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2023.04_2.1.0-phy1
+
+
+
    +

  • 从技术上讲，您现在可以编译U-Boot，但实际上还需要一些进一步的步骤：

    +
      +

    • 创建您自己的开发分支：

      +
      host:~/u-boot-imx$ git switch --create <new-branch>
+
      +
      +
      +

      备注

      +

      您可以根据您的需要自行命名您的开发分支，这只是一个示例。

      +
      +
      • +
    +
    • +

  • 设置编译环境：

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor-wayland/4.2.2/environment-setup-cortexa55-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. 获取所需的二进制文件

+

要编译imx-boot，您需要 收集 这些 文件 以便后续使用 imx-mkimage工具 ：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx93.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +

  • 容器镜像：mx93a1-ahab-container.img

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以从此处提到的目录中获取这些文件：BSP Images

+

或者您可以从PHYTEC下载服务器（ https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools/ ）下载文件。您可以使用下面的命令从该服务器下载所有文件：

+
host:~$ mkdir ./artefacts && cd ./artefacts
+host:~/artefacts$ wget \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//bl31-imx93.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//tee.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_dmem_1d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_dmem_2d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_imem_1d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_imem_2d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//mx93a1-ahab-container.img
+host:~/artefacts$ cd ..
+
+
+
+
+

5.5.3. 编译bootloader

+
    +

  • 编译u-boot：

    +
    host:~/u-boot-imx$ make <defconfig>
+host:~/u-boot-imx$ make
+host:~/u-boot-imx$ cd ..
+
    +
    +
    +

    备注

    +

    In command above replace <defconfig> with phycore-imx93_defconfig.

    +
    +
    • +
+
+

5.5.3.1. 使用 imx-mkimage 编译最终的 flash.bin

+
    +

  • 获取 imx-mkimage：

    +
    host:~$ git clone https://github.com/nxp-imx/imx-mkimage
+host:~$ cd imx-mkimage/
+host:~/imx-mkimage$ git checkout tags/lf-6.1.36_2.1.0
+
    +
    +
    • +

  • 将固件二进制文件复制到 imx-mkimage

    +
    host:~/imx-mkimage$ cp ../artefacts/bl31-imx93.bin ./iMX9/bl31.bin
+host:~/imx-mkimage$ cp \
+                     ../artefacts/lpddr4_* \
+                     ../artefacts/mx93a1-ahab-container.img \
+                     ../artefacts/tee.bin \
+                     ./iMX9/
+
    +
    +
    • +

  • 将u-boot二进制文件和DTB复制到imx-mkimage中

    +
    host:~/imx-mkimage$ cp ../u-boot-imx/spl/u-boot-spl.bin ../u-boot-imx/u-boot.bin ./iMX9/
+host:~/imx-mkimage$ cp ../u-boot-imx/arch/arm/dts/<dtb> ./iMX9/
+
    +
    +
    +

    备注

    +

    In command above replace <dtb> with imx93-phyboard-segin.dtb.

    +
    +
    • +

  • 编译最终的 flash.bin 二进制文件

    +
    +
    host:~/imx-mkimage$ make SOC=iMX9 REV=A1 flash_singleboot
+
    +
    +
    +
    • +
+
+
+
+

5.5.4. 将bootloader烧写到块设备上

+

flash.bin可以在imx-mkimage/iMX9/目录下找到，现在可以进行烧写。需要一个特定于芯片的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 93

32 kiB

0 kiB

/dev/mmcblk0

+

例如，烧写SD卡：

+
host:~/imx-mkimage$ sudo dd if=./iMX9/flash.bin of=<sd-card> bs=1024 seek=32 conv=sync
+
+
+
+

备注

+

In the command above, replace <sd-card> with your sd-card device name. +For more information on how to find the device name, see the section +Finding the Correct Device in +Getting Started.

+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+
+

5.6. 单独编译内核

+
+

5.6.1. 配置源代码

+
    +

  • 使用的 linux-imx 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v6.1.36_2.1.0-phy1

    • +

  • Check out 所需的 linux-imx 标签：

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v6.1.36_2.1.0-phy1
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor-wayland/4.2.2/environment-setup-cortexa55-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-imx$ make imx_v8_defconfig imx9_phytec_distro.config imx9_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-imx/arch/arm64/boot/Image 找到

    • +

  • dtb文件可以在 ~/linux-imx/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. 将内核复制到SD卡

+

内核及module和对应的设备树二进制文件可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.7.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.7.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将 phytec-qt6demo-image-phyboard-segin-imx93-2.wic 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-segin-imx93-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.7.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将 phytec-qt6demo-image-phyboard-segin-imx93-2.wic 镜像复制到其中。然后卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-segin-imx93-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 93 BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 93 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Board.dts - 包含module dtsi 文件。从SoC i.MX 93 引出并在底板使用的设备也包含在此 dts 中。

    • +

  • Overlay.dtso - 根据核心板或底板上可选硬件（例如 SPI 闪存或 PEB-AV-10）的情况来启用/禁用一些功能。

    • +
+

在Linux内核的根目录下，我们的 i.MX 9 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。下面是扩展板的硬件描述。对比源码中的include，overlay通过覆盖的方式来生效。overlay也可以根据实际开发板的硬件配置来设置设备树节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/ 中。

+

phyboard-segin-imx93-2.conf 可用的overlay文件有：

+
imx93-phyboard-segin-peb-av-02.dtbo
+imx93-phyboard-segin-peb-eval-01.dtbo
+imx93-phycore-rpmsg.dtbo
+
+
+

可以在Linux或U-Boot环境下配置overlay。overlay是在引导命令调用后、内核加载之前生效。接下来的部分将更详细地解释配置方法。

+
+

6.2.2.1. 设置 ${overlays} 变量

+

${overlays} U-Boot 环境变量包含一个以空格分隔的overlay文件列表，这些overlay文件将在启动过程中应用。根据启动源，overlay文件必须放置在 eMMC/SD 卡的启动分区中，或者通过 tftp 加载。在 $KERNEL_DEVICETREE 这个 Yocto machine 变量中设置的 overlay 文件将自动添加到最终 WIC 镜像的启动分区中。

+

${overlays} 变量可以直接在U-Boot环境中设置，也可以作为外部 bootenv.txt 环境文件的一部分。默认情况下， ${overlays} 变量来自位于启动分区的 bootenv.txt 文件。您可以在已启动的开发板上从Linux读取和写入该文件：

+
target:~$ cat /boot/bootenv.txt
+overlays=imx93-phyboard-segin-peb-eval-01.dtbo imx93-phyboard-segin-peb-av-02.dtbo
+
+
+
+

备注

+

确保boot分区已挂载！如果没有，您可以使用以下命令进行挂载：

+
target:~$ mount /dev/mmcblkXp0 /boot
+
+
+
+

更改将在下次重启后生效。如果没有可用的 bootenv.txt 文件，可以直接在U-Boot环境中设置overlay变量。

+
u-boot=> setenv overlays imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> printenv overlays
+overlays=imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> boot
+
+
+

如果用户定义了 ${overlays} 变量，同时存在 bootenv.txt 文件，则需要设置 ${no_bootenv} 变量：

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> boot
+
+
+

有关环境的更多信息，请参见 U-boot External Environment subsection of the +device tree overlay section。

+

我们使用 ${overlays} 变量来描述在运行时无法检测到的扩展板。为了禁止在启动时应用列在 ${overlays} 变量中的overlay，可以在bootloader环境中将 ${no_overlays} 变量设置为 1。

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot外部环境

+

在Linux内核启动时，外部环境 bootenv.txt 文本文件将从MMC设备的boot分区或通过TFTP加载。该文件的主要目的是存储 ${overlays} 变量。这可以针对不同的machine在Yocto中预定义不同的overlay配置。文件的内容在meta-phytec中的Yocto recipe中的bootenv中定义： https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=mickledore

+

该文件中也可以设置其他变量。这些变量将覆盖环境中现有的设置。但只有对boot命令后进行计算的变量生效，例如 ${nfsroot} 或 ${mmcargs}。在文件中更改其他变量将不会有作用。以网络启动的用法作为示例。

+

如果无法加载外部环境，启动过程将继续进行，并使用自带的环境变量值。

+
+
+

6.2.4. 在Linux环境下更改开发板上的U-boot环境变量

+

Libubootenv是我们镜像中包含的一个工具，用于在开发板linux上修改U-Boot环境。

+

使用以下命令打印U-Boot环境：

+
target:~$ fw_printenv
+
+
+

使用以下命令修改U-Boot环境：

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

小心

+

Libubootenv会读取配置文件中配置的环境变量。要修改的环境变量会被插入到该文件中，默认情况下使用eMMC中存储环境变量。

+

如果eMMC没有被烧写过或者eMMC环境被擦除，libubootenv将无法工作。您应该修改 /etc/fw_env.config 文件，以匹配您想要使用的环境源。

+
+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 93 BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 93 BSP设备树概念部分，以了解我们的 i.MX 9 BSP设备树模型。

+

以下部分概述了 i.MX 9 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 93 引脚复用

+

该 i.MX 93 Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 93 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 93 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是 imx93-phyboard-segin.dts中UART1设备的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX93_PAD_UART1_RXD__LPUART1_RX     0x31e
+                MX93_PAD_UART1_TXD__LPUART1_TX     0x30e
+        >;
+};
+
+
+

字符串的第一部分 MX93_PAD_UART1_RXD__LPUART1_RX 指定了引脚（在这个例子中是 UART1_RXD）。字符串的第二部分（LPUART1_RX）是该引脚的期望复用选项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部上拉电阻是否被激活。在当前情况下，内部上拉电阻被激活。

+

UART1引脚复用的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n267

+
+
+

7.2. 网络

+

phyBOARD-Segin i.MX 93-i.MX 93 提供两个以太网接口。我们的核心板和底板各提供一个百兆以太网。

+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi?h=v6.1.36_2.1.0-phy1#n61。

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Segin i.MX 93 can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n114.

+
+

7.2.1. 网络配置

+
+

7.2.1.1. U-boot网络环境

+
    +

  • 要在bootloader中查找以太网设置：

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • 在将主机设置为IP 192.168.3.10和子网掩码255.255.255.0的情况下，开发板应该返回：

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • 如果您需要进行任何更改：

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> 应该是 ipaddr、netmask、gatewayip 或 serverip 中的一个。<value> 将是所选参数的设定值。

    +
    • +

  • 您所做的更改目前是临时的。要保存这些更改：

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

在这里，您也可以将IP地址更改为DHCP，而不是使用静态IP地址。

+
    +

  • 配置：

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • 设置 TFTP 和 NFS 的路径。修改可以如下所示：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+

小技巧

+

像nfsroot和netargs这样的变量可以被U-boot外部环境重新赋值。对于网络启动，外部环境将通过tftp加载。例如，要在 bootenv.txt 文件中设置nfsroot变量，请在tftproot目录修改：

+
nfsroot=/home/user/nfssrc
+
+
+

无需在开发板上存储这些信息。请注意，U-boot外部环境对于像 ipaddr 或 serveraddr 这样的变量不起作用，因为它们在加载外部环境之前已经被设置完成。

+
+
+
+

7.2.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+
+

7.3. SD/MMC 卡

+

该 i.MX 93 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

MMC（SD卡插槽）接口的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n216

+

eMMC接口的DT配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi?h=v6.1.36_2.1.0-phy1#n195

+
+
+

7.4. eMMC设备

+

PHYTEC模块如phyCORE-i.MX 93 配备了eMMC存储芯片作为主要存储。eMMC设备使用多层单元（MLC）或三层单元（TLC）技术来实现存储，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 93 ，并在Linux内核中作为块设备表示，如SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.4.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk0
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.4.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），该层负责处理原始MLC或TLC的磨损均衡、块管理和错误更正码（ECC）。这需要定期执行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 通过以下命令使能BKOPS_EN：

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops_en manual /dev/mmcblk0
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.4.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 93 SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk0 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.4.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk0 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk0: 7617MB
+Sect[ 1799.850385]  mmcblk0: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk0 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk0 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk0: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk0: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk0p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk0p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk0p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk0p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
+
+

7.4.5. 启用伪SLC模式

+

eMMC设备使用 MLC或TLC 来存储数据。与NAND Flash中使用的SLC相比，MLC或TLC在成本更低的情况下，可靠性较低且错误率较高。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk0 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk0:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk0
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk0
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk0 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk0 unit B print
+BYT;
+/dev/mmcblk0:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.4.6. 擦除设备

+

可以直接擦除eMMC设备，而不是通过写零覆盖。eMMC块管理算法将擦除底层的MLC或TLC，或者将这些块标记为可丢弃。设备上的数据将丢失，并将被读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk0
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk0 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.4.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 93 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.4.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk0boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk0boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk0boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk0boot1
+
+
+

下表是 i.MX 93 SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 93

32 kiB

0 kiB

/dev/mmcblk0

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk0
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk0
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk0
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk0
+
+
+
+
+

7.4.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk0
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk0p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk0p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk0
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk0p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk0p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk0p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk0p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk0p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.5. GPIOs

+

phyBOARD-Segin i.MX 93 没有用户可以使用的GPIO，因为所有GPIO都被内核设备驱动程序使用或用于其他特定目的。处理器将其GPIO组织为五个32个GPIO的组（GPIO1 – GPIO4）。gpiochip0、gpiochip32、gpiochip64和gpiochip96是这些内部 i.MX 93 GPIO组GPIO1 – GPIO4的sysfs表示。

+

GPIO被标识为GPIO<X>_<Y>（例如，GPIO4_07）。<X>标识GPIO Bank，并从1到4计数，而<Y>表示Bank内的GPIO。<Y>从0到31计数（每个Bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [43810080.gpio] (32 lines)
+gpiochip1 [43820080.gpio] (32 lines)
+gpiochip2 [43830080.gpio] (32 lines)
+gpiochip3 [47400080.gpio] (32 lines)
+
    +
    +
    • +
+
+

备注

+

Order of GPIOchips in i.MX 93 Application Processor Reference Manual and +in Linux kernel differ!

+ + + + + + + + + + + + + + + + + + + + + + + +

GPIOchip 地址

Linux

Reference Manual

0x43810080

gpiochip0

gpiochip2

0x43820080

gpiochip1

gpiochip3

0x43830080

gpiochip2

gpiochip4

0x47400080

gpiochip3

gpiochip1

+
+
    +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如，从chip0读取GPIO 3）：

    +
    target:~$ gpioget gpiochip0 3
+
    +
    +
    • +

  • 将chip0上的GPIO 3的值设置为0并退出：

    +
    target:~$ gpioset --mode=exit gpiochip0 3=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.5.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用CONFIG_GPIO_SYSFS后才能支持。要使CONFIG_GPIO_SYSFS在menuconfig中可见，必须先启用CONFIG_EXPERT选项。

+

您还可以将此选项添加到Linux内核源代码中arch/arm64/configs下的imx9_phytec_distro.config配置片段中，例如：

+
..
+CONFIG_GPIO_SYSFS=y
+..
+
+
+
+
+
+

7.6. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+green:heartbeat@  mmc0::@  mmc1::@  yellow:@
+
+
+

这里的LED灯 green:heartbeat 位于 phyCORE-i.MX93 上。如果您使用的是phyBOARD-Segin，PEB-EVAL-01上还有一个 黄色 LED灯。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 1 > /sys/class/leds/green\:heartbeat/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/green\:heartbeat/brightness
+
    +
    +
    • +
+

GPIO配置的设备树配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-eval-01.dtso?h=v6.1.36_2.1.0-phy1#n33

+
+
+

7.7. I²C总线

+

该 i.MX 93 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 93 的I²C模块。 本节描述了我们 phyBOARD-Segin i.MX 93 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

I²C1总线DT配置（例如 imx93-phycore-som.dtsi）： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi?h=v6.1.36_2.1.0-phy1#n88

+

I²C2总线DT配置（例如 imx93-phyboard-segin.dts）: imx-dt:imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n155

+
+
+

7.8. EEPROM

+

在 phyCORE-i.MX93 SoM和 phyBOARD-Segin i.MX 93 上有两个不同的I2C EEPROM存储。目前只有 phyCORE-i.MX93 上的存储被启用，它用于硬件检测。

+
+

7.8.1. phyCORE-i.MX93 上的I2C EEPROM

+

phyCORE-i.MX93 SoM上的I2C EEPROM的空间被划分两部分。

+
    +

  • 正常区域（大小：4096字节，总线：I2C-2，地址：0x50）

    • +

  • ID页面（大小：32字节，总线：I2C-2，地址：0x58）

    • +
+

可以从设备进行读写操作：

+
target:~$ hexdump -C /sys/class/i2c-dev/i2c-2/device/2-0058/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-2/device/2-0050/eeprom bs=1 count=1024  | od -x
+
+
+

要将整个EEPROM（ID页）填充为零，我们首先需要禁用EEPROM写保护，请使用：

+
target:~$ gpioset 2 21=0
+
+
+

然后可以写入EEPROM：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-2/device/2-0058/eeprom bs=32 count=1
+
+
+
+

警告

+

正常EEPROM区域的前256个字节（总线：I2C-2 地址：0x50）是保留的，不应被覆盖！ （见下文）

+
+
+
+

7.8.2. EEPROM SoM 检测

+

PHYTEC在EEPROM正常区域的前256字节中存储有关核心板的信息。这包括PCB版本和贴装选项。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果正常区域的前256个字节被删除，启动加载程序将回退到 phyCORE-i.MX93 开发板内存配置，即 1GiB RAM。

+
+

警告

+

正常EEPROM区域的前256个字节（总线：I2C-2 地址：0x50）不应被擦除或损坏！这可能会影响bootloader的行为。板子可能无法正确启动。

+
+
+
+

7.8.3. 恢复EEPROM数据

+

硬件自检数据已预先写入EEPROM数据空间。如果您不小心删除或覆盖了数据，请联系我们的支持团队！

+

phyCORE-i.MX 93 核心板的设备树可以在我们的PHYTEC Git中找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi?h=v6.1.36_2.1.0-phy1#n173

+
+
+
+

7.9. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.9.1. RTC唤醒alarm

+

可以从实时时钟（RTC）发出中断以唤醒系统。该格式使用Unix纪元时间，即自1970年1月1日UTC午夜以来的秒数。要在从挂起到RAM状态后的4分钟唤醒系统，请输入：

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

备注

+

内部唤醒alarm时间将被向上舍入到下一个分钟，因为alarm功能不支持秒。

+
+
+
+

7.9.2. RTC参数

+

实时时钟（RTC）具有一些功能，可以通过 hwclock 工具进行读取和设置。

+
    +

  • 我们可以通过以下方式检查RTC支持的功能：

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    这个值的含义在内核中进行了编码，每个位的定义为：

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • 我们可以通过以下方式检查RTC BSM（Backup Switchover Mode 备份切换模式）：

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • 我们可以通过以下方式设置RTC BSM：

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    BSM位的定义为：

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    小技巧

    +

    您应该将BSM模式设置为DSM或LSM，以便在初始电源不可用时，RTC可以切换到备用电源。请查看 RV-3028 RTC的Datasheet，以了解LSM（电平切换模式）和DSM（直接切换模式）这两个定义的工作模式。

    +
    +
    • +
+

I²C RTC的DT表示： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n173

+
+
+
+

7.10. USB主控制器

+

i.MX 93 SoC 的 USB 控制器为众多消费类便携设备提供了一种低成本的连接解决方案，传输速度高达 480 Mbps （高速 'HS'）。USB 子系统具有两个独立的 USB 控制器。两个控制器都能够充当 USB Device或 USB Host，但在 phyBOARD-Segin i.MX 93 上，其中一个被用作仅Host端口（USB-A 连接器）。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+

OTG端口提供了一个额外的引脚用于过流保护，但在 phyBOARD-Segin i.MX 93 上并未使用。由于未使用，该引脚在设备树中也被禁用。如果需要使用该引脚，请在设备树中激活过流保护，并根据设备规格设置正确的极性（高电平/低电平）。有关正确的设置，请参考Linux内核文档中的Linux/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt。

+

USB主机的DT：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n190

+
+
+

7.11. CAN FD

+

phyBOARD-Segin i.MX 93 具有一个支持CAN FD的flexCAN接口。它们由Linux标准CAN框架支持，该框架建立在Linux网络层之上。使用该框架，CAN接口表现得像普通的Linux网络设备，并具有一些特定于CAN的附加功能。更多信息可以在Linux内核文档中找到：https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。CAN接口应该显示为can0。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
+   link/can  promiscuity 0  allmulti 0 minmtu 0 maxmtu 0
+   can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+         bitrate 500000 sample-point 0.875
+         tq 25 prop-seg 37 phase-seg1 32 phase-seg2 10 sjw 1 brp 1
+         flexcan: tseg1 2..96 tseg2 2..32 sjw 1..16 brp 1..1024 brp_inc 1
+         flexcan: dtseg1 2..39 dtseg2 2..8 dsjw 1..4 dbrp 1..1024 dbrp_inc 1
+         clock 40000000
+         re-started bus-errors arbit-lost error-warn error-pass bus-off
+         0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 parentbus platform parentdev 443a0000.can
+   RX:  bytes packets errors dropped  missed   mcast
+            0       0      0       0       0       0
+   TX:  bytes packets errors dropped carrier collsns
+            0       0      0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+

imx93-phyboard-segin.dts的设备树CAN配置: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n147

+
+
+

7.12. 音频

+

在 phyBOARD-Segin i.MX 93 上使用了 TI TLV320AIC3007 音频编解码器（CODEC）。它使用 I2S 进行数据传输，使用 I2C 进行控制。可用的音频信号有：

+
    +

  • 立体声 LINE IN，

    • +

  • 立体声 LINE OUT，

    • +

  • Class D 1W的扬声器输出

    • +
+

要检查您的声卡驱动程序是否正确加载以及设备名称，请输入以下命令以查看播放设备：

+
target:~$ aplay -L
+
+
+

或输入录音设备：

+
target:~$ arecord -L
+
+
+
+

7.12.1. Alsamixer

+

要检查声卡的功能，请输入：

+
target:~$ alsamixer
+
+
+

您应该会看到很多选项，因为音频IC具有许多可以测试的功能。通过SSH打开alsamixer的图形界面比通过调试串口打开更易于使用。所有混音点都有单声道或立体声增益控制。"MM"表示该功能被静音（左右输出均为静音），可以通过按' m '切换。您还可以通过按' < ' 左和 ' > '切换右声道输出。使用 tab 键，您可以在播放和录音控制之间切换。

+
+
+

7.12.2. 恢复默认音量

+

一些默认设置存储在 /var/lib/alsa/asound.state 中。您可以使用以下命令保存当前的alsa设置：

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

您可以通过以下方式恢复已保存的alsa设置：

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.12.3. 播放

+

运行speaker-test以检查播放功能：

+
target:~$ speaker-test -c 2 -t wav
+
+
+

要播放简单的音频流，您可以使用aplay。例如，要播放ALSA测试音频：

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

要播放其他格式，例如mp3，您可以使用Gstreamer：

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+

如果扬声器音量太低，可以增加音量（值范围 0-3）：

+
target:~$ amixer -c 0 sset Class-D 3
+
+
+
+

提示

+

扬声器输出仅为单声道，因此当播放立体声轨道时，扬声器只会播放左声道。

+
+
+
+

7.12.4. 录音

+

arecord 是一个命令行工具，用于捕获音频流，默认输入源为线路输入（Line In）。

+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

提示

+

由于播放和录音共享硬件接口，因此无法在同时进行播放和录音操作时使用不同的采样率和格式。

+
+

设备树音频配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.36_2.1.0-phy1#n62

+
+
+
+

7.13. 视频

+
+

7.13.1. 视频与Gstreamer

+

默认情况下，BSP安装了一个示例视频，路径为 /usr/share/qtphy/videos/ 。可以使用以下命令之一开始视频播放：

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.14. 显示

+

phyBOARD-Segin i.MX 93 支持 PEB-AV-02，配备 7 英寸的 edt,etm0700g0edh6 并口显示屏和电容触摸屏。该显示屏的设备树overlay在 BOOT/bootenv.txt 中默认启用！

+

phyBOARD-Nash i.MX 93需要额外的扩展板来支持10英寸的 edt,etml1010g3dra LVDS显示器和电容触摸。PEB-AV-10（1531.1修订版）可以单独购买。该LCD的overlay在 BOOT/bootenv.txt 中默认启用！

+
+

7.14.1. Qt Demo

+

使用 phytec-qt6demo-image 时，Weston会在启动时启动。我们的Qt6 DEMO应用程序名为“qtphy”，可以通过以下方式停止：

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • 要重新开始Demo，请运行：

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • 要禁用Demo的自动启动，请运行：

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • 要启用Demo的自动启动，请运行：

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston可以通过以下方式停止：

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

备注

+

在关闭Weston之前，必须先关闭Qt Demo。

+
+
+
+

7.14.2. 背光控制

+

如果LCD连接到PHYTEC开发板，可以通过Linux内核的sysfs接口控制其背光。系统中所有可用的背光设备可以在文件夹/sys/class/backlight中找到。读取相应的文件并向其写入数据可以控制背光。

+
+

备注

+

一些具有多显示的开发板在 /sys/class/backlight 有多个背光控制。比如：backlight0和backlight1

+
+
    +

  • 例如，要获取最大亮度级别（max_brightness），请执行：

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    有效的亮度值范围是 0 到 <max_brightness>。

    +
    • +

  • 要获取当前亮度级别，请输入：

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • 写入文件brightness以更改亮度：

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    例如，关闭背光。

    +

    有关所有文件的文档，请参见 https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight。

    +
    • +
+

PEB-AV-02的设备树可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-02.dtso?h=v6.1.36_2.1.0-phy1

+
+
+
+

7.15. 电源管理

+
+

7.15.1. CPU核心频率调节

+

i.MX 93 SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。与i.MX8 M系列不同，i.MX 93不支持 动态 电压和频率调整（DVFS），但支持简化的 电压和频率调整（VFS） 。可以进入以下模式：

+
    +

  • nominal（ND），

    • +

  • overdrive （OD），

    • +

  • Low Drive（LD）和

    • +

  • Low Drive（LD）与软件快速频率变化（SWFFC）。

    • +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

模式

CPU频率

DDR数据速率

VDD_SOC

OverDrive (OD)

1.7 GHz

3733 MT/s

900mV

NominalDrive (ND)

1.4 GHz

1866 MT/s

850mV

LowDrive (LD)

900 MHz

1866 MT/s

800mV

带有SWFFC的LowDrive（LD）

900 MHz

625 MT/s

800mV

+

i.MX 93 BSP支持VFS功能。Linux内核提供了一个LPM驱动程序，可以设置VDD_SOC、CPU频率和DDR速度。

+
+

备注

+

Low-cost i.MX 93 SoC variants such as parts numbers NXP IMX9301/IMX9302 do not +support VFS features. Those SoCs always run in LowDrive (LD) mode. Hence, +the Linux LPM driver is disabled automatically for SoMs with such SoCs.

+
+
    +

  • 要将设备置于 OverDrive（OD） 模式，请输入：

    +
    +
    target:~$ echo 0 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • 要将设备置于 NominalDrive（ND） 模式，请输入：

    +
    +
    target:~$ echo 1 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • 要将设备置于 LowDrive（LD） 模式，请输入：

    +
    +
    target:~$ echo 2 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • 将设备置于 LowDrive（LD） 模式，使用最低DDR速度，SWFFC类型：

    +
    +
    target:~$ echo 3 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • 要检查当前的CPU频率，请输入：

    +
    +
    target:~$ mhz
+
    +
    +
    +
    • +

  • 要检查当前模式和DDR频率，请输入：

    +
    +
    target:~$ cat /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • 要检查当前的 VDD_SOC 类型，请输入：

    +
    +
    target:~$ cat /sys/kernel/debug/regulator/regulator_summary
+
    +
    +
    +
    • +
+

有关LPM驱动程序和模式的更详细信息，请参考NXP的文档：https://docs.nxp.com/bundle/AN13917/page/topics/low_power_mode_use_cases.html

+
+
+

7.15.2. CPU核心管理

+

i.MX 93 SoC 在芯片上拥有多个处理器核心。例如，i.MX 93 具有 2 个 ARM 核，这些核可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0/
+cpu1/
+cpufreq/
+[...]
+
    +
    +

    这里系统有两个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu1/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU1 killed (polled 0 ms)
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu1/online
+
    +
    +
    • +
+
+
+

7.15.3. 挂起到RAM

+

phyCORE-i.MX93 支持基本的挂起和恢复。可以使用不同的唤醒源。挂起/恢复可以通过以下方式实现：

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

要通过串行控制台唤醒，请运行

+
target:~$ echo enabled > /sys/class/tty/ttyLP0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+

设备可以通过PEB-EVAL-01的S2按钮进入休眠状态并唤醒

+

要通过RTC闹钟唤醒，请检查：RTC Wakealarm

+
+
+
+

7.16. 热管理

+
+

7.16.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.16.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 93 SoC 平台上使用热管理内核 API。 i.MX 9 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个温度阈值。这些阈值根据CPU型号的不同而有所区别。包括商业级、工业级和扩展工业级。

+ + + + + + + + + + + + + + + + + + + + +

商业

工业

扩展工业级

被动（警告）

85°C

95°C

115°C

严重（关机）

90°C

100°C

120°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并改变温控行为。内核中可用的热政策（也称为thermal governor）包括：Step Wise和Power Allocator。BSP中使用的默认政策是step_wise。

+
+

小技巧

+

如果sysfs文件中的SoC温度值达到 trip_point_1 ，主板将立即关闭以避免任何热损伤。如果这不符合您的期望，可以实现一个外部监控电路，当温度降到选定的触发点以下时，通过X_ONOFF信号重新启动模块

+
+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+

7.16.3. PWM Fan

+

A PWM fan can be connected to the phyBOARD-Nash i.MX 93 connector X48 (label FAN).

+

Afterwards, a PWM fan overlay needs to be activated, otherwise PWM fan won't +be recognized.

+
target:~$ vi /boot/bootenv.txt
+
+
+

The bootenv.txt file should look like this (it can also contain other devicetree +overlays!):

+
overlays=imx93-phyboard-nash-pwm-fan.dtbo
+
+
+

更改将在重启后应用：

+
+
target:~$ reboot
+
+
+
+

有关设备树overlay的更多信息，请阅读 device tree 章节。

+

The SoC only contains one temperature sensor which is already used by the +thermal frequency scaling. The fan thus can not be controlled by the kernel. +We use lmsensors with hwmon for this instead. lmsensors reads the temperature +periodically and adjusts output PWM duty-cycle accordingly. By default, +temperature threshold for PWM fan to activate is set to 60°C.

+

设置可以在配置文件中进行配置：

+
/etc/fancontrol
+
+
+

风扇控制在启动时由systemd服务启动。可以通过以下方式禁用它：

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.17. 看门狗

+

PHYTEC i.MX 93 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.17.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.18. bbnsm 电源键

+

连接到开/关按钮的 X_ONOFF 引脚可以长按（5 秒）以触发关机，而无需软件干预，或者用于唤醒系统以退出挂起状态。使用 bbnsm_pwrkey 驱动程序时，当按钮被按下时，KEY_POWER 事件也会报告给用户空间。默认情况下，systemd 被配置为忽略此类事件，并未配置无软件干预的关机功能。如果需要，可以在 /etc/systemd/logind.conf 中配置在按下开/关按钮时通过 systemd 触发关机：

+
HandlePowerKey=poweroff
+
+
+
+
+

7.19. PXP

+

i.MX 93 SoC包含一个PiXel Pipeline (PXP)。PXP将以下内容组合成一个单独的处理引擎：

+
    +

  • 缩放

    • +

  • 颜色空间转换 (CSC)

    • +

  • 辅助色彩空间转换 (CSC2)

    • +

  • 旋转

    • +
+

因此，减少了显示管道所需的内存占用。有关如何在 Gstreamer 和 Wayland 中使用 PXP，请查看 NXP 的《How to Use PXP in GStreamer and Wayland》（AN13829）应用笔记。

+
+
+

7.20. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 93 提供一次性可编程寄存器（fuse），用于存储信息，例如MAC地址、启动配置和其他永久设置（在 i.MX 93 reference manual中称为“片上一次性可编程控制器（OCOTP_CTRL）”）。以下列表是 i.MX 93 reference manual的摘要，包括OCOTP_CTRL中的一些有用寄存器（基地址为0x47510000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为 0x47510000

描述

BOOT_CFG0

3

0 0x60

启动fuse设置

BOOT_CFG1

3

1 0x64

启动fuse设置

BOOT_CFG2

3

2 0x68

启动fuse设置

BOOT_CFG3

3

3 0x6c

启动fuse设置

MAC1_ADDR

39

3

0x4ec

包含ENET0 MAC地址的低32位

MAC1/2_ADDR

39

4

0x4f0

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

MAC2_ADDR

39

5

0x4f4

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 93 Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.20.1. 在uBoot中读取fuse的值

+

MAC1_ADDR:

+
u-boot=> fuse read 39 3
+
+
+
+
+

7.20.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc\@0/47510000.efuse/fsb_s400_fuse0/nvmem
+
+
+
+
+

7.20.3. 烧录MAC地址

+

假设我们想要烧录以下MAC地址：

+ + + + + + + + + +

MAC1

12:34:56:78:90:AA

MAC2

Bb:Cc:Dd:Ee:Ff:D0

+

我们将在u-boot中执行这个：

+
u-boot=> fuse prog 39 3 0x567890Aa
+u-boot=> fuse prog 39 4 0xFfD01234
+u-boot=> fuse prog 39 5 0xBbCcDdEe
+
+
+
+
+

7.20.4. 烧写启动fuse

+
+

警告

+

fuse只能写入一次！如果烧录了错误的启动配置，您可能会轻易地将您的板子变砖。这个过程是不可逆的！

+
+

可以在附带的名为 i.MX93_Fusemap.xlsx 的excel表格中查找应使用哪个fuse bank/word来编程 BOOT_CFGX，这些信息可以在 i.MX 93 Applications Processor Reference Manual 中找到。

+

这些值应该写入BOOT_CFG0，可以从第3个 Bank 的第0字节中读取/写入fuse。

+ + + + + + + + + + + + + + +

启动设备

BOOT_CFG0

eMMC

0x20020002

SD卡

0x20000103

+

要设置内部fuse以从eMMC启动，可以使用以下方法进行编程：

+
u-boot=> fuse prog 3 0 0x20020002
+
+
+

在这个例子中，我们：

+
    +

  • 将 Boot_Mode 设置为 0b0010 （eMMC），也就是 BOOT_CFG0[3:0]，

    • +

  • 将eMMC总线宽度设置为0b01（8位），也就是 BOOT_CFG0[18:17]。

    • +

  • 设置BT_FUSE_SEL（Boot fuses already programmed）位，也就是BOOT_CFG0[29]

    • +
+

确保通过阅读 i.MX 93 Applications Processor Reference Manual 中的 Boot Fusemap 章节来设置正确的位。

+
+
+
+
+

8. i.MX 93 M33 Core

+

除了Cortex-A55核心外，SoC中还集成了一个Cortex-M33 Core 作为单片机（MCU）。我们的Yocto-Linux-BSP在A55核心上运行，而 M33 Core 可以作为辅助核心使用，执行额外的任务，采用bare-metal的固件。两个核心都可以访问相同的外设，因此在 M33 Core 的固件或Linux操作系统的设备树中，需要限制外设的使用。

+

我们的Yocto-BSP包含来自NXP的 M33 Core 预编译固件示例。

+

本节描述了如何在 phyBOARD-Segin i.MX 93 上运行预编译的 M33 Core 固件示例。

+
+

8.1. 运行 M33 Core 示例

+

运行 M33 Core 固件示例有两种方式：从 U-Boot bootloader和在正在运行的 Linux 中使用 Remoteproc 子系统。

+

要接收调试信息，请在您的主机PC上启动您喜欢的终端软件（例如Minicom、Tio或Tera Term），并将其配置为115200波特率、8个数据位、无奇偶校验和1个停止位（8n1），且不使用握手。

+

在 phyBOARD-Segin i.MX 93 上需要一个“USB接口 TTL 串口转换器”。转换器的 I/O 引脚应能够在 3.3V 电压水平下工作。

+

根据下表，将外部“USB接口 TTL 串口转换器”信号连接到板上的 X16 连接器：

+ + + + + + + + + + + + + + + + + + + + + +

USB-TTL适配器引脚

X16信号

X16 引脚

RXD

X_UART2_TX

5

TXD

X_UART2_RX

8

GND

GND

4

+
+

8.1.1. 从U-Boot运行示例

+

要使用U-Boot bootloader加载固件示例，可以使用 bootaux 命令：

+
    +

  1. 准备一张烧写了BSP镜像的SD卡

    2. +

  2. 通过按任意键停止自动启动

    3. +

  3. 列出SD卡第一分区上可用的 M33 Core 固件示例：

    4. +
+
u-boot=> ls mmc 1
+
+
+
+

备注

+

可用的固件示例以 imx93-11x11-evk_m33_TCM_* 开头，以 *.bin 结尾。这些示例来自NXP的Yocto层meta-imx，并根据与 phyBOARD-Segin i.MX 93 硬件的兼容性进行选择。

+
+
    +

  1. 加载所需的固件示例：

    2. +
+
u-boot=> fatload mmc 1 ${loadaddr} <firmware.bin>
+u-boot=> cp.b ${loadaddr} 0x201e0000 ${filesize}
+u-boot=> run prepare_mcore
+u-boot=> bootaux 0x1ffe0000 0
+## Starting auxiliary core addr = 0x1FFE0000...
+
+
+

程序的输出应显示在 M33 Core 的调试UART上。

+
+
+

8.1.2. 通过Remoteproc在Linux上运行示例

+

Remoteproc是一个模块，它允许您在运行时从Linux控制 M33 Core 。可以加载 M33 Core 的固件示例，并在Linux中控制它启动或停止。要使用Remoteproc，需要设置设备树overlay：

+

在开发板的 /boot 目录中编辑 bootenv.txt 文件，添加 imx93-phycore-rpmsg.dtso ：

+
overlays=imx93-phyboard-segin-peb-av-02.dtbo imx93-phycore-rpmsg.dtso
+
+
+

重启目标并在U-Boot中执行:

+
u-boot=> run prepare_mcore
+
+
+

针对 M33 Core 的固件示例 *.elf 文件可以在 /lib/firmware 下找到。列出可用的固件示例：

+
target:~$ ls /lib/firmware/*.elf
+
+
+

要加载固件，请输入：

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

要加载不同的固件，M33 Core 需要停止：

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

备注

+

在开发板的 /lib/firmware 目录中找到的例子来自NXP的Yocto层meta-imx，并根据与 phyBOARD-Segin i.MX 93 硬件的兼容性进行了挑选。

+
+

NXP的一些固件示例需要加载额外的Linux内核模块。

+

例如，当加载 imx93-11x11-evk_m33_TCM_rpmsg_lite_str_echo_rtos.elf 固件时，需要加载相应的 imx_rpmsg_tty 模块：

+
target:~$ modprobe imx_rpmsg_tty
+
+
+

这将一个RPMsg端点作为虚拟TTY暴露在 /dev/ttyRPMSG30 。现在可以通过输入以下内容从A55核心发送消息到 M33 Core ：

+
target:~$ echo "PHYTEC" > /dev/ttyRPMSG30
+
+
+

观察 M33 Core 调试 UART 应该会产生以下输出：

+
RPMSG String Echo FreeRTOS RTOS API Demo...
+
+Nameservice sent, ready for incoming messages...
+Get Message From Master Side : "PHYTEC" [len : 6]
+
+
+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx9/imx93/pd24.1.1.html b/previews/271/zh_CN/bsp/imx9/imx93/pd24.1.1.html new file mode 100644 index 000000000..b222f3658 --- /dev/null +++ b/previews/271/zh_CN/bsp/imx9/imx93/pd24.1.1.html @@ -0,0 +1,3433 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 93 BSP手册

文档标题

i.MX 93 BSP手册

文档类型

BSP 手册

Yocto 手册

Mickledore

发布日期

2024/01/31

母文档

i.MX 93 BSP手册

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP发布日期

BSP 状态

BSP-Yocto-NXP-i.MX93-PD24.1.1

小更新

2024/05/07

已发布

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 phyBOARD-Segin i.MX 93 and phyBOARD-Nash i.MX 93 Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-91-93/#downloads 中找到。

+
+

1.1. 支持的硬件

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-NXP-i.MX93-PD24.1.1 的所有Machine及其对应的Article Numbers(产品型号)： 请参见 网页。

+

如果您在“Supported Machines”部分选择了特定的 Machine Name ，您可以查看该Machine下可用的 Article Number(产品型号) 以及硬件信息的简短描述。如果您只有硬件的 Article Number ，可以将 Machine Name 下拉菜单留空，仅选择您的 Article Number 。现在它会显示您特定硬件所需的 Machine Name 。

+
+

小技巧

+

本BSP手册中的终端示例仅针对phyBOARD-Segin i.MX 93。类似的命令也可以在phyBOARD-Nash i.MX 93上执行。

+
+
+

1.1.1. phyBOARD-Segin i.MX 93 器件

+
+../../../_images/phyBOARD-Segin-iMX93-top-components.jpg + +
+

phyBOARD-Segin i.MX 93 器件（顶部）

+
+
+
+../../../_images/phyBOARD-Segin-iMX93-bottom-components.jpg + +
+

phyBOARD-Segin i.MX 93 器件（底部）

+
+
+
+
+

1.1.2. phyBOARD-Nash i.MX 93 器件

+
+../../../_images/phyBOARD-Nash-iMX93-top-components.jpg + +
+

phyBOARD-Nash i.MX 93 器件（顶部）

+
+
+
+../../../_images/phyBOARD-Nash-iMX93-bottom-components.jpg + +
+

phyBOARD-Nash i.MX 93 器件（底部）

+
+
+
+
+
+
+

2. 开始使用

+

该 phyBOARD-Segin i.MX 93 and phyBOARD-Nash i.MX 93 Kit 包含预先烧写好的SD卡。它包含 phytec-qt6demo-image 镜像，可以直接用作启动盘。默认情况下，核心板上的eMMC仅烧写了U-Boot。您可以从 PHYTEC下载服务器 获取所有镜像资源。本章将解释如何将BSP镜像烧写到SD卡以及如何启动开发板。

+

有几种方法可以将镜像写入SD卡或eMMC。最为人熟知的方式是使用Linux命令行工具 dd 进行简单的顺序写入。另一种方法是使用PHYTEC的自研程序 partup ，它可以让格式化复杂系统的过程变得简单。您可以从其发布页面获取 预编译的Linux partup 二进制文件 。请阅读 partup的readme文件 来获取安装指导。

+
+

2.1. 下载镜像

+

phytec-qt6demo-image 镜像包含完整系统所需的所有必要文件，您需确保镜像中各个分区以及裸数据都会被正确写入启动盘。可以从 PHYTEC 下载服务器 下载 partup 镜像文件或者是可以使用 dd 进行烧写的 WIC 镜像。

+

从下载服务器获取 partup 镜像文件或WIC镜像：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz
+
+
+
+

备注

+

针对eMMC，我们建议使用partup去烧写比较大的或者是有复杂分区配置的镜像，因为它在写入速度上比 dd 更快，并且可以对闪存设备进行更灵活的配置。

+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要创建SD卡启动盘，必须要拥有Linux PC上的root权限。在选择烧写设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+
+

2.2.1. 寻找正确的设备

+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行命令：

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+

卸载所有这些分区，例如：

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

现在，SD卡已经准备好可以使用 partup 、 dd 或 bmap-tools 来写入镜像。

+
+
+

2.2.2. 使用bmap-tools

+

烧写SD卡的其中一种方法是使用 bmap-tools 。Yocto会自动为WIC镜像创建一个block map文件（ <IMAGENAME>-<MACHINE>.wic.bmap ），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host:~$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

将 <your_device> 替换为您之前找到的SD卡设备名称，并确保将文件 <IMAGENAME>-<MACHINE>.wic.bmap 与WIC镜像文件放在一起，以便bmaptool知道哪些块需要写入，哪些块需要跳过。

+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.2.3. 使用partup

+

使用partup烧写SD卡只需一个命令：

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).partup /dev/<your_device>
+
+
+

确保将 <your_device> 替换为您之前找到的设备名称。

+

关于partup的进一步使用说明，请参阅其 官方文档 。

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 release notes 。

+
+
+

备注

+

partup 具有清除eMMC user区域中特定区域的功能，我们提供的partup程序中用该功能擦除U-Boot环境变量。这是 bmaptool 工具所无法完成的一点，如前一部分所提到的。

+

partup相较于其他烧写工具的一个主要优势是，它可以配置MMC的特定部分，比如他可以直接写入eMMCboot分区，无需调用其他命令。

+
+
+
+

2.2.4. 使用 dd

+

在卸载所有SD卡的挂载分区后，您可以烧写SD卡。

+

一些PHYTEC BSP会生成未压缩的镜像（文件名扩展名为*.wic），而另一些则生成压缩的镜像（文件名扩展名为*.wic.xz）。

+

要写入未压缩的镜像（*.wic），请使用以下命令：

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

或者要写入压缩后的镜像（*.wic.xz），请使用以下命令：

+
host:~$ xzcat phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

再次确保将 <your_device> 替换为之前找到的设备名称。

+

参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

+
+
+
+

2.3. 首次启动

+ +../../../_images/SD_Card_Boot.png +
    +

  • 插入SD卡

    • +

  • 将开发板的调试接口与您的主机连接。使用 UART1 console on PEB-EVAL-01 for phyBOARD-Segin and X-37 +USB-C debug for phyBOARD-Nash。

    • +

  • 给开发板通电

    • +

  • 以115200波特率和8N1格式打开串口/USB端口（您应该在终端上看到u-boot/linux启动信息）

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 93 BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (mickledore).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (mickledore).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-i.MX93 ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-wayland MACHINE=phyboard-segin-imx93-2 ./phyLinux init -p imx93 -r BSP-Yocto-NXP-i.MX93-PD24.1.1
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 phyboard-segin-imx93-2 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx93.bin: ARM可信固件二进制文件

    • +

  • lpddr4_dmem_1d_v202201.bin, lpddr4_dmem_2d_v202201.bin, lpddr4_imem_1d_v202201.bin, lpddr4_imem_2d_v202201.bin: DDR PHY 固件镜像

    • +

  • imx-boot：由imx-mkimage编译的bootloader镜像，包括SPL、U-Boot、ARM可信固件和DDR固件。这是最终的可引导bootloader镜像。

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx93-phyboard-*.dtb: 内核设备树文件

    • +

  • imx93-phy*.dtbo: 内核设备树overlay文件

    • +

  • phytec-*.tar.gz: bitbake-image编译生成的root文件系统。

    +
      +

    • phytec-qt6demo-image-phyboard-*-imx93-*.tar.gz：在使用bitbake-build编译 phytec-qt6demo-image 时

      • +

    • phytec-headless-image-phyboard-*-imx93-*.tar.gz：在使用bitbake-build编译 phytec-headless-image 时

      • +
    +
    • +

  • phytec-*.wic.xz：bitbake-image编译生成的压缩的可引导SD卡镜像，包括bootloader、设备树二进制文件（DTB）、内核和根文件系统。

    +
      +

    • phytec-qt6demo-image-phyboard-*-imx93-*.wic.xz：在使用bitbake-build编译 phytec-qt5demo-image 时

      • +

    • phytec-headless-image-phyboard-*-imx93-*.wic.xz：在使用bitbake-build编译 phytec-headless-image 时

      • +
    +
    • +

  • imx93-11x11-evk_m33_*.bin，Cortex-M33 MCU的Demo应用程序的二进制文件；可以通过U-Boot或Linux手动加载和启动

    • +
+
+
+
+
+

4. 安装操作系统

+
+

4.1. 启动模式开关 (S3)

+
+

小技巧

+

底板版本：

+
    +

  • phyBOARD-Segin-i.MX 93: 1472.5

    • +

  • phyBOARD-Nash-i.MX 93: 1616.0

    • +
+
+

该 phyBOARD-Segin/Nash i.MX 93 具有一个（启动源配置）开关，配有四个可单独切换的位，用于选择phyCORE-i.MX 93 默认的启动源。

+ + + + + + + + + +
+../../../_images/eMMC.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses.png +
+

内部fuse

+
+
+
+../../../_images/USB_Serial_Download.png +
+

USB

+
+
+
+../../../_images/SD_Card_Boot.png +
+

SD卡

+
+
+
+
+
+

4.2. 烧写eMMC

+

要从 eMMC 启动，请确保 BSP 镜像已正确烧写到 eMMC，并且 bootmode switch (S3) 设置为 eMMC。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行以检查当前设置是否受到影响。如果 mmcblk0p1 和 mmcblk1p1 具有相同的 UUID，则该设置受到影响。

+
+
+

4.2.1. 从SD卡烧写eMMC

+

如果没有可用的网络，您可以通过SD卡更新eMMC。为此，您只需在SD卡上准备一个可用的镜像文件（*.wic）。由于镜像文件相当大，您需要扩展SD卡以使用其全部空间（如果之前没有扩展的话）。有关如何扩展SD卡，请参见“调整 ext4 根文件系统的大小”。

+

或者，使用partup包烧写SD卡，如 Getting Started 中所述。这样就可使用SD卡的全部容量。

+
+

4.2.1.1. 在开发板的linux环境中通过SD卡烧写eMMC

+

您可以在Linux上烧写eMMC。您只需在SD卡上保存一个partup包或WIC镜像即可。

+
    +

  • 在SD卡上查看您保存的partup包或WIC镜像或WIC.XZ镜像文件：

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.partup
+phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz
+
    +
    +
    • +

  • 显示可用的MMC设备列表：

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk0
+mmcblk0boot0
+mmcblk0boot1
+mmcblk0p1
+mmcblk0p2
+mmcblk0rpmb
+
    +
    +
    • +

  • eMMC设备的特征是它包含两个boot分区：(mmcblk0 boot0; mmcblk0 boot1)

    • +

  • 使用 partup 将镜像写入 phyCORE-i.MX 93 的 eMMC (/dev/mmcblk0 不带 分区)：

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-segin-imx93-2.partup /dev/mmcblk0
+
    +
    +
    +

    小技巧

    +

    强烈建议使用partup，因为它更易于使用，并且可以充分利用eMMC设备的容量，自动调整分区大小。

    +
    +
    +

    备注

    +

    或者，可以使用 dd 命令。

    +

    对于未压缩的WIC镜像（*.wic）：

    +
    target:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.wic of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +

    对于压缩的WIC镜像（*.wic.xz）：

    +
    target:~$ zstdcat phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz | sudo dd of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +

    请注意，在使用 dd 进行烧写时，root分区并没有使用全部存储容量。

    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    警告

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+
+

4.2.2. 从网络烧写 eMMC

+

i.MX 93 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

备注

+

一些PHYTEC的BSP会生成压缩的 .wic.xz 镜像。在这种情况下，必须先对压缩镜像进行解压缩。

+
host:~$ unxz phytec-qt6demo-image-phyboard-segin-imx93-2.wic.xz
+
+
+
+
+

4.2.2.1. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

在主机上获取一个未压缩的镜像，并通过网络使用ssh将其发送到开发板的eMMC，使用一行命令：

+
target:~$ ssh <USER>@192.168.3.10 "dd if=<path_to_file>/phytec-qt6demo-image-phyboard-segin-imx93-2.wic" | dd of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
+
+
+
+

4.2.2.2. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

查看主机上可用的镜像文件：

+
host:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.wic
+
+
+

通过网络使用 dd 命令结合ssh将镜像发送到您设备的eMMC：

+
host:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.wic bs=1M status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk0 conv=fsync"
+
+
+
+
+
+

4.2.3. 在运行的U-Boot中通过网络烧写eMMC U-Boot镜像

+

可以在U-Boot中更新U-Boot镜像imx-boot，eMMC上的U-Boot需要位于eMMC的user区域。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 0
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.4. 从USB烧写eMMC

+
+

4.2.4.1. 在运行的Linux系统中从USB烧写eMMC

+

下面这些步骤展示如何在Linux系统上使用USB大容量存储设备烧写eMMC。您需要一个保存了完整镜像的U盘和一个可从SD卡启动的核心板（例如 phytec-qt6demo-image-phyboard-segin-imx93-2.wic）。将 bootmode switch (S3) 设置为SD卡启动。

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ cd /mnt
+target:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.wic
+
    +
    +
    • +

  • 显示可用的MMC设备列表：

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk0
+mmcblk0boot0
+mmcblk0boot1
+mmcblk0p1
+mmcblk0p2
+mmcblk0rpmb
+
    +
    +
    • +

  • eMMC设备的特征是它包含两个boot分区：(mmcblk0 boot0; mmcblk0 boot1)

    • +

  • 将镜像写入 phyCORE-i.MX 93 eMMC (/dev/mmcblk0，无分区)：

    +
    target:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.wic of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    小技巧

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+
+
+

4.3. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC：L-1006e.A5 RAUC更新与设备管理手册。

+
+
+
+

5. 开发

+
+

5.1. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.1.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.2. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.2.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核镜像复制到您的tftp目录中：

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • 将设备树复制到您的tftp目录：

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • 将您想要使用的所有overlay文件复制到您的tftp目录中：

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-segin-imx93-2.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.2.2. 设置网络启动的bootenv.txt文件

+

在您的tftp目录中创建一个bootenv.txt文件，并将以下变量写入其中。

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> 必须替换为您想要使用的overlay设备树文件名。用空格分隔文件名。例如：

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

小技巧

+

所有支持的设备树overlay在 device tree 章节中。

+
+
+
+

5.2.3. 开发板上的网络设置

+

如果要自定义开发板上的以太网配置，请按照此处的说明进行操作： Network Environment Customization

+
+
+

5.2.4. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.3.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. 获取镜像

+

可以从我们的服务器下载imx-boot，或者从Yocto编译目录中的build/deploy/images/phyboard-segin-imx93-2/获取它。要将wic镜像烧写到eMMC，你还需要 phytec-qt6demo-image-phyboard-segin-imx93-2.wic。

+
+
+

5.3.3. 开发板准备

+

将 bootmode switch (S3) 设置为 USB串行下载。同时，将 USB 端口 X8 (USB micro/OTG connector) 连接到主机。

+
+
+

5.3.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 UART1 console on PEB-EVAL-01 for phyBOARD-Segin and X-37 +USB-C debug for phyBOARD-Nash 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.3.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 0 0 0 0
+u-boot=> mmc partconf 0
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-segin-imx93-2.wic
+
+
+
+
+
+

5.4. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone git://git.phytec.de/u-boot-imx）

+
+
+

5.4.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-imx 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    git://git.phytec.de/linux-imx
+
    +
    +
    • +

  • 我们的 i.MX 93 内核是基于 linux-imx 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
meta-phytec/dynamic-layers/freescale-layer/recipes-kernel/linux/linux-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. 获取SDK

+

您可以在此处下载SDK 这里，或者使用Yocto去编译生成SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

在成功编译后，SDK安装包保存在 build/deploy*/sdk。

+
+
+

5.4.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-vendor-wayland-glibc-x86_64-phytec-qt6demo-image-cortexa55-toolchain-4.2.3.sh
+host:~$ ./phytec-ampliphy-vendor-wayland-glibc-x86_64-phytec-qt6demo-image-cortexa55-toolchain-4.2.3.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-wayland/4.2.3):
+You are about to install the SDK to "/opt/ampliphy-vendor-wayland/4.2.3". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-vendor-wayland/4.2.3/environment-setup-cortexa55-phytec-linux
+
+
+
+
+

5.4.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. 单独编译U-Boot

+
+

5.5.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本的 tag 称为 v2023.04_2.2.0-phy3

    • +

  • 查看所需的 U-Boot tag：

    • +
+
host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2023.04_2.2.0-phy3
+
+
+
    +

  • 从技术上讲，您现在可以编译U-Boot，但实际上还需要一些进一步的步骤：

    +
      +

    • 创建您自己的开发分支：

      +
      host:~/u-boot-imx$ git switch --create <new-branch>
+
      +
      +
      +

      备注

      +

      您可以根据您的需要自行命名您的开发分支，这只是一个示例。

      +
      +
      • +
    +
    • +

  • 设置编译环境：

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor-wayland/4.2.3/environment-setup-cortexa55-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. 获取所需的二进制文件

+

要编译imx-boot，您需要 收集 这些 文件 以便后续使用 imx-mkimage工具 ：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx93.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +

  • 容器镜像：mx93a1-ahab-container.img

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以从此处提到的目录中获取这些文件：BSP Images

+

或者您可以从PHYTEC下载服务器（ https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools/ ）下载文件。您可以使用下面的命令从该服务器下载所有文件：

+
host:~$ mkdir ./artefacts && cd ./artefacts
+host:~/artefacts$ wget \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//bl31-imx93.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//tee.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_dmem_1d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_dmem_2d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_imem_1d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_imem_2d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.1.1/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//mx93a1-ahab-container.img
+host:~/artefacts$ cd ..
+
+
+
+
+

5.5.3. 编译bootloader

+
    +

  • 编译u-boot：

    +
    host:~/u-boot-imx$ make <defconfig>
+host:~/u-boot-imx$ make
+host:~/u-boot-imx$ cd ..
+
    +
    +
    +

    备注

    +

    In command above replace <defconfig> with imx93-phyboard-segin_defconfig or imx93-phyboard-nash_defconfig, depending on the board you are about to build for.

    +
    +
    • +
+
+

5.5.3.1. 使用 imx-mkimage 编译最终的 flash.bin

+
    +

  • 获取 imx-mkimage：

    +
    host:~$ git clone https://github.com/nxp-imx/imx-mkimage
+host:~$ cd imx-mkimage/
+host:~/imx-mkimage$ git checkout tags/lf-6.1.55-2.2.0
+
    +
    +
    • +

  • 将固件二进制文件复制到 imx-mkimage

    +
    host:~/imx-mkimage$ cp ../artefacts/bl31-imx93.bin ./iMX9/bl31.bin
+host:~/imx-mkimage$ cp \
+                     ../artefacts/lpddr4_* \
+                     ../artefacts/mx93a1-ahab-container.img \
+                     ../artefacts/tee.bin \
+                     ./iMX9/
+
    +
    +
    • +

  • 将u-boot二进制文件和DTB复制到imx-mkimage中

    +
    host:~/imx-mkimage$ cp ../u-boot-imx/spl/u-boot-spl.bin ../u-boot-imx/u-boot.bin ./iMX9/
+host:~/imx-mkimage$ cp ../u-boot-imx/arch/arm/dts/<dtb> ./iMX9/
+
    +
    +
    +

    备注

    +

    In command above replace <dtb> with imx93-phyboard-segin.dtb or imx93-phyboard-nash.dtb, depending on the board you are about to build for.

    +
    +
    • +

  • 编译最终的 flash.bin 二进制文件

    +
    +
    host:~/imx-mkimage$ make SOC=iMX9 REV=A1 flash_singleboot
+
    +
    +
    +
    • +
+
+
+
+

5.5.4. 将bootloader烧写到块设备上

+

flash.bin可以在imx-mkimage/iMX9/目录下找到，现在可以进行烧写。需要一个特定于芯片的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 93

32 kiB

0 kiB

/dev/mmcblk0

+

例如，烧写SD卡：

+
host:~/imx-mkimage$ sudo dd if=./iMX9/flash.bin of=<sd-card> bs=1024 seek=32 conv=sync
+
+
+
+

备注

+

In the command above, replace <sd-card> with your sd-card device name. +For more information on how to find the device name, see the section +Finding the Correct Device in +Getting Started.

+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+
+

5.6. 单独编译内核

+
+

5.6.1. 配置源代码

+
    +

  • 使用的 linux-imx 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v6.1.55_2.2.0-phy3

    • +

  • Check out 所需的 linux-imx 标签：

    +
    host:~$ git clone git://git.phytec.de/linux-imx
+host:~$ cd ~/linux-imx/
+host:~/linux-imx$ git fetch --all --tags
+host:~/linux-imx$ git checkout tags/v6.1.55_2.2.0-phy3
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-imx$ source /opt/ampliphy-vendor-wayland/4.2.3/environment-setup-cortexa55-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-imx$ make imx_v8_defconfig imx9_phytec_distro.config imx9_phytec_platform.config
+host:~/linux-imx$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-imx/arch/arm64/boot/Image 找到

    • +

  • dtb文件可以在 ~/linux-imx/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-imx$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. 将内核复制到SD卡

+

内核及module和对应的设备树二进制文件可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-imx$ cp arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dtb /path/to/sdcard/boot/oftree
+host:~/linux-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.7.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.7.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将 phytec-qt6demo-image-phyboard-segin-imx93-2.wic 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-segin-imx93-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.7.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将 phytec-qt6demo-image-phyboard-segin-imx93-2.wic 镜像复制到其中。然后卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-segin-imx93-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 93 BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 93 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Board.dts - 包含module dtsi 文件。从SoC i.MX 93 引出并在底板使用的设备也包含在此 dts 中。

    • +

  • Overlay.dtso - 根据核心板或底板上可选硬件（例如 SPI 闪存或 PEB-AV-10）的情况来启用/禁用一些功能。

    • +
+

在Linux内核的根目录下，我们的 i.MX 9 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。下面是扩展板的硬件描述。对比源码中的include，overlay通过覆盖的方式来生效。overlay也可以根据实际开发板的硬件配置来设置设备树节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/ 中。

+

phyboard-segin-imx93-2.conf 可用的overlay文件有：

+
imx93-phyboard-segin-peb-av-02.dtbo
+imx93-phyboard-segin-peb-eval-01.dtbo
+imx93-phycore-rpmsg.dtbo
+imx93-phycore-no-emmc.dtbo
+imx93-phycore-no-eth.dtbo
+
+
+

phyboard-nash-imx93-1.conf可用的overlay有：

+
imx93-phyboard-nash-peb-av-010.dtbo
+imx93-phycore-rpmsg.dtbo
+imx93-phycore-no-emmc.dtbo
+imx93-phycore-no-eth.dtbo
+
+
+

可以在Linux或U-Boot环境下配置overlay。overlay是在引导命令调用后、内核加载之前生效。接下来的部分将更详细地解释配置方法。

+
+

6.2.2.1. 设置 ${overlays} 变量

+

${overlays} U-Boot 环境变量包含一个以空格分隔的overlay文件列表，这些overlay文件将在启动过程中应用。根据启动源，overlay文件必须放置在 eMMC/SD 卡的启动分区中，或者通过 tftp 加载。在 $KERNEL_DEVICETREE 这个 Yocto machine 变量中设置的 overlay 文件将自动添加到最终 WIC 镜像的启动分区中。

+

${overlays} 变量可以直接在U-Boot环境中设置，也可以作为外部 bootenv.txt 环境文件的一部分。默认情况下， ${overlays} 变量来自位于启动分区的 bootenv.txt 文件。您可以在已启动的开发板上从Linux读取和写入该文件：

+
target:~$ cat /boot/bootenv.txt
+overlays=imx93-phyboard-segin-peb-eval-01.dtbo imx93-phyboard-segin-peb-av-02.dtbo
+
+
+
+

备注

+

确保boot分区已挂载！如果没有，您可以使用以下命令进行挂载：

+
target:~$ mount /dev/mmcblkXp0 /boot
+
+
+
+

更改将在下次重启后生效。如果没有可用的 bootenv.txt 文件，可以直接在U-Boot环境中设置overlay变量。

+
u-boot=> setenv overlays imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> printenv overlays
+overlays=imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> boot
+
+
+

如果用户定义了 ${overlays} 变量，同时存在 bootenv.txt 文件，则需要设置 ${no_bootenv} 变量：

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> boot
+
+
+

有关环境的更多信息，请参见 U-boot External Environment subsection of the +device tree overlay section。

+

我们使用 ${overlays} 变量来描述在运行时无法检测到的扩展板。为了禁止在启动时应用列在 ${overlays} 变量中的overlay，可以在bootloader环境中将 ${no_overlays} 变量设置为 1。

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot外部环境

+

在Linux内核启动时，外部环境 bootenv.txt 文本文件将从MMC设备的boot分区或通过TFTP加载。该文件的主要目的是存储 ${overlays} 变量。这可以针对不同的machine在Yocto中预定义不同的overlay配置。文件的内容在meta-phytec中的Yocto recipe中的bootenv中定义： https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=mickledore

+

该文件中也可以设置其他变量。这些变量将覆盖环境中现有的设置。但只有对boot命令后进行计算的变量生效，例如 ${nfsroot} 或 ${mmcargs}。在文件中更改其他变量将不会有作用。以网络启动的用法作为示例。

+

如果无法加载外部环境，启动过程将继续进行，并使用自带的环境变量值。

+
+
+

6.2.4. 在Linux环境下更改开发板上的U-boot环境变量

+

Libubootenv是我们镜像中包含的一个工具，用于在开发板linux上修改U-Boot环境。

+

使用以下命令打印U-Boot环境：

+
target:~$ fw_printenv
+
+
+

使用以下命令修改U-Boot环境：

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

小心

+

Libubootenv会读取配置文件中配置的环境变量。要修改的环境变量会被插入到该文件中，默认情况下使用eMMC中存储环境变量。

+

如果eMMC没有被烧写过或者eMMC环境被擦除，libubootenv将无法工作。您应该修改 /etc/fw_env.config 文件，以匹配您想要使用的环境源。

+
+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 93 BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 93 BSP设备树概念部分，以了解我们的 i.MX 9 BSP设备树模型。

+

以下部分概述了 i.MX 9 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 93 引脚复用

+

该 i.MX 93 Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 93 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 93 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是 imx93-phyboard-segin.dts中UART1设备的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX93_PAD_UART1_RXD__LPUART1_RX     0x31e
+                MX93_PAD_UART1_TXD__LPUART1_TX     0x30e
+        >;
+};
+
+
+

字符串的第一部分 MX93_PAD_UART1_RXD__LPUART1_RX 指定了引脚（在这个例子中是 UART1_RXD）。字符串的第二部分（LPUART1_RX）是该引脚的期望复用选项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部上拉电阻是否被激活。在当前情况下，内部上拉电阻被激活。

+

UART1引脚复用的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n262

+
+
+

7.2. 网络

+

phyBOARD-Segin/Nash i.MX 93 提供两个以太网接口。

+
    +

  • 在 phyBOARD-Segin 上，我们有：

    +
      +

    • 由 phyCORE-i.MX93 提供的百兆以太网

      • +

    • 由phyBOARD提供的百兆以太网。

      • +
    +
    • +

  • 在 phyBOARD-Nash 上，我们有：

    +
      +

    • 由 phyCORE-i.MX93 提供的百兆以太网

      • +

    • 由phyBOARD提供的千兆以太网。

      • +
    +
    • +
+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi?h=v6.1.55_2.2.0-phy3#n61。

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Segin/Nash i.MX 93 can be found here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n114 or here: +https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n83.

+
+

7.2.1. 网络配置

+
+

7.2.1.1. U-boot网络环境

+
    +

  • 要在bootloader中查找以太网设置：

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • 在将主机设置为IP 192.168.3.10和子网掩码255.255.255.0的情况下，开发板应该返回：

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • 如果您需要进行任何更改：

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> 应该是 ipaddr、netmask、gatewayip 或 serverip 中的一个。<value> 将是所选参数的设定值。

    +
    • +

  • 您所做的更改目前是临时的。要保存这些更改：

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

在这里，您也可以将IP地址更改为DHCP，而不是使用静态IP地址。

+
    +

  • 配置：

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • 设置 TFTP 和 NFS 的路径。修改可以如下所示：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+

小技巧

+

像nfsroot和netargs这样的变量可以被U-boot外部环境重新赋值。对于网络启动，外部环境将通过tftp加载。例如，要在 bootenv.txt 文件中设置nfsroot变量，请在tftproot目录修改：

+
nfsroot=/home/user/nfssrc
+
+
+

无需在开发板上存储这些信息。请注意，U-boot外部环境对于像 ipaddr 或 serveraddr 这样的变量不起作用，因为它们在加载外部环境之前已经被设置完成。

+
+
+
+

7.2.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+
+

7.3. SD/MMC 卡

+

该 i.MX 93 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

MMC（SD卡插槽）接口的设备树配置可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n216 或者这里：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n201

+

eMMC接口的DT配置可以在这里找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi?h=v6.1.55_2.2.0-phy3#n194 或者在这里：

+
+
+

7.4. eMMC设备

+

PHYTEC模块如phyCORE-i.MX 93 配备了eMMC存储芯片作为主要存储。eMMC设备使用多层单元（MLC）或三层单元（TLC）技术来实现存储，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 93 ，并在Linux内核中作为块设备表示，如SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.4.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk0
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.4.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），该层负责处理原始MLC或TLC的磨损均衡、块管理和错误更正码（ECC）。这需要定期执行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 通过以下命令使能BKOPS_EN：

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops_en manual /dev/mmcblk0
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.4.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 93 SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk0 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.4.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk0 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk0: 7617MB
+Sect[ 1799.850385]  mmcblk0: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk0 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk0 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk0: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk0: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk0p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk0p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk0p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk0p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
+
+

7.4.5. 启用伪SLC模式

+

eMMC设备使用 MLC或TLC 来存储数据。与NAND Flash中使用的SLC相比，MLC或TLC在成本更低的情况下，可靠性较低且错误率较高。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk0 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk0:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk0
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk0
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk0 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk0 unit B print
+BYT;
+/dev/mmcblk0:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.4.6. 擦除设备

+

可以直接擦除eMMC设备，而不是通过写零覆盖。eMMC块管理算法将擦除底层的MLC或TLC，或者将这些块标记为可丢弃。设备上的数据将丢失，并将被读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk0
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk0 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.4.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 93 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.4.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk0boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk0boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk0boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk0boot1
+
+
+

下表是 i.MX 93 SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 93

32 kiB

0 kiB

/dev/mmcblk0

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk0
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk0
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk0
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk0
+
+
+
+
+

7.4.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk0
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk0p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk0p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk0
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk0p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk0p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk0p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk0p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk0p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.5. GPIOs

+

phyBOARD-Segin/Nash i.MX 93 没有用户可以使用的GPIO，因为所有GPIO都被内核设备驱动程序使用或用于其他特定目的。处理器将其GPIO组织为五个32个GPIO的组（GPIO1 – GPIO4）。gpiochip0、gpiochip32、gpiochip64和gpiochip96是这些内部 i.MX 93 GPIO组GPIO1 – GPIO4的sysfs表示。

+

GPIO被标识为GPIO<X>_<Y>（例如，GPIO4_07）。<X>标识GPIO Bank，并从1到4计数，而<Y>表示Bank内的GPIO。<Y>从0到31计数（每个Bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [43810080.gpio] (32 lines)
+gpiochip1 [43820080.gpio] (32 lines)
+gpiochip2 [43830080.gpio] (32 lines)
+gpiochip3 [47400080.gpio] (32 lines)
+
    +
    +
    • +
+
+

备注

+

Order of GPIOchips in i.MX 93 Application Processor Reference Manual and +in Linux kernel differ!

+ + + + + + + + + + + + + + + + + + + + + + + +

GPIOchip 地址

Linux

Reference Manual

0x43810080

gpiochip0

gpiochip2

0x43820080

gpiochip1

gpiochip3

0x43830080

gpiochip2

gpiochip4

0x47400080

gpiochip3

gpiochip1

+
+
    +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如，从chip0读取GPIO 3）：

    +
    target:~$ gpioget gpiochip0 3
+
    +
    +
    • +

  • 将chip0上的GPIO 3的值设置为0并退出：

    +
    target:~$ gpioset --mode=exit gpiochip0 3=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.5.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用CONFIG_GPIO_SYSFS后才能支持。要使CONFIG_GPIO_SYSFS在menuconfig中可见，必须先启用CONFIG_EXPERT选项。

+

您还可以将此选项添加到Linux内核源代码中arch/arm64/configs下的imx9_phytec_distro.config配置片段中，例如：

+
..
+CONFIG_GPIO_SYSFS=y
+..
+
+
+
+
+
+

7.6. ADC

+

PHYTEC i.MX 93 包含通用的ADC，可用于与模拟传感器连接。

+

通过sysfs可以读取ADC值：

+
target:~$ cat /sys/bus/iio/devices/iio:deviceX/in_voltageY_raw
+
+
+

在phyBOARD-Nash上，ADC线路可以通过X16扩展连接器访问：

+ + + + + + + + + + + + + + +

ADC输入

X16 引脚

ADC_IN0

47

ADC_IN2

49

+
+
+

7.7. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+green:heartbeat@  mmc0::@  mmc1::@  yellow:@
+
+
+

这里的LED灯 green:heartbeat 位于 phyCORE-i.MX93 上。如果您使用的是phyBOARD-Segin，PEB-EVAL-01上还有一个 黄色 LED灯。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 1 > /sys/class/leds/green\:heartbeat/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/green\:heartbeat/brightness
+
    +
    +
    • +
+

GPIO的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-eval-01.dtso?h=v6.1.55_2.2.0-phy3#n33

+
+
+

7.8. I²C总线

+

该 i.MX 93 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 93 的I²C模块。 本节描述了我们 phyBOARD-Segin/Nash i.MX 93 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

I²C1总线DT配置（例如 imx93-phycore-som.dtsi）：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi?h=v6.1.55_2.2.0-phy3#n88

+

imx93-phyboard-segin.dts的I²C2总线DT配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n155 或者 imx93-phyboard-nash.dts: https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n113

+
+
+

7.9. EEPROM

+

在 phyCORE-i.MX93 SoM和 phyBOARD-Segin/Nash i.MX 93 上有两个不同的I2C EEPROM存储。目前只有 phyCORE-i.MX93 上的存储被启用，它用于硬件检测。

+
+

7.9.1. phyCORE-i.MX93 上的I2C EEPROM

+

phyCORE-i.MX93 SoM上的I2C EEPROM的空间被划分两部分。

+
    +

  • 正常区域（大小：4096字节，总线：I2C-2，地址：0x50）

    • +

  • ID页面（大小：32字节，总线：I2C-2，地址：0x58）

    • +
+

可以从设备进行读写操作：

+
target:~$ hexdump -C /sys/class/i2c-dev/i2c-2/device/2-0058/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-2/device/2-0050/eeprom bs=1 count=1024  | od -x
+
+
+

要将整个EEPROM（ID页）填充为零，我们首先需要禁用EEPROM写保护，请使用：

+
target:~$ gpioset 2 21=0
+
+
+

然后可以写入EEPROM：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-2/device/2-0058/eeprom bs=32 count=1
+
+
+
+

警告

+

正常EEPROM区域的前256个字节（总线：I2C-2 地址：0x50）是保留的，不应被覆盖！ （见下文）

+
+
+
+

7.9.2. EEPROM SoM 检测

+

PHYTEC在EEPROM正常区域的前256字节中存储有关核心板的信息。这包括PCB版本和贴装选项。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果正常区域的前256个字节被删除，启动加载程序将回退到 phyCORE-i.MX93 开发板内存配置，即 1GiB RAM。

+
+

警告

+

正常EEPROM区域的前256个字节（总线：I2C-2 地址：0x50）不应被擦除或损坏！这可能会影响bootloader的行为。板子可能无法正确启动。

+
+
+
+

7.9.3. 恢复EEPROM数据

+

硬件自检数据已预先写入EEPROM数据空间。如果您不小心删除或覆盖了数据，请联系我们的支持团队！

+

phyCORE-i.MX 93 核心板的设备树文件可以在 PHYTEC git 中找到：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi?h=v6.1.55_2.2.0-phy3#n172

+
+
+
+

7.10. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.10.1. RTC唤醒alarm

+

可以从实时时钟（RTC）发出中断以唤醒系统。该格式使用Unix纪元时间，即自1970年1月1日UTC午夜以来的秒数。要在从挂起到RAM状态后的4分钟唤醒系统，请输入：

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

备注

+

内部唤醒alarm时间将被向上舍入到下一个分钟，因为alarm功能不支持秒。

+
+
+
+

7.10.2. RTC参数

+

实时时钟（RTC）具有一些功能，可以通过 hwclock 工具进行读取和设置。

+
    +

  • 我们可以通过以下方式检查RTC支持的功能：

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    这个值的含义在内核中进行了编码，每个位的定义为：

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • 我们可以通过以下方式检查RTC BSM（Backup Switchover Mode 备份切换模式）：

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • 我们可以通过以下方式设置RTC BSM：

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    BSM位的定义为：

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    小技巧

    +

    您应该将BSM模式设置为DSM或LSM，以便在初始电源不可用时，RTC可以切换到备用电源。请查看 RV-3028 RTC的Datasheet，以了解LSM（电平切换模式）和DSM（直接切换模式）这两个定义的工作模式。

    +
    +
    • +
+

I²C RTC的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n173 或 https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n122

+
+
+
+

7.11. USB主控制器

+

i.MX 93 SoC 的 USB 控制器为众多消费类便携设备提供了一种低成本的连接解决方案，传输速度高达 480 Mbps （高速 'HS'）。USB 子系统具有两个独立的 USB 控制器。两个控制器都能够充当 USB Device或 USB Host，但在 phyBOARD-Segin/Nash i.MX 93 上，其中一个被用作仅Host端口（USB-A 连接器）。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+

OTG端口提供了一个额外的引脚用于过流保护，但在 phyBOARD-Segin/Nash i.MX 93 上并未使用。由于未使用，该引脚在设备树中也被禁用。如果需要使用该引脚，请在设备树中激活过流保护，并根据设备规格设置正确的极性（高电平/低电平）。有关正确的设置，请参考Linux内核文档中的Linux/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt。

+

USB Host的DT：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n190 或 https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n180

+
+
+

7.12. RS232/RS485

+

phyBOARD-Nash i.MX 93 SoC 提供一个 RS232/RS485 串口。

+
+

警告

+

由于phyBOARD-Nash PCB版本1616.0上的硬件缺陷，RS232的硬件流控制和RS485无法正常工作

+
+
+

7.12.1. RS232

+
    +

  • 以人类可读的格式显示终端的当前设置：

    +
    target:~$ stty -a
+
    +
    +
    • +

  • UART接口的配置可以通过stty命令完成。例如：

    +
    target:~$ stty -F /dev/ttyLP6 115200 crtscts raw -echo
+
    +
    +
    • +

  • 通过简单的echo和cat，可以测试基本的通信。示例：

    +
    target:~$ echo 123 > /dev/ttyLP6
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

主机应打印出 "123"。

+
+
+

7.12.2. RS485

+
+

提示

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

为了方便测试，请查看linux-serial-test。这个工具会通过调用RS485的IOCTL，发送恒定的数据流。

+
target:~$ linux-serial-test -p /dev/ttyLP6 -b 115200 --rs485 0
+
+
+

有关linux-serial-test工具及其参数的更多信息，请访问此链接：linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Linux kernel文档描述了如何在C代码中调用IOCTL： https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+

RS232和RS485的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n173

+
+
+
+

7.13. CAN FD

+

phyBOARD-Segin/Nash i.MX 93 具有一个支持CAN FD的flexCAN接口。它们由Linux标准CAN框架支持，该框架建立在Linux网络层之上。使用该框架，CAN接口表现得像普通的Linux网络设备，并具有一些特定于CAN的附加功能。更多信息可以在Linux内核文档中找到：https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。CAN接口应该显示为can0。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
+   link/can  promiscuity 0  allmulti 0 minmtu 0 maxmtu 0
+   can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+         bitrate 500000 sample-point 0.875
+         tq 25 prop-seg 37 phase-seg1 32 phase-seg2 10 sjw 1 brp 1
+         flexcan: tseg1 2..96 tseg2 2..32 sjw 1..16 brp 1..1024 brp_inc 1
+         flexcan: dtseg1 2..39 dtseg2 2..8 dsjw 1..4 dbrp 1..1024 dbrp_inc 1
+         clock 40000000
+         re-started bus-errors arbit-lost error-warn error-pass bus-off
+         0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 parentbus platform parentdev 443a0000.can
+   RX:  bytes packets errors dropped  missed   mcast
+            0       0      0       0       0       0
+   TX:  bytes packets errors dropped carrier collsns
+            0       0      0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+

imx93-phyboard-segin.dts 的CAN设备树： https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n147 或 https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n105

+
+
+

7.14. phyBOARD-Segin上的音频

+

在phyBOARD-Segin i.MX 93上使用的是TI TLV320AIC3007音频编解码器（CODEC）。它使用I2S进行数据传输，使用I2C进行编解码器控制。可用的音频信号包括：

+
    +

  • 立体声 LINE IN，

    • +

  • 立体声 LINE OUT，

    • +

  • Class D 1W的扬声器输出

    • +
+

要检查您的声卡驱动程序是否正确加载以及设备名称，请输入以下命令以查看播放设备：

+
target:~$ aplay -L
+
+
+

或输入录音设备：

+
target:~$ arecord -L
+
+
+
+

7.14.1. Alsamixer

+

要检查声卡的功能，请输入：

+
target:~$ alsamixer
+
+
+

您应该会看到很多选项，因为音频IC具有许多可以测试的功能。通过SSH打开alsamixer的图形界面比通过调试串口打开更易于使用。所有混音点都有单声道或立体声增益控制。"MM"表示该功能被静音（左右输出均为静音），可以通过按' m '切换。您还可以通过按' < ' 左和 ' > '切换右声道输出。使用 tab 键，您可以在播放和录音控制之间切换。

+
+
+

7.14.2. 恢复默认音量

+

一些默认设置存储在 /var/lib/alsa/asound.state 中。您可以使用以下命令保存当前的alsa设置：

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

您可以通过以下方式恢复已保存的alsa设置：

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.14.3. 播放

+

运行speaker-test以检查播放功能：

+
target:~$ speaker-test -c 2 -t wav
+
+
+

要播放简单的音频流，您可以使用aplay。例如，要播放ALSA测试音频：

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

要播放其他格式，例如mp3，您可以使用Gstreamer：

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+

如果扬声器音量太低，可以增加音量（值范围 0-3）：

+
target:~$ amixer -c 0 sset Class-D 3
+
+
+
+

提示

+

扬声器输出仅为单声道，因此当播放立体声轨道时，扬声器只会播放左声道。

+
+
+
+

7.14.4. 录音

+

arecord 是一个命令行工具，用于捕获音频流，默认输入源为线路输入（Line In）。

+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

提示

+

由于播放和录音共享硬件接口，因此无法在同时进行播放和录音操作时使用不同的采样率和格式。

+
+

音频设备树配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts?h=v6.1.55_2.2.0-phy3#n62

+
+
+
+

7.15. phyBOARD-Nash上的音频

+
+

警告

+

由于硬件缺陷，phyBOARD-Nash i.MX 93 PCB 版本：1616.0上的音频功能不可用

+
+

要在phyBOARD-Nash上使用音频，需要在Audio/Video接口连接一个扩展板。PEB-AV-10（1531.1修订版）可以单独购买，并未随套件一起提供。PEB-AV-10配备了TI TLV320AIC3007音频编解码器（CODEC）。音频支持通过I2S接口实现，并通过I2C控制。

+

有一个符合OMTP标准的3.5mm耳机插孔和一个8针接口，用于连接带有AV连接器的音频设备。这个8针接口包含单声道扬声器、耳机和线路输入信号（line-in）。

+

要检查您的声卡驱动程序是否正确加载以及设备名称，请输入以下命令以查看播放设备：

+
target:~$ aplay -L
+
+
+

或输入录音设备：

+
target:~$ arecord -L
+
+
+
+

7.15.1. Alsamixer

+

要检查声卡的功能，请输入：

+
target:~$ alsamixer
+
+
+

您应该会看到很多选项，因为音频IC具有许多可以测试的功能。通过SSH打开alsamixer的图形界面比通过调试串口打开更易于使用。所有混音点都有单声道或立体声增益控制。"MM"表示该功能被静音（左右输出均为静音），可以通过按' m '切换。您还可以通过按' < ' 左和 ' > '切换右声道输出。使用 tab 键，您可以在播放和录音控制之间切换。

+
+
+

7.15.2. 恢复默认音量

+

一些默认设置存储在 /var/lib/alsa/asound.state 中。您可以使用以下命令保存当前的alsa设置：

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

您可以通过以下方式恢复已保存的alsa设置：

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.15.3. ALSA配置

+

我们的BSP附带一个ALSA配置文件 /etc/asound.conf 。

+

ALSA配置文件可以根据需要进行编辑或删除，它并不是ALSA正常工作所必需的。

+
target:~$ vi /etc/asound.conf
+
+
+

要将PEB-AV-10设置为输出，请将 playback.pcm 从 "dummy" 设置为 "pebav10":

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

如果听不到声音，请将播放设备更改为软件音量控制播放设备，将 playback.pcm 设置为相应的软音量播放设备，例如“softvol_pebav10”。使用alsamixer控制来调整音量级别。

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.15.4. PulseAudio 配置

+

对于使用 Pulseaudio 的应用程序，请检查可用的音频输出设备：

+
target:~$ pactl list short sinks
+
+
+

要选择输出设备，请输入：

+
target:~$ pactl set-default-sink <sink_number>
+
+
+
+
+

7.15.5. 播放

+

运行speaker-test以检查播放功能：

+
target:~$ speaker-test -c 2 -t wav
+
+
+

要播放简单的音频流，您可以使用aplay。例如，要播放ALSA测试音频：

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

要播放其他格式，例如mp3，您可以使用Gstreamer：

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.15.6. 录音

+

arecord 是一个命令行工具，用于录制音频流，默认输入源为线路输入。要选择不同的音频源，可以使用 alsamixer。例如，打开 右侧 PGA 混音器 Mic3R 和 左侧 PGA 混音器 Mic3R，以便通过 3.5mm 插孔录制来自 TLV320 编解码器的麦克风输入音频。

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

提示

+

由于播放和录音共享硬件接口，因此无法在同时进行播放和录音操作时使用不同的采样率和格式。

+
+

设备树音频配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash-peb-av-010.dtso?h=v6.1.55_2.2.0-phy3#n57

+
+
+
+

7.16. 视频

+
+

7.16.1. 视频与Gstreamer

+

默认情况下，BSP安装了一个示例视频，路径为 /usr/share/qtphy/videos/ 。可以使用以下命令之一开始视频播放：

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.17. 显示

+

phyBOARD-Segin i.MX 93 支持 PEB-AV-02，配备 7 英寸的 edt,etm0700g0edh6 并口显示屏和电容触摸屏。该显示屏的设备树overlay在 BOOT/bootenv.txt 中默认启用！

+

phyBOARD-Nash i.MX 93需要额外的扩展板来支持10英寸的 edt,etml1010g3dra LVDS显示器和电容触摸。PEB-AV-10（1531.1修订版）可以单独购买。该LCD的overlay在 BOOT/bootenv.txt 中默认启用！

+
+

7.17.1. Qt Demo

+

使用 phytec-qt6demo-image 时，Weston会在启动时启动。我们的Qt6 DEMO应用程序名为“qtphy”，可以通过以下方式停止：

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • 要重新开始Demo，请运行：

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • 要禁用Demo的自动启动，请运行：

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • 要启用Demo的自动启动，请运行：

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston可以通过以下方式停止：

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

备注

+

在关闭Weston之前，必须先关闭Qt Demo。

+
+
+
+

7.17.2. 背光控制

+

如果LCD连接到PHYTEC开发板，可以通过Linux内核的sysfs接口控制其背光。系统中所有可用的背光设备可以在文件夹/sys/class/backlight中找到。读取相应的文件并向其写入数据可以控制背光。

+
+

备注

+

一些具有多显示的开发板在 /sys/class/backlight 有多个背光控制。比如：backlight0和backlight1

+
+
    +

  • 例如，要获取最大亮度级别（max_brightness），请执行：

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    有效的亮度值范围是 0 到 <max_brightness>。

    +
    • +

  • 要获取当前亮度级别，请输入：

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • 写入文件brightness以更改亮度：

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    例如，关闭背光。

    +

    有关所有文件的文档，请参见 https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight。

    +
    • +
+

PEB-AV-02的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-02.dtso?h=v6.1.55_2.2.0-phy3

+

PEB-AV-10的设备树：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash-peb-av-010.dtso?h=v6.1.55_2.2.0-phy3

+
+
+
+

7.18. 电源管理

+
+

7.18.1. CPU核心频率调节

+

i.MX 93 SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。与i.MX8 M系列不同，i.MX 93不支持 动态 电压和频率调整（DVFS），但支持简化的 电压和频率调整（VFS） 。可以进入以下模式：

+
    +

  • nominal（ND），

    • +

  • overdrive （OD），

    • +

  • Low Drive（LD）和

    • +

  • Low Drive（LD）与软件快速频率变化（SWFFC）。

    • +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

模式

CPU频率

DDR数据速率

VDD_SOC

OverDrive (OD)

1.7 GHz

3733 MT/s

900mV

NominalDrive (ND)

1.4 GHz

1866 MT/s

850mV

LowDrive (LD)

900 MHz

1866 MT/s

800mV

带有SWFFC的LowDrive（LD）

900 MHz

625 MT/s

800mV

+

i.MX 93 BSP支持VFS功能。Linux内核提供了一个LPM驱动程序，可以设置VDD_SOC、CPU频率和DDR速度。

+
+

备注

+

Low-cost i.MX 93 SoC variants such as parts numbers NXP IMX9301/IMX9302 do not +support VFS features. Those SoCs always run in LowDrive (LD) mode. Hence, +the Linux LPM driver is disabled automatically for SoMs with such SoCs.

+
+
    +

  • 要将设备置于 OverDrive（OD） 模式，请输入：

    +
    +
    target:~$ echo 0 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • 要将设备置于 NominalDrive（ND） 模式，请输入：

    +
    +
    target:~$ echo 1 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • 要将设备置于 LowDrive（LD） 模式，请输入：

    +
    +
    target:~$ echo 2 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • 将设备置于 LowDrive（LD） 模式，使用最低DDR速度，SWFFC类型：

    +
    +
    target:~$ echo 3 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • 要检查当前的CPU频率，请输入：

    +
    +
    target:~$ mhz
+
    +
    +
    +
    • +

  • 要检查当前模式和DDR频率，请输入：

    +
    +
    target:~$ cat /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • 要检查当前的 VDD_SOC 类型，请输入：

    +
    +
    target:~$ cat /sys/kernel/debug/regulator/regulator_summary
+
    +
    +
    +
    • +
+

有关LPM驱动程序和模式的更详细信息，请参考NXP的文档：https://docs.nxp.com/bundle/AN13917/page/topics/low_power_mode_use_cases.html

+
+
+

7.18.2. CPU核心管理

+

i.MX 93 SoC 在芯片上拥有多个处理器核心。例如，i.MX 93 具有 2 个 ARM 核，这些核可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0/
+cpu1/
+cpufreq/
+[...]
+
    +
    +

    这里系统有两个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu1/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU1 killed (polled 0 ms)
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu1/online
+
    +
    +
    • +
+
+
+

7.18.3. 挂起到RAM

+

phyCORE-i.MX93 支持基本的挂起和恢复。可以使用不同的唤醒源。挂起/恢复可以通过以下方式实现：

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

要通过串行控制台唤醒，请运行

+
target:~$ echo enabled > /sys/class/tty/ttyLP0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+

设备可以通过PEB-EVAL-01的S2按钮进入休眠状态并唤醒

+

要通过RTC闹钟唤醒，请检查：RTC Wakealarm

+
+
+
+

7.19. 热管理

+
+

7.19.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.19.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 93 SoC 平台上使用热管理内核 API。 i.MX 9 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个温度阈值。这些阈值根据CPU型号的不同而有所区别。包括商业级、工业级和扩展工业级。

+ + + + + + + + + + + + + + + + + + + + +

商业

工业

扩展工业级

被动（警告）

85°C

95°C

115°C

严重（关机）

90°C

100°C

120°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并改变温控行为。内核中可用的热政策（也称为thermal governor）包括：Step Wise和Power Allocator。BSP中使用的默认政策是step_wise。

+
+

小技巧

+

如果sysfs文件中的SoC温度值达到 trip_point_1 ，主板将立即关闭以避免任何热损伤。如果这不符合您的期望，可以实现一个外部监控电路，当温度降到选定的触发点以下时，通过X_ONOFF信号重新启动模块

+
+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+

7.19.3. PWM Fan

+

A PWM fan can be connected to the phyBOARD-Nash i.MX 93 connector X48 (label FAN).

+

Afterwards, a PWM fan overlay needs to be activated, otherwise PWM fan won't +be recognized.

+
target:~$ vi /boot/bootenv.txt
+
+
+

The bootenv.txt file should look like this (it can also contain other devicetree +overlays!):

+
overlays=imx93-phyboard-nash-pwm-fan.dtbo
+
+
+

更改将在重启后应用：

+
+
target:~$ reboot
+
+
+
+

有关设备树overlay的更多信息，请阅读 device tree 章节。

+

The SoC only contains one temperature sensor which is already used by the +thermal frequency scaling. The fan thus can not be controlled by the kernel. +We use lmsensors with hwmon for this instead. lmsensors reads the temperature +periodically and adjusts output PWM duty-cycle accordingly. By default, +temperature threshold for PWM fan to activate is set to 60°C.

+

设置可以在配置文件中进行配置：

+
/etc/fancontrol
+
+
+

风扇控制在启动时由systemd服务启动。可以通过以下方式禁用它：

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.20. 看门狗

+

PHYTEC i.MX 93 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.20.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.21. bbnsm 电源键

+

连接到开/关按钮的 X_ONOFF 引脚可以长按（5 秒）以触发关机，而无需软件干预，或者用于唤醒系统以退出挂起状态。使用 bbnsm_pwrkey 驱动程序时，当按钮被按下时，KEY_POWER 事件也会报告给用户空间。默认情况下，systemd 被配置为忽略此类事件，并未配置无软件干预的关机功能。如果需要，可以在 /etc/systemd/logind.conf 中配置在按下开/关按钮时通过 systemd 触发关机：

+
HandlePowerKey=poweroff
+
+
+
+
+

7.22. PXP

+

i.MX 93 SoC包含一个PiXel Pipeline (PXP)。PXP将以下内容组合成一个单独的处理引擎：

+
    +

  • 缩放

    • +

  • 颜色空间转换 (CSC)

    • +

  • 辅助色彩空间转换 (CSC2)

    • +

  • 旋转

    • +
+

因此，减少了显示管道所需的内存占用。有关如何在 Gstreamer 和 Wayland 中使用 PXP，请查看 NXP 的《How to Use PXP in GStreamer and Wayland》（AN13829）应用笔记。

+
+
+

7.23. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 93 提供一次性可编程寄存器（fuse），用于存储信息，例如MAC地址、启动配置和其他永久设置（在 i.MX 93 reference manual中称为“片上一次性可编程控制器（OCOTP_CTRL）”）。以下列表是 i.MX 93 reference manual的摘要，包括OCOTP_CTRL中的一些有用寄存器（基地址为0x47510000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为 0x47510000

描述

BOOT_CFG0

3

0 0x60

启动fuse设置

BOOT_CFG1

3

1 0x64

启动fuse设置

BOOT_CFG2

3

2 0x68

启动fuse设置

BOOT_CFG3

3

3 0x6c

启动fuse设置

MAC1_ADDR

39

3

0x4ec

包含ENET0 MAC地址的低32位

MAC1/2_ADDR

39

4

0x4f0

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

MAC2_ADDR

39

5

0x4f4

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 93 Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.23.1. 在uBoot中读取fuse的值

+

MAC1_ADDR:

+
u-boot=> fuse read 39 3
+
+
+
+
+

7.23.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc\@0/47510000.efuse/fsb_s400_fuse0/nvmem
+
+
+
+
+

7.23.3. 烧录MAC地址

+

假设我们想要烧录以下MAC地址：

+ + + + + + + + + +

MAC1

12:34:56:78:90:AA

MAC2

Bb:Cc:Dd:Ee:Ff:D0

+

我们将在u-boot中执行这个：

+
u-boot=> fuse prog 39 3 0x567890Aa
+u-boot=> fuse prog 39 4 0xFfD01234
+u-boot=> fuse prog 39 5 0xBbCcDdEe
+
+
+
+
+

7.23.4. 烧写启动fuse

+
+

警告

+

fuse只能写入一次！如果烧录了错误的启动配置，您可能会轻易地将您的板子变砖。这个过程是不可逆的！

+
+

可以在附带的名为 i.MX93_Fusemap.xlsx 的excel表格中查找应使用哪个fuse bank/word来编程 BOOT_CFGX，这些信息可以在 i.MX 93 Applications Processor Reference Manual 中找到。

+

这些值应该写入BOOT_CFG0，可以从第3个 Bank 的第0字节中读取/写入fuse。

+ + + + + + + + + + + + + + +

启动设备

BOOT_CFG0

eMMC

0x20020002

SD卡

0x20000103

+

要设置内部fuse以从eMMC启动，可以使用以下方法进行编程：

+
u-boot=> fuse prog 3 0 0x20020002
+
+
+

在这个例子中，我们：

+
    +

  • 将 Boot_Mode 设置为 0b0010 （eMMC），也就是 BOOT_CFG0[3:0]，

    • +

  • 将eMMC总线宽度设置为0b01（8位），也就是 BOOT_CFG0[18:17]。

    • +

  • 设置BT_FUSE_SEL（Boot fuses already programmed）位，也就是BOOT_CFG0[29]

    • +
+

确保通过阅读 i.MX 93 Applications Processor Reference Manual 中的 Boot Fusemap 章节来设置正确的位。

+
+
+
+

7.24. TPM

+

phyBOARD-Nash i.MX 93配备了可信任的平台模块（TPM），提供基于硬件的安全功能。

+

以下是一些与TPM相关的示例

+

使用TPM2工具生成4字节随机值：

+
+
target:~$ tpm2_getrandom --hex 4
+
+
+
+

使用OpenSSL工具生成4字节随机值：

+
+
target:~$ openssl rand -engine libtpm2tss --hex 4
+
+
+
+

生成RSA私钥并验证其内容：

+
+
target:~$ openssl genrsa -engine libtpm2tss -out /tmp/priv_key 512
+Engine "tpm2tss" set.
+target:~$ openssl rsa -check -in /tmp/priv_key -noout
+RSA key ok
+target:~$ cat /tmp/priv_key
+-----BEGIN PRIVATE KEY-----
+MIIBVQIBADANBgkqhkiG9w0BAQEFAASCAT8wggE7AgEAAkEAxsvmcbxjwuKnYeuZ
+2AVBmuLvYyqF/LpYOD3IB/v+YvEolxdGGmjiFLECU6xZ1j3+dIt4Y1zbcKS1OcWT
+I8mbSwIDAQABAkBoy8wrYNhmP/1kzUJIclznPYJckGoZlFI1M7xjGSA9H1xDK6if
+5g5CYCHPrbBp8e0mEokPRZoihxxzGTxGPiahAiEA/7OYMOpVZ5SD3YcRsWcQlkWI
+MOSPUYg6vxvGG9xp4FcCIQDHB01RoHr+qXJwxIu3/3oQAUBI4ACJ4JRp0KelwhC0
+LQIhANJzSvg/dak5l8pU55/99q3nbm7nPnnZSJiP0F6P62gjAiEAjf7qrfMF7Uyt
+RkEjwbl2t5Z868FNARGGMVxZT4x+aF0CIGxlmP2pL8xFu1bWB282LSedqZUdQwel
+Lxi7+svb2+uJ
+-----END PRIVATE KEY-----
+
+
+
+
+

备注

+

如果您打算将这些密钥用于任何安全目的，请不要共享您的私有RSA密钥。

+
+

生成RSA公钥并验证其内容：

+
+
target:~$ openssl rsa -in /tmp/test_key -pubout -out /tmp/pub_key
+writing RSA key
+target:~$ openssl pkey -inform PEM -pubin -in /tmp/pub_key -noout
+target:~$ cat /tmp/pub_key
+-----BEGIN PUBLIC KEY-----
+MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMbL5nG8Y8Lip2HrmdgFQZri72Mqhfy6
+WDg9yAf7/mLxKJcXRhpo4hSxAlOsWdY9/nSLeGNc23CktTnFkyPJm0sCAwEAAQ==
+-----END PUBLIC KEY-----
+
+
+
+

TPM的设备树配置：https://git.phytec.de/linux-imx/tree/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts?h=v6.1.55_2.2.0-phy3#n151

+
+
+
+

8. i.MX 93 M33 Core

+

除了Cortex-A55核心外，SoC中还集成了一个Cortex-M33 Core 作为单片机（MCU）。我们的Yocto-Linux-BSP在A55核心上运行，而 M33 Core 可以作为辅助核心使用，执行额外的任务，采用bare-metal的固件。两个核心都可以访问相同的外设，因此在 M33 Core 的固件或Linux操作系统的设备树中，需要限制外设的使用。

+

我们的Yocto-BSP包含来自NXP的 M33 Core 预编译固件示例。

+

本节描述了如何在 phyBOARD-Segin/Nash i.MX 93 上运行预编译的 M33 Core 固件示例。

+
+

8.1. 运行 M33 Core 示例

+

运行 M33 Core 固件示例有两种方式：从 U-Boot bootloader和在正在运行的 Linux 中使用 Remoteproc 子系统。

+

要接收调试信息，请在您的主机PC上启动您喜欢的终端软件（例如Minicom、Tio或Tera Term），并将其配置为115200波特率、8个数据位、无奇偶校验和1个停止位（8n1），且不使用握手。

+

在 phyBOARD-Segin/Nash i.MX 93 上需要一个“USB接口 TTL 串口转换器”。转换器的 I/O 引脚应能够在 3.3V 电压水平下工作。

+

根据下表，将外部“USB接口 TTL 串口转换器”信号连接到板上的 X16 连接器：

+ + + + + + + + + + + + + + + + + + + + + +

USB-TTL适配器引脚

X16信号

X16 引脚

RXD

X_UART2_TX

5

TXD

X_UART2_RX

8

GND

GND

4

+
+

8.1.1. 从U-Boot运行示例

+

要使用U-Boot bootloader加载固件示例，可以使用 bootaux 命令：

+
    +

  1. 准备一张烧写了BSP镜像的SD卡

    2. +

  2. 通过按任意键停止自动启动

    3. +

  3. 列出SD卡第一分区上可用的 M33 Core 固件示例：

    4. +
+
u-boot=> ls mmc 1
+
+
+
+

备注

+

可用的固件示例以 imx93-11x11-evk_m33_TCM_* 开头，以 *.bin 结尾。这些示例来自NXP的Yocto层meta-imx，并根据与 phyBOARD-Segin/Nash i.MX 93 硬件的兼容性进行选择。

+
+
    +

  1. 加载所需的固件示例：

    2. +
+
u-boot=> fatload mmc 1 ${loadaddr} <firmware.bin>
+u-boot=> cp.b ${loadaddr} 0x201e0000 ${filesize}
+u-boot=> run prepare_mcore
+u-boot=> bootaux 0x1ffe0000 0
+## Starting auxiliary core addr = 0x1FFE0000...
+
+
+

程序的输出应显示在 M33 Core 的调试UART上。

+
+
+

8.1.2. 通过Remoteproc在Linux上运行示例

+

Remoteproc是一个模块，它允许您在运行时从Linux控制 M33 Core 。可以加载 M33 Core 的固件示例，并在Linux中控制它启动或停止。要使用Remoteproc，需要设置设备树overlay：

+

在开发板的 /boot 目录中编辑 bootenv.txt 文件，添加 imx93-phycore-rpmsg.dtso ：

+
overlays=imx93-phyboard-segin-peb-av-02.dtbo imx93-phycore-rpmsg.dtso
+
+
+

重启目标并在U-Boot中执行:

+
u-boot=> run prepare_mcore
+
+
+

针对 M33 Core 的固件示例 *.elf 文件可以在 /lib/firmware 下找到。列出可用的固件示例：

+
target:~$ ls /lib/firmware/*.elf
+
+
+

要加载固件，请输入：

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

要加载不同的固件，M33 Core 需要停止：

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

备注

+

在开发板的 /lib/firmware 目录中找到的例子来自NXP的Yocto层meta-imx，并根据与 phyBOARD-Segin/Nash i.MX 93 硬件的兼容性进行了挑选。

+
+

NXP的一些固件示例需要加载额外的Linux内核模块。

+

例如，当加载 imx93-11x11-evk_m33_TCM_rpmsg_lite_str_echo_rtos.elf 固件时，需要加载相应的 imx_rpmsg_tty 模块：

+
target:~$ modprobe imx_rpmsg_tty
+
+
+

这将一个RPMsg端点作为虚拟TTY暴露在 /dev/ttyRPMSG30 。现在可以通过输入以下内容从A55核心发送消息到 M33 Core ：

+
target:~$ echo "PHYTEC" > /dev/ttyRPMSG30
+
+
+

观察 M33 Core 调试 UART 应该会产生以下输出：

+
RPMSG String Echo FreeRTOS RTOS API Demo...
+
+Nameservice sent, ready for incoming messages...
+Get Message From Master Side : "PHYTEC" [len : 6]
+
+
+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/bsp/imx9/imx93/pd24.2.0.html b/previews/271/zh_CN/bsp/imx9/imx93/pd24.2.0.html new file mode 100644 index 000000000..c10df8c8b --- /dev/null +++ b/previews/271/zh_CN/bsp/imx9/imx93/pd24.2.0.html @@ -0,0 +1,3553 @@ + + + + + + + + + 1. PHYTEC 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + + +

i.MX 93 BSP手册

文档标题

i.MX 93 BSP手册

文档类型

BSP 手册

Yocto 手册

Scarthgap

发布日期

2024/10/08

母文档

i.MX 93 BSP手册

+

下表显示了与本手册兼容的 BSP：

+ + + + + + + + + + + + + + + +

Compatible BSPs

BSP 发布类型

BSP发布日期

BSP 状态

BSP-Yocto-NXP-i.MX93-PD24.2.0

大版本

2024/10/08

已发布

+

本手册指导您完成BSP包的安装、编译和烧写，并描述如何使用 phyBOARD-Segin i.MX 93 and phyBOARD-Nash i.MX 93 Kit 的硬件接口。本手册还包括如何从源码编译内核、u-boot镜像。本手册包含需要在PC(linux操作系统)上执行的指令。

+
+

备注

+

本文档包含指令示例，描述如何在串口终端上与核心板进行交互。指令示例以“host:~$”、“target:~$”或“u-boot=>”开头，开头的这些关键字描述了指令执行的软件环境。如果需要复制这些指令，请仅复制这些关键字之后的内容。

+
+
+

1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 指南：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大部分文档都可以在我们产品的 https://www.phytec.de/produkte/system-on-modules/phycore-imx-91-93/#downloads 中找到。

+
+

1.1. 支持的硬件

+

在我们的网页上，您可以查看适用于BSP版本 BSP-Yocto-NXP-i.MX93-PD24.2.0 的所有Machine及其对应的Article Numbers(产品型号)： 请参见 网页。

+

如果您在“Supported Machines”部分选择了特定的 Machine Name ，您可以查看该Machine下可用的 Article Number(产品型号) 以及硬件信息的简短描述。如果您只有硬件的 Article Number ，可以将 Machine Name 下拉菜单留空，仅选择您的 Article Number 。现在它会显示您特定硬件所需的 Machine Name 。

+
+

小技巧

+

本BSP手册中的终端示例仅针对phyBOARD-Segin i.MX 93。类似的命令也可以在phyBOARD-Nash i.MX 93上执行。

+
+
+

1.1.1. phyBOARD-Segin i.MX 93 器件

+
+../../../_images/phyBOARD-Segin-iMX93-top-components.jpg + +
+

phyBOARD-Segin i.MX 93 器件（顶部）

+
+
+
+../../../_images/phyBOARD-Segin-iMX93-bottom-components.jpg + +
+

phyBOARD-Segin i.MX 93 器件（底部）

+
+
+
+
+

1.1.2. phyBOARD-Nash i.MX 93 器件

+
+../../../_images/phyBOARD-Nash-iMX93-top-components.jpg + +
+

phyBOARD-Nash i.MX 93 器件（顶部）

+
+
+
+../../../_images/phyBOARD-Nash-iMX93-bottom-components.jpg + +
+

phyBOARD-Nash i.MX 93 器件（底部）

+
+
+
+
+
+
+

2. 开始使用

+

该 phyBOARD-Segin i.MX 93 and phyBOARD-Nash i.MX 93 Kit 包含预先烧写好的SD卡。它包含 phytec-qt6demo-image 镜像，可以直接用作启动盘。默认情况下，核心板上的eMMC仅烧写了U-Boot。您可以从 PHYTEC下载服务器 获取所有镜像资源。本章将解释如何将BSP镜像烧写到SD卡以及如何启动开发板。

+

有几种方法可以将镜像写入SD卡或eMMC。最为人熟知的方式是使用Linux命令行工具 dd 进行简单的顺序写入。另一种方法是使用PHYTEC的自研程序 partup ，它可以让格式化复杂系统的过程变得简单。您可以从其发布页面获取 预编译的Linux partup 二进制文件 。请阅读 partup的readme文件 来获取安装指导。

+
+

2.1. 下载镜像

+

phytec-qt6demo-image 镜像包含完整系统所需的所有必要文件，您需确保镜像中各个分区以及裸数据都会被正确写入启动盘。可以从 PHYTEC 下载服务器 下载 partup 镜像文件或者是可以使用 dd 进行烧写的 WIC 镜像。

+

从下载服务器获取 partup 镜像文件或WIC镜像：

+
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.partup
+host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic.xz
+
+
+
+

备注

+

针对eMMC，我们建议使用partup去烧写比较大的或者是有复杂分区配置的镜像，因为它在写入速度上比 dd 更快，并且可以对闪存设备进行更灵活的配置。

+
+
+
+

2.2. 将镜像写入SD卡

+
+

警告

+

要创建SD卡启动盘，必须要拥有Linux PC上的root权限。在选择烧写设备时请务必小心！所选设备上的所有文件将在命令执行后立即被擦除，而且擦除前不会有任何进一步的确认！

+

选择错误的设备可能会导致 数据丢失 ，例如，可能会擦除您当前所在PC上的系统！

+
+
+

2.2.1. 寻找正确的设备

+

要创建SD卡启动盘，首先要找到PC上您SD卡对应的正确设备名称。在开始将镜像复制到SD卡之前，请卸载任何已挂载的分区。

+
    +

  1. 为了获取正确的设备名称，请移除您的SD卡并执行：

    +
    host:~$ lsblk
+
    +
    +
    2. +

  2. 现在插入你的SD卡，然后再次执行命令：

    +
    host:~$ lsblk
+
    +
    +
    3. +

  3. 比较两个输出，以获取第二个输出中的新设备名称。这些是SD卡的设备名称（如果SD卡已格式化，则包括设备名称和对应的分区）。

    4. +

  4. 为了验证找到的设备名称的最终正确性，请执行命令 sudo dmesg。在其输出的最后几行中，您应该也能找到设备名称，例如 /dev/sde 或 /dev/mmcblk0 （具体取决于您的系统）。

    5. +
+

或者，您可以使用图形化的程序，例如 GNOME Disks 或 KDE Partition Manager 来找到正确的设备。

+

现在您已经得到了正确的设备名称，例如 /dev/sde，如果SD卡曾格式化过，需要确认已取消其分区的挂载，您可以在输出中看到带有附加了数字的设备名称（例如 /dev/sde1），它们是SD卡的分区。一些Linux发行版系统在设备插入时会自动挂载分区。在写入之前，必须卸载这些分区，以避免数据损坏。

+

卸载所有这些分区，例如：

+
host:~$ sudo umount /dev/sde1
+host:~$ sudo umount /dev/sde2
+
+
+

现在，SD卡已经准备好可以使用 partup 、 dd 或 bmap-tools 来写入镜像。

+
+
+

2.2.2. 使用bmap-tools

+

烧写SD卡的其中一种方法是使用 bmap-tools 。Yocto会自动为WIC镜像创建一个block map文件（ <IMAGENAME>-<MACHINE>.wic.bmap ），该文件描述了镜像内容并包含数据完整性的校验。 bmaptool 已被多种Linux发行版支持。对于基于Debian的系统，可以通过以下命令安装：

+
host:~$ sudo apt install bmap-tools
+
+
+

通过以下命令将WIC镜像烧写到SD卡：

+
host:~$ bmaptool copy phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic?(.xz) /dev/<your_device>
+
+
+

将 <your_device> 替换为您之前找到的SD卡设备名称，并确保将文件 <IMAGENAME>-<MACHINE>.wic.bmap 与WIC镜像文件放在一起，以便bmaptool知道哪些块需要写入，哪些块需要跳过。

+
+

警告

+

bmaptool 仅擦写SD卡上镜像数据所在的区域。这意味着在写入新的镜像后，之前写入的旧U-Boot环境变量可能仍然可用。

+
+
+
+

2.2.3. 使用partup

+

使用partup烧写SD卡只需一个命令：

+
host:~$ sudo partup install phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).partup /dev/<your_device>
+
+
+

确保将 <your_device> 替换为您之前找到的设备名称。

+

关于partup的进一步使用说明，请参阅其 官方文档 。

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 release notes 。

+
+
+

备注

+

partup 具有清除eMMC user区域中特定区域的功能，我们提供的partup程序中用该功能擦除U-Boot环境变量。这是 bmaptool 工具所无法完成的一点，如前一部分所提到的。

+

partup相较于其他烧写工具的一个主要优势是，它可以配置MMC的特定部分，比如他可以直接写入eMMCboot分区，无需调用其他命令。

+
+
+
+

2.2.4. 使用 dd

+

在卸载所有SD卡的挂载分区后，您可以烧写SD卡。

+

一些PHYTEC BSP会生成未压缩的镜像（文件名扩展名为*.wic），而另一些则生成压缩的镜像（文件名扩展名为*.wic.xz）。

+

要写入未压缩的镜像（*.wic），请使用以下命令：

+
host:~$ sudo dd if=phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

或者要写入压缩后的镜像（*.wic.xz），请使用以下命令：

+
host:~$ xzcat phytec-qt6demo-image-phyboard-segin-imx93-2?(.rootfs).wic.xz | sudo dd of=/dev/<your_device> bs=1M conv=fsync status=progress
+
+
+

再次确保将 <your_device> 替换为之前找到的设备名称。

+

参数 conv=fsync 强制在 dd 返回之前对设备进行sync操作。这确保所有数据块都已写入SD卡，而没有任何数据缓存在内存中。参数 status=progress 将打印出进度信息。

+
+
+
+

2.3. 首次启动

+ +../../../_images/SD_Card_Boot.png +
    +

  • 插入SD卡

    • +

  • 将开发板的调试接口与您的主机连接。使用 UART1 console on PEB-EVAL-01 for phyBOARD-Segin and X-37 +USB-C debug for phyBOARD-Nash。

    • +

  • 给开发板通电

    • +

  • 以115200波特率和8N1格式打开串口/USB端口（您应该在终端上看到u-boot/linux启动信息）

    • +
+
+
+
+

3. 编译BSP

+

This section will guide you through the general build process of the i.MX 93 BSP +using Yocto and the phyLinux script. For more information about our +meta-layer or Yocto in general visit: Yocto Reference Manual (scarthgap).

+
+

3.1. 基本设置

+

If you have never created a Phytec BSP with Yocto on your computer, you should +take a closer look at the chapter BSP Workspace Installation in the +Yocto Reference Manual (scarthgap).

+
+
+

3.2. 下载BSP

+

获取BSP有两种方式。您可以从我们的下载页面下载完整的BSP镜像： BSP-Yocto-i.MX93 ；您也可以使用Yocto下载BSP工程并编译。如果您想要对BSP进行修改，建议使用第二种方式。

+

phyLinux脚本使用python语言编写，是一个用于管理PHYTEC Yocto BSP工程的基础工具，帮助用户更快上手BSP。

+
    +

  • 创建一个新的项目文件夹，获取phyLinux脚本，并赋予脚本具备可执行权限：

    +
    host:~$ mkdir ~/yocto
+host:~$ cd yocto/
+host:~/yocto$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
+host:~/yocto$ chmod +x phyLinux
+
    +
    +
    +

    警告

    +

    我们需要一个空的项目文件夹，phyLinux首先会清理当前所在的工作目录。从一个不为空的目录下调用phyLinux将会产生告警。

    +
    +
    • +

  • 运行phyLinux：

    +
    host:~/yocto$ ./phyLinux init
+
    +
    +
    +

    备注

    +

    在首次初始化时，phyLinux脚本会要求您在 /usr/local/bin 目录中安装Repo工具。

    +
    +
    • +

  • 在执行init命令时，您需要选择您的处理器平台（SoC）、PHYTEC的BSP版本号以及您正在使用的硬件。

    +
    +

    备注

    +

    如果您无法根据菜单中提供的信息识别您的开发板，请查看产品的发票。并查看 our BSP 。

    +
    +
    • +

  • 也可以通过命令行参数直接传递这些信息：

    +
    host:~/yocto$ DISTRO=ampliphy-vendor-wayland MACHINE=phyboard-segin-imx93-2 ./phyLinux init -p imx93 -r BSP-Yocto-NXP-i.MX93-PD24.2.0
+
    +
    +
    • +
+

在执行init命令后，phyLinux将打印一些重要的说明。例如，它将打印您的git用户信息、选择的SOC和BSP版本，以及引导构建过程进行下一步处理的信息。

+
+

3.2.1. 开始构建

+
    +

  • 设置Shell环境变量：

    +
    host:~/yocto$ source sources/poky/oe-init-build-env
+
    +
    +
    +

    备注

    +

    在每次打开新的用于编译的shell时，都需要先执行这一步骤。

    +
    +
    • +

  • 当前的工作目录会变更为 build/。

    • +

  • 打开主配置文件，同意并接受GPU和VPU二进制文件的许可证协议。通过取消注释相应的行来完成此操作，如下所示。

    +
    host:~/yocto/build$ vim conf/local.conf
+# Uncomment to accept NXP EULA
+# EULA can be found under ../sources/meta-freescale/EULA
+ACCEPT_FSL_EULA = "1"
+
    +
    +
    • +

  • 编译您的镜像：

    +
    host:~/yocto/build$ bitbake phytec-qt6demo-image
+
    +
    +
    +

    备注

    +

    对于第一次编译，我们建议从我们的较小的非图形化镜像phytec-headless-image开始，以查看一切是否正常工作。

    +
    host:~/yocto/build$ bitbake phytec-headless-image
+
    +
    +

    第一次构建过程在现代的Intel Core i7处理器上大约需要40分钟。后续的构建将使用本次编译产生的缓存，大约需要3分钟。

    +
    +
    • +
+
+
+

3.2.2. BSP镜像

+

所有由Bitbake生成的镜像都放在 ~/yocto/build/deploy*/images/<machine> 。例如以下列表是 phyboard-segin-imx93-2 machine生成的所有文件：

+
    +

  • u-boot.bin: 编译后的U-boot bootloader二进制文件。不是最终镜像中的bootloader！

    • +

  • oftree: 默认内核设备树

    • +

  • u-boot-spl.bin: 二级程序加载器 (SPL)

    • +

  • bl31-imx93.bin: ARM可信固件二进制文件

    • +

  • lpddr4_dmem_1d_v202201.bin, lpddr4_dmem_2d_v202201.bin, lpddr4_imem_1d_v202201.bin, lpddr4_imem_2d_v202201.bin: DDR PHY 固件镜像

    • +

  • imx-boot：由imx-mkimage编译的bootloader镜像，包括SPL、U-Boot、ARM可信固件和DDR固件。这是最终的可引导bootloader镜像。

    • +

  • Image: Linux内核镜像

    • +

  • Image.config: 内核config文件

    • +

  • imx93-phyboard-*.dtb: 内核设备树文件

    • +

  • imx93-phy*.dtbo: 内核设备树overlay文件

    • +

  • phytec-*.tar.gz: bitbake-image编译生成的root文件系统。

    +
      +

    • phytec-qt6demo-image-phyboard-*-imx93-*.tar.gz：在使用bitbake-build编译 phytec-qt6demo-image 时

      • +

    • phytec-headless-image-phyboard-*-imx93-*.tar.gz：在使用bitbake-build编译 phytec-headless-image 时

      • +
    +
    • +

  • phytec-*.rootfs.wic.xz: Compressed bootable SD +card image of bitbake-image that was built. Includes bootloader, DTBs, Kernel +and Root file system.

    +
      +

    • phytec-qt6demo-image-phyboard-*-imx93-*.rootfs.wic.xz: when bitbake-build +was processed for phytec-qt6demo-image

      • +

    • phytec-headless-image-phyboard-*-imx93-*.rootfs.wic.xz: when bitbake-build +was processed for phytec-headless-image

      • +
    +
    • +

  • imx93-11x11-evk_m33_*.bin，Cortex-M33 MCU的Demo应用程序的二进制文件；可以通过U-Boot或Linux手动加载和启动

    • +
+
+
+
+
+

4. 安装操作系统

+
+

4.1. 启动模式开关 (S3)

+
+

小技巧

+

底板版本：

+
    +

  • phyBOARD-Segin i.MX 93: 1472.5

    • +

  • phyBOARD-Nash i.MX 93: 1616.0, 1616.1

    • +
+
+

该 phyBOARD-Segin/Nash i.MX 93 具有一个（启动源配置）开关，配有四个可单独切换的位，用于选择phyCORE-i.MX 93 默认的启动源。

+ + + + + + + + + +
+../../../_images/eMMC.png +
+

eMMC

+
+
+
+../../../_images/Internal_Fuses.png +
+

内部fuse

+
+
+
+../../../_images/USB_Serial_Download.png +
+

USB

+
+
+
+../../../_images/SD_Card_Boot.png +
+

SD卡

+
+
+
+
+
+

4.2. 烧写eMMC

+

要从 eMMC 启动，请确保 BSP 镜像已正确烧写到 eMMC，并且 bootmode switch (S3) 设置为 eMMC。

+
+

警告

+

当eMMC和SD卡上烧录了相同（完全一致）的镜像时，他们boot分区的UUID也是相同的。所以如果从emmc启动时，烧录一致镜像的SD卡也同时存在，这会导致不确定的后果，因为Linux会根据UUID来挂载启动分区。

+
target:~$ blkid
+
+
+

可以运行以检查当前设置是否受到影响。如果 mmcblk0p1 和 mmcblk1p1 具有相同的 UUID，则该设置受到影响。

+
+
+

4.2.1. 从SD卡烧写eMMC

+

如果没有可用的网络，您可以通过SD卡更新eMMC。为此，您只需在SD卡上准备一个可用的镜像文件（*.wic）。由于镜像文件相当大，您需要扩展SD卡以使用其全部空间（如果之前没有扩展的话）。有关如何扩展SD卡，请参见“调整 ext4 根文件系统的大小”。

+

或者，使用partup包烧写SD卡，如 Getting Started 中所述。这样就可使用SD卡的全部容量。

+
+

4.2.1.1. 在开发板的linux环境中通过SD卡烧写eMMC

+

您可以在Linux上烧写eMMC。您只需在SD卡上保存一个partup包或WIC镜像即可。

+
    +

  • 在SD卡上查看您保存的partup包或WIC镜像或WIC.XZ镜像文件：

    +
    target:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.partup
+phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic.xz
+
    +
    +
    • +

  • 显示可用的MMC设备列表：

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk0
+mmcblk0boot0
+mmcblk0boot1
+mmcblk0p1
+mmcblk0p2
+mmcblk0rpmb
+
    +
    +
    • +

  • eMMC设备的特征是它包含两个boot分区：(mmcblk0 boot0; mmcblk0 boot1)

    • +

  • 使用 partup 将镜像写入 phyCORE-i.MX 93 的 eMMC (/dev/mmcblk0 不带 分区)：

    +
    target:~$ partup install phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.partup /dev/mmcblk0
+
    +
    +
    +

    小技巧

    +

    强烈建议使用partup，因为它更易于使用，并且可以充分利用eMMC设备的容量，自动调整分区大小。

    +
    +
    +

    备注

    +

    或者，可以使用 dd 命令。

    +

    对于未压缩的WIC镜像（*.wic）：

    +
    target:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +

    对于压缩的WIC镜像（*.wic.xz）：

    +
    target:~$ zstdcat phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic.xz | sudo dd of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +

    请注意，在使用 dd 进行烧写时，root分区并没有使用全部存储容量。

    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    警告

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+
+

4.2.2. 从网络烧写 eMMC

+

i.MX 93 开发板具有以太网连接器，可以通过网络进行更新。确保正确设置主机，主机的IP需要设置为192.168.3.10，子网掩码为255.255.255.0，并且需要在主机开启TFTP服务。抽象来看，eMMC设备和SD卡十分类似。因此，可以直接将Yocto生成的 WIC镜像 （ <name>.wic ）直接烧写到eMMC。该镜像包含bootloader、内核、设备树、设备树overlay和根文件系统。

+
+

备注

+

一些PHYTEC的BSP会生成压缩的 .wic.xz 镜像。在这种情况下，必须先对压缩镜像进行解压缩。

+
host:~$ unxz phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic.xz
+
+
+
+
+

4.2.2.1. 在开发板的Linux系统中通过网络烧写eMMC

+

您可以在开发板系统中更新eMMC。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

在主机上获取一个未压缩的镜像，并通过网络使用ssh将其发送到开发板的eMMC，使用一行命令：

+
target:~$ ssh <USER>@192.168.3.10 "dd if=<path_to_file>/phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic" | dd of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
+
+
+
+

4.2.2.2. 在Linux主机上通过网络烧写 eMMC

+

可以在您的Linux主机上将镜像烧写到eMMC。和之前一样，您需要在主机上准备一个完整的镜像。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

查看主机上可用的镜像文件：

+
host:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic
+
+
+

通过网络使用 dd 命令结合ssh将镜像发送到您设备的eMMC：

+
host:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic bs=1M status=progress | ssh root@192.168.3.11 "dd of=/dev/mmcblk0 conv=fsync"
+
+
+
+
+
+

4.2.3. 在运行的U-Boot中通过网络烧写eMMC U-Boot镜像

+

可以在U-Boot中更新U-Boot镜像imx-boot，eMMC上的U-Boot需要位于eMMC的user区域。

+
+

小技巧

+

需要保证设备和存储镜像的主机之间的网络正常！ Setup Network Host

+
+

通过tftp将镜像加载到RAM中，然后写入eMMC：

+
u-boot=> tftp ${loadaddr} imx-boot
+u-boot=> setexpr nblk ${filesize} / 0x200
+u-boot=> mmc dev 0
+u-boot=> mmc write ${loadaddr} 0x40 ${nblk}
+
+
+
+

提示

+

十六进制值表示偏移量，单位为512字节块的倍数。请参阅 偏移表 以获取相应SoC的正确值。

+
+
+
+

4.2.4. 从USB烧写eMMC

+
+

4.2.4.1. 在运行的Linux系统中从USB烧写eMMC

+

These steps will show how to flash the eMMC on Linux with a USB stick. You only +need a complete image saved on the USB stick and a bootable WIC image. (e.g. +phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic). Set the bootmode switch (S3) to SD Card.

+
    +

  • 插入并挂载U盘：

    +
    [   60.458908] usb-storage 1-1.1:1.0: USB Mass Storage device detected
+[   60.467286] scsi host0: usb-storage 1-1.1:1.0
+[   61.504607] scsi 0:0:0:0: Direct-Access                               8.07 PQ: 0 ANSI: 2
+[   61.515283] sd 0:0:0:0: [sda] 3782656 512-byte logical blocks: (1.94 GB/1.80 GiB)
+[   61.523285] sd 0:0:0:0: [sda] Write Protect is off
+[   61.528509] sd 0:0:0:0: [sda] No Caching mode page found
+[   61.533889] sd 0:0:0:0: [sda] Assuming drive cache: write through
+[   61.665969]  sda: sda1
+[   61.672284] sd 0:0:0:0: [sda] Attached SCSI removable disk
+target:~$ mount /dev/sda1 /mnt
+
    +
    +
    • +

  • 现在查看您在USB优盘上保存的镜像文件：

    +
    target:~$ cd /mnt
+target:~$ ls
+phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic
+
    +
    +
    • +

  • 显示可用的MMC设备列表：

    +
    target:~$ ls /dev | grep mmc
+mmcblk1
+mmcblk1p1
+mmcblk1p2
+mmcblk0
+mmcblk0boot0
+mmcblk0boot1
+mmcblk0p1
+mmcblk0p2
+mmcblk0rpmb
+
    +
    +
    • +

  • eMMC设备的特征是它包含两个boot分区：(mmcblk0 boot0; mmcblk0 boot1)

    • +

  • 将镜像写入 phyCORE-i.MX 93 eMMC (/dev/mmcblk0，无分区)：

    +
    target:~$ dd if=phytec-qt6demo-image-phyboard-segin-imx93-2.rootfs.wic of=/dev/mmcblk0 bs=1M conv=fsync status=progress
+
    +
    +
    • +

  • 在完成写入后，您的开发板可以从eMMC启动。

    +
    +

    小技巧

    +

    在此之前，您需要将 bootmode switch (S3) 配置为 eMMC。

    +
    +
    • +
+
+
+
+
+

4.3. RAUC

+

BSP支持RAUC（Robust Auto-Update Controller）。它管理设备固件更新的过程。这包括更新Linux内核、设备树和根文件系统。PHYTEC已撰写了一份在线手册，介绍如何在我们的BSP中集成RAUC：L-1006e.A5 RAUC更新与设备管理手册。

+
+
+
+

5. 开发

+
+

5.1. 主机网络准备

+

为了在bootloader中执行涉及网络的各种任务，需要配置一些主机服务。在开发主机上，必须安装和配置TFTP、NFS和DHCP服务。启动以太网所需的工具如下：

+
host:~$ sudo apt install tftpd-hpa nfs-kernel-server kea
+
+
+
+

5.1.1. TFTP服务设置

+
    +

  • 首先，创建一个目录来存储TFTP文件：

    +
    host:~$ sudo mkdir /srv/tftp
+
    +
    +
    • +

  • 然后将您的BSP镜像文件复制到此目录，并确保other用户也对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问这些文件。

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 您还需要为相应的接口配置一个静态IP地址。PHYTEC开发板的默认IP地址是192.168.3.11。可以将主机地址设置为192.168.3.10，子网掩码为255.255.255.0

    +
    host:~$ ip addr show <network-interface>
+
    +
    +

    将 <network-interface> 替换为连接到开发板的网络接口。您可以通过不指定网络接口来显示所有可选网络接口。

    +
    • +

  • 返回的结果应包含以下内容：

    +
    inet 192.168.3.10/24 brd 192.168.3.255
+
    +
    +
    • +

  • 创建或编辑 /etc/default/tftpd-hpa 文件：

    +
    # /etc/default/tftpd-hpa
+
+TFTP_USERNAME="tftp"
+TFTP_DIRECTORY="/srv/tftp"
+TFTP_ADDRESS=":69"
+TFTP_OPTIONS="-s -c"
+
    +
    +
    • +

  • 将 TFTP_DIRECTORY 设置为您的 TFTP 服务器根目录

    • +

  • 将TFTP_ADDRESS设置为TFTP服务监听的主机地址（设置为0.0.0.0:69以监听69端口上所有IP）。

    • +

  • 设置 TFTP_OPTIONS，以下命令显示可配置的选项：

    +
    host:~$ man tftpd
+
    +
    +
    • +

  • 重新启动服务以应用配置更改：

    +
    host:~$ sudo service tftpd-hpa restart
+
    +
    +
    • +
+

现在将开发板的以太网端口连接到您的主机。我们还需要在开发板和运行TFTP服务的主机之间建立网络连接。TFTP服务器的IP地址应设置为192.168.3.10，子网掩码为255.255.255.0。

+
+

5.1.1.1. NFS服务器设置

+
    +

  • 创建一个NFS目录：

    +
    host:~$ sudo mkdir /srv/nfs
+
    +
    +
    • +

  • NFS服务对文件共享的路径没有限制，因此在大多数linux发行版中，我们只需修改文件 /etc/exports ，并将我们的根文件系统共享到网络。在这个示例文件中，整个目录被共享在主机地址为192.168.3.10的IP地址上。注意这个地址需要根据本地情况进行调整：

    +
    /srv/nfs 192.168.3.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
+
    +
    +
    • +

  • 现在NFS服务器需要再次读取 /etc/exportfs 文件：

    +
    host:~$ sudo exportfs -ra
+
    +
    +
    • +
+
+
+

5.1.1.2. DHCP服务器设置

+
    +

  • 创建或编辑 /etc/kea/kea-dhcp4.conf 文件；以内部子网为例，将 <network-interface> 替换为物理网络接口的名称：

    +
    {
+  "Dhcp4": {
+    "interfaces-config": {
+      "interfaces": [ "<network-interface>/192.168.3.10" ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/tmp/dhcp4.leases"
+    },
+    "valid-lifetime": 28800,
+    "subnet4": [{
+        "id": 1,
+        "next-server": "192.168.3.10",
+        "subnet": "192.168.3.0/24",
+        "pools": [
+          { "pool": "192.168.3.1 - 192.168.3.255" }
+        ]
+    }]
+  }
+}
+
    +
    +
    • +
+
+

警告

+

在创建子网时请小心，因为这可能会扰乱公司网络政策。为了安全起见，请使用不同的子网，并通过 interfaces 配置选项指定该网络。

+
+
    +

  • 现在DHCP服务需要重新读取 /etc/kea/kea-dhcp4.conf 文件：

    +
    host:~$ sudo systemctl restart kea-dhcp4-server
+
    +
    +
    • +
+

当您启动/重启主机时，如果kea-dhcp4配置中指定的网络接口未处于活动状态，kea-dhcp4-server将无法启动。因此请确保在连接接口后启动或者重启该systemd服务。

+
+
+
+
+

5.2. 从网络启动内核

+

从网络启动意味着通过TFTP加载内核和设备树，并通过NFS加载根文件系统。但bootloader需要从另外的的启动设备加载。

+
+

5.2.1. 在主机上放置网络启动的镜像

+
    +

  • 将内核镜像复制到您的tftp目录中：

    +
    host:~$ cp Image /srv/tftp
+
    +
    +
    • +

  • 将设备树复制到您的tftp目录：

    +
    host:~$ cp oftree /srv/tftp
+
    +
    +
    • +

  • 将您想要使用的所有overlay文件复制到您的tftp目录中：

    +
    host:~$ cp *.dtbo /srv/tftp
+
    +
    +
    • +

  • 确保other用户对tftp目录中的所有文件具有读取权限，否则将无法从开发板访问它们：

    +
    host:~$ sudo chmod -R o+r /srv/tftp
+
    +
    +
    • +

  • 将根文件系统解压到您的NFS目录中：

    +
    host:~$ sudo tar -xvzf phytec-qt6demo-image-phyboard-segin-imx93-2.tar.gz -C /srv/nfs
+
    +
    +
    • +
+
+

备注

+

请确保使用sudo执行命令，以保留根文件系统中文件的所属权限。

+
+
+
+

5.2.2. 设置网络启动的bootenv.txt文件

+

在您的tftp目录中创建一个bootenv.txt文件，并将以下变量写入其中。

+
bootfile=Image
+fdt_file=oftree
+nfsroot=/srv/nfs
+overlays=<overlayfilenames>
+
+
+

<overlayfilenames> 必须替换为您想要使用的overlay设备树文件名。用空格分隔文件名。例如：

+
overlays=example-overlay1.dtbo example-overlay2.dtbo
+
+
+
+

小技巧

+

所有支持的设备树overlay在 device tree 章节中。

+
+
+
+

5.2.3. 开发板上的网络设置

+

如果要自定义开发板上的以太网配置，请按照此处的说明进行操作： Network Environment Customization

+
+
+

5.2.4. 从开发板启动

+

将开发板启动到U-boot，按任意键暂停。

+
    +

  • 要从网络启动，请运行：

    +
    u-boot=> run netboot
+
    +
    +
    • +
+
+
+
+

5.3. 使用UUU工具

+

NXP的镜像更新工具（UUU-Tool）是一款在主机上运行的软件，用于通过SDP（串行下载协议）在开发板上下载并运行bootloader。有关详细信息，请访问 https://github.com/nxp-imx/mfgtools 或下载 官方UUU工具文档。

+
+

5.3.1. 使用UUU工具的准备

+
    +

  • 请按照 https://github.com/nxp-imx/mfgtools#linux 上的说明进行操作。

    • +

  • 如果您要从源代码编译UUU，请将其添加到 PATH 中：

    +

    这个BASH命令只是暂时将UUU添加到 PATH 中。要永久添加，请将此行添加到 ~/.bashrc 中。

    +
    export PATH=~/mfgtools/uuu/:"$PATH"
+
    +
    +
    • +

  • 设置udev规则（在 uuu -udev 中有详细说明）：

    +
    host:~$ sudo sh -c "uuu -udev >> /etc/udev/rules.d/70-uuu.rules"
+host:~$ sudo udevadm control --reload
+
    +
    +
    • +
+
+
+

5.3.2. 获取镜像

+

可以从我们的服务器下载imx-boot，或者从Yocto编译目录中的build/deploy/images/phyboard-segin-imx93-2/获取它。要将wic镜像烧写到eMMC，你还需要 phytec-qt6demo-image-phyboard-segin-imx93-2.wic。

+
+
+

5.3.3. 开发板准备

+

将 bootmode switch (S3) 设置为 USB串行下载。同时，将 USB 端口 X8 (USB micro/OTG connector) 连接到主机。

+
+
+

5.3.4. 通过UUU工具启动bootloader

+

执行并给开发板上电：

+
host:~$ sudo uuu -b spl imx-boot
+
+
+

您可以像往常一样通过 UART1 console on PEB-EVAL-01 for phyBOARD-Segin and X-37 +USB-C debug for phyBOARD-Nash 在终端上查看启动日志。

+
+

备注

+

UUU工具使用的默认启动命令为fastboot。如果您想更改此设置，请在U-Boot提示符下使用setenv bootcmd_mfg修改环境变量bootcmd_mfg。但是请注意，当开发板再次使用UUU工具启动时，默认环境变量会被加载，saveenv重启后不生效。如果您想永久的更改U-boot的启动命令，则需要更改U-Boot代码。

+
+
+
+

5.3.5. 通过UUU工具将U-boot镜像烧写到eMMC

+
+

警告

+

UUU将U-boot刷入eMMC BOOT（硬件）启动分区后，会在eMMC中设置BOOT_PARTITION_ENABLE。这带来一个问题，因为我们希望bootloader保存在eMMC 的USER分区中。如果烧写入新的包含U-boot的.wic镜像而不禁用BOOT_PARTITION_ENABLE位，将导致设备始终使用保存在BOOT分区中的U-boot。为了在U-Boot中解决此问题，需要：

+
u-boot=> mmc partconf 0 0 0 0
+u-boot=> mmc partconf 0
+EXT_CSD[179], PARTITION_CONFIG:
+BOOT_ACK: 0x0
+BOOT_PARTITION_ENABLE: 0x0
+PARTITION_ACCESS: 0x0
+
+
+

or check Disable booting from eMMC boot partitions +from Linux.

+

这样bootloader虽然会被烧写到 eMMC 的BOOT分区，但在启动中不会被使用！

+

在使用 partup 工具和 .partup 包进行eMMC烧写时，上述过程是默认进行的，这是partup的优势，简化烧写过程。

+
+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc imx-boot
+
+
+
+
+

5.3.6. 通过UUU工具将wic镜像烧写到eMMC

+

执行并给开发板上电：

+
host:~$ sudo uuu -b emmc_all imx-boot phytec-qt6demo-image-phyboard-segin-imx93-2.wic
+
+
+
+
+
+

5.4. 独立编译准备

+

在本节中，我们将描述如何在不使用 Yocto Project 的情况下编译 U-Boot 和 Linux kernel。U-Boot、Linux kernel以及其他源码的 git 仓库都可以在我们的 Git 服务器 上找到，地址为 git://git.phytec.de。

+
+

备注

+

如果您的公司防火墙/网关禁止git协议，您可以改用HTTP或HTTPS（例如：git clone git://git.phytec.de/u-boot-imx）

+
+
+

5.4.1. Git 仓库

+
    +

  • 使用的 U-Boot 仓库：

    +
    git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 我们的U-Boot基于 u-boot-imx 并添加了一些硬件相关的补丁。

    • +

  • 使用的 Linux 内核仓库：

    +
    git://github.com/phytec/linux-phytec-imx.git
+
    +
    +
    • +

  • 我们的 i.MX 93 内核是基于 linux-phytec-imx 内核。

    • +
+

要找出核心板应使用的u-boot和kernel版本对应的git仓库tag标签，请查看您的BSP源文件夹：

+
+
meta-phytec/recipes-kernel/linux/linux-phytec-imx_*.bb
+meta-phytec/recipes-bsp/u-boot/u-boot-imx_*.bb
+
+
+
+
+
+

5.4.2. 获取SDK

+

您可以在此处下载SDK 这里，或者使用Yocto去编译生成SDK：

+
    +

  • 移动到Yocto的build目录：

    +
    host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
    +
    +
    • +
+

在成功编译后，SDK安装包保存在 build/deploy*/sdk。

+
+
+

5.4.3. 安装SDK

+
    +

  • 设置正确的权限并安装SDK：

    +
    host:~$ chmod +x phytec-ampliphy-vendor-wayland-glibc-x86_64-phytec-qt6demo-image-cortexa55-toolchain-5.0.sh
+host:~$ ./phytec-ampliphy-vendor-wayland-glibc-x86_64-phytec-qt6demo-image-cortexa55-toolchain-5.0.sh
+============================================================================================================
+Enter target directory for SDK (default: /opt/ampliphy-vendor-wayland/5.0):
+You are about to install the SDK to "/opt/ampliphy-vendor-wayland/5.0". Proceed [Y/n]? Y
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
    +
    +
    • +
+
+
+

5.4.4. 使用SDK

+

通过在工具链目录中source environment-setup 文件来初始化您的 shell 交叉编译环境：

+
host:~$ source /opt/ampliphy-vendor-wayland/5.0/environment-setup-cortexa55-phytec-linux
+
+
+
+
+

5.4.5. 安装所需工具

+

独立编译Linux kernel和U-Boot需要主机安装一些额外的工具。对于Ubuntu，您可以使用以下命令安装它们：

+
host:~$ sudo apt install bison flex libssl-dev
+
+
+
+
+
+

5.5. 单独编译U-Boot

+
+

5.5.1. 获取源代码

+
    +

  • 获取U-Boot源代码：

    +
    host:~$ git clone git://git.phytec.de/u-boot-imx
+
    +
    +
    • +

  • 要获取正确的 U-Boot tag，您需要查看我们的release notes，可以在这里找到：release notes

    • +

  • 此版本的 tag 称为 v2024.04-2.0.0-phy6

    • +

  • 查看所需的 U-Boot tag：

    • +
+
host:~$ cd ~/u-boot-imx/
+host:~/u-boot-imx$ git fetch --all --tags
+host:~/u-boot-imx$ git checkout tags/v2024.04-2.0.0-phy6
+
+
+
    +

  • 从技术上讲，您现在可以编译U-Boot，但实际上还需要一些进一步的步骤：

    +
      +

    • 创建您自己的开发分支：

      +
      host:~/u-boot-imx$ git switch --create <new-branch>
+
      +
      +
      +

      备注

      +

      您可以根据您的需要自行命名您的开发分支，这只是一个示例。

      +
      +
      • +
    +
    • +

  • 设置编译环境：

    +
    host:~/u-boot-imx$ source /opt/ampliphy-vendor-wayland/5.0/environment-setup-cortexa55-phytec-linux
+
    +
    +
    • +
+
+
+

5.5.2. 获取所需的二进制文件

+

要编译imx-boot，您需要 收集 这些 文件 以便后续使用 imx-mkimage工具 ：

+
    +

  • ARM Trusted firmware 二进制文件 （ mkimage 工具 兼容格式 bl31.bin ）：bl31-imx93.bin

    • +

  • OPTEE 镜像 (可选的)：tee.bin

    • +

  • DDR firmware files ( mkimage 工具 兼容格式 lpddr4_[i,d]mem_*d_*.bin ): lpddr4_dmem_1d_*.bin, lpddr4_dmem_2d_*.bin, lpddr4_imem_1d_*.bin, lpddr4_imem_2d_*.bin

    • +

  • 容器镜像：mx93a1-ahab-container.img

    • +
+

如果您已经使用Yocto编译了我们的BSP，您可以从此处提到的目录中获取这些文件：BSP Images

+

或者您可以从PHYTEC下载服务器（ https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools/ ）下载文件。您可以使用下面的命令从该服务器下载所有文件：

+
host:~$ mkdir ./artefacts && cd ./artefacts
+host:~/artefacts$ wget \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//bl31-imx93.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//tee.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_dmem_1d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_dmem_2d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_imem_1d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//lpddr4_imem_2d_v202201.bin \
+                    https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX93/BSP-Yocto-NXP-i.MX93-PD24.2.0/images/ampliphy-vendor-wayland/phyboard-segin-imx93-2/imx-boot-tools//mx93a1-ahab-container.img
+host:~/artefacts$ cd ..
+
+
+
+
+

5.5.3. 编译bootloader

+
    +

  • 编译u-boot：

    +
    host:~/u-boot-imx$ make <defconfig>
+host:~/u-boot-imx$ make
+host:~/u-boot-imx$ cd ..
+
    +
    +
    +

    备注

    +

    In command above replace <defconfig> with imx93-phycore_defconfig

    +
    +
    • +
+
+

5.5.3.1. 使用 imx-mkimage 编译最终的 flash.bin

+
    +

  • 获取 imx-mkimage：

    +
    host:~$ git clone https://github.com/nxp-imx/imx-mkimage
+host:~$ cd imx-mkimage/
+host:~/imx-mkimage$ git checkout tags/lf-6.6.23-2.0.0
+
    +
    +
    • +

  • 将固件二进制文件复制到 imx-mkimage

    +
    host:~/imx-mkimage$ cp ../artefacts/bl31-imx93.bin ./iMX9/bl31.bin
+host:~/imx-mkimage$ cp \
+                     ../artefacts/lpddr4_* \
+                     ../artefacts/mx93a1-ahab-container.img \
+                     ../artefacts/tee.bin \
+                     ./iMX9/
+
    +
    +
    • +

  • 将u-boot二进制文件和DTB复制到imx-mkimage中

    +
    host:~/imx-mkimage$ cp ../u-boot-imx/spl/u-boot-spl.bin ../u-boot-imx/u-boot.bin ./iMX9/
+host:~/imx-mkimage$ cp ../u-boot-imx/arch/arm/dts/<dtb> ./iMX9/
+
    +
    +
    +

    备注

    +

    In command above replace <dtb> with imx93-phyboard-segin.dtb

    +
    +
    • +

  • 编译最终的 flash.bin 二进制文件

    +
    +
    host:~/imx-mkimage$ make SOC=iMX9 REV=A1 flash_singleboot
+
    +
    +
    +
    • +
+
+
+
+

5.5.4. 将bootloader烧写到块设备上

+

flash.bin可以在imx-mkimage/iMX9/目录下找到，现在可以进行烧写。需要一个特定于芯片的偏移量：

+ + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

i.MX 93

32 kiB

0 kiB

/dev/mmcblk0

+

例如，烧写SD卡：

+
host:~/imx-mkimage$ sudo dd if=./iMX9/flash.bin of=<sd-card> bs=1024 seek=32 conv=sync
+
+
+
+

备注

+

In the command above, replace <sd-card> with your sd-card device name. +For more information on how to find the device name, see the section +Finding the Correct Device in +Getting Started.

+
+
+

提示

+

如果您有我们的BSP Yocto工程代码，具体的偏移值也会在Yocto变量"BOOTLOADER_SEEK"和"BOOTLOADER_SEEK_EMMC"中声明。

+
+
+
+
+

5.6. 单独编译内核

+
+

5.6.1. 配置源代码

+
    +

  • 使用的 linux-phytec-imx 分支可以在 release notes 中找到

    • +

  • 此版本所需的标签称为 v6.6.23-2.0.0-phy8

    • +

  • Check out 所需的 linux-phytec-imx 标签：

    +
    host:~$ git clone git://github.com/phytec/linux-phytec-imx.git
+host:~$ cd ~/linux-phytec-imx/
+host:~/linux-phytec-imx$ git fetch --all --tags
+host:~/linux-phytec-imx$ git checkout tags/v6.6.23-2.0.0-phy8
+
    +
    +
    • +

  • 为了提交更改，强烈建议切换到一个新分支：

    +
    host:~/linux-phytec-imx$ git switch --create <new-branch>
+
    +
    +
    • +

  • 设置编译环境：

    +
    host:~/linux-phytec-imx$ source /opt/ampliphy-vendor-wayland/5.0/environment-setup-cortexa55-phytec-linux
+
    +
    +
    • +
+
+
+

5.6.2. 编译内核

+
    +

  • 编译Linux内核：

    +
    host:~/linux-phytec-imx$ make imx9_phytec_defconfig
+host:~/linux-phytec-imx$ make -j$(nproc)
+
    +
    +
    • +

  • 安装内核模块，比如安装到 NFS 目录：

    +
    host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/home/<user>/<rootfspath> modules_install
+
    +
    +
    • +

  • 镜像可以在 ~/linux-phytec-imx/arch/arm64/boot/Image 找到

    • +

  • dtb文件可以在 ~/linux-phytec-imx/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dtb 找到

    • +

  • 要（重新）编译设备树和 -overlay 文件，只需运行

    +
    host:~/linux-phytec-imx$ make dtbs
+
    +
    +
    • +
+
+

备注

+

如果您遇到以下编译问题：

+
scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: No such file or directory
+
+
+

确保您在主机系统上安装了 "libyaml-dev" 包：

+
host:~$ sudo apt install libyaml-dev
+
+
+
+
+
+

5.6.3. 将内核复制到SD卡

+

内核及module和对应的设备树二进制文件可以用以下方式复制到已挂载的SD卡上。

+
host:~/linux-phytec-imx$ cp arch/arm64/boot/Image /path/to/sdcard/boot/
+host:~/linux-phytec-imx$ cp arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dtb /path/to/sdcard/boot/oftree
+host:~/linux-phytec-imx$ make INSTALL_MOD_PATH=/path/to/sdcard/root/ modules_install
+
+
+
+
+
+

5.7. 格式化SD卡启动盘以允许通过SD卡进行烧录

+

使用单一的SD卡启动盘对存储介质进行烧写是开发过程中的常见任务。本章节针对此场景提供基础说明。大多数镜像的大小超过了默认的root分区剩余容量。要使用SD卡进行烧写，根文件系统需要扩展或创建一个单独的分区。有几种不同的方法可以格式化SD卡。最简单的方法是使用Gparted。

+
+

5.7.1. Gparted

+
    +

  • 获取 GParted：

    +
    host:~$ sudo apt install gparted
+
    +
    +
    • +

  • 将SD卡插入主机并获取设备名称：

    +
    host:~$ dmesg | tail
+...
+[30436.175412] sd 4:0:0:0: [sdb] 62453760 512-byte logical blocks: (32.0 GB/29.8 GiB)
+[30436.179846]  sdb: sdb1 sdb2
+...
+
    +
    +
    • +

  • 卸载所有SD卡分区。

    • +

  • 启动 GParted：

    +
    host:~$ sudo gparted
+
    +
    +
    • +
+../../../_images/gparted1.png +
+

5.7.1.1. 扩展根文件系统

+
+

警告

+

使用resize2fs版本1.46.6及更早版本的PC系统（例如Ubuntu 22.04）无法烧写在Mickledore以及更新的yocto版本上创建的partup软件包。这个是因为resize2fs新增了默认选项而导致的兼容性问题。有关详细信息，请参阅 发布说明 。

+
+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +

  • 选择 ext4 根分区并点击调整大小：

    • +
+../../../_images/gparted5.png +../../../_images/gparted2.png +
    +

  • 您可以根据需要拖动滑块或手动输入大小。

    • +
+../../../_images/gparted3.png +
    +

  • 通过点击“Change Size”按钮确认您的输入。

    • +
+../../../_images/gparted4.png +
    +

  • 要应用您的更改，请按绿色勾号。

    • +

  • 现在您可以挂载根分区并将 phytec-qt6demo-image-phyboard-segin-imx93-2.wic 镜像复制到其中。然后再卸载它：

    +
    host:~$ sudo cp phytec-qt6demo-image-phyboard-segin-imx93-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+

5.7.1.2. 创建第三个分区

+
    +

  • 在右上角的下拉菜单中选择您的SD卡设备

    • +
+../../../_images/gparted1.png +
    +

  • 选择更大的未分配区域，然后点击"New"：

    • +
+../../../_images/gparted6.png +
    +

  • 点击"Add"

    • +
+../../../_images/gparted7.png +
    +

  • 按绿色勾确认更改。

    • +
+../../../_images/gparted8.png +
    +

  • 现在您可以挂载新的分区并将 phytec-qt6demo-image-phyboard-segin-imx93-2.wic 镜像复制到其中。然后卸载它：

    +
    host:~$ sudo mount /dev/sde3 /mnt
+host:~$ sudo cp phytec-qt6demo-image-phyboard-segin-imx93-2.wic /mnt/ ; sync
+host:~$ umount /mnt
+
    +
    +
    • +
+
+
+
+
+
+

6. 设备树 (DT)

+
+

6.1. 介绍

+

以下文本简要描述了设备树，关于设备树的相关文档可以在Linux kernel文档中找到（https://docs.kernel.org/devicetree/usage-model.html）。

+

“Open Firmware Device Tree”或简称设备树（DT）是一种用于描述硬件的数据结构和语言。更具体地说，它是一个可由操作系统读取的硬件描述，以便操作系统不需要对machine的细节进行硬编码

+

内核文档是学习设备树的一个非常好的资源。关于设备树数据格式的概述可以在 devicetree.org 的设备树使用页面找到。

+
+
+

6.2. PHYTEC i.MX 93 BSP设备树概念

+

以下部分说明了PHYTEC配置基于 i.MX 93 的核心板设备树的一些规则。

+
+

6.2.1. 设备树结构

+
    +

  • Module.dtsi - 文件包括所有安装在核心板上的设备，例如PMIC和RAM。

    • +

  • Board.dts - 包含module dtsi 文件。从SoC i.MX 93 引出并在底板使用的设备也包含在此 dts 中。

    • +

  • Overlay.dtso - 根据核心板或底板上可选硬件（例如 SPI 闪存或 PEB-AV-10）的情况来启用/禁用一些功能。

    • +
+

在Linux内核的根目录下，我们的 i.MX 9 平台的设备树文件可以在 arch/arm64/boot/dts/freescale/ 找到。

+
+
+

6.2.2. 设备树Overlay

+

设备树Overlay是可以在启动时合并到设备树中的设备树片段。下面是扩展板的硬件描述。对比源码中的include，overlay通过覆盖的方式来生效。overlay也可以根据实际开发板的硬件配置来设置设备树节点状态。设备树Overlay与我们Linux内核仓库中的其他设备树文件一起放在子文件夹 arch/arm64/boot/dts/freescale/ 中。

+

phyboard-segin-imx93-2.conf 可用的overlay文件有：

+
imx93-phyboard-segin-peb-av-02.dtbo
+imx93-phyboard-segin-peb-eval-01.dtbo
+imx93-phyboard-segin-peb-wlbt-05.dtbo
+imx93-phycore-rpmsg.dtbo
+imx93-phycore-no-emmc.dtbo
+imx93-phycore-no-eth.dtbo
+
+
+

phyboard-nash-imx93-1.conf可用的overlay有：

+
imx93-phyboard-nash-jtag.dtbo
+imx93-phyboard-nash-peb-av-10.dtbo
+imx93-phyboard-nash-pwm-fan.dtbo
+imx93-phyboard-nash-vm016.dtbo
+imx93-phycore-rpmsg.dtbo
+imx93-phycore-no-emmc.dtbo
+imx93-phycore-no-eth.dtbo
+
+
+

可以在Linux或U-Boot环境下配置overlay。overlay是在引导命令调用后、内核加载之前生效。接下来的部分将更详细地解释配置方法。

+
+

6.2.2.1. 设置 ${overlays} 变量

+

${overlays} U-Boot 环境变量包含一个以空格分隔的overlay文件列表，这些overlay文件将在启动过程中应用。根据启动源，overlay文件必须放置在 eMMC/SD 卡的启动分区中，或者通过 tftp 加载。在 $KERNEL_DEVICETREE 这个 Yocto machine 变量中设置的 overlay 文件将自动添加到最终 WIC 镜像的启动分区中。

+

${overlays} 变量可以直接在U-Boot环境中设置，也可以作为外部 bootenv.txt 环境文件的一部分。默认情况下， ${overlays} 变量来自位于启动分区的 bootenv.txt 文件。您可以在已启动的开发板上从Linux读取和写入该文件：

+
target:~$ cat /boot/bootenv.txt
+overlays=imx93-phyboard-segin-peb-eval-01.dtbo imx93-phyboard-segin-peb-av-02.dtbo
+
+
+
+

备注

+

确保boot分区已挂载！如果没有，您可以使用以下命令进行挂载：

+
target:~$ mount /dev/mmcblkXp0 /boot
+
+
+
+

更改将在下次重启后生效。如果没有可用的 bootenv.txt 文件，可以直接在U-Boot环境中设置overlay变量。

+
u-boot=> setenv overlays imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> printenv overlays
+overlays=imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> boot
+
+
+

如果用户定义了 ${overlays} 变量，同时存在 bootenv.txt 文件，则需要设置 ${no_bootenv} 变量：

+
u-boot=> setenv no_bootenv 1
+u-boot=> setenv overlays imx93-phyboard-segin-peb-av-02.dtbo
+u-boot=> boot
+
+
+

有关环境的更多信息，请参见 U-boot External Environment subsection of the +device tree overlay section。

+

我们使用 ${overlays} 变量来描述在运行时无法检测到的扩展板。为了禁止在启动时应用列在 ${overlays} 变量中的overlay，可以在bootloader环境中将 ${no_overlays} 变量设置为 1。

+
u-boot=> setenv no_overlays 1
+u-boot=> boot
+
+
+
+
+
+

6.2.3. U-boot外部环境

+

在Linux内核启动时，外部环境 bootenv.txt 文本文件将从MMC设备的boot分区或通过TFTP加载。该文件的主要目的是存储 ${overlays} 变量。这可以针对不同的machine在Yocto中预定义不同的overlay配置。文件的内容在meta-phytec中的Yocto recipe中的bootenv中定义： https://git.phytec.de/meta-phytec/tree/recipes-bsp/bootenv?h=scarthgap

+

该文件中也可以设置其他变量。这些变量将覆盖环境中现有的设置。但只有对boot命令后进行计算的变量生效，例如 ${nfsroot} 或 ${mmcargs}。在文件中更改其他变量将不会有作用。以网络启动的用法作为示例。

+

如果无法加载外部环境，启动过程将继续进行，并使用自带的环境变量值。

+
+
+

6.2.4. 在Linux环境下更改开发板上的U-boot环境变量

+

Libubootenv是我们镜像中包含的一个工具，用于在开发板linux上修改U-Boot环境。

+

使用以下命令打印U-Boot环境：

+
target:~$ fw_printenv
+
+
+

使用以下命令修改U-Boot环境：

+
target:~$ fw_setenv <variable> <value>
+
+
+
+

小心

+

Libubootenv会读取配置文件中配置的环境变量。要修改的环境变量会被插入到该文件中，默认情况下使用eMMC中存储环境变量。

+

如果eMMC没有被烧写过或者eMMC环境被擦除，libubootenv将无法工作。您应该修改 /etc/fw_env.config 文件，以匹配您想要使用的环境源。

+
+
+
+
+
+

7. 访问外设

+

要查找本文中所述的PHYTEC的phyCORE-i.MX 93 BSP支持的开发板和核心板，请访问 our BSP 网页，并在下载部分点击相应的BSP版本。在这里，您可以在"Hardware Article Number"列中找到所有支持的硬件，并在"Machine Name"下的相应单元格中找到正确的"Machine Name"。

+

为了最大化软件的可复用性，Linux内核提供了一个巧妙的软件架构，软件会根据不同硬件组件来分层。BSP（板级支持包）尽可能地对套件的功能进行模块化。当定制开发板或自定义核心板时，大部分软件配置可以简单的复制粘贴。与具体的开发板相关的内核代码可以在内核代码仓库中的设备树（DT）中找到，路径为 arch/arm64/boot/dts/freescale/*.dts 。

+

实际上，软件复用是Linux内核最重要的特性之一，尤其是在ARM架构中，它必须应对大量复杂且不同的系统级芯片（SoC）。整个开发板的硬件在设备树（DT）中描述，独立于内核镜像。硬件描述在一个单独的二进制文件中，称为设备树二进制文件（Device Tree Blob，DTB）（参见 device tree）。

+

请阅读PHYTEC i.MX 93 BSP设备树概念部分，以了解我们的 i.MX 9 BSP设备树模型。

+

以下部分概述了 i.MX 9 平台上支持的硬件组件及其对应操作系统驱动程序。客户可以根据自身的需求进行更改。

+
+

7.1. i.MX 93 引脚复用

+

该 i.MX 93 Soc包含许多外设接口。为了在保持最大功能性的同时减少封装尺寸和降低整体系统成本，许多 i.MX 93 引脚可以多路复用为多达八种信号功能。尽管存在许多可能的引脚多路复用组合，但由于时序限制，只有一定数量的组合被称为有效的 IO 集合。这些有效的 IO 集合经过精心挑选，以为用户提供尽可能多的应用场景。

+

请参考我们的硬件手册或NXP i.MX 93 参考手册，以获取有关特定引脚和复用能力的更多信息。

+

IO 集合的配置，也称为复用（muxing），是在设备树中完成的。驱动程序pinctrl-single读取设备树的节点fsl,pins，并进行引脚复用配置。

+

以下是 imx93-phyboard-segin.dts中UART1设备的引脚复用示例：

+
pinctrl_uart1: uart1grp {
+        fsl,pins = <
+                MX93_PAD_UART1_RXD__LPUART1_RX     0x31e
+                MX93_PAD_UART1_TXD__LPUART1_TX     0x30e
+        >;
+};
+
+
+

字符串的第一部分 MX93_PAD_UART1_RXD__LPUART1_RX 指定了引脚（在这个例子中是 UART1_RXD）。字符串的第二部分（LPUART1_RX）是该引脚的期望复用选项。引脚设置值（右侧的十六进制值）定义了引脚的不同模式，例如，内部上拉电阻是否被激活。在当前情况下，内部上拉电阻被激活。

+

The device tree representation for UART1 pinmuxing: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L259

+
+
+

7.2. 网络

+

phyBOARD-Segin/Nash i.MX 93 提供两个以太网接口。

+
    +

  • On phyBOARD-Segin i.MX 93 we have:

    +
      +

    • 由 phyCORE-i.MX93 提供的百兆以太网

      • +

    • 由phyBOARD提供的百兆以太网。

      • +
    +
    • +

  • On phyBOARD-Nash i.MX 93 we have:

    +
      +

    • 由 phyCORE-i.MX93 提供的百兆以太网

      • +

    • 由phyBOARD提供的千兆以太网。

      • +
    +
    • +
+

所有接口都提供一个标准的Linux网络端口，可以使用BSD套接字接口进行编程。整个网络配置由systemd-networkd守护进程管理。相关的配置文件可以在开发板的 /lib/systemd/network/ 目录中找到，以及在BSP中的 meta-ampliphy/recipes-core/systemd/systemd-conf 目录中。

+

IP地址可以在*.network文件中进行配置。eth0的默认IP地址和子网掩码为：

+
eth0: 192.168.3.11/24
+
+
+

根据您的硬件配置，设备树的以太网设置可能会分为两个文件：核心板的DT文件和底板的DT。FEC以太网IP核心的设备树设置，其中以太网PHY被集成在核心板上，可以在这里找到：https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi#L61。

+

The device tree set up for EQOS Ethernet IP core where the PHY is populated +on the phyBOARD-Segin/Nash i.MX 93 can be found here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L114 or here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L83.

+
+

7.2.1. 网络配置

+
+

7.2.1.1. U-boot网络环境

+
    +

  • 要在bootloader中查找以太网设置：

    +
    u-boot=> printenv ipaddr serverip netmask
+
    +
    +
    • +

  • 在将主机设置为IP 192.168.3.10和子网掩码255.255.255.0的情况下，开发板应该返回：

    +
    u-boot=> printenv ipaddr serverip netmask
+ipaddr=192.168.3.11
+serverip=192.168.3.10
+netmask=255.225.255.0
+
    +
    +
    • +

  • 如果您需要进行任何更改：

    +
    u-boot=> setenv <parameter> <value>
+
    +
    +

    <parameter> 应该是 ipaddr、netmask、gatewayip 或 serverip 中的一个。<value> 将是所选参数的设定值。

    +
    • +

  • 您所做的更改目前是临时的。要保存这些更改：

    +
    u-boot=> saveenv
+
    +
    +
    • +
+

在这里，您也可以将IP地址更改为DHCP，而不是使用静态IP地址。

+
    +

  • 配置：

    +
    u-boot=> setenv ip dhcp
+
    +
    +
    • +

  • 设置 TFTP 和 NFS 的路径。修改可以如下所示：

    +
    u-boot=> setenv nfsroot /home/user/nfssrc
+
    +
    +
    • +
+

请注意，这些修改只会影响bootloader的设置。

+
+

小技巧

+

像nfsroot和netargs这样的变量可以被U-boot外部环境重新赋值。对于网络启动，外部环境将通过tftp加载。例如，要在 bootenv.txt 文件中设置nfsroot变量，请在tftproot目录修改：

+
nfsroot=/home/user/nfssrc
+
+
+

无需在开发板上存储这些信息。请注意，U-boot外部环境对于像 ipaddr 或 serveraddr 这样的变量不起作用，因为它们在加载外部环境之前已经被设置完成。

+
+
+
+

7.2.1.2. 内核网络环境

+
    +

  • 在开发板中查找eth0的以太网设置：

    +
    target:~$ ifconfig eth0
+eth0      Link encap:Ethernet  HWaddr 50:2D:F4:19:D6:33
+          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
    +
    +
    • +

  • 临时调整eth0的配置：

    +
    target:~$ ifconfig eth0 192.168.3.11 netmask 255.255.255.0 up
+
    +
    +
    • +
+
+
+
+

7.2.2. 无线局域网

+
+

备注

+

For now, only phyBOARD-Segin i.MX 93 supports WLAN/Bluetooth features. WLAN/Bluetooth is +thus not supported on phyBOARD-Nash i.MX 93 yet.

+
+

WLAN and Bluetooth on the phyBOARD-Segin i.MX 93 are provided by the PEB-WLBT-05 expansion card. +The PEB-WLBT-05 for phyBOARD-Segin i.MX 93 Quickstart Guide shows you how to install the +PEB-WLBT-05.

+
+

小技巧

+

With the BSP Version PD24.2 and newer, the PEB-WLBT-05 overlay needs to be activated first, +otherwise the PEB-WLBT-05 won't be recognized.

+
target:~$ vi /boot/bootenv.txt
+
+
+

之后，bootenv.txt 文件应该如下所示（它还可以包含其他设备树overlay！）：

+
overlays=imx93-phyboard-segin-peb-wlbt-05.dtbo
+
+
+

更改将在重启后应用：

+
target:~$ reboot
+
+
+

有关设备树overlay的更多信息，请阅读 device tree 章节。

+
+

为了支持WLAN和蓝牙，我们使用来自LSR的Sterling-LWB模块。该模块支持2.4 GHz，并且可以在多种模式下运行，如客户端模式、使用WEP、WPA、WPA2加密的接入点（AP）模式等。有关该模块的更多信息，请访问 https://connectivity-staging.s3.us-east-2.amazonaws.com/2019-09/CS-DS-SterlingLWB%20v7_2.pdf

+
+

备注

+

By default, bluetooth is not supported on phyBOARD-Segin i.MX 93 with PEB-WLBT-05 +expansion card due to hard-wired connections. However, it is possible to +re-work PEB-WLBT-05 card by adjusting solder pads and enabling bluetooth in +the software. Please contact your PHYTEC representative for more information.

+
+
+

7.2.2.1. 连接到WLAN网络

+

首先设置您所在国家的正确监管域：

+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

你将会看到：

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+

设置无线接口：

+
target:~$ ip link
+target:~$ ip link set up dev wlan0
+
+
+

现在您可以扫描可用的网络：

+
target:~$ iw wlan0 scan | grep SSID
+
+
+

您可以使用一个跨平台的客户端，名为wpa_supplicant，支持WEP、WPA和WPA2，以建立加密连接。

+

为此，请将网络凭据添加到文件 /etc/wpa_supplicant.conf 中：

+
country=DE
+network={
+    ssid="<SSID>"
+    proto=WPA2
+    psk="<KEY>"
+}
+
+
+

现在可以建立连接：

+
target:~$ wpa_supplicant -D nl80211 -c /etc/wpa_supplicant.conf -i wlan0 -B
+
+
+

这会得到如下输出：

+
Successfully initialized wpa_supplicant
+
+
+

The ip address is automatically configured over DHCP. For other possible IP configurations, +see section Changing the Network Configuration in the Yocto Reference Manual (scarthgap).

+
+
+
+
+

7.3. SD/MMC 卡

+

该 i.MX 93 支持一个用于SD卡和MMC卡的接口，作为linux通用块设备。这些设备可以像其他任何块设备一样使用。

+
+

警告

+

这些设备是热插拔的。然而，您必须确保在设备仍然挂载时不要拔掉它。这可能会导致数据丢失！

+
+

插入SD/MMC卡后，内核将在/dev中生成新的设备节点。完整设备可以通过其/dev/mmcblk1设备节点访问。SD/MMC卡的分区将显示为：

+
/dev/mmcblk1p<Y>
+
+
+

<Y> 作为分区编号，从1开始计数，直到该设备的最大分区数量。分区可以使用任何类型的文件系统进行格式化，并且可以以标准方式进行处理，例如，可以使用mount 和 umount 命令进行分区挂载和卸载。

+
+

小技巧

+

这些分区设备节点要求SD卡包含有效的分区表（类似于“硬盘”）。如果没有分区表，则整个设备作为一个文件系统使用（类似于“软盘”）。在这种情况下，必须使用 /dev/mmcblk1 进行格式化和挂载。卡始终以可写方式挂载。

+
+

DT configuration for the MMC (SD card slot) interface can be found here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L213 or here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L202

+

DT configuration for the eMMC interface can be found here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi#L194 or here:

+
+
+

7.4. eMMC设备

+

PHYTEC模块如phyCORE-i.MX 93 配备了eMMC存储芯片作为主要存储。eMMC设备使用多层单元（MLC）或三层单元（TLC）技术来实现存储，并集成了处理ECC和磨损均衡的存储控制器。它们通过SD/MMC接口连接到 i.MX 93 ，并在Linux内核中作为块设备表示，如SD卡、优盘或硬盘。

+

电气和协议规范由JEDEC提供（https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc）。eMMC制造商的数据手册相对较简单，旨在与支持的JEDEC eMMC标准版本一起阅读。

+

PHYTEC目前使用JEDEC版本5.0和5.1的eMMC芯片。

+
+

7.4.1. 扩展CSD寄存器

+

通过扩展CSD寄存器可以读取eMMC设备其他的信息和配置。有关寄存器的详细列表，请参阅制造商的数据手册和JEDEC标准。

+

在Linux用户空间中，您可以查询寄存器：

+
target:~$ mmc extcsd read /dev/mmcblk0
+
+
+

你将会看到：

+
=============================================
+   Extended CSD rev 1.7 (MMC 5.0)
+=============================================
+
+ Card Supported Command sets [S_CMD_SET: 0x01]
+ [...]
+
+
+
+
+

7.4.2. 使能后台操作 (BKOPS)

+

与原始NAND Flash相比，eMMC设备包含一个闪存传输层（FTL），该层负责处理原始MLC或TLC的磨损均衡、块管理和错误更正码（ECC）。这需要定期执行一些维护任务（例如擦除未使用的块）。这些任务被称为 后台操作（BKOPS） 。

+

默认情况下（取决于芯片），后台操作可能会定期执行，也可能不会，他影响读写的最大延迟时间。

+

JEDEC标准自版本v4.41起规定了一种方法，主机可以手动触发BKOPS。有关更多详细信息，请参阅JEDEC标准章节“Background Operations”以及eMMC数据手册中寄存器BKOPS_EN（寄存器：163）和BKOPS_START（寄存器：164）的描述。

+

寄存器 BKOPS_EN（寄存器：163）的位 MANUAL_EN（位 0）的含义：

+
    +

  • 值 0：主机不支持手动触发 BKOPS。设备写入性能会受到影响。

    • +

  • 值1：主机支持手动触发BKOPS。当主机不进行设备读写时，它会不时触发BKOPS。

    • +
+

自v3.7版本以来，Linux内核已经实现了触发后台操作的机制。您只需在eMMC设备上启用BKOPS_EN（详细信息见下文）。

+

JEDEC标准v5.1引入了一种新的自动BKOPS功能。它使主机能够定期触发后台操作，因为设备在空闲时会自动启动BKOPS（请参见寄存器BKOPS_EN（寄存器：163）中位AUTO_EN的描述）。

+
    +

  • 要检查 BKOPS_EN 是否已设置，请执行：

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep BKOPS_EN
+
    +
    +

    输出将会是，例如：

    +
    Enable background operations handshake [BKOPS_EN]: 0x01
+#OR
+Enable background operations handshake [BKOPS_EN]: 0x00
+
    +
    +

    值0x00表示BKOPS_EN被禁用，设备的写入性能受到影响。值0x01表示BKOPS_EN被启用，主机将不时发起后台操作。

    +
    • +

  • 通过以下命令使能BKOPS_EN：

    +
    target:~$ target:~$ mmc --help
+
+[...]
+mmc bkops_en <auto|manual> <device>
+    Enable the eMMC BKOPS feature on <device>.
+    The auto (AUTO_EN) setting is only supported on eMMC 5.0 or newer.
+    Setting auto won't have any effect if manual is set.
+    NOTE!  Setting manual (MANUAL_EN) is one-time programmable (unreversible) change.
+
    +
    +
    • +

  • 要设置BKOPS_EN位，请执行：

    +
    target:~$ mmc bkops_en manual /dev/mmcblk0
+
    +
    +
    • +

  • 为了确保新设置生效并且内核能够自动触发BKOPS，请先关闭系统：

    +
    target:~$ poweroff
+
    +
    +
    • +
+
+

小技巧

+

BKOPS_EN位是一次性可编程的，无法恢复。

+
+
+
+

7.4.3. 可靠写入

+

有两种不同的可靠写入选项：

+
    +

  1. 对整个eMMC设备/分区的可靠写入方式。

    2. +

  2. 单次写的可靠写入方式。

    3. +
+
+

小技巧

+

不要将 eMMC 分区与 DOS、MBR 或 GPT 分区表的分区混淆（请参阅前一节）。

+
+

第一个可靠写入方式大多数情况下已经在phyCORE-i.MX 93 SoM上挂载的eMMC上被启用。想要在运行的开发板上检查这一点：

+
target:~$ mmc extcsd read /dev/mmcblk0 | grep -A 5 WR_REL_SET
+Write reliability setting register [WR_REL_SET]: 0x1f
+ user area: the device protects existing data if a power failure occurs during a write o
+peration
+ partition 1: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 2: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 3: the device protects existing data if a power failure occurs during a write
+ operation
+ partition 4: the device protects existing data if a power failure occurs during a write
+ operation
+--
+ Device supports writing EXT_CSD_WR_REL_SET
+ Device supports the enhanced def. of reliable write
+
+
+

如果默认没有启用，可以使用mmc工具启用它：

+
target:~$ mmc --help
+
+[...]
+mmc write_reliability set <-y|-n|-c> <partition> <device>
+    Enable write reliability per partition for the <device>.
+    Dry-run only unless -y or -c is passed.
+    Use -c if more partitioning settings are still to come.
+    NOTE!  This is a one-time programmable (unreversible) change.
+
+
+

第二个可靠写入方式是命令CMD23中的配置位Reliable Write Request parameter（可靠写入请求参数）（位31）。自内核版本v3.0起，文件系统（例如ext4的日志）和用户空间应用程序（如fdisk的分区表）会通过内核使用该可靠写功能。在Linux内核源代码中，它通过标志REQ_META进行处理。

+

结论：使用挂载选项 data=journal 的 ext4 文件系统在断电情况下是安全的。文件系统检查可以在断电后恢复文件系统，但在断电前刚写入的数据可能会丢失。在各种情况下，都可以恢复文件系统的正常状态。为了确保应用程序文件的正常保存，应用程序中应使用系统函数 fdatasync 或 fsync。

+
+
+

7.4.4. 调整 ext4 根文件系统的大小

+

在将SD卡镜像写入eMMC时，ext4文件系统分区没有扩展到eMMC的末尾。可以使用parted来扩展根分区。这个示例适用于任何块设备，例如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ parted /dev/mmcblk0 print
+
    +
    +
    • +

  • 输出如下：

    +
    Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk0: 7617MB
+Sect[ 1799.850385]  mmcblk0: p1 p2
+or size (logical/physical): 512B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  537MB   465MB   primary  ext4
+
    +
    +
    • +

  • 使用parted将文件系统分区调整为设备的最大大小：

    +
    target:~$ parted /dev/mmcblk0 resizepart 2 100%
+Information: You may need to update /etc/fstab.
+
+target:~$ parted /dev/mmcblk0 print
+Model: MMC Q2J55L (sd/mmc)
+Disk /dev/mmcblk0: 7617MB
+Sector size (logical/physical): 512[ 1974.191657]  mmcblk0: p1 p2
+B/512B
+Partition Table: msdos
+Disk Flags:
+
+Number  Start   End     Size    Type     File system  Flags
+ 1      4194kB  72.4MB  68.2MB  primary  fat16        boot, lba
+ 2      72.4MB  7617MB  7545MB  primary  ext4
+
    +
    +
    • +

  • 将文件系统调整为新的分区大小：

    +
    target:~$ resize2fs /dev/mmcblk0p2
+resize2fs 1.46.1 (9-Feb-2021)
+Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
+[ 131.609512] EXT4-fs (mmcblk0p2): resizing filesystem
+from 454136 to 7367680 blocks
+old_desc_blocks = 4, new_desc_blocks = 57
+[ 131.970278] EXT4-fs (mmcblk0p2): resized filesystem to 7367680
+The filesystem on /dev/mmcblk0p2 is now 7367680 (1k) blocks long
+
    +
    +
    • +
+

在文件系统挂载时可以增加其大小。但您也可以从SD卡启动板，然后在eMMC分区未挂载时调整文件系统的大小。

+
+
+

7.4.5. 启用伪SLC模式

+

eMMC设备使用 MLC或TLC 来存储数据。与NAND Flash中使用的SLC相比，MLC或TLC在成本更低的情况下，可靠性较低且错误率较高。

+

如果您更喜欢可靠性而不是存储容量，可以启用伪SLC模式或SLC模式。这个方法采用了增强属性，该属性在JEDEC标准中有所描述，可以对设备的一个连续区域设置。JEDEC标准并未规定增强属性的实现细节和保证，这由芯片制造商自行决定。对于美光（Micron）芯片，增强属性提高了可靠性，但也将容量减半。

+
+

警告

+

在设备上启用增强属性时，所有数据将被丢失。

+
+

以下步骤展示了如何启用增强属性。

+
    +

  • 首先使用以下命令获取eMMC设备的当前大小：

    +
    target:~$ parted -m /dev/mmcblk0 unit B print
+
    +
    +

    你将收到：

    +
    BYT;
+/dev/mmcblk0:63652757504B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +

    如您所见，该设备的容量为 63652757504 字节 = 60704 MiB。

    +
    • +

  • 要获取启用伪SLC模式后的设备的大小，请使用：

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep ENH_SIZE_MULT -A 1
+
    +
    +

    例如：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
+i.e. 0 KiB
+
    +
    +

    这里的最大大小是3719168 KiB = 3632 MiB。

    +
    • +

  • 现在，您可以通过输入以下命令为整个设备设置增强属性，例如 3719168 KiB：

    +
    target:~$ mmc enh_area set -y 0 3719168 /dev/mmcblk0
+
    +
    +

    你将获得：

    +
    Done setting ENH_USR area on /dev/mmcblk0
+setting OTP PARTITION_SETTING_COMPLETED!
+Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk0 SUCCESS
+Device power cycle needed for settings to take effect.
+Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after power cycle
+
    +
    +
    • +

  • 为了确保新设置已生效，请关闭系统：

    +
    target:~$ poweroff
+
    +
    +

    并进行上下电。建议您现在确认设置是否正确。

    +
    • +

  • 首先，检查ENH_SIZE_MULT的值，它必须是3719168 KiB：

    +
    target:~$ mmc extcsd read /dev/mmcblk0 | grep ENH_SIZE_MULT  -A 1
+
    +
    +

    您应该看到：

    +
    Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+--
+Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000764
+i.e. 3719168 KiB
+
    +
    +
    • +

  • 最后，检查设备的大小：

    +
    target:~$ parted -m /dev/mmcblk0 unit B print
+BYT;
+/dev/mmcblk0:31742492672B:sd/mmc:512:512:unknown:MMC S0J58X:;
+
    +
    +
    • +
+
+
+

7.4.6. 擦除设备

+

可以直接擦除eMMC设备，而不是通过写零覆盖。eMMC块管理算法将擦除底层的MLC或TLC，或者将这些块标记为可丢弃。设备上的数据将丢失，并将被读取为零。

+
    +

  • SD卡启动后执行：

    +
    target:~$ blkdiscard -f --secure /dev/mmcblk0
+
    +
    +

    选项 --secure 确保命令在 eMMC 设备擦除所有块之前会等待。-f (强制) 选项强制擦写，当 eMMC 设备包含有效数据分区时需要使用-f选项。

    +
    • +
+
+

小技巧

+
target:~$ dd if=/dev/zero of=/dev/mmcblk0 conv=fsync
+
+
+

该命令也会擦除设备上的所有信息，但这个命令不利于设备的磨损均衡，并且需要花费更长的时间！

+
+
+
+

7.4.7. eMMC Boot分区

+

eMMC设备包含四个不同的硬件分区：User分区、boot1分区、boot2分区和rpmb分区。

+

User分区在JEDEC标准中称为用户数据区，是主要的存储分区。分区boot1和boot2可以用于存放bootloader，并且更可靠。 i.MX 93 使用哪个分区加载bootloader由eMMC设备的引导配置控制。分区rpmb是一个小分区，只能通过受信任的机制访问。

+

此外，User分区可以分为四个自定义的一般用途分区。对此功能的解释不在本文件涵盖的范围。有关更多信息，请参阅JEDEC标准第7.2章分区管理。

+
+

小技巧

+

不要将eMMC分区与DOS、MBR或GPT分区表的分区混淆。

+
+

当前的PHYTEC BSP没有使用eMMC设备的额外分区功能。U-Boot被烧写到用户分区的开始位置。U-Boot环境被放置在U-Boot之后的固定位置。使用MBR分区表创建两个分区，一个是FAT32引导分区，另一个是ext4根文件系统分区。它们位于U-Boot和U-Boot环境之后。FAT32引导分区包含内核和设备树。

+

使用eMMC时，可以利用专用的boot分区备份存储bootloader。U-Boot环境仍然位于第一个分区之前的用户区。用户区仍然在出厂时包含bootloader。下面是一个示例，演示如何将bootloader烧写到两个启boot分区中的一个，并通过用户空间命令切换启动设备。

+
+
+

7.4.8. 通过用户空间命令

+

在主机上运行：

+
host:~$ scp imx-boot root@192.168.3.11:/tmp/
+
+
+

默认情况下，boot1和boot2分区是只读的。要从用户空间写入它们，您必须在sysfs中禁用force_ro。

+

要手动将bootloader写入eMMC boot分区，首先禁用写保护：

+
target:~$ echo 0 > /sys/block/mmcblk0boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk0boot1/force_ro
+
+
+

将bootloader写入eMMC boot分区：

+
target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk0boot0
+target:~$ dd if=/tmp/imx-boot of=/dev/mmcblk0boot1
+
+
+

下表是 i.MX 93 SoC的偏移量：

+ + + + + + + + + + + + + + + + + +

SoC

User分区偏移量

Boot分区偏移量

eMMC设备

bootloader文件名

i.MX 93

32 kiB

0 kiB

/dev/mmcblk0

imx-boot

+

之后使用mmc工具从用户空间设置引导分区：

+

(对于 'boot0') :

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk0
+
+
+

(对于'boot1')：

+
target:~$ mmc bootpart enable 2 0 /dev/mmcblk0
+
+
+

要禁用从eMMC boot分区启动，只需输入以下命令：

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk0
+
+
+

返回到User分区启动：

+
target:~$ mmc bootpart enable 7 0 /dev/mmcblk0
+
+
+
+
+

7.4.9. 调整 ext4 根文件系统的大小

+

fdisk可以用来扩展根文件系统。这个例子适用于任何块设备，比如eMMC、SD卡或硬盘。

+
    +

  • 获取当前设备大小：

    +
    target:~$ fdisk -l /dev/mmcblk0
+
    +
    +
    • +

  • 输出如下：

    +
    Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors 116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk0p1 *    128,0,1       1023,3,32    16384       140779     124396   60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk0p2      1023,3,32     1023,3,32    141312      2192013    2050702  1001M  83 Linux
+
    +
    +
    • +

  • 使用fdisk删除并创建一个最大化使用设备容量的分区：

    +
    target:~$ fdisk /dev/mmcblk0
+
+The number of cylinders for this disk is set to 116224.
+There is nothing wrong with that, but this is larger than 1024,
+and could in certain setups cause problems with:
+1) software that runs at boot time (e.g., old versions of LILO)
+2) booting and partitioning software from other OSs
+   (e.g., DOS FDISK, OS/2 FDISK)
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot   StartCHS        EndCHS      StartLBA     EndLBA    Sectors   Size   Id Type
+/dev/mmcblk0p1 *     128,0,1     1023,3,32         16384     140779     124396  60,7M    c Win95 FAT32 (LBA)
+/dev/mmcblk0p2     1023,3,32     1023,3,32        141312    2192013    2050702  1001M   83 Linux
+
+Command (m for help): d
+Partition number (1-4): 2
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS    EndCHS          StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk0p1 *  128,0,1     1023,3,32          16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+
+Command (m for help): n
+Partition type
+   p   primary partition (1-4)
+   e   extended
+p
+Partition number (1-4): 2
+First sector (32-14876671, default 32): 141456
+Last sector or +size{,K,M,G,T} (141456-14876671, default 14876671):
+Using default value 14876671
+
+Command (m for help): p
+Disk /dev/mmcblk0: 7264 MB, 7616856064 bytes, 14876672 sectors
+116224 cylinders, 4 heads, 32 sectors/track
+Units: sectors of 1 * 512 = 512 bytes
+
+Device       Boot StartCHS      EndCHS        StartLBA     EndLBA    Sectors  Size   Id Type
+/dev/mmcblk0p1 *   128,0,1      1023,3,32        16384     140779     124396  60.7M   c Win95 FAT32 (LBA)
+/dev/mmcblk0p2   1023,3,32      1023,3,32       141456   14876671   14735216  7194M  83 Linux
+
    +
    +
    • +
+

可以在文件系统挂载时修改文件系统的大小。这是一个在线调整大小的操作。但您也可以从SD卡启动，然后在eMMC分区未挂载时调整其文件系统的大小。此外，必须重启板子，以便读取新的分区表。

+
+
+
+

7.5. GPIOs

+

phyBOARD-Segin/Nash i.MX 93 没有用户可以使用的GPIO，因为所有GPIO都被内核设备驱动程序使用或用于其他特定目的。处理器将其GPIO组织为五个32个GPIO的组（GPIO1 – GPIO4）。gpiochip0、gpiochip32、gpiochip64和gpiochip96是这些内部 i.MX 93 GPIO组GPIO1 – GPIO4的sysfs表示。

+

GPIO被标识为GPIO<X>_<Y>（例如，GPIO4_07）。<X>标识GPIO Bank，并从1到4计数，而<Y>表示Bank内的GPIO。<Y>从0到31计数（每个Bank有32个GPIO）。

+

相比之下，Linux内核使用一个单一的整数来枚举系统中所有可用的GPIO。计算正确数字的公式是：

+
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
+
+
+

从用户空间访问GPIO将使用libgpiod。它提供了一个库和工具，用于与Linux GPIO字符设备进行交互。以下是一些工具的用法示例：

+
    +

  • 检测芯片上的gpiochips：

    +
    target:~$ gpiodetect
+gpiochip0 [43810080.gpio] (32 lines)
+gpiochip1 [43820080.gpio] (32 lines)
+gpiochip2 [43830080.gpio] (32 lines)
+gpiochip3 [47400080.gpio] (32 lines)
+
    +
    +
    • +
+
+

备注

+

Order of GPIOchips in i.MX 93 Application Processor Reference Manual and +in Linux kernel differ!

+ + + + + + + + + + + + + + + + + + + + + + + +

GPIOchip 地址

Linux

Reference Manual

0x43810080

gpiochip0

gpiochip2

0x43820080

gpiochip1

gpiochip3

0x43830080

gpiochip2

gpiochip4

0x47400080

gpiochip3

gpiochip1

+
+
    +

  • 显示关于gpiochips的详细信息，包括它们的名称、consumer、方向、活动状态和附加flag：

    +
    target:~$ gpioinfo gpiochip0
+
    +
    +
    • +

  • 读取GPIO的值（例如，从chip0读取GPIO 3）：

    +
    target:~$ gpioget gpiochip0 3
+
    +
    +
    • +

  • 将chip0上的GPIO 3的值设置为0并退出：

    +
    target:~$ gpioset --mode=exit gpiochip0 3=0
+
    +
    +
    • +

  • gpioset的帮助文本显示了可能的选项：

    +
    target:~$ gpioset --help
+Usage: gpioset [OPTIONS] <chip name/number> <offset1>=<value1> <offset2>=<value2> ...
+Set GPIO line values of a GPIO chip
+
+Options:
+  -h, --help:           display this message and exit
+  -v, --version:        display the version and exit
+  -l, --active-low:     set the line active state to low
+  -m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
+                tell the program what to do after setting values
+  -s, --sec=SEC:        specify the number of seconds to wait (only valid for --mode=time)
+  -u, --usec=USEC:      specify the number of microseconds to wait (only valid for --mode=time)
+  -b, --background:     after setting values: detach from the controlling terminal
+
+Modes:
+  exit:         set values and exit immediately
+  wait:         set values and wait for user to press ENTER
+  time:         set values and sleep for a specified amount of time
+  signal:       set values and wait for SIGINT or SIGTERM
+
+Note: the state of a GPIO line controlled over the character device reverts to default
+when the last process referencing the file descriptor representing the device file exits.
+This means that it's wrong to run gpioset, have it exit and expect the line to continue
+being driven high or low. It may happen if given pin is floating but it must be interpreted
+as undefined behavior.
+
    +
    +
    • +
+
+

警告

+

某些GPIO用于特殊功能。在使用某个GPIO之前，请参考您板子的原理图或硬件手册，以确保该IO未被其他功能占用。

+
+
+

7.5.1. 通过sysfs访问GPIO

+
+

警告

+

通过sysfs访问GPIO已经过时了，我们建议使用libgpiod。

+
+

默认情况下不再支持通过sysfs访问GPIO。只有手动在内核配置中启用CONFIG_GPIO_SYSFS后才能支持。要使CONFIG_GPIO_SYSFS在menuconfig中可见，必须先启用CONFIG_EXPERT选项。

+

您还可以将此选项添加到Linux内核源代码中arch/arm64/configs下的imx9_phytec_distro.config配置片段中，例如：

+
..
+CONFIG_GPIO_SYSFS=y
+..
+
+
+
+
+
+

7.6. ADC

+

PHYTEC i.MX 93 包含通用的ADC，可用于与模拟传感器连接。

+

通过sysfs可以读取ADC值：

+
target:~$ cat /sys/bus/iio/devices/iio:deviceX/in_voltageY_raw
+
+
+

On phyBOARD-Nash i.MX 93 the ADC lines are accessible on X16 expansion connector:

+ + + + + + + + + + + + + + +

ADC输入

X16 引脚

ADC_IN0

47

ADC_IN2

49

+
+
+

7.7. LED灯

+

如果有任何LED灯连接到GPIO管脚，您可以通过特定的LED驱动程序接口访问它们，而不是使用通用的GPIO接口（请参见GPIO部分）。您将通过 /sys/class/leds/ 而不是 /sys/class/gpio/ 来访问它们。LED的最大亮度可以从 max_brightness 文件中读取。brightness文件将设置LED的亮度（取值范围从0到max_brightness）。大多数LED硬件上不支持调整亮度，所以在所有非零亮度下都会点亮。

+

下面是一个简单的例子。

+

要获取所有可用的LED，请输入：

+
target:~$ ls /sys/class/leds
+green:heartbeat@  mmc0::@  mmc1::@  yellow:@
+
+
+

这里的LED灯 green:heartbeat 位于 phyCORE-i.MX93 上。如果您使用的是phyBOARD-Segin，PEB-EVAL-01上还有一个 黄色 LED灯。

+
    +

  • 打开LED灯：

    +
    target:~$ echo 1 > /sys/class/leds/green\:heartbeat/brightness
+
    +
    +
    • +

  • 关闭LED：

    +
    target:~$ echo 0 > /sys/class/leds/green\:heartbeat/brightness
+
    +
    +
    • +
+

Device tree configuration for the User I/O configuration can be found here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-eval-01.dtso#L33

+
+
+

7.8. I²C总线

+

该 i.MX 93 包含多个多主支持快速模式的 I²C模块。PHYTEC板提供了许多不同的I²C设备，这些设备连接到 i.MX 93 的I²C模块。 本节描述了我们 phyBOARD-Segin/Nash i.MX 93 中集成的一些I²C设备的基本设备使用及其设备树（DT）表示。

+

i2c的设备树节点包含一些设置，例如时钟频率，用于设置总线频率，以及引脚控制设置，包括scl-gpios和sda-gpios，这些是用于总线恢复的备用引脚配置。

+

General I²C3 bus configuration (e.g. imx93-phycore-som.dtsi): +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi#L88

+

General I²C2 bus configuration for imx93-phyboard-segin.dts: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L155 or for +imx93-phyboard-nash.dts: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L113

+
+
+

7.9. EEPROM

+

在 phyCORE-i.MX93 SoM和 phyBOARD-Segin/Nash i.MX 93 上有两个不同的I2C EEPROM存储。目前只有 phyCORE-i.MX93 上的存储被启用，它用于硬件检测。

+
+

7.9.1. phyCORE-i.MX93 上的I2C EEPROM

+

phyCORE-i.MX93 SoM上的I2C EEPROM的空间被划分两部分。

+
    +

  • 正常区域（大小：4096字节，总线：I2C-2，地址：0x50）

    • +

  • ID页面（大小：32字节，总线：I2C-2，地址：0x58）

    • +
+

可以从设备进行读写操作：

+
target:~$ hexdump -C /sys/class/i2c-dev/i2c-2/device/2-0058/eeprom
+
+
+

要读取并以十六进制打印 EEPROM 的前 1024 字节，请执行：

+
target:~$ dd if=/sys/class/i2c-dev/i2c-2/device/2-0050/eeprom bs=1 count=1024  | od -x
+
+
+

要将整个EEPROM（ID页）填充为零，我们首先需要禁用EEPROM写保护，请使用：

+
target:~$ gpioset 2 21=0
+
+
+

然后可以写入EEPROM：

+
target:~$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-2/device/2-0058/eeprom bs=32 count=1
+
+
+
+

警告

+

正常EEPROM区域的前256个字节（总线：I2C-2 地址：0x50）是保留的，不应被覆盖！ （见下文）

+
+
+
+

7.9.2. EEPROM SoM 检测

+

PHYTEC在EEPROM正常区域的前256字节中存储有关核心板的信息。这包括PCB版本和贴装选项。

+

在启动的早期阶段读取EEPROM数据。它用于选择正确的DDR RAM配置。这使得可以使用相同的bootloader镜像来支持不同的RAM大小，并自动选择正确的DTS overlay。

+

如果正常区域的前256个字节被删除，启动加载程序将回退到 phyCORE-i.MX93 开发板内存配置，即 1GiB RAM。

+
+

警告

+

正常EEPROM区域的前256个字节（总线：I2C-2 地址：0x50）不应被擦除或损坏！这可能会影响bootloader的行为。板子可能无法正确启动。

+
+
+
+

7.9.3. 恢复EEPROM数据

+

硬件自检数据已预先写入EEPROM数据空间。如果您不小心删除或覆盖了数据，请联系我们的支持团队！

+

DT representation, e.g. in phyCORE-i.MX 93 file can be found in our PHYTEC git: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi#L172

+
+
+
+

7.10. RTC

+

RTC可以通过 /dev/rtc* 访问。由于PHYTEC板通常有多个RTC，因此可能会有多个RTC设备文件。

+
    +

  • 要找到RTC设备的名称，可以通过以下方式读取其sysfs条目：

    +
    target:~$ cat /sys/class/rtc/rtc*/name
+
    +
    +
    • +

  • 例如，你将得到：

    +
    rtc-rv3028 0-0052
+snvs_rtc 30370000.snvs:snvs-rtc-lp
+
    +
    +
    • +
+
+

小技巧

+

这将列出所有实时时钟（RTC），包括非I²C接口的RTC。如果存在设备树/aliases条目，Linux会根据这些条目分配RTC设备ID。

+
+

日期和时间可以通过 hwclock 工具和date命令进行操作。要显示目标上设置的当前日期和时间：

+
target:~$ date
+Thu Jan  1 00:01:26 UTC 1970
+
+
+

使用日期命令更改日期和时间。日期命令以以下语法设置时间："YYYY-MM-DD hh:mm:ss (+|-)hh:mm"：

+
target:~$ date -s "2022-03-02 11:15:00 +0100"
+Wed Mar  2 10:15:00 UTC 2022
+
+
+
+

备注

+

您的时区（在此示例中为 +0100）可能会有所不同。

+
+

使用date命令并不会改变实时时钟（RTC）的时间和日期，因此如果我们重启开发板，这些更改将会被丢弃。要写入RTC，我们需要使用 hwclock 命令。使用 hwclock 工具将当前的日期和时间（通过date命令设置）写入RTC，然后重启开发板以检查更改是否已应用到RTC上：

+
target:~$ hwclock -w
+target:~$ reboot
+    .
+    .
+    .
+target:~$ date
+Wed Mar  2 10:34:06 UTC 2022
+
+
+

要从实时时钟（RTC）设置系统时间和日期，请使用：

+
target:~$ date
+Thu Jan  1 01:00:02 UTC 1970
+target:~$ hwclock -s
+target:~$ date
+Wed Mar  2 10:45:01 UTC 2022
+
+
+
+

7.10.1. RTC唤醒alarm

+

可以从实时时钟（RTC）发出中断以唤醒系统。该格式使用Unix纪元时间，即自1970年1月1日UTC午夜以来的秒数。要在从挂起到RAM状态后的4分钟唤醒系统，请输入：

+
target:~$ echo "+240" > /sys/class/rtc/rtc0/wakealarm
+target:~$ echo mem > /sys/power/state
+
+
+
+

备注

+

内部唤醒alarm时间将被向上舍入到下一个分钟，因为alarm功能不支持秒。

+
+
+
+

7.10.2. RTC参数

+

实时时钟（RTC）具有一些功能，可以通过 hwclock 工具进行读取和设置。

+
    +

  • 我们可以通过以下方式检查RTC支持的功能：

    +
    target:~$ hwclock --param-get features
+The RTC parameter 0x0 is set to 0x71.
+
    +
    +

    这个值的含义在内核中进行了编码，每个位的定义为：

    +
    #define RTC_FEATURE_ALARM               0
+#define RTC_FEATURE_ALARM_RES_MINUTE    1
+#define RTC_FEATURE_NEED_WEEK_DAY       2
+#define RTC_FEATURE_ALARM_RES_2S        3
+#define RTC_FEATURE_UPDATE_INTERRUPT    4
+#define RTC_FEATURE_CORRECTION          5
+#define RTC_FEATURE_BACKUP_SWITCH_MODE  6
+#define RTC_FEATURE_ALARM_WAKEUP_ONLY   7
+#define RTC_FEATURE_CNT                 8
+
    +
    +
    • +

  • 我们可以通过以下方式检查RTC BSM（Backup Switchover Mode 备份切换模式）：

    +
    target:~$ hwclock --param-get bsm
+The RTC parameter 0x2 is set to 0x1.
+
    +
    +
    • +

  • 我们可以通过以下方式设置RTC BSM：

    +
    target:~$ hwclock --param-set bsm=0x2
+The RTC parameter 0x2 will be set to 0x2.
+
    +
    +

    BSM位的定义为：

    +
    #define RTC_BSM_DISABLED   0
+#define RTC_BSM_DIRECT     1
+#define RTC_BSM_LEVEL      2
+#define RTC_BSM_STANDBY    3
+
    +
    +
    +

    小技巧

    +

    您应该将BSM模式设置为DSM或LSM，以便在初始电源不可用时，RTC可以切换到备用电源。请查看 RV-3028 RTC的Datasheet，以了解LSM（电平切换模式）和DSM（直接切换模式）这两个定义的工作模式。

    +
    +
    • +
+

DT representation for I²C RTCs: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L173 or +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L122

+
+
+
+

7.11. USB主控制器

+

i.MX 93 SoC 的 USB 控制器为众多消费类便携设备提供了一种低成本的连接解决方案，传输速度高达 480 Mbps （高速 'HS'）。USB 子系统具有两个独立的 USB 控制器。两个控制器都能够充当 USB Device或 USB Host，但在 phyBOARD-Segin/Nash i.MX 93 上，其中一个被用作仅Host端口（USB-A 连接器）。

+

BSP支持大容量存储设备（优盘）和键盘。其他与USB相关的设备驱动程序必须根据需要在内核配置中启用。由于udev，所有连接的存储设备都会获得唯一的ID，并可以在 /dev/disk/by-id 中找到。这些ID可以在 /etc/fstab 中用于以不同的方式挂载不同的USB存储设备。

+

OTG端口提供了一个额外的引脚用于过流保护，但在 phyBOARD-Segin/Nash i.MX 93 上并未使用。由于未使用，该引脚在设备树中也被禁用。如果需要使用该引脚，请在设备树中激活过流保护，并根据设备规格设置正确的极性（高电平/低电平）。有关正确的设置，请参考Linux内核文档中的Linux/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt。

+

DT representation for USB Host: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L193 or +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L181

+
+
+

7.12. RS232/RS485

+

The phyBOARD-Nash i.MX 93 i.MX 93 SoC provides one RS232/RS485 serial port.

+
+

警告

+

RS232 with HW flow control and RS485 are not working due to HW bug on the +phyBOARD-Nash i.MX 93 PCB revision 1616.0

+
+
+

7.12.1. RS232

+
    +

  • 以人类可读的格式显示终端的当前设置：

    +
    target:~$ stty -a
+
    +
    +
    • +

  • UART接口的配置可以通过stty命令完成。例如：

    +
    target:~$ stty -F /dev/ttyLP6 115200 crtscts raw -echo
+
    +
    +
    • +

  • 通过简单的echo和cat，可以测试基本的通信。示例：

    +
    target:~$ echo 123 > /dev/ttyLP6
+
    +
    +
    host:~$ cat /dev/ttyUSB2
+
    +
    +
    • +
+

主机应打印出 "123"。

+
+
+

7.12.2. RS485

+
+

提示

+

Remember to use bus termination resistors of 120 Ohm at each end of the bus, +when using longer cables.

+
+

为了方便测试，请查看linux-serial-test。这个工具会通过调用RS485的IOCTL，发送恒定的数据流。

+
target:~$ linux-serial-test -p /dev/ttyLP6 -b 115200 --rs485 0
+
+
+

有关linux-serial-test工具及其参数的更多信息，请访问此链接：linux-serial-test

+

The linux-serial-test will automatically set ioctls, but they can also be set +manually with rs485conf.

+

You can show the current config with:

+
target:~$ rs485conf /dev/ttymxc1
+
+
+

You can show all options with:

+
target:~$ rs485conf /dev/ttymxc1 -h
+
+
+

Linux kernel文档描述了如何在C代码中调用IOCTL： https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt

+

The device tree representation for RS232 and RS485: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L174

+
+
+
+

7.13. CAN FD

+

phyBOARD-Segin/Nash i.MX 93 具有一个支持CAN FD的flexCAN接口。它们由Linux标准CAN框架支持，该框架建立在Linux网络层之上。使用该框架，CAN接口表现得像普通的Linux网络设备，并具有一些特定于CAN的附加功能。更多信息可以在Linux内核文档中找到：https://www.kernel.org/doc/html/latest/networking/can.html

+
    +

  • 使用：

    +
    target:~$ ip link
+
    +
    +

    查看接口的状态。CAN接口应该显示为can0。

    +
    • +

  • 要获取有关can0的信息，例如比特率和错误计数器，请输入：

    +
    target:~$ ip -d -s link show can0
+4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
+   link/can  promiscuity 0  allmulti 0 minmtu 0 maxmtu 0
+   can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
+         bitrate 500000 sample-point 0.875
+         tq 25 prop-seg 37 phase-seg1 32 phase-seg2 10 sjw 1 brp 1
+         flexcan: tseg1 2..96 tseg2 2..32 sjw 1..16 brp 1..1024 brp_inc 1
+         flexcan: dtseg1 2..39 dtseg2 2..8 dsjw 1..4 dbrp 1..1024 dbrp_inc 1
+         clock 40000000
+         re-started bus-errors arbit-lost error-warn error-pass bus-off
+         0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 parentbus platform parentdev 443a0000.can
+   RX:  bytes packets errors dropped  missed   mcast
+            0       0      0       0       0       0
+   TX:  bytes packets errors dropped carrier collsns
+            0       0      0       0       0       0
+
    +
    +
    • +
+

输出包含一组标准参数，这些参数也适用于以太网接口，因此并非所有参数对于CAN都是相关的（例如MAC地址）。以下输出参数包含有用的信息：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

can0

接口名称

NOARP

CAN无法使用ARP协议

MTU

最大传输单元

RX packets

接收的数据包数量

TX packets

发送的数据包数量

RX bytes

接收字节数

TX bytes

发送字节数

errors...

总线错误统计信息

+

CAN配置是在systemd配置文件 /lib/systemd/network/can0.network 中完成的。为了持久化更改（例如，默认比特率），请在BSP中更改根文件系统下的 ./meta-ampliphy/recipes-core/systemd/systemd-conf/can0.network 中的配置，并重新编译根文件系统。

+
[Match]
+Name=can0
+
+[Can]
+BitRate=500000
+
+
+

比特率也可以手动更改，例如，设置为灵活比特率（flexible bitrate）：

+
target:~$ ip link set can0 down
+target:~$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
+
+
+

您可以使用cansend发送消息，或使用candump接收消息：

+
target:~$ cansend can0 123#45.67
+target:~$ candump can0
+
+
+

要生成用于测试目的的随机CAN流量，请使用cangen：

+
target:~$ cangen
+
+
+

cansend --help 和 candump --help 提供了关于选项和用法的帮助信息。

+

Device Tree CAN configuration of imx93-phyboard-segin.dts: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L147 or +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L105

+
+
+

7.14. Audio on phyBOARD-Segin i.MX 93

+

On phyBOARD-Segin i.MX 93 the TI TLV320AIC3007 audio codec is used. It uses I2S +for data transmission and I2C for codec control. The audio signals available +are:

+
    +

  • 立体声 LINE IN，

    • +

  • 立体声 LINE OUT，

    • +

  • Class D 1W的扬声器输出

    • +
+

要检查您的声卡驱动程序是否正确加载以及设备名称，请输入以下命令以查看播放设备：

+
target:~$ aplay -L
+
+
+

或输入录音设备：

+
target:~$ arecord -L
+
+
+
+

7.14.1. Alsamixer

+

要检查声卡的功能，请输入：

+
target:~$ alsamixer
+
+
+

您应该会看到很多选项，因为音频IC具有许多可以测试的功能。通过SSH打开alsamixer的图形界面比通过调试串口打开更易于使用。所有混音点都有单声道或立体声增益控制。"MM"表示该功能被静音（左右输出均为静音），可以通过按' m '切换。您还可以通过按' < ' 左和 ' > '切换右声道输出。使用 tab 键，您可以在播放和录音控制之间切换。

+
+
+

7.14.2. 恢复默认音量

+

一些默认设置存储在 /var/lib/alsa/asound.state 中。您可以使用以下命令保存当前的alsa设置：

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

您可以通过以下方式恢复已保存的alsa设置：

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.14.3. 播放

+

运行speaker-test以检查播放功能：

+
target:~$ speaker-test -c 2 -t wav
+
+
+

要播放简单的音频流，您可以使用aplay。例如，要播放ALSA测试音频：

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

要播放其他格式，例如mp3，您可以使用Gstreamer：

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+

如果扬声器音量太低，可以增加音量（值范围 0-3）：

+
target:~$ amixer -c 0 sset Class-D 3
+
+
+
+

提示

+

扬声器输出仅为单声道，因此当播放立体声轨道时，扬声器只会播放左声道。

+
+
+
+

7.14.4. 录音

+

arecord 是一个命令行工具，用于捕获音频流，默认输入源为线路输入（Line In）。

+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

提示

+

由于播放和录音共享硬件接口，因此无法在同时进行播放和录音操作时使用不同的采样率和格式。

+
+

Device Tree Audio configuration: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin.dts#L62

+
+
+
+

7.15. Audio on phyBOARD-Nash i.MX 93

+
+

警告

+

Due to HW bug Audio is broken on phyBOARD-Nash i.MX 93 PCB revision: 1616.0

+
+

To use audio with phyBOARD-Nash i.MX 93 an additional adapter for the Audio/Video +connector is needed. The PEB-AV-10 (1531.1 revision) can be bought separately to +the Kit. PEB-AV-10 is populated with a TI TLV320AIC3007 audio codec. Audio +support is done via the I2S interface and controlled via I2C.

+

有一个符合OMTP标准的3.5mm耳机插孔和一个8针接口，用于连接带有AV连接器的音频设备。这个8针接口包含单声道扬声器、耳机和线路输入信号（line-in）。

+

要检查您的声卡驱动程序是否正确加载以及设备名称，请输入以下命令以查看播放设备：

+
target:~$ aplay -L
+
+
+

或输入录音设备：

+
target:~$ arecord -L
+
+
+
+

7.15.1. Alsamixer

+

要检查声卡的功能，请输入：

+
target:~$ alsamixer
+
+
+

您应该会看到很多选项，因为音频IC具有许多可以测试的功能。通过SSH打开alsamixer的图形界面比通过调试串口打开更易于使用。所有混音点都有单声道或立体声增益控制。"MM"表示该功能被静音（左右输出均为静音），可以通过按' m '切换。您还可以通过按' < ' 左和 ' > '切换右声道输出。使用 tab 键，您可以在播放和录音控制之间切换。

+
+
+

7.15.2. 恢复默认音量

+

一些默认设置存储在 /var/lib/alsa/asound.state 中。您可以使用以下命令保存当前的alsa设置：

+
target:~$ alsactl --file </path/to/filename> store
+
+
+

您可以通过以下方式恢复已保存的alsa设置：

+
target:~$ alsactl --file </path/to/filename> restore
+
+
+
+
+

7.15.3. ALSA配置

+

我们的BSP附带一个ALSA配置文件 /etc/asound.conf 。

+

ALSA配置文件可以根据需要进行编辑或删除，它并不是ALSA正常工作所必需的。

+
target:~$ vi /etc/asound.conf
+
+
+

要将PEB-AV-10设置为输出，请将 playback.pcm 从 "dummy" 设置为 "pebav10":

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+

如果听不到声音，请将播放设备更改为软件音量控制播放设备，将 playback.pcm 设置为相应的软音量播放设备，例如“softvol_pebav10”。使用alsamixer控制来调整音量级别。

+
[...]
+
+pcm.asymed {
+        type asym
+        playback.pcm "softvol_pebav10"
+        capture.pcm "dsnoop"
+}
+
+[...]
+
+
+
+
+

7.15.4. PulseAudio 配置

+

对于使用 Pulseaudio 的应用程序，请检查可用的音频输出设备：

+
target:~$ pactl list short sinks
+
+
+

要选择输出设备，请输入：

+
target:~$ pactl set-default-sink <sink_number>
+
+
+
+
+

7.15.5. 播放

+

运行speaker-test以检查播放功能：

+
target:~$ speaker-test -c 2 -t wav
+
+
+

要播放简单的音频流，您可以使用aplay。例如，要播放ALSA测试音频：

+
target:~$ aplay /usr/share/sounds/alsa/*
+
+
+

要播放其他格式，例如mp3，您可以使用Gstreamer：

+
target:~$ gst-launch-1.0 playbin uri=file:/path/to/file.mp3
+
+
+
+
+

7.15.6. 录音

+

arecord 是一个命令行工具，用于录制音频流，默认输入源为线路输入。要选择不同的音频源，可以使用 alsamixer。例如，打开 右侧 PGA 混音器 Mic3R 和 左侧 PGA 混音器 Mic3R，以便通过 3.5mm 插孔录制来自 TLV320 编解码器的麦克风输入音频。

+
target:~$ amixer -c "sndpebav10" sset 'Left PGA Mixer Mic3R' on
+target:~$ amixer -c "sndpebav10" sset 'Right PGA Mixer Mic3R' on
+
+
+
target:~$ arecord -t wav -c 2 -r 44100 -f S16_LE test.wav
+
+
+
+

提示

+

由于播放和录音共享硬件接口，因此无法在同时进行播放和录音操作时使用不同的采样率和格式。

+
+

Device Tree Audio configuration: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash-peb-av-10.dtso#L56

+
+
+
+

7.16. 视频

+
+

7.16.1. 视频与Gstreamer

+

默认情况下，BSP安装了一个示例视频，路径为 /usr/share/qtphy/videos/ 。可以使用以下命令之一开始视频播放：

+
target:~$ gst-launch-1.0 playbin uri=file:///usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-launch-1.0 -v filesrc location=/usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm ! decodebin name=decoder decoder. ! videoconvert ! waylandsink
+
+
+
    +

  • 或者：

    • +
+
target:~$ gst-play-1.0 /usr/share/qtphy/videos/caminandes_3_llamigos_720p_vp9.webm --videosink waylandsink
+
+
+
+
+
+

7.17. 显示

+

phyBOARD-Segin i.MX 93 支持 PEB-AV-02，配备 7 英寸的 edt,etm0700g0edh6 并口显示屏和电容触摸屏。该显示屏的设备树overlay在 BOOT/bootenv.txt 中默认启用！

+

phyBOARD-Nash i.MX 93需要额外的扩展板来支持10英寸的 edt,etml1010g3dra LVDS显示器和电容触摸。PEB-AV-10（1531.1修订版）可以单独购买。该LCD的overlay在 BOOT/bootenv.txt 中默认启用！

+
+

7.17.1. Qt Demo

+

使用 phytec-qt6demo-image 时，Weston会在启动时启动。我们的Qt6 DEMO应用程序名为“qtphy”，可以通过以下方式停止：

+
target:~$ systemctl stop qtphy
+
+
+
    +

  • 要重新开始Demo，请运行：

    +
    target:~$ systemctl start qtphy
+
    +
    +
    • +

  • 要禁用Demo的自动启动，请运行：

    +
    target:~$ systemctl disable qtphy
+
    +
    +
    • +

  • 要启用Demo的自动启动，请运行：

    +
    target:~$ systemctl enable qtphy
+
    +
    +
    • +

  • Weston可以通过以下方式停止：

    +
    target:~$ systemctl stop weston
+
    +
    +
    • +
+
+

备注

+

在关闭Weston之前，必须先关闭Qt Demo。

+
+
+
+

7.17.2. 背光控制

+

如果LCD连接到PHYTEC开发板，可以通过Linux内核的sysfs接口控制其背光。系统中所有可用的背光设备可以在文件夹/sys/class/backlight中找到。读取相应的文件并向其写入数据可以控制背光。

+
+

备注

+

一些具有多显示的开发板在 /sys/class/backlight 有多个背光控制。比如：backlight0和backlight1

+
+
    +

  • 例如，要获取最大亮度级别（max_brightness），请执行：

    +
    target:~$ cat /sys/class/backlight/backlight/max_brightness
+
    +
    +

    有效的亮度值范围是 0 到 <max_brightness>。

    +
    • +

  • 要获取当前亮度级别，请输入：

    +
    target:~$ cat /sys/class/backlight/backlight/brightness
+
    +
    +
    • +

  • 写入文件brightness以更改亮度：

    +
    target:~$ echo 0 > /sys/class/backlight/backlight/brightness
+
    +
    +

    例如，关闭背光。

    +

    有关所有文件的文档，请参见 https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight。

    +
    • +
+

The device tree of PEB-AV-02 can be found here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-02.dtso

+

The device tree of PEB-AV-10 can be found here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash-peb-av-10.dtso

+
+
+
+

7.18. 电源管理

+
+

7.18.1. CPU核心频率调节

+

i.MX 93 SoC中的CPU能够调整时钟频率和电压。这用于在不需要CPU的全部性能时节省电力。与i.MX8 M系列不同，i.MX 93不支持 动态 电压和频率调整（DVFS），但支持简化的 电压和频率调整（VFS） 。可以进入以下模式：

+
    +

  • nominal（ND），

    • +

  • overdrive （OD），

    • +

  • Low Drive（LD）和

    • +

  • Low Drive（LD）与软件快速频率变化（SWFFC）。

    • +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

模式

CPU频率

DDR数据速率

VDD_SOC

OverDrive (OD)

1.7 GHz

3733 MT/s

900mV

NominalDrive (ND)

1.4 GHz

1866 MT/s

850mV

LowDrive (LD)

900 MHz

1866 MT/s

800mV

带有SWFFC的LowDrive（LD）

900 MHz

625 MT/s

800mV

+

i.MX 93 BSP支持VFS功能。Linux内核提供了一个LPM驱动程序，可以设置VDD_SOC、CPU频率和DDR速度。

+
+

备注

+

Low-cost i.MX 93 SoC variants such as parts numbers NXP IMX9301/IMX9302 do not +support VFS features. Those SoCs always run in LowDrive (LD) mode. Hence, +the Linux LPM driver is disabled automatically for SoMs with such SoCs.

+
+
    +

  • 要将设备置于 OverDrive（OD） 模式，请输入：

    +
    +
    target:~$ echo 0 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • 要将设备置于 NominalDrive（ND） 模式，请输入：

    +
    +
    target:~$ echo 1 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • 要将设备置于 LowDrive（LD） 模式，请输入：

    +
    +
    target:~$ echo 2 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • 将设备置于 LowDrive（LD） 模式，使用最低DDR速度，SWFFC类型：

    +
    +
    target:~$ echo 3 > /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • 要检查当前的CPU频率，请输入：

    +
    +
    target:~$ mhz
+
    +
    +
    +
    • +

  • 要检查当前模式和DDR频率，请输入：

    +
    +
    target:~$ cat /sys/devices/platform/imx93-lpm/mode
+
    +
    +
    +
    • +

  • 要检查当前的 VDD_SOC 类型，请输入：

    +
    +
    target:~$ cat /sys/kernel/debug/regulator/regulator_summary
+
    +
    +
    +
    • +
+

有关LPM驱动程序和模式的更详细信息，请参考NXP的文档：https://docs.nxp.com/bundle/AN13917/page/topics/low_power_mode_use_cases.html

+
+
+

7.18.2. CPU核心管理

+

i.MX 93 SoC 在芯片上拥有多个处理器核心。例如，i.MX 93 具有 2 个 ARM 核，这些核可以在运行时单独开启和关闭。

+
    +

  • 要查看系统中所有可用的核心，请执行：

    +
    target:~$ ls /sys/devices/system/cpu  -1
+
    +
    +
    • +

  • 这将显示，例如：

    +
    cpu0/
+cpu1/
+cpufreq/
+[...]
+
    +
    +

    这里系统有两个处理器核心。默认情况下，系统中所有可用的核心都被启用，以获得最佳性能。

    +
    • +

  • 要关闭某个核，请执行：

    +
    target:~$ echo 0 > /sys/devices/system/cpu/cpu1/online
+
    +
    +

    作为确认，您将看到：

    +
    [  110.505012] psci: CPU1 killed (polled 0 ms)
+
    +
    +

    现在核心已关闭电源，并且该核心上不再安排任何进程。

    +
    • +

  • 您可以使用 top 命令查看核心和进程的图形概览：

    +
    target:~$ htop
+
    +
    +
    • +

  • 要重新启用核心，请执行：

    +
    target:~$ echo 1 > /sys/devices/system/cpu/cpu1/online
+
    +
    +
    • +
+
+
+

7.18.3. 挂起到RAM

+

phyCORE-i.MX93 支持基本的挂起和恢复。可以使用不同的唤醒源。挂起/恢复可以通过以下方式实现：

+
target:~$ echo mem > /sys/power/state
+#resume with pressing on/off button
+
+
+

要通过串行控制台唤醒，请运行

+
target:~$ echo enabled > /sys/class/tty/ttyLP0/power/wakeup
+target:~$ echo mem > /sys/power/state
+
+
+

设备可以通过PEB-EVAL-01的S2按钮进入休眠状态并唤醒

+

要通过RTC闹钟唤醒，请检查：RTC Wakealarm

+
+
+
+

7.19. 热管理

+
+

7.19.1. U-Boot

+

之前U-Boot中的温度控制不够理想。现在，U-Boot增加了温度关机功能，以防止在启动过程中板子过热。关机发生的温度与内核中的温度一致。

+

当前温度的各个温度范围在启动日志中显示：

+
CPU:   Industrial temperature grade (-40C to 105C) at 33C
+
+
+
+
+

7.19.2. 内核

+

Linux内核集成了热管理功能，能够监测芯片（SoC）温度，降低CPU频率，控制风扇，通知其他驱动程序减少功耗，并在最坏的情况下关闭系统（https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt）。

+

本节描述了如何在 i.MX 93 SoC 平台上使用热管理内核 API。 i.MX 9 具有用于 SoC 的内部温度传感器。

+
    +

  • 当前温度可以以毫摄氏度为单位读取：

    +
    target:~$ cat /sys/class/thermal/thermal_zone0/temp
+
    +
    +
    • +

  • 例如，你将得到：

    +
    49000
+
    +
    +
    • +
+

imx_thermal内核驱动注册了两个温度阈值。这些阈值根据CPU型号的不同而有所区别。包括商业级、工业级和扩展工业级。

+ + + + + + + + + + + + + + + + + + + + +

商业

工业

扩展工业级

被动（警告）

85°C

95°C

115°C

严重（关机）

90°C

100°C

120°C

+

（请查看内核 sysfs 文件夹 /sys/class/thermal/thermal_zone0/）

+

内核热管理使用这些触发点来触发事件并改变温控行为。内核中可用的热政策（也称为thermal governor）包括：Step Wise和Power Allocator。BSP中使用的默认政策是step_wise。

+
+

小技巧

+

如果sysfs文件中的SoC温度值达到 trip_point_1 ，主板将立即关闭以避免任何热损伤。如果这不符合您的期望，可以实现一个外部监控电路，当温度降到选定的触发点以下时，通过X_ONOFF信号重新启动模块

+
+
+

备注

+

由于我们安装了不同温度等级的CPU，因此热触发点的实际值可能会有所不同。

+
+
+
+

7.19.3. PWM Fan

+

A PWM fan can be connected to the phyBOARD-Nash i.MX 93 connector X48 (label FAN).

+

Afterwards, a PWM fan overlay needs to be activated, otherwise PWM fan won't +be recognized.

+
target:~$ vi /boot/bootenv.txt
+
+
+

The bootenv.txt file should look like this (it can also contain other devicetree +overlays!):

+
overlays=imx93-phyboard-nash-pwm-fan.dtbo
+
+
+

更改将在重启后应用：

+
+
target:~$ reboot
+
+
+
+

有关设备树overlay的更多信息，请阅读 device tree 章节。

+

The SoC only contains one temperature sensor which is already used by the +thermal frequency scaling. The fan thus can not be controlled by the kernel. +We use lmsensors with hwmon for this instead. lmsensors reads the temperature +periodically and adjusts output PWM duty-cycle accordingly. By default, +temperature threshold for PWM fan to activate is set to 60°C.

+

设置可以在配置文件中进行配置：

+
/etc/fancontrol
+
+
+

风扇控制在启动时由systemd服务启动。可以通过以下方式禁用它：

+
target:~$ systemctl disable fancontrol
+
+
+
+
+
+

7.20. 看门狗

+

PHYTEC i.MX 93 模块包含一个硬件看门狗，当系统挂起时能够重置开发板。看门狗在 U-Boot 中默认启动，超时时间为 60 秒。因此，即使在早期内核启动过程中，看门狗也已经开始运行。Linux 内核驱动程序控制看门狗，并确保它有被踢到。本节将解释如何使用 systemd 在 Linux 中配置看门狗，以避免系统挂起和重启期间的情况。

+
+

7.20.1. Systemd中的看门狗支持

+

Systemd 从版本 183 开始支持硬件看门狗。

+
    +

  • 要启用看门狗支持，需要通过启用选项来配置 /etc/systemd/ 中的文件system.conf文件：

    +
    RuntimeWatchdogSec=60s
+ShutdownWatchdogSec=10min
+
    +
    +
    • +
+

RuntimeWatchdogSec 定义了看门狗的超时时间，而 ShutdownWatchdogSec 定义了系统重启时的超时时间。有关 systemd 下硬件看门狗的更多详细信息，请访问 http://0pointer.de/blog/projects/watchdog.html。更改将在重启后生效，或者运行：

+
target:~$  systemctl daemon-reload
+
+
+
+
+
+

7.21. bbnsm 电源键

+

连接到开/关按钮的 X_ONOFF 引脚可以长按（5 秒）以触发关机，而无需软件干预，或者用于唤醒系统以退出挂起状态。使用 bbnsm_pwrkey 驱动程序时，当按钮被按下时，KEY_POWER 事件也会报告给用户空间。默认情况下，systemd 被配置为忽略此类事件，并未配置无软件干预的关机功能。如果需要，可以在 /etc/systemd/logind.conf 中配置在按下开/关按钮时通过 systemd 触发关机：

+
HandlePowerKey=poweroff
+
+
+
+
+

7.22. PXP

+

i.MX 93 SoC包含一个PiXel Pipeline (PXP)。PXP将以下内容组合成一个单独的处理引擎：

+
    +

  • 缩放

    • +

  • 颜色空间转换 (CSC)

    • +

  • 辅助色彩空间转换 (CSC2)

    • +

  • 旋转

    • +
+

因此，减少了显示管道所需的内存占用。有关如何在 Gstreamer 和 Wayland 中使用 PXP，请查看 NXP 的《How to Use PXP in GStreamer and Wayland》（AN13829）应用笔记。

+
+
+

7.23. 片上一次性可编程控制器 (OCOTP_CTRL) - eFuse

+

该 i.MX 93 提供一次性可编程寄存器（fuse），用于存储信息，例如MAC地址、启动配置和其他永久设置（在 i.MX 93 reference manual中称为“片上一次性可编程控制器（OCOTP_CTRL）”）。以下列表是 i.MX 93 reference manual的摘要，包括OCOTP_CTRL中的一些有用寄存器（基地址为0x47510000）：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

名称

Bank

字

内存偏移量为 0x47510000

描述

BOOT_CFG0

3

0 0x60

启动fuse设置

BOOT_CFG1

3

1 0x64

启动fuse设置

BOOT_CFG2

3

2 0x68

启动fuse设置

BOOT_CFG3

3

3 0x6c

启动fuse设置

MAC1_ADDR

39

3

0x4ec

包含ENET0 MAC地址的低32位

MAC1/2_ADDR

39

4

0x4f0

包含ENET0 MAC地址的高16位和ENET1 MAC地址的低16位

MAC2_ADDR

39

5

0x4f4

包含 ENET1 MAC 地址的高 32 位

+

关于OCOTP_CTRL中的fuse与启动配置之间的完整列表和详细映射，请参阅 i.MX 93 Security Reference Manual中的 "Fuse Map" 部分。

+
+

7.23.1. 在uBoot中读取fuse的值

+

MAC1_ADDR:

+
u-boot=> fuse read 39 3
+
+
+
+
+

7.23.2. 在Linux中读取fuse值

+

要访问Linux中的fuse内容，NXP提供了NVMEM_IMX_OCOTP模块。所有内存映射的shadow寄存器的fuse内容可以通过sysfs访问：

+
target:~$ hexdump /sys/devices/platform/soc\@0/47510000.efuse/fsb_s400_fuse0/nvmem
+
+
+
+
+

7.23.3. 烧录MAC地址

+

假设我们想要烧录以下MAC地址：

+ + + + + + + + + +

MAC1

12:34:56:78:90:AA

MAC2

Bb:Cc:Dd:Ee:Ff:D0

+

我们将在u-boot中执行这个：

+
u-boot=> fuse prog 39 3 0x567890Aa
+u-boot=> fuse prog 39 4 0xFfD01234
+u-boot=> fuse prog 39 5 0xBbCcDdEe
+
+
+
+
+

7.23.4. 烧写启动fuse

+
+

警告

+

fuse只能写入一次！如果烧录了错误的启动配置，您可能会轻易地将您的板子变砖。这个过程是不可逆的！

+
+

可以在附带的名为 i.MX93_Fusemap.xlsx 的excel表格中查找应使用哪个fuse bank/word来编程 BOOT_CFGX，这些信息可以在 i.MX 93 Applications Processor Reference Manual 中找到。

+

这些值应该写入BOOT_CFG0，可以从第3个 Bank 的第0字节中读取/写入fuse。

+ + + + + + + + + + + + + + +

启动设备

BOOT_CFG0

eMMC

0x20020002

SD卡

0x20000103

+

要设置内部fuse以从eMMC启动，可以使用以下方法进行编程：

+
u-boot=> fuse prog 3 0 0x20020002
+
+
+

在这个例子中，我们：

+
    +

  • 将 Boot_Mode 设置为 0b0010 （eMMC），也就是 BOOT_CFG0[3:0]，

    • +

  • 将eMMC总线宽度设置为0b01（8位），也就是 BOOT_CFG0[18:17]。

    • +

  • 设置BT_FUSE_SEL（Boot fuses already programmed）位，也就是BOOT_CFG0[29]

    • +
+

确保通过阅读 i.MX 93 Applications Processor Reference Manual 中的 Boot Fusemap 章节来设置正确的位。

+
+
+
+

7.24. TPM

+

phyBOARD-Nash i.MX 93配备了可信任的平台模块（TPM），提供基于硬件的安全功能。

+

以下是一些与TPM相关的示例

+

使用TPM2工具生成4字节随机值：

+
+
target:~$ tpm2_getrandom --hex 4
+
+
+
+

使用OpenSSL工具生成4字节随机值：

+
+
target:~$ openssl rand -engine libtpm2tss --hex 4
+
+
+
+

生成RSA私钥并验证其内容：

+
+
target:~$ openssl genrsa -engine libtpm2tss -out /tmp/priv_key 512
+Engine "tpm2tss" set.
+target:~$ openssl rsa -check -in /tmp/priv_key -noout
+RSA key ok
+target:~$ cat /tmp/priv_key
+-----BEGIN PRIVATE KEY-----
+MIIBVQIBADANBgkqhkiG9w0BAQEFAASCAT8wggE7AgEAAkEAxsvmcbxjwuKnYeuZ
+2AVBmuLvYyqF/LpYOD3IB/v+YvEolxdGGmjiFLECU6xZ1j3+dIt4Y1zbcKS1OcWT
+I8mbSwIDAQABAkBoy8wrYNhmP/1kzUJIclznPYJckGoZlFI1M7xjGSA9H1xDK6if
+5g5CYCHPrbBp8e0mEokPRZoihxxzGTxGPiahAiEA/7OYMOpVZ5SD3YcRsWcQlkWI
+MOSPUYg6vxvGG9xp4FcCIQDHB01RoHr+qXJwxIu3/3oQAUBI4ACJ4JRp0KelwhC0
+LQIhANJzSvg/dak5l8pU55/99q3nbm7nPnnZSJiP0F6P62gjAiEAjf7qrfMF7Uyt
+RkEjwbl2t5Z868FNARGGMVxZT4x+aF0CIGxlmP2pL8xFu1bWB282LSedqZUdQwel
+Lxi7+svb2+uJ
+-----END PRIVATE KEY-----
+
+
+
+
+

备注

+

如果您打算将这些密钥用于任何安全目的，请不要共享您的私有RSA密钥。

+
+

生成RSA公钥并验证其内容：

+
+
target:~$ openssl rsa -in /tmp/test_key -pubout -out /tmp/pub_key
+writing RSA key
+target:~$ openssl pkey -inform PEM -pubin -in /tmp/pub_key -noout
+target:~$ cat /tmp/pub_key
+-----BEGIN PUBLIC KEY-----
+MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMbL5nG8Y8Lip2HrmdgFQZri72Mqhfy6
+WDg9yAf7/mLxKJcXRhpo4hSxAlOsWdY9/nSLeGNc23CktTnFkyPJm0sCAwEAAQ==
+-----END PUBLIC KEY-----
+
+
+
+

Device tree TPM configuration can be found here: +https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy8/arch/arm64/boot/dts/freescale/imx93-phyboard-nash.dts#L151

+
+
+
+

8. i.MX 93 M33 Core

+

除了Cortex-A55核心外，SoC中还集成了一个Cortex-M33 Core 作为单片机（MCU）。我们的Yocto-Linux-BSP在A55核心上运行，而 M33 Core 可以作为辅助核心使用，执行额外的任务，采用bare-metal的固件。两个核心都可以访问相同的外设，因此在 M33 Core 的固件或Linux操作系统的设备树中，需要限制外设的使用。

+

我们的Yocto-BSP包含来自NXP的 M33 Core 预编译固件示例。

+

本节描述了如何在 phyBOARD-Segin/Nash i.MX 93 上运行预编译的 M33 Core 固件示例。

+
+

8.1. 运行 M33 Core 示例

+

运行 M33 Core 固件示例有两种方式：从 U-Boot bootloader和在正在运行的 Linux 中使用 Remoteproc 子系统。

+

要接收调试信息，请在您的主机PC上启动您喜欢的终端软件（例如Minicom、Tio或Tera Term），并将其配置为115200波特率、8个数据位、无奇偶校验和1个停止位（8n1），且不使用握手。

+

在 phyBOARD-Segin/Nash i.MX 93 上需要一个“USB接口 TTL 串口转换器”。转换器的 I/O 引脚应能够在 3.3V 电压水平下工作。

+

根据下表，将外部“USB接口 TTL 串口转换器”信号连接到板上的 X16 连接器：

+ + + + + + + + + + + + + + + + + + + + + +

USB-TTL适配器引脚

X16信号

X16 引脚

RXD

X_UART2_TX

5

TXD

X_UART2_RX

8

GND

GND

4

+
+

8.1.1. 从U-Boot运行示例

+

要使用U-Boot bootloader加载固件示例，可以使用 bootaux 命令：

+
    +

  1. 准备一张烧写了BSP镜像的SD卡

    2. +

  2. 通过按任意键停止自动启动

    3. +

  3. 列出SD卡第一分区上可用的 M33 Core 固件示例：

    4. +
+
u-boot=> ls mmc 1
+
+
+
+

备注

+

可用的固件示例以 imx93-11x11-evk_m33_TCM_* 开头，以 *.bin 结尾。这些示例来自NXP的Yocto层meta-imx，并根据与 phyBOARD-Segin/Nash i.MX 93 硬件的兼容性进行选择。

+
+
    +

  1. 加载所需的固件示例：

    2. +
+
u-boot=> fatload mmc 1 ${loadaddr} <firmware.bin>
+u-boot=> cp.b ${loadaddr} 0x201e0000 ${filesize}
+u-boot=> run prepare_mcore
+u-boot=> bootaux 0x1ffe0000 0
+## Starting auxiliary core addr = 0x1FFE0000...
+
+
+

程序的输出应显示在 M33 Core 的调试UART上。

+
+
+

8.1.2. 通过Remoteproc在Linux上运行示例

+

Remoteproc是一个模块，它允许您在运行时从Linux控制 M33 Core 。可以加载 M33 Core 的固件示例，并在Linux中控制它启动或停止。要使用Remoteproc，需要设置设备树overlay：

+

在开发板的 /boot 目录中编辑 bootenv.txt 文件，添加 imx93-phycore-rpmsg.dtso ：

+
overlays=imx93-phyboard-segin-peb-av-02.dtbo imx93-phycore-rpmsg.dtso
+
+
+

重启目标并在U-Boot中执行:

+
u-boot=> run prepare_mcore
+
+
+

针对 M33 Core 的固件示例 *.elf 文件可以在 /lib/firmware 下找到。列出可用的固件示例：

+
target:~$ ls /lib/firmware/*.elf
+
+
+

要加载固件，请输入：

+
target:~$ echo /lib/firmware/<firmware>.elf > /sys/class/remoteproc/remoteproc0/firmware
+target:~$ echo start > /sys/class/remoteproc/remoteproc0/state
+
+
+

要加载不同的固件，M33 Core 需要停止：

+
target:~$ echo stop > /sys/class/remoteproc/remoteproc0/state
+
+
+
+

备注

+

在开发板的 /lib/firmware 目录中找到的例子来自NXP的Yocto层meta-imx，并根据与 phyBOARD-Segin/Nash i.MX 93 硬件的兼容性进行了挑选。

+
+

NXP的一些固件示例需要加载额外的Linux内核模块。

+

例如，当加载 imx93-11x11-evk_m33_TCM_rpmsg_lite_str_echo_rtos.elf 固件时，需要加载相应的 imx_rpmsg_tty 模块：

+
target:~$ modprobe imx_rpmsg_tty
+
+
+

这将一个RPMsg端点作为虚拟TTY暴露在 /dev/ttyRPMSG30 。现在可以通过输入以下内容从A55核心发送消息到 M33 Core ：

+
target:~$ echo "PHYTEC" > /dev/ttyRPMSG30
+
+
+

观察 M33 Core 调试 UART 应该会产生以下输出：

+
RPMSG String Echo FreeRTOS RTOS API Demo...
+
+Nameservice sent, ready for incoming messages...
+Get Message From Master Side : "PHYTEC" [len : 6]
+
+
+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/contributing_links.html b/previews/271/zh_CN/contributing_links.html new file mode 100644 index 000000000..0c8bb9515 --- /dev/null +++ b/previews/271/zh_CN/contributing_links.html @@ -0,0 +1,142 @@ + + + + + + + + + 贡献 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

贡献

+

Phytec 的 Yocto BSP 以开源许可证发布，我们欢迎对我们的 Yocto BSP 和本文档的贡献。请查看各个项目和层的 Git 仓库以获取贡献指南。

+

如果您对我们的 Yocto BSP 有 疑问 或注意到本文档的任何 问题，我们鼓励您在Github 仓库 doc-bsp-yocto 上打开一个 Issue 或 Pull Request。查阅 贡献指南 以获取更多信息。

+
+ + +
+
+
+ +
+ +
+

© 版权所有 2024, PHYTEC Messtechnik GmbH。

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/genindex.html b/previews/271/zh_CN/genindex.html new file mode 100644 index 000000000..3ff35987e --- /dev/null +++ b/previews/271/zh_CN/genindex.html @@ -0,0 +1,139 @@ + + + + + + + + 索引 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ + +

索引

+ +
+ +
+ + +
+
+
+ +
+ +
+

© 版权所有 2024, PHYTEC Messtechnik GmbH。

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/googledd12f2e41658d61e.html b/previews/271/zh_CN/googledd12f2e41658d61e.html new file mode 100644 index 000000000..cb695ae9f --- /dev/null +++ b/previews/271/zh_CN/googledd12f2e41658d61e.html @@ -0,0 +1 @@ +google-site-verification: googledd12f2e41658d61e.html \ No newline at end of file diff --git a/previews/271/zh_CN/index.html b/previews/271/zh_CN/index.html new file mode 100644 index 000000000..ff791ad0c --- /dev/null +++ b/previews/271/zh_CN/index.html @@ -0,0 +1,156 @@ + + + + + + + + + 欢迎阅读 PHYTEC BSP 文档 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

欢迎阅读 PHYTEC BSP 文档

+

欢迎阅读我们的 Yocto BSP 文档。

+
+

目录

+ +
+
+

贡献

+ +
+
+ + +
+
+
+ +
+ +
+

© 版权所有 2024, PHYTEC Messtechnik GmbH。

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/objects.inv b/previews/271/zh_CN/objects.inv new file mode 100644 index 000000000..8579f5fe7 Binary files /dev/null and b/previews/271/zh_CN/objects.inv differ diff --git a/previews/271/zh_CN/rauc/kirkstone.html b/previews/271/zh_CN/rauc/kirkstone.html new file mode 100644 index 000000000..af5edea03 --- /dev/null +++ b/previews/271/zh_CN/rauc/kirkstone.html @@ -0,0 +1,1281 @@ + + + + + + + + + 1. Introduction — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+ +
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + +

RAUC Update & Device Management Manual

Document Title

RAUC Update & Device Management Manual Kirkstone

Document Type

RAUC Update & Device Management +Manual

Release Date

XXXX/XX/XX

Is Branch of

RAUC Update & Device Management Manual

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-Ampliphy-i.MX6-PD22.1.0

Major

14.12.2022

released

BSP-Yocto-Ampliphy-i.MX6-PD22.1.1

Minor

20.06.2023

released

BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.0

Major

11.08.2022

released

BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1

Minor

23.05.2023

released

BSP-Yocto-NXP-i.MX8MM-PD23.1.0

Major

12.12.2023

released

BSP-Yocto-NXP-i.MX8MP-PD23.1.0

Major

12.12.2023

released

BSP-Yocto-Ampliphy-AM62x-PD23.2.0

Major

28.09.2023

released

BSP-Yocto-Ampliphy-AM62Ax-PD23.1.0

Major

28.09.2023

released

BSP-Yocto-Ampliphy-AM64x-PD23.2.0

Major

28.09.2023

released

+

This manual was tested using the Yocto version Kirkstone.

+
+

1. Introduction

+

PHYTEC's Yocto distribution Ampliphy (former Yogurt) supports the RAUC (Robust Auto-Update Controller) +mechanism. RAUC controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. For +eMMC devices only, it can also update the bootloader.

+

This manual describes how RAUC is used and implemented on various PHYTEC +platforms. Note, that different modules use different bootloaders and flash +storage devices, which affects the way things are handled by RAUC. Make sure to +read the correct sections fitting your platform.

+
+

备注

+

This manual contains machine-specific paths and variable contents. Make sure +you are using the correct machine and device names for your application when +executing any commands.

+
+
+
+

2. System Configuration

+

RAUC can be used with both eMMC and NAND flash storage. Using the distro +ampliphy-rauc or ampliphy-vendor-rauc, it is enabled by default and requires +no additional setup to get started. RAUC can be used in different update +scenarios. As an example, we configured the BSP to use an A/B setup to have a +completely redundant system (including the bootloader on eMMC devices). Note, +that there is an additional partition named config storing persistent +configuration data not being changed when updating.

+../_images/rauc-ab-system.png +
+

2.1. RAUC BSP Example Setup

+

The partition layout is defined in the /etc/rauc/system.conf file. As an +example, this is what it looks like for i.MX 8M Mini with eMMC flash storage:

+
+
/etc/rauc/system.conf
+
[system]
+compatible=phyboard-polis-imx8mm-4
+bootloader=uboot
+mountprefix=/mnt/rauc
+
+[handlers]
+pre-install=/usr/lib/rauc/rauc-pre-install.sh
+post-install=/usr/lib/rauc/rauc-post-install.sh
+
+[keyring]
+path=mainca-rsa.crt.pem
+
+[slot.bootloader.0]
+device=/dev/mmcblk2
+type=boot-emmc
+
+# System A
+[slot.rootfs.0]
+device=/dev/mmcblk2p5
+type=ext4
+bootname=system0
+
+[slot.boot.0]
+device=/dev/mmcblk2p1
+type=vfat
+parent=rootfs.0
+
+# System B
+[slot.rootfs.1]
+device=/dev/mmcblk2p6
+type=ext4
+bootname=system1
+
+[slot.boot.1]
+device=/dev/mmcblk2p2
+type=vfat
+parent=rootfs.1
+
+
+
+

Note, that the devices specified in the slots are different depending on the +selected machine.

+
+

警告

+

Updates with RAUC use an OpenSSL certificate to verify the validity of an +image. The BSP includes a certificate that can be used for development. In a +productive system, however, it is highly recommended to use a self-created +key and certificate. If you need to change the keyring on an existing device, +see Switching RAUC Keyrings for more +information.

+
+
+
+
+

3. Design Considerations

+

In order to prevent the system from locking up, it may be a good idea to utilize +a hardware watchdog. In case the Linux Kernel does not boot or another +catastrophic event occurs that prevents the system from operating normally, the +hardware watchdog then resets the system. By default, the hardware watchdog is +disabled. To enable it, refer to the corresponding BSP manual that fits your +SoM.

+

Other important design considerations, as well as a checklist, can be found in +the official RAUC documentation: +https://rauc.readthedocs.io/en/latest/checklist.html

+
+
+

4. Initial Setup

+

To use RAUC, the flash device needs to be written with a complete Linux system +and bootloader. The preferred method to do this is using the included tool +partup.

+
+

4.1. Flash Storage

+

To flash the device with the correct partitions/volumes, use a partup package +built with the ampliphy-rauc or ampliphy-vendor-rauc distribution. +Prebuilt partup packages can be found in the BSP release. It is also possible to +build a package with this distribution yourself using Yocto. Change +local.conf so separate build directories are created, storing the images and +packages for the RAUC system:

+
+
build/conf/local.conf
+
# When building multiple distros in the same TOPDIR
+TMPDIR = "${TOPDIR}/tmp-${DISTRO}"
+DEPLOY_DIR = "${TOPDIR}/deploy-${DISTRO}"
+
+
+
+

Then initialize the build directory with the OE init script:

+
host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source sources/poky/oe-init-build-env
+
+
+

Change the distribution to ampliphy-rauc (for i.MX6, AM6x) or +ampliphy-vendor-rauc (for i.MX8):

+
+
build/conf/local.conf
+
DISTRO ?= "ampliphy-rauc"
+
+
+
+

Any image built with this distro now includes a full A/B system. Build the image +as usual:

+
host:~$ bitbake phytec-headless-image
+
+
+

The resulting partup package is stored in the deploy-ampliphy-vendor-rauc directory, e.g.:

+
deploy-ampliphy-vendor-rauc/images/phyboard-segin-imx93-2/phytec-headless-image-phyboard-segin-imx93-2.partup
+
+
+

This partup package contains all the necessary data and configuration to flash +an eMMC. Partup can be obtained from its +release page. Also, see its +README for detailed installation instructions. Partup is already installed +in our Ampliphy images, phytec-headless-image and can be directly used e.g. +from an SD card.

+
+

备注

+

To flash the initial RAUC system, a booted non-RAUC system is needed first on +a different flash device. E.g. you could boot a regular +phytec-headless-image image with distro ampliphy from an SD card.

+
+
+

4.1.1. eMMC

+

While running a non-RAUC system from an SD card on the target, copy the +.partup package built with distro ampliphy-rauc or +ampliphy-vendor-rauc to the running target first:

+
host:~$ scp phytec-headless-image-phyboard-segin-imx93-2.partup 192.168.3.11:/root
+
+
+

Then install the partup package to the eMMC:

+
target:~$ partup install phytec-headless-image-phyboard-segin-imx93-2.partup /dev/mmcblk0
+
+
+

Now the target can boot the flashed A/B system.

+
+
+

4.1.2. NAND

+
+

备注

+

There are scripts provided with the bootloader barebox that previously were +used to initialize NAND flash with an A/B system: rauc_init_nand, +rauc_flash_nand_from_tftp and rauc_flash_nand_from_mmc. These scripts +are deprecated. It is advised to use the script rauc-flash-nand provided +in the Linux environment with PHYTEC's distribution Ampliphy.

+
+

With raw NAND flash the kernel, device tree, and root filesystem are written +individually. Initialize the NAND flash with the correct volumes from a Linux on +the target:

+
target:~$ rauc-flash-nand -k /path/to/zImage -d /path/to/oftree -r /path/to/root.ubifs
+
+
+

The initialization script will automatically utilize all available space of NAND +flash. The NAND device is also determined automatically by finding the device +root in /proc/mtd.

+

On i.MX6 and i.MX6UL devices with barebox, use bbu (barebox update) to flash the +bootloader:

+
target:~$ bbu.sh -f /path/to/barebox.bin
+
+
+

The A/B system on NAND Flash is now ready to be booted.

+
+
+
+

4.2. Bootloader

+
+

4.2.1. Booting the A/B System by Default

+

Booting the A/B system is done mostly automatically by the bootloader since the +Yocto release hardknott. For devices with eMMC flash storage, the +corresponding setting is written into the bootloader environment during the +building of the BSP. In particular, if the distribution ampliphy-rauc or +ampliphy-vendor-rauc is used, as described previously, the bootloader should +automatically start the A/B system and have the variables set for RAUC +accordingly.

+

This automatic setting can be manually changed by setting one variable in the +bootloader. The procedure is described in more detail in the following chapters +for U-Boot and barebox.

+
+
+

4.2.2. U-Boot

+

After a successful boot into a Linux environment, this command is used to view +the available parameters:

+
target:~$ fw_printenv
+
+
+

You may see this parameter along with others in the output:

+
doraucboot=1
+
+
+

To manually disable or enable booting the A/B system with RAUC, set this +variable to 0 or 1:

+
target:~$ fw_setenv doraucboot 1
+
+
+

This parameter can also be edited in U-Boot. Restart your board and hit any key +to stop the automatic boot. The environment variables can now be viewed:

+
u-boot=> printenv
+
+
+

and set:

+
u-boot=> setenv doraucboot 1
+u-boot=> saveenv
+
+
+
+
+

4.2.3. Barebox

+

In barebox, the system to be booted can be selected directly by its name. To +boot the A/B system, including RAUC, bootchooser is used. To boot e.g. a +regular SD card without RAUC use mmc instead, or nand for NAND devices:

+
barebox$ nv boot.default=bootchooser
+
+
+
+
+
+
+

5. Creating RAUC Bundles

+

To update your system with RAUC, a RAUC bundle (.raucb) needs to be created. +It contains all required images and scripts for the update and a RAUC +manifest.raucm that describes the content of the bundle for the RAUC update +on the target. The BSP includes a Yocto target that lets you build a RAUC bundle +from your Yocto build.

+

To create the bundle with Yocto, run the following in build/ with the +distribution ampliphy-rauc or ampliphy-vendor-rauc set up, as described +previously:

+
host:~$ bitbake phytec-headless-bundle
+
+
+

This results in the creation of a .raucb bundle file in +deploy/images/<MACHINE>/ which can be used for updating the system as +described later. There is no need to create a manifest.raucm manually as it +is created automatically during the build of the bundle. As a reference, the +created manifest would look something like this:

+
+
manifest.raucm
+
[update]
+compatible=phyboard-polis-imx8mm-3
+version=r0
+description=PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0
+build=20200624074335
+
+[image.rootfs]
+sha256=cc3f65cd1c1993951d7a39bdb7b7d723617ac46460f8b640cd8d1622ad6e4c17
+size=99942000
+filename=phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz
+
+[image.boot]
+sha256=bafe46679af8c6292dba22b9d402e3119ef78c6f8b458bcb6993326060de3aa4
+size=12410534
+filename=boot.tar.gz.img
+
+
+
+

For more information about the manifest format, see +https://rauc.readthedocs.io/en/latest/reference.html#manifest.

+
+
+

6. Updating with RAUC

+

To update the target system with RAUC, the RAUC bundle file previously created +first needs to be copied to the board or to a memory device that can be mounted +in Linux. One way is to copy the bundle file with scp, but this requires +enough space left on the board's filesystem. To do this, boot the target board +to Linux and connect it via Ethernet to your host PC.

+

On the host, run:

+
host:~$ scp phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb root@192.168.3.11:/tmp/
+
+
+

On the target, the bundle can be verified:

+
target:~$ rauc info /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+
+
+

and the output should look similar to this:

+
rauc-Message: 12:52:49.821: Reading bundle: /phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+rauc-Message: 12:52:49.830: Verifying bundle...
+Compatible:     'phyboard-polis-imx8mm-3'
+Version:        'r0'
+Description:    'PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0'
+Build:          '20200624073212'
+Hooks:          ''
+2 Images:
+(1)     phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz
+        Slotclass: rootfs
+        Checksum:  342f67f7678d7af3f77710e1b68979f638c7f4d20393f6ffd0c36beff2789070
+        Size:      180407809
+        Hooks:
+(2)     boot.tar.gz.img
+        Slotclass: boot
+        Checksum:  8c84465b4715cc142eca2785fea09804bd970755142c9ff57e08c791e2b71f28
+        Size:      12411786
+        Hooks:
+0 Files
+
+Certificate Chain:
+ 0 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH Development-1
+   Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   SPKI sha256: E2:47:5F:32:05:37:04:D4:8C:48:8D:A6:74:A8:21:2E:97:41:EE:88:74:B5:F4:65:75:97:76:1D:FF:1D:7B:EE
+   Not Before: Jan  1 00:00:00 1970 GMT
+   Not After:  Dec 31 23:59:59 9999 GMT
+ 1 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   SPKI sha256: AB:5C:DB:C6:0A:ED:A4:48:B9:40:AC:B1:48:06:AA:BA:92:09:83:8C:DC:6F:E1:5F:B6:FB:0C:39:3C:3B:E6:A2
+   Not Before: Jan  1 00:00:00 1970 GMT
+   Not After:  Dec 31 23:59:59 9999 GMT
+
+
+

To check the current state of the system, run:

+
target:~$ rauc status
+
+
+

and get output similar to this:

+
=== System Info ===
+Compatible:  phyboard-segin-imx6ul-6
+Variant:
+Booted from: rootfs.0 (system0)
+
+=== Bootloader ===
+Activated: rootfs.0 (system0)
+
+=== Slot States ===
+o [rootfs.1] (/dev/ubi0_6, ubifs, inactive)
+        bootname: system1
+        boot status: good
+    [dtb.1] (/dev/ubi0_3, ubivol, inactive)
+    [kernel.1] (/dev/ubi0_2, ubivol, inactive)
+
+x [rootfs.0] (/dev/ubi0_5, ubifs, booted)
+        bootname: system0
+        boot status: good
+    [kernel.0] (/dev/ubi0_0, ubivol, active)
+    [dtb.0] (/dev/ubi0_1, ubivol, active)
+
+
+

To update the currently inactive system with the downloaded bundle, run:

+
target:~$ rauc install /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+
+
+

and reboot afterward:

+
target:~$ reboot
+
+
+

With the success of the update, RAUC automatically switches the active system to +the newly updated system. Now during reboot, RAUC counts the boot attempts of +the kernel and if it fails more often than specified in the state framework of +the system, RAUC switches back to the old system and marks the new system as +bad. If the boot attempt to the kernel is successful, the new system is marked +as good and the old system can now be updated with the same instructions. After +two successful rauc install and reboot, both systems are updated.

+
+

小技巧

+

When you update from a USB stick, make sure to remove the stick after a +successful update before rebooting. If not, an automatic update will be +started after each boot. This is due to the Automatic Update from USB Flash +Drive with RAUC you can find below.

+
+
+

6.1. Changing the Active Boot Slot

+

It is possible to switch the active system manually:

+
target:~$ rauc status mark-active other
+
+
+

After a reboot, the target now starts from the other system.

+
+
+
+

7. Switching RAUC Keyrings

+

PHYTEC's distribution comes with keys and certificates used for development and +demonstration purposes only. To change to a different PKI when devices are +already rolled out, RAUC's keyring must be changed. This chapter describes the +full procedure from a development state to a production state. Keep in mind, +that it is always a better idea to roll out your devices with a production +keyring in the first place, instead of relying on a development one for too +long. The following diagram shows the general process of switching keyrings for +RAUC:

+../_images/rauc-switching-keyrings.png +
+

7.1. Keyring Switching Process

+

Create new certificates and keys for your own PKI. See our security manual for a +detailed description on how to create a custom PKI. For this document, we refer +to this newly created PKI as "production", as opposed to the existing +"development" keys.

+

Move the generated keys and certificates, to your main Yocto build directory +root, alongside with build/ and sources/.

+
+

警告

+

Be careful where you store the private keys! These should in no way be made +publicly available. E.g. do not store the private keys in a public Git +repository. Otherwise, unauthorized entities could create RAUC bundles that +can be installed on your target system!

+
+

Now, a RAUC bundle must be created that contains the new "production" CA keyring +in its root filesystem but is still signed by the "development" CA. With this, +the system is converted from a "development" system to a "production" system. To +achieve this, exchange the file ca.cert.pem installed by the RAUC recipe in +the Yocto sources. Create a file rauc_%.bbappend in your own Yocto layer:

+
+
recipes-core/rauc/rauc_%.bbappend
+
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+RAUC_KEYRING_FILE = "${CERT_PATH}/rauc-customer/ca.cert.pem"
+
+
+
+

Build the same RAUC bundle as before, now with the exchanged keyring:

+
host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source source/poky/oe-init-build-env
+host:~$ bitbake phytec-headless-bundle  # Build the desired RAUC bundle
+
+
+

Install the resulting RAUC bundle as usual. The target now has the image with +the "production" keyring installed in its other slot ("System B" in the figure +above). Reboot to start that system.

+

All future RAUC bundles for the "production" system must now also be signed by +the "production" CA. For this, change the key and certificate to your newly +generated "production" ones in the bundle recipe:

+
+
recipes-images/bundles/customer-headless-bundle.bb
+
require phytec-base-bundle.inc
+
+RAUC_SLOT_rootfs ?= "phytec-headless-image"
+
+RAUC_KEY_FILE = "${CERT_PATH}/rauc-customer/private/production-1.key.pem"
+RAUC_CERT_FILE = "${CERT_PATH/rauc-customer/production-1.cert.pem"
+
+RAUC_INTERMEDIATE_CERT_FILE = ""
+
+
+
+

Rebuild the RAUC bundle:

+
host:~$ bitbake customer-headless-bundle
+
+
+

These and any future bundles are now ready to be installed on your "production" +target system and have been fully migrated away from the "development" system. +This also means that now only bundles signed by the "production" CA can be +installed on the target (and e.g. "development" bundles cannot).

+
+
+
+

8. Use Case Examples

+
+

8.1. Automatic Updates from USB Flash Drive with RAUC

+

One of the most prominent use cases for RAUC might be an automatic update system +from a USB flash drive. This use case is implemented in the BSP as a reference +example. We combine only standard Linux mechanisms with RAUC to build the +system. The kernel notifies udev when a device gets plugged into the USB port. +We use a custom udev rule to trigger a systemd service when this event +happens.

+
+
10-update-usb.rules
+
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"
+
+# Trigger systemd service
+ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}="update-usb@%k.service"
+
+# Exit
+LABEL="media_by_label_auto_mount_end"
+
+
+
+

The service automatically mounts the USB flash drive and notifies the +application.

+
+
update-usb@.service
+
[Unit]
+Description=usb media RAUC service
+After=multi-user.target
+Requires=rauc.service
+
+[Service]
+Type=oneshot
+Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket
+ExecStartPre=/bin/mkdir -p /media/%I
+ExecStartPre=/bin/mount -t auto /dev/%I /media/%I
+ExecStart=/usr/bin/update_usb.sh %I
+ExecStop=/bin/umount -l /media/%i
+ExecStopPost=-/bin/rmdir /media/%I
+
+
+
+

In our reference implementation, we simply use a shell script for the +application logic.

+
+
update_usb.sh
+
#!/bin/sh
+
+MOUNT=/media/$1
+
+NUMRAUCM=$(find ${MOUNT}/*.raucb -maxdepth 0 | wc -l)
+
+[ "$NUMRAUCM" -eq 0 ] && echo "${MOUNT}*.raucb not found" && exit
+[ "$NUMRAUCM" -ne 1 ] && echo "more than one ${MOUNT}/*.raucb" && exit
+
+rauc install $MOUNT/*.raucb
+if [ "$?" -ne 0 ]; then
+    echo "Failed to install RAUC bundle."
+else
+    echo "Update successful."
+fi
+exit $?
+
+
+
+

The update logic can be integrated into an application using the systemd D-Bus +API. RAUC does not need to be called by its command-line interface but can be +integrated with D-Bus.

+
+

小技巧

+

RAUC features a D-Bus API interface (see +https://rauc.readthedocs.io/en/latest/using.html#using-the-d-bus-api).

+
+
+
+

8.2. Security Measurement: Downgrade Barrier

+

As a second reference example, we will implement a security mechanism: a +downgrade barrier. When you detect a security vulnerability on your system, you +will fix it and update your system. The systems with the new software will now +be secure again. If an attacker gets a hold of the old software update bundle, +which still has a valid signature, the attacker might have the possibility to +install the old software and still take advantage of the previously fixed +security vulnerability. To prevent this from happening, you could revoke the +updated certificate for every single update and create a new one. This might be +difficult to handle, depending on the environment. A simpler solution would be +to allow updates only in one direction using a version check.

+
+
rauc_downgrade_barrier.sh
+
#!/bin/sh
+
+VERSION_FILE=/etc/rauc/downgrade_barrier_version
+MANIFEST_FILE=${RAUC_UPDATE_SOURCE}/manifest.raucm
+
+[ ! -f ${VERSION_FILE} ] && exit 1
+[ ! -f ${MANIFEST_FILE} ] && exit 2
+
+VERSION=`cat ${VERSION_FILE} | cut -d 'r' -f 2`
+BUNDLE_VERSION=`grep "version" -rI ${MANIFEST_FILE} | cut -d 'r' -f 3`
+
+# check from empty or unset variables
+[ -z "${VERSION}" ] && exit 3
+[ -z "${BUNDLE_VERSION}" ] && exit 4
+
+# developer mode, allow all updates if version is r0
+#[ ${VERSION} -eq 0 ] && exit 0
+
+# downgrade barrier
+if [ ${VERSION} -gt ${BUNDLE_VERSION} ]; then
+        echo "Downgrade barrier blocked rauc update! CODE5\n"
+else
+        exit 0
+fi
+exit 5
+
+
+
+

The script is installed on the target but it is not activated. You need to +remove the developer mode line in the script to activate it.

+
+
+

8.3. Streaming Bundles over HTTP

+

Instead of copying the bundle to the device, the bundle can be streamed over +HTTP. Using bundle streaming has the advantage of not requiring local storage on +the target. A simple approach to this is running NGINX inside a Docker +container. The following example shows how to implement a minimal download +server enabling HTTP range requests to support this feature.

+

Create a Dockerfile with the following content:

+
+
Dockerfile
+
FROM nginx
+
+COPY bundles /bundles
+COPY nginx.conf /etc/nginx/nginx.conf
+
+
+
+

Configure NGINX to enable HTTP range requests and point it to the bundle file.

+
+
nginx.conf
+
events {}
+http {
+    server {
+        proxy_force_ranges on;
+
+        location / {
+            root /bundles;
+        }
+    }
+}
+
+
+
+

Place a bundle in the bundles sub-directory. The folder structure looks like +the following after creating all configuration files:

+
user@host:rauc-bundle-streaming$ find
+.
+./bundles
+./bundles/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb
+./nginx.conf
+./Dockerfile
+
+
+

Build and run the docker container on the host system:

+
host:~$ sudo docker build -t rauc-bundle-streaming .
+host:~$ sudo docker run --name bundles -p 80:80 -d rauc-bundle-streaming
+
+
+

Install the bundle on the currently inactive target partitions:

+
target:~$ rauc install http://192.168.3.10/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb
+
+
+
+

备注

+

After the update finishes the target may display the following error which +has no impact on the success of the update:

+
[ 7416.336609] block nbd0: NBD_DISCONNECT
+[ 7416.340413] block nbd0: Send disconnect failed -32
+
+
+
+
+
+
+

9. Reference

+
+

9.1. Boot Logic Implementation

+
+

小技巧

+

The implementation details described in this chapter serve as a reference +guide. PHYTEC BSPs that have RAUC support include these by default and the +changes are already incorporated.

+
+
+

9.1.1. U-Boot Environment Variables

+

For U-Boot, the boot logic that selects the correct partitions to boot from is +implemented in its environment. As a reference, these are the most important +U-Boot variables that are used for the A/B system with RAUC:

+

For BSP-Yocto-NXP-i.MX8M*-PD23.1.0:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Function

BOOT_ORDER

Contains a space-separated list of boot targets in the +order they should be tried. This parameter is +automatically set by RAUC.

BOOT_<slot>_LEFT

Contains the number of remaining boot attempts to +perform for the respective slot. This parameter is +automatically set by RAUC.

raucboot

Contains the boot logic that sets the partitions so +the correct system is loaded.

doraucboot

Enables booting the A/B system if set to 1 and +disables it if set to 0.

raucslot

Contains the current boot slot used in +BOOT_<slot>_LEFT.

raucargs

Sets the Kernel bootargs like console, root, and RAUC +lot.

raucdev

Sets the eMMC as the boot device.

raucrootpart

Sets the root filesystem partitions of the device.

raucpart

Sets the boot partitions of the device.

loadraucimage

Loads the Kernel image into RAM.

loadraucfdt

Loads the device tree into RAM.

+

These environment variables are defined in include/configs/phycore_<SOC>.h +in the u-boot source code.

+

For BSP-Yocto-Ampliphy-AM6xx-PD23.2.0:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Function

BOOT_ORDER

Contains a space-separated list of boot targets in the +order they should be tried. This parameter is +automatically set by RAUC.

BOOT_<slot>_LEFT

Contains the number of remaining boot attempts to +perform for the respective slot. This parameter is +automatically set by RAUC.

init_rauc

Contains the boot logic that sets the partitions so +the correct system is loaded.

doraucboot

Enables booting the A/B system if set to 1 and +disables it if set to 0.

raucslot

Contains the current boot slot used in +BOOT_<slot>_LEFT.

raucrootpart

Sets the root filesystem partitions of the device.

raucbootpart

Sets the boot partitions of the device.

+

These environment variables are defined in +include/environment/phytec/rauc.env in the u-boot source code.

+
+

备注

+

A change in the partition layout, e.g. when using an additional data +partition, may require changing the variables raucrootpart and +raucpart. Make sure to rebuild your image with the new bootloader +environment after you have made the appropriate changes.

+
+
+
+

9.1.2. Barebox Bootchooser Framework

+

For the barebox, the boot logic that selects the correct partitions to boot from +is implemented using the bootchooser and state framework. See the barebox +documentation for detailed information about these: Barebox Bootchooser +Framework, Barebox +State Framework.

+

First, the state framework configuration needs to be added to the barebox device +tree. Check out the Customizing the BSP +chapter in the Yocto reference manual. The state framework configuration is +already included with our BSP for the supported SoC and can be directly included +in the main barebox device tree. E.g. for i.MX6 based module:

+
#include "imx6qdl-phytec-state.dtsi"
+
+
+

Afterward, rebuild the image and flash the new bootloader.

+
+

警告

+

Be aware that by adding the state framework configuration, the first 160 +bytes of the EEPROM are occupied and can no longer be used for user-specific +purposes.

+
+

The following device tree snippet shows an example of the state framework +configuration used with the BSP. As can be seen, the EEPROM is used as a backend +for the state information:

+
/ {
+    aliases {
+        state = &state;
+    };
+
+    state: imx6qdl_phytec_boot_state {
+        magic = <0x883b86a6>;
+        compatible = "barebox,state";
+        backend-type = "raw";
+        backend = <&backend_update_eeprom>;
+        backend-stridesize = <54>;
+
+        #address-cells = <1>;
+        #size-cells = <1>;
+        bootstate {
+            #address-cells = <1>;
+            #size-cells = <1>;
+            last_chosen {
+                reg = <0x0 0x4>;
+                type = "uint32";
+            };
+            system0 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                remaining_attempts {
+                    reg = <0x4 0x4>;
+                    type = "uint32";
+                    default = <3>;
+                };
+                priority {
+                    reg = <0x8 0x4>;
+                    type = "uint32";
+                    default = <21>;
+                };
+                ok {
+                    reg = <0xc 0x4>;
+                    type = "uint32";
+                    default = <0>;
+                };
+            };
+            system1 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                remaining_attempts {
+                    reg = <0x10 0x4>;
+                    type = "uint32";
+                    default = <3>;
+                };
+                priority {
+                    reg = <0x14 0x4>;
+                    type = "uint32";
+                    default = <20>;
+                };
+                ok {
+                    reg = <0x18 0x4>;
+                    type = "uint32";
+                    default = <0>;
+                };
+            };
+        };
+    };
+};
+
+&eeprom {
+    status = "okay";
+    partitions {
+        compatible = "fixed-partitions";
+        #size-cells = <1>;
+        #address-cells = <1>;
+        backend_update_eeprom: state@0 {
+            reg = <0x0 0x100>;
+            label = "update-eeprom";
+        };
+    };
+};
+
+
+

To be able to boot from two systems alternately, the bootchooser needs to be +aware of the state framework configuration. For each system, a boot script is +required. For a system with NAND flash, the boot script of the first system may +look like the following:

+
+
/env/boot/system0
+
#!/bin/sh
+
+[ -e /env/config-expansions ] && /env/config-expansions
+
+[ ! -e /dev/nand0.root.ubi ] && ubiattach /dev/nand0.root
+
+global.bootm.image="/dev/nand0.root.ubi.kernel0"
+global.bootm.oftree="/dev/nand0.root.ubi.oftree0"
+global.linux.bootargs.dyn.root="root=ubi0:root0 ubi.mtd=root rootfstype=ubifs"
+
+
+
+

The second boot script has the same structure but uses the partitions containing +the second system. Machines with eMMC flash use similar boot scripts, albeit the +mounting and boot arguments look different.

+

Run the following commands to create the required bootchooser non-volatile +environment variables:

+
barebox$ nv bootchooser.state_prefix=state.bootstate
+barebox$ nv bootchooser.system0.boot=system0
+barebox$ nv bootchooser.system1.boot=system1
+barebox$ nv bootchooser.targets="system0 system1"
+
+
+
+
+
+

9.2. eMMC Boot Partitions

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader.

+

By default, bundles built with our BSP (e.g. phytec-headless-bundle) contain +the bootloader for updating eMMC boot partitions accordingly.

+

Note, that the U-Boot environment still resides in the user area before the +first partition. The user area also still contains the bootloader which the +image first shipped during its initialization process.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=imx-boot of=/dev/mmcblk2boot0 bs=1k seek=33
+target:~$ dd if=imx-boot of=/dev/mmcblk2boot1 bs=1k seek=33
+
+
+

This example is valid for the i.MX 8M Mini SoC. Note, that other SoCs may have +different bootloader files and require different offsets where the bootloader is +expected, specified by the seek parameter. See the following table for the +different offsets being required by each SoC:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

Bootloader

i.MX 6

1 kiB

0 kiB

/dev/mmcblk3

barebox.bin

i.MX 6UL

1 kiB

0 kiB

/dev/mmcblk1

barebox.bin

i.MX 8M

33 kiB

33 kiB

/dev/mmcblk0

imx-boot

i.MX 8M Mini

33 kiB

33 kiB

/dev/mmcblk2

imx-boot

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

AM62x +AM62Ax +AM64x

N/A

0 kiB +512 kiB +2560 kiB

/dev/mmcblk0

tiboot3.bin +tispl.bin +u-boot.img

+
+

9.2.1. Bootloader Offsets

+

Note that the offset is different, depending on whether the bootloader resides +in the user area or the boot partitions of the eMMC.

+

After a bootloader has been written to the eMMC boot partitions, booting from +these can be enabled by using the following command:

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

This also means that only the bootloaders written in the eMMC boot partitions +are used. The bootloader in the user area is not used anymore. These steps are +also executed by RAUC internally when updating the target system with a bundle.

+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

After this command, the eMMC user area is used to provide the bootloader.

+

When using U-Boot, a similar command is also available in the bootloader:

+
u-boot=> mmc partconf 2 0 0 0  # disable
+u-boot=> mmc partconf 2 0 1 0  # enable
+
+
+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/rauc/manual-index.html b/previews/271/zh_CN/rauc/manual-index.html new file mode 100644 index 000000000..7ff38a47c --- /dev/null +++ b/previews/271/zh_CN/rauc/manual-index.html @@ -0,0 +1,300 @@ + + + + + + + + + RAUC Update & Device Management Manuals — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

RAUC Update & Device Management Manuals

+
+

Kirkstone

+
+

Table of Contents

+ +
+
+
+

Mickledore

+
+

Table of Contents

+ +
+
+
+

Scarthgap

+
+

Table of Contents

+ +
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/rauc/mickledore.html b/previews/271/zh_CN/rauc/mickledore.html new file mode 100644 index 000000000..b3480b2ee --- /dev/null +++ b/previews/271/zh_CN/rauc/mickledore.html @@ -0,0 +1,1189 @@ + + + + + + + + + 1. Introduction — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+ +
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + +

RAUC Update & Device Management Manual

Document Title

RAUC Update & Device Management Manual Mickledore

Document Type

RAUC Update & Device Management +Manual

Release Date

XXXX/XX/XX

Is Branch of

RAUC Update & Device Management Manual

+ + + + + + + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-NXP-i.MX93-PD24.1.0

Major

05.02.2024

released

BSP-Yocto-NXP-i.MX93-PD24.1.1

Minor

08.05.2024

released

+

This manual was tested using the Yocto version Mickledore.

+
+

1. Introduction

+

PHYTEC's Yocto distribution Ampliphy (former Yogurt) supports the RAUC (Robust Auto-Update Controller) +mechanism. RAUC controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. For +eMMC devices only, it can also update the bootloader.

+

This manual describes how RAUC is used and implemented on various PHYTEC +platforms. Note, that different modules use different bootloaders and flash +storage devices, which affects the way things are handled by RAUC. Make sure to +read the correct sections fitting your platform.

+
+

备注

+

This manual contains machine-specific paths and variable contents. Make sure +you are using the correct machine and device names for your application when +executing any commands.

+
+
+
+

2. System Configuration

+

RAUC can be used with both eMMC and NAND flash storage. Using the distro +ampliphy-rauc or ampliphy-vendor-rauc, it is enabled by default and requires +no additional setup to get started. RAUC can be used in different update +scenarios. As an example, we configured the BSP to use an A/B setup to have a +completely redundant system (including the bootloader on eMMC devices). Note, +that there is an additional partition named config storing persistent +configuration data not being changed when updating.

+../_images/rauc-ab-system.png +
+

2.1. RAUC BSP Example Setup

+

The partition layout is defined in the /etc/rauc/system.conf file. As an +example, this is what it looks like for i.MX 8M Mini with eMMC flash storage:

+
+
/etc/rauc/system.conf
+
[system]
+compatible=phyboard-polis-imx8mm-4
+bootloader=uboot
+mountprefix=/mnt/rauc
+
+[handlers]
+pre-install=/usr/lib/rauc/rauc-pre-install.sh
+post-install=/usr/lib/rauc/rauc-post-install.sh
+
+[keyring]
+path=mainca-rsa.crt.pem
+
+[slot.bootloader.0]
+device=/dev/mmcblk2
+type=boot-emmc
+
+# System A
+[slot.rootfs.0]
+device=/dev/mmcblk2p5
+type=ext4
+bootname=system0
+
+[slot.boot.0]
+device=/dev/mmcblk2p1
+type=vfat
+parent=rootfs.0
+
+# System B
+[slot.rootfs.1]
+device=/dev/mmcblk2p6
+type=ext4
+bootname=system1
+
+[slot.boot.1]
+device=/dev/mmcblk2p2
+type=vfat
+parent=rootfs.1
+
+
+
+

Note, that the devices specified in the slots are different depending on the +selected machine.

+
+

警告

+

Updates with RAUC use an OpenSSL certificate to verify the validity of an +image. The BSP includes a certificate that can be used for development. In a +productive system, however, it is highly recommended to use a self-created +key and certificate. If you need to change the keyring on an existing device, +see Switching RAUC Keyrings for more +information.

+
+
+
+
+

3. Design Considerations

+

In order to prevent the system from locking up, it may be a good idea to utilize +a hardware watchdog. In case the Linux Kernel does not boot or another +catastrophic event occurs that prevents the system from operating normally, the +hardware watchdog then resets the system. By default, the hardware watchdog is +disabled. To enable it, refer to the corresponding BSP manual that fits your +SoM.

+

Other important design considerations, as well as a checklist, can be found in +the official RAUC documentation: +https://rauc.readthedocs.io/en/latest/checklist.html

+
+
+

4. Initial Setup

+

To use RAUC, the flash device needs to be written with a complete Linux system +and bootloader. The preferred method to do this is using the included tool +partup.

+
+

4.1. Flash Storage

+

To flash the device with the correct partitions/volumes, use a partup package +built with the ampliphy-rauc or ampliphy-vendor-rauc distribution. +Prebuilt partup packages can be found in the BSP release. It is also possible to +build an image with this distribution yourself using Yocto. Separate build +directories are created, storing the images and packages for the RAUC system. +Initialize the build directory with the OE init script:

+
host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source sources/poky/oe-init-build-env
+
+
+

Change the distribution to ampliphy-rauc (for i.MX6, AM6x, i.MX8 mainline BSP) or +ampliphy-vendor-rauc (for i.MX8, i.MX9 vendor BSP):

+
+
build/conf/local.conf
+
DISTRO ?= "ampliphy-rauc"
+
+
+
+

Any image built with this distro now includes a full A/B system. Build the image +as usual:

+
host:~$ bitbake phytec-headless-image
+
+
+

The resulting partup package is stored in the deploy-ampliphy-vendor-rauc directory, e.g.:

+
deploy-ampliphy-vendor-rauc/images/phyboard-segin-imx93-2/phytec-headless-image-phyboard-segin-imx93-2.partup
+
+
+

This partup package contains all the necessary data and configuration to flash +an eMMC. Partup can be obtained from its +release page. Also, see its +README for detailed installation instructions. Partup is already installed +in our Ampliphy images, phytec-headless-image and can be directly used e.g. +from an SD card.

+
+

备注

+

To flash the initial RAUC system, a booted non-RAUC system is needed first on +a different flash device. E.g. you could boot a regular +phytec-headless-image image with distro ampliphy from an SD card.

+
+
+

4.1.1. eMMC

+

While running a non-RAUC system from an SD card on the target, copy the +.partup package built with distro ampliphy-rauc or +ampliphy-vendor-rauc to the running target first:

+
host:~$ scp phytec-headless-image-phyboard-segin-imx93-2.partup 192.168.3.11:/root
+
+
+

Then install the partup package to the eMMC:

+
target:~$ partup install phytec-headless-image-phyboard-segin-imx93-2.partup /dev/mmcblk0
+
+
+

Now the target can boot the flashed A/B system.

+
+
+

4.1.2. NAND

+
+

备注

+

There are scripts provided with the bootloader barebox that previously were +used to initialize NAND flash with an A/B system: rauc_init_nand, +rauc_flash_nand_from_tftp and rauc_flash_nand_from_mmc. These scripts +are deprecated. It is advised to use the script rauc-flash-nand provided +in the Linux environment with PHYTEC's distribution Ampliphy.

+
+

With raw NAND flash the kernel, device tree, and root filesystem are written +individually. Initialize the NAND flash with the correct volumes from a Linux on +the target:

+
target:~$ rauc-flash-nand -k /path/to/zImage -d /path/to/oftree -r /path/to/root.ubifs
+
+
+

The initialization script will automatically utilize all available space of NAND +flash. The NAND device is also determined automatically by finding the device +root in /proc/mtd.

+

On i.MX6 and i.MX6UL devices with barebox, use bbu (barebox update) to flash the +bootloader:

+
target:~$ bbu.sh -f /path/to/barebox.bin
+
+
+

The A/B system on NAND Flash is now ready to be booted.

+
+
+
+

4.2. Bootloader

+
+

4.2.1. Booting the A/B System by Default

+

Booting the A/B system is done mostly automatically by the bootloader since the +Yocto release hardknott. For devices with eMMC flash storage, the +corresponding setting is written into the bootloader environment during the +building of the BSP. In particular, if the distribution ampliphy-rauc or +ampliphy-vendor-rauc is used, as described previously, the bootloader should +automatically start the A/B system and have the variables set for RAUC +accordingly.

+

This automatic setting can be manually changed by setting one variable in the +bootloader. The procedure is described in more detail in the following chapters +for U-Boot and barebox.

+
+
+

4.2.2. U-Boot

+

After a successful boot into a Linux environment, this command is used to view +the available parameters:

+
target:~$ fw_printenv
+
+
+

You may see this parameter along with others in the output:

+
doraucboot=1
+
+
+

To manually disable or enable booting the A/B system with RAUC, set this +variable to 0 or 1:

+
target:~$ fw_setenv doraucboot 1
+
+
+

This parameter can also be edited in U-Boot. Restart your board and hit any key +to stop the automatic boot. The environment variables can now be viewed:

+
u-boot=> printenv
+
+
+

and set:

+
u-boot=> setenv doraucboot 1
+u-boot=> saveenv
+
+
+
+
+

4.2.3. Barebox

+

In barebox, the system to be booted can be selected directly by its name. To +boot the A/B system, including RAUC, bootchooser is used. To boot e.g. a +regular SD card without RAUC use mmc instead, or nand for NAND devices:

+
barebox$ nv boot.default=bootchooser
+
+
+
+
+
+
+

5. Creating RAUC Bundles

+

To update your system with RAUC, a RAUC bundle (.raucb) needs to be created. +It contains all required images and scripts for the update and a RAUC +manifest.raucm that describes the content of the bundle for the RAUC update +on the target. The BSP includes a Yocto target that lets you build a RAUC bundle +from your Yocto build.

+

To create the bundle with Yocto, run the following in build/ with the +distribution ampliphy-rauc or ampliphy-vendor-rauc set up, as described +previously:

+
host:~$ bitbake phytec-headless-bundle
+
+
+

This results in the creation of a .raucb bundle file in +deploy/images/<MACHINE>/ which can be used for updating the system as +described later. There is no need to create a manifest.raucm manually as it +is created automatically during the build of the bundle. As a reference, the +created manifest would look something like this:

+
+
manifest.raucm
+
[update]
+compatible=phyboard-polis-imx8mm-3
+version=r0
+description=PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0
+build=20200624074335
+
+[image.rootfs]
+sha256=cc3f65cd1c1993951d7a39bdb7b7d723617ac46460f8b640cd8d1622ad6e4c17
+size=99942000
+filename=phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz
+
+[image.boot]
+sha256=bafe46679af8c6292dba22b9d402e3119ef78c6f8b458bcb6993326060de3aa4
+size=12410534
+filename=boot.tar.gz.img
+
+
+
+

For more information about the manifest format, see +https://rauc.readthedocs.io/en/latest/reference.html#manifest.

+
+
+

6. Updating with RAUC

+

To update the target system with RAUC, the RAUC bundle file previously created +first needs to be copied to the board or to a memory device that can be mounted +in Linux. One way is to copy the bundle file with scp, but this requires +enough space left on the board's filesystem. To do this, boot the target board +to Linux and connect it via Ethernet to your host PC.

+

On the host, run:

+
host:~$ scp phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb root@192.168.3.11:/tmp/
+
+
+

On the target, the bundle can be verified:

+
target:~$ rauc info /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+
+
+

and the output should look similar to this:

+
rauc-Message: 12:52:49.821: Reading bundle: /phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+rauc-Message: 12:52:49.830: Verifying bundle...
+Compatible:     'phyboard-polis-imx8mm-3'
+Version:        'r0'
+Description:    'PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0'
+Build:          '20200624073212'
+Hooks:          ''
+2 Images:
+(1)     phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz
+        Slotclass: rootfs
+        Checksum:  342f67f7678d7af3f77710e1b68979f638c7f4d20393f6ffd0c36beff2789070
+        Size:      180407809
+        Hooks:
+(2)     boot.tar.gz.img
+        Slotclass: boot
+        Checksum:  8c84465b4715cc142eca2785fea09804bd970755142c9ff57e08c791e2b71f28
+        Size:      12411786
+        Hooks:
+0 Files
+
+Certificate Chain:
+ 0 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH Development-1
+   Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   SPKI sha256: E2:47:5F:32:05:37:04:D4:8C:48:8D:A6:74:A8:21:2E:97:41:EE:88:74:B5:F4:65:75:97:76:1D:FF:1D:7B:EE
+   Not Before: Jan  1 00:00:00 1970 GMT
+   Not After:  Dec 31 23:59:59 9999 GMT
+ 1 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   SPKI sha256: AB:5C:DB:C6:0A:ED:A4:48:B9:40:AC:B1:48:06:AA:BA:92:09:83:8C:DC:6F:E1:5F:B6:FB:0C:39:3C:3B:E6:A2
+   Not Before: Jan  1 00:00:00 1970 GMT
+   Not After:  Dec 31 23:59:59 9999 GMT
+
+
+

To check the current state of the system, run:

+
target:~$ rauc status
+
+
+

and get output similar to this:

+
=== System Info ===
+Compatible:  phyboard-segin-imx6ul-6
+Variant:
+Booted from: rootfs.0 (system0)
+
+=== Bootloader ===
+Activated: rootfs.0 (system0)
+
+=== Slot States ===
+o [rootfs.1] (/dev/ubi0_6, ubifs, inactive)
+        bootname: system1
+        boot status: good
+    [dtb.1] (/dev/ubi0_3, ubivol, inactive)
+    [kernel.1] (/dev/ubi0_2, ubivol, inactive)
+
+x [rootfs.0] (/dev/ubi0_5, ubifs, booted)
+        bootname: system0
+        boot status: good
+    [kernel.0] (/dev/ubi0_0, ubivol, active)
+    [dtb.0] (/dev/ubi0_1, ubivol, active)
+
+
+

To update the currently inactive system with the downloaded bundle, run:

+
target:~$ rauc install /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+
+
+

and reboot afterward:

+
target:~$ reboot
+
+
+

With the success of the update, RAUC automatically switches the active system to +the newly updated system. Now during reboot, RAUC counts the boot attempts of +the kernel and if it fails more often than specified in the state framework of +the system, RAUC switches back to the old system and marks the new system as +bad. If the boot attempt to the kernel is successful, the new system is marked +as good and the old system can now be updated with the same instructions. After +two successful rauc install and reboot, both systems are updated.

+
+

小技巧

+

When you update from a USB stick, make sure to remove the stick after a +successful update before rebooting. If not, an automatic update will be +started after each boot. This is due to the Automatic Update from USB Flash +Drive with RAUC you can find below.

+
+
+

6.1. Changing the Active Boot Slot

+

It is possible to switch the active system manually:

+
target:~$ rauc status mark-active other
+
+
+

After a reboot, the target now starts from the other system.

+
+
+
+

7. Switching RAUC Keyrings

+

PHYTEC's distribution comes with keys and certificates used for development and +demonstration purposes only. To change to a different PKI when devices are +already rolled out, RAUC's keyring must be changed. This chapter describes the +full procedure from a development state to a production state. Keep in mind, +that it is always a better idea to roll out your devices with a production +keyring in the first place, instead of relying on a development one for too +long. The following diagram shows the general process of switching keyrings for +RAUC:

+../_images/rauc-switching-keyrings.png +
+

7.1. Keyring Switching Process

+

Create new certificates and keys for your own PKI. See our security manual for a +detailed description on how to create a custom PKI. For this document, we refer +to this newly created PKI as "production", as opposed to the existing +"development" keys.

+

Move the generated keys and certificates, to your main Yocto build directory +root, alongside with build/ and sources/.

+
+

警告

+

Be careful where you store the private keys! These should in no way be made +publicly available. E.g. do not store the private keys in a public Git +repository. Otherwise, unauthorized entities could create RAUC bundles that +can be installed on your target system!

+
+

Now, a RAUC bundle must be created that contains the new "production" CA keyring +in its root filesystem but is still signed by the "development" CA. With this, +the system is converted from a "development" system to a "production" system. To +achieve this, exchange the file ca.cert.pem installed by the RAUC recipe in +the Yocto sources. Create a file rauc_%.bbappend in your own Yocto layer:

+
+
recipes-core/rauc/rauc_%.bbappend
+
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+RAUC_KEYRING_FILE = "${CERT_PATH}/rauc-customer/ca.cert.pem"
+
+
+
+

Build the same RAUC bundle as before, now with the exchanged keyring:

+
host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source source/poky/oe-init-build-env
+host:~$ bitbake phytec-headless-bundle  # Build the desired RAUC bundle
+
+
+

Install the resulting RAUC bundle as usual. The target now has the image with +the "production" keyring installed in its other slot ("System B" in the figure +above). Reboot to start that system.

+

All future RAUC bundles for the "production" system must now also be signed by +the "production" CA. For this, change the key and certificate to your newly +generated "production" ones in the bundle recipe:

+
+
recipes-images/bundles/customer-headless-bundle.bb
+
require phytec-base-bundle.inc
+
+RAUC_SLOT_rootfs ?= "phytec-headless-image"
+
+RAUC_KEY_FILE = "${CERT_PATH}/rauc-customer/private/production-1.key.pem"
+RAUC_CERT_FILE = "${CERT_PATH/rauc-customer/production-1.cert.pem"
+
+RAUC_INTERMEDIATE_CERT_FILE = ""
+
+
+
+

Rebuild the RAUC bundle:

+
host:~$ bitbake customer-headless-bundle
+
+
+

These and any future bundles are now ready to be installed on your "production" +target system and have been fully migrated away from the "development" system. +This also means that now only bundles signed by the "production" CA can be +installed on the target (and e.g. "development" bundles cannot).

+
+
+
+

8. Use Case Examples

+
+

8.1. Automatic Updates from USB Flash Drive with RAUC

+

One of the most prominent use cases for RAUC might be an automatic update system +from a USB flash drive. This use case is implemented in the BSP as a reference +example. We combine only standard Linux mechanisms with RAUC to build the +system. The kernel notifies udev when a device gets plugged into the USB port. +We use a custom udev rule to trigger a systemd service when this event +happens.

+
+
10-update-usb.rules
+
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"
+
+# Trigger systemd service
+ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}="update-usb@%k.service"
+
+# Exit
+LABEL="media_by_label_auto_mount_end"
+
+
+
+

The service automatically mounts the USB flash drive and notifies the +application.

+
+
update-usb@.service
+
[Unit]
+Description=usb media RAUC service
+After=multi-user.target
+Requires=rauc.service
+
+[Service]
+Type=oneshot
+Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket
+ExecStartPre=/bin/mkdir -p /media/%I
+ExecStartPre=/bin/mount -t auto /dev/%I /media/%I
+ExecStart=/usr/bin/update_usb.sh %I
+ExecStop=/bin/umount -l /media/%i
+ExecStopPost=-/bin/rmdir /media/%I
+
+
+
+

In our reference implementation, we simply use a shell script for the +application logic.

+
+
update_usb.sh
+
#!/bin/sh
+
+MOUNT=/media/$1
+
+NUMRAUCM=$(find ${MOUNT}/*.raucb -maxdepth 0 | wc -l)
+
+[ "$NUMRAUCM" -eq 0 ] && echo "${MOUNT}*.raucb not found" && exit
+[ "$NUMRAUCM" -ne 1 ] && echo "more than one ${MOUNT}/*.raucb" && exit
+
+rauc install $MOUNT/*.raucb
+if [ "$?" -ne 0 ]; then
+    echo "Failed to install RAUC bundle."
+else
+    echo "Update successful."
+fi
+exit $?
+
+
+
+

The update logic can be integrated into an application using the systemd D-Bus +API. RAUC does not need to be called by its command-line interface but can be +integrated with D-Bus.

+
+

小技巧

+

RAUC features a D-Bus API interface (see +https://rauc.readthedocs.io/en/latest/using.html#using-the-d-bus-api).

+
+
+
+

8.2. Security Measurement: Downgrade Barrier

+

As a second reference example, we will implement a security mechanism: a +downgrade barrier. When you detect a security vulnerability on your system, you +will fix it and update your system. The systems with the new software will now +be secure again. If an attacker gets a hold of the old software update bundle, +which still has a valid signature, the attacker might have the possibility to +install the old software and still take advantage of the previously fixed +security vulnerability. To prevent this from happening, you could revoke the +updated certificate for every single update and create a new one. This might be +difficult to handle, depending on the environment. A simpler solution would be +to allow updates only in one direction using a version check.

+
+
rauc_downgrade_barrier.sh
+
#!/bin/sh
+
+VERSION_FILE=/etc/rauc/downgrade_barrier_version
+MANIFEST_FILE=${RAUC_UPDATE_SOURCE}/manifest.raucm
+
+[ ! -f ${VERSION_FILE} ] && exit 1
+[ ! -f ${MANIFEST_FILE} ] && exit 2
+
+VERSION=`cat ${VERSION_FILE} | cut -d 'r' -f 2`
+BUNDLE_VERSION=`grep "version" -rI ${MANIFEST_FILE} | cut -d 'r' -f 3`
+
+# check from empty or unset variables
+[ -z "${VERSION}" ] && exit 3
+[ -z "${BUNDLE_VERSION}" ] && exit 4
+
+# developer mode, allow all updates if version is r0
+#[ ${VERSION} -eq 0 ] && exit 0
+
+# downgrade barrier
+if [ ${VERSION} -gt ${BUNDLE_VERSION} ]; then
+        echo "Downgrade barrier blocked rauc update! CODE5\n"
+else
+        exit 0
+fi
+exit 5
+
+
+
+

The script is installed on the target but it is not activated. You need to +remove the developer mode line in the script to activate it.

+
+
+

8.3. Streaming Bundles over HTTP

+

Instead of copying the bundle to the device, the bundle can be streamed over +HTTP. Using bundle streaming has the advantage of not requiring local storage on +the target. A simple approach to this is running NGINX inside a Docker +container. The following example shows how to implement a minimal download +server enabling HTTP range requests to support this feature.

+

Create a Dockerfile with the following content:

+
+
Dockerfile
+
FROM nginx
+
+COPY bundles /bundles
+COPY nginx.conf /etc/nginx/nginx.conf
+
+
+
+

Configure NGINX to enable HTTP range requests and point it to the bundle file.

+
+
nginx.conf
+
events {}
+http {
+    server {
+        proxy_force_ranges on;
+
+        location / {
+            root /bundles;
+        }
+    }
+}
+
+
+
+

Place a bundle in the bundles sub-directory. The folder structure looks like +the following after creating all configuration files:

+
user@host:rauc-bundle-streaming$ find
+.
+./bundles
+./bundles/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb
+./nginx.conf
+./Dockerfile
+
+
+

Build and run the docker container on the host system:

+
host:~$ sudo docker build -t rauc-bundle-streaming .
+host:~$ sudo docker run --name bundles -p 80:80 -d rauc-bundle-streaming
+
+
+

Install the bundle on the currently inactive target partitions:

+
target:~$ rauc install http://192.168.3.10/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb
+
+
+
+

备注

+

After the update finishes the target may display the following error which +has no impact on the success of the update:

+
[ 7416.336609] block nbd0: NBD_DISCONNECT
+[ 7416.340413] block nbd0: Send disconnect failed -32
+
+
+
+
+
+
+

9. Reference

+
+

9.1. Boot Logic Implementation

+
+

小技巧

+

The implementation details described in this chapter serve as a reference +guide. PHYTEC BSPs that have RAUC support include these by default and the +changes are already incorporated.

+
+
+

9.1.1. U-Boot Environment Variables

+

For U-Boot, the boot logic that selects the correct partitions to boot from is +implemented in its environment. As a reference, these are the most important +U-Boot variables that are used for the A/B system with RAUC:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Function

BOOT_ORDER

Contains a space-separated list of boot targets in the +order they should be tried. This parameter is +automatically set by RAUC.

BOOT_<slot>_LEFT

Contains the number of remaining boot attempts to +perform for the respective slot. This parameter is +automatically set by RAUC.

raucinit

Contains the boot logic that sets the partitions so +the correct system is loaded.

doraucboot

Enables booting the A/B system if set to 1 and +disables it if set to 0.

raucargs

Sets the Kernel bootargs like console, root, and RAUC +slot.

raucrootpart

Sets the root filesystem partitions of the device.

raucbootpart

Sets the boot partitions of the device.

+

These environment variables are defined in include/environment/phytec/rauc.env in +the u-boot source code.

+
+

备注

+

A change in the partition layout, e.g. when using an additional data +partition, may require changing the variables raucrootpart and +raucbootpart. Make sure to rebuild your image with the new bootloader +environment after you have made the appropriate changes.

+
+
+
+

9.1.2. Barebox Bootchooser Framework

+

For the barebox, the boot logic that selects the correct partitions to boot from +is implemented using the bootchooser and state framework. See the barebox +documentation for detailed information about these: Barebox Bootchooser +Framework, Barebox +State Framework.

+

First, the state framework configuration needs to be added to the barebox device +tree. Check out the Customizing the BSP +chapter in the Yocto reference manual. The state framework configuration is +already included with our BSP for the supported SoC and can be directly included +in the main barebox device tree. E.g. for i.MX6 based module:

+
#include "imx6qdl-phytec-state.dtsi"
+
+
+

Afterward, rebuild the image and flash the new bootloader.

+
+

警告

+

Be aware that by adding the state framework configuration, the first 160 +bytes of the EEPROM are occupied and can no longer be used for user-specific +purposes.

+
+

The following device tree snippet shows an example of the state framework +configuration used with the BSP. As can be seen, the EEPROM is used as a backend +for the state information:

+
/ {
+    aliases {
+        state = &state;
+    };
+
+    state: imx6qdl_phytec_boot_state {
+        magic = <0x883b86a6>;
+        compatible = "barebox,state";
+        backend-type = "raw";
+        backend = <&backend_update_eeprom>;
+        backend-stridesize = <54>;
+
+        #address-cells = <1>;
+        #size-cells = <1>;
+        bootstate {
+            #address-cells = <1>;
+            #size-cells = <1>;
+            last_chosen {
+                reg = <0x0 0x4>;
+                type = "uint32";
+            };
+            system0 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                remaining_attempts {
+                    reg = <0x4 0x4>;
+                    type = "uint32";
+                    default = <3>;
+                };
+                priority {
+                    reg = <0x8 0x4>;
+                    type = "uint32";
+                    default = <21>;
+                };
+                ok {
+                    reg = <0xc 0x4>;
+                    type = "uint32";
+                    default = <0>;
+                };
+            };
+            system1 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                remaining_attempts {
+                    reg = <0x10 0x4>;
+                    type = "uint32";
+                    default = <3>;
+                };
+                priority {
+                    reg = <0x14 0x4>;
+                    type = "uint32";
+                    default = <20>;
+                };
+                ok {
+                    reg = <0x18 0x4>;
+                    type = "uint32";
+                    default = <0>;
+                };
+            };
+        };
+    };
+};
+
+&eeprom {
+    status = "okay";
+    partitions {
+        compatible = "fixed-partitions";
+        #size-cells = <1>;
+        #address-cells = <1>;
+        backend_update_eeprom: state@0 {
+            reg = <0x0 0x100>;
+            label = "update-eeprom";
+        };
+    };
+};
+
+
+

To be able to boot from two systems alternately, the bootchooser needs to be +aware of the state framework configuration. For each system, a boot script is +required. For a system with NAND flash, the boot script of the first system may +look like the following:

+
+
/env/boot/system0
+
#!/bin/sh
+
+[ -e /env/config-expansions ] && /env/config-expansions
+
+[ ! -e /dev/nand0.root.ubi ] && ubiattach /dev/nand0.root
+
+global.bootm.image="/dev/nand0.root.ubi.kernel0"
+global.bootm.oftree="/dev/nand0.root.ubi.oftree0"
+global.linux.bootargs.dyn.root="root=ubi0:root0 ubi.mtd=root rootfstype=ubifs"
+
+
+
+

The second boot script has the same structure but uses the partitions containing +the second system. Machines with eMMC flash use similar boot scripts, albeit the +mounting and boot arguments look different.

+

Run the following commands to create the required bootchooser non-volatile +environment variables:

+
barebox$ nv bootchooser.state_prefix=state.bootstate
+barebox$ nv bootchooser.system0.boot=system0
+barebox$ nv bootchooser.system1.boot=system1
+barebox$ nv bootchooser.targets="system0 system1"
+
+
+
+
+
+

9.2. eMMC Boot Partitions

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader.

+

By default, bundles built with our BSP (e.g. phytec-headless-bundle) contain +the bootloader for updating eMMC boot partitions accordingly.

+

Note, that the U-Boot environment still resides in the user area before the +first partition. The user area also still contains the bootloader which the +image first shipped during its initialization process.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=imx-boot of=/dev/mmcblk2boot0 bs=1k seek=33
+target:~$ dd if=imx-boot of=/dev/mmcblk2boot1 bs=1k seek=33
+
+
+

This example is valid for the i.MX 8M Mini SoC. Note, that other SoCs may have +different bootloader files and require different offsets where the bootloader is +expected, specified by the seek parameter. See the following table for the +different offsets being required by each SoC:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

Bootloader

i.MX 6

1 kiB

0 kiB

/dev/mmcblk3

barebox.bin

i.MX 6UL

1 kiB

0 kiB

/dev/mmcblk1

barebox.bin

i.MX 8M

33 kiB

33 kiB

/dev/mmcblk0

imx-boot

i.MX 8M Mini

33 kiB

33 kiB

/dev/mmcblk2

imx-boot

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

i.MX 93

32 kiB

0 kiB

/dev/mmcblk0

imx-boot

AM62x +AM62Ax +AM64x

N/A

0 kiB +512 kiB +2560 kiB

/dev/mmcblk0

tiboot3.bin +tispl.bin +u-boot.img

+
+

9.2.1. Bootloader Offsets

+

Note that the offset is different, depending on whether the bootloader resides +in the user area or the boot partitions of the eMMC.

+

After a bootloader has been written to the eMMC boot partitions, booting from +these can be enabled by using the following command:

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

This also means that only the bootloaders written in the eMMC boot partitions +are used. The bootloader in the user area is not used anymore. These steps are +also executed by RAUC internally when updating the target system with a bundle.

+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

After this command, the eMMC user area is used to provide the bootloader.

+

When using U-Boot, a similar command is also available in the bootloader:

+
u-boot=> mmc partconf 2 0 0 0  # disable
+u-boot=> mmc partconf 2 0 1 0  # enable
+
+
+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/rauc/scarthgap.html b/previews/271/zh_CN/rauc/scarthgap.html new file mode 100644 index 000000000..3aee9f2d6 --- /dev/null +++ b/previews/271/zh_CN/rauc/scarthgap.html @@ -0,0 +1,1240 @@ + + + + + + + + + 1. Introduction — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+ +
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + +

RAUC Update & Device Management Manual

Document Title

RAUC Update & Device Management Manual Scarthgap

Document Type

RAUC Update & Device Management +Manual

Release Date

XXXX/XX/XX

Is Branch of

RAUC Update & Device Management Manual

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Compatible BSPs

BSP Release Type

BSP Release Date

BSP Status

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.0

Major

2024-04-02

released

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1

Minor

2024-04-09

released

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2

Minor

2024-06-26

released

BSP-Yocto-NXP-i.MX8MP-PD24.1.0

Major

2024-11-07

released

BSP-Yocto-NXP-i.MX93-PD24.2.0

Major

2024-10-08

released

BSP-Yocto-Ampliphy-i.MX6UL-PD24.1.0

Major

2024-07-19

released

BSP-Yocto-Ampliphy-AM62Ax-PD24.1.0

Major

2024-06-27

released

BSP-Yocto-Ampliphy-AM62x-PD24.1.0

Major

2024-06-27

released

BSP-Yocto-Ampliphy-AM64x-PD24.1.0

Major

2024-06-27

released

+

This manual was tested using the Yocto version Scarthgap.

+
+

1. Introduction

+

PHYTEC's Yocto distribution Ampliphy (former Yogurt) supports the RAUC (Robust Auto-Update Controller) +mechanism. RAUC controls the procedure of updating a device with new firmware. +This includes updating the Linux kernel, Device Tree, and root filesystem. For +eMMC devices only, it can also update the bootloader.

+

This manual describes how RAUC is used and implemented on various PHYTEC +platforms. Note, that different modules use different bootloaders and flash +storage devices, which affects the way things are handled by RAUC. Make sure to +read the correct sections fitting your platform.

+
+

备注

+

This manual contains machine-specific paths and variable contents. Make sure +you are using the correct machine and device names for your application when +executing any commands.

+
+
+
+

2. System Configuration

+

RAUC can be used with both eMMC and NAND flash storage. Using the distro +ampliphy-rauc or ampliphy-vendor-rauc, it is enabled by default and requires +no additional setup to get started. RAUC can be used in different update +scenarios. As an example, we configured the BSP to use an A/B setup to have a +completely redundant system (including the bootloader on eMMC devices). Note, +that there is an additional partition named config storing persistent +configuration data not being changed when updating.

+../_images/rauc-ab-system.png +
+

2.1. RAUC BSP Example Setup

+

The partition layout is defined in the /etc/rauc/system.conf file. As an +example, this is what it looks like for i.MX 8M Mini with eMMC flash storage:

+
+
/etc/rauc/system.conf
+
[system]
+compatible=phyboard-polis-imx8mm-4
+bootloader=uboot
+mountprefix=/mnt/rauc
+
+[handlers]
+pre-install=/usr/lib/rauc/rauc-pre-install.sh
+post-install=/usr/lib/rauc/rauc-post-install.sh
+
+[keyring]
+path=mainca-rsa.crt.pem
+
+[slot.bootloader.0]
+device=/dev/mmcblk2
+type=boot-emmc
+
+# System A
+[slot.rootfs.0]
+device=/dev/mmcblk2p5
+type=ext4
+bootname=system0
+
+[slot.boot.0]
+device=/dev/mmcblk2p1
+type=vfat
+parent=rootfs.0
+
+# System B
+[slot.rootfs.1]
+device=/dev/mmcblk2p6
+type=ext4
+bootname=system1
+
+[slot.boot.1]
+device=/dev/mmcblk2p2
+type=vfat
+parent=rootfs.1
+
+
+
+

Note, that the devices specified in the slots are different depending on the +selected machine.

+
+

警告

+

Updates with RAUC use an OpenSSL certificate to verify the validity of an +image. The BSP includes a certificate that can be used for development. In a +productive system, however, it is highly recommended to use a self-created +key and certificate. If you need to change the keyring on an existing device, +see Switching RAUC Keyrings for more +information.

+
+
+
+
+

3. Design Considerations

+

In order to prevent the system from locking up, it may be a good idea to utilize +a hardware watchdog. In case the Linux Kernel does not boot or another +catastrophic event occurs that prevents the system from operating normally, the +hardware watchdog then resets the system. By default, the hardware watchdog is +disabled. To enable it, refer to the corresponding BSP manual that fits your +SoM.

+

Other important design considerations, as well as a checklist, can be found in +the official RAUC documentation: +https://rauc.readthedocs.io/en/latest/checklist.html

+
+
+

4. Initial Setup

+

To use RAUC, the flash device needs to be written with a complete Linux system +and bootloader. The preferred method to do this is using the included tool +partup.

+
+

4.1. Flash Storage

+

To flash the device with the correct partitions/volumes, use a partup package +built with the ampliphy-rauc or ampliphy-vendor-rauc distribution. +Prebuilt partup packages can be found in the BSP release. It is also possible to +build an image with this distribution yourself using Yocto. Separate build +directories are created, storing the images and packages for the RAUC system. +Initialize the build directory with the OE init script:

+
host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source sources/poky/oe-init-build-env
+
+
+

Change the distribution to ampliphy-rauc (for i.MX6, AM6x, i.MX8 mainline BSP) or +ampliphy-vendor-rauc (for i.MX8, i.MX9 vendor BSP):

+
+
build/conf/local.conf
+
DISTRO ?= "ampliphy-rauc"
+
+
+
+

Any image built with this distro now includes a full A/B system. Build the image +as usual:

+
host:~$ bitbake phytec-headless-image
+
+
+

The resulting partup package is stored in the deploy-ampliphy-vendor-rauc directory, e.g.:

+
deploy-ampliphy-vendor-rauc/images/phyboard-segin-imx93-2/phytec-headless-image-phyboard-segin-imx93-2.partup
+
+
+

This partup package contains all the necessary data and configuration to flash +an eMMC. Partup can be obtained from its +release page. Also, see its +README for detailed installation instructions. Partup is already installed +in our Ampliphy images, phytec-headless-image and can be directly used e.g. +from an SD card.

+
+

备注

+

To flash the initial RAUC system, a booted non-RAUC system is needed first on +a different flash device. E.g. you could boot a regular +phytec-headless-image image with distro ampliphy from an SD card.

+
+
+

4.1.1. eMMC

+

While running a non-RAUC system from an SD card on the target, copy the +.partup package built with distro ampliphy-rauc or +ampliphy-vendor-rauc to the running target first:

+
host:~$ scp phytec-headless-image-phyboard-segin-imx93-2.partup 192.168.3.11:/root
+
+
+

Then install the partup package to the eMMC:

+
target:~$ partup install phytec-headless-image-phyboard-segin-imx93-2.partup /dev/mmcblk0
+
+
+

Now the target can boot the flashed A/B system.

+
+
+

4.1.2. NAND

+
+

备注

+

There are scripts provided with the bootloader barebox that previously were +used to initialize NAND flash with an A/B system: rauc_init_nand, +rauc_flash_nand_from_tftp and rauc_flash_nand_from_mmc. These scripts +are deprecated. It is advised to use the script rauc-flash-nand provided +in the Linux environment with PHYTEC's distribution Ampliphy.

+
+

With raw NAND flash the kernel, device tree, and root filesystem are written +individually. Initialize the NAND flash with the correct volumes from a Linux on +the target:

+
target:~$ rauc-flash-nand -k /path/to/zImage -d /path/to/oftree -r /path/to/root.ubifs
+
+
+

The initialization script will automatically utilize all available space of NAND +flash. The NAND device is also determined automatically by finding the device +root in /proc/mtd.

+

On i.MX6 and i.MX6UL devices with barebox, use bbu (barebox update) to flash the +bootloader:

+
target:~$ bbu.sh -f /path/to/barebox.bin
+
+
+

The A/B system on NAND Flash is now ready to be booted.

+
+
+
+

4.2. Bootloader

+
+

4.2.1. Booting the A/B System by Default

+

Booting the A/B system is done mostly automatically by the bootloader since the +Yocto release hardknott. For devices with eMMC flash storage, the +corresponding setting is written into the bootloader environment during the +building of the BSP. In particular, if the distribution ampliphy-rauc or +ampliphy-vendor-rauc is used, as described previously, the bootloader should +automatically start the A/B system and have the variables set for RAUC +accordingly.

+

This automatic setting can be manually changed by setting one variable in the +bootloader. The procedure is described in more detail in the following chapters +for U-Boot and barebox.

+
+
+

4.2.2. U-Boot

+

After a successful boot into a Linux environment, this command is used to view +the available parameters:

+
target:~$ fw_printenv
+
+
+

You may see this parameter along with others in the output:

+
doraucboot=1
+
+
+

To manually disable or enable booting the A/B system with RAUC, set this +variable to 0 or 1:

+
target:~$ fw_setenv doraucboot 1
+
+
+

This parameter can also be edited in U-Boot. Restart your board and hit any key +to stop the automatic boot. The environment variables can now be viewed:

+
u-boot=> printenv
+
+
+

and set:

+
u-boot=> setenv doraucboot 1
+u-boot=> saveenv
+
+
+
+
+

4.2.3. Barebox

+

In barebox, the system to be booted can be selected directly by its name. To +boot the A/B system, including RAUC, bootchooser is used. To boot e.g. a +regular SD card without RAUC use mmc instead, or nand for NAND devices:

+
barebox$ nv boot.default=bootchooser
+
+
+
+
+
+
+

5. Creating RAUC Bundles

+

To update your system with RAUC, a RAUC bundle (.raucb) needs to be created. +It contains all required images and scripts for the update and a RAUC +manifest.raucm that describes the content of the bundle for the RAUC update +on the target. The BSP includes a Yocto target that lets you build a RAUC bundle +from your Yocto build.

+

To create the bundle with Yocto, run the following in build/ with the +distribution ampliphy-rauc or ampliphy-vendor-rauc set up, as described +previously:

+
host:~$ bitbake phytec-headless-bundle
+
+
+

This results in the creation of a .raucb bundle file in +deploy/images/<MACHINE>/ which can be used for updating the system as +described later. There is no need to create a manifest.raucm manually as it +is created automatically during the build of the bundle. As a reference, the +created manifest would look something like this:

+
+
manifest.raucm
+
[update]
+compatible=phyboard-polis-imx8mm-3
+version=r0
+description=PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0
+build=20200624074335
+
+[image.rootfs]
+sha256=cc3f65cd1c1993951d7a39bdb7b7d723617ac46460f8b640cd8d1622ad6e4c17
+size=99942000
+filename=phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz
+
+[image.boot]
+sha256=bafe46679af8c6292dba22b9d402e3119ef78c6f8b458bcb6993326060de3aa4
+size=12410534
+filename=boot.tar.gz.img
+
+
+
+

For more information about the manifest format, see +https://rauc.readthedocs.io/en/latest/reference.html#manifest.

+
+

5.1. Creating transition bundles

+

Updating to a new major release can require a special RAUC bundle.

+

When updating to a Scarthgap based release, add the following to your +local.conf and rebuild the RAUC bundle:

+
+
build/conf/local.conf
+
RAUC_IMAGE_FSTYPE = "tar.gz"
+RAUC_SLOT_rootfs[adaptive] = ""
+
+
+
+
+
+
+

6. Updating with RAUC

+

To update the target system with RAUC, the RAUC bundle file previously created +first needs to be copied to the board or to a memory device that can be mounted +in Linux. One way is to copy the bundle file with scp, but this requires +enough space left on the board's filesystem. To do this, boot the target board +to Linux and connect it via Ethernet to your host PC.

+

On the host, run:

+
host:~$ scp phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb root@192.168.3.11:/tmp/
+
+
+

On the target, the bundle can be verified:

+
target:~$ rauc info /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+
+
+

and the output should look similar to this:

+
rauc-Message: 12:52:49.821: Reading bundle: /phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+rauc-Message: 12:52:49.830: Verifying bundle...
+Compatible:     'phyboard-polis-imx8mm-3'
+Version:        'r0'
+Description:    'PHYTEC rauc bundle based on BSP-Yocto-FSL-i.MX8MM-PD20.1.0'
+Build:          '20200624073212'
+Hooks:          ''
+2 Images:
+(1)     phytec-headless-image-phyboard-polis-imx8mm-3.tar.gz
+        Slotclass: rootfs
+        Checksum:  342f67f7678d7af3f77710e1b68979f638c7f4d20393f6ffd0c36beff2789070
+        Size:      180407809
+        Hooks:
+(2)     boot.tar.gz.img
+        Slotclass: boot
+        Checksum:  8c84465b4715cc142eca2785fea09804bd970755142c9ff57e08c791e2b71f28
+        Size:      12411786
+        Hooks:
+0 Files
+
+Certificate Chain:
+ 0 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH Development-1
+   Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   SPKI sha256: E2:47:5F:32:05:37:04:D4:8C:48:8D:A6:74:A8:21:2E:97:41:EE:88:74:B5:F4:65:75:97:76:1D:FF:1D:7B:EE
+   Not Before: Jan  1 00:00:00 1970 GMT
+   Not After:  Dec 31 23:59:59 9999 GMT
+ 1 Subject: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   Issuer: /O=PHYTEC Messtechnik GmbH/CN=PHYTEC Messtechnik GmbH PHYTEC BSP CA Development
+   SPKI sha256: AB:5C:DB:C6:0A:ED:A4:48:B9:40:AC:B1:48:06:AA:BA:92:09:83:8C:DC:6F:E1:5F:B6:FB:0C:39:3C:3B:E6:A2
+   Not Before: Jan  1 00:00:00 1970 GMT
+   Not After:  Dec 31 23:59:59 9999 GMT
+
+
+

To check the current state of the system, run:

+
target:~$ rauc status
+
+
+

and get output similar to this:

+
=== System Info ===
+Compatible:  phyboard-segin-imx6ul-6
+Variant:
+Booted from: rootfs.0 (system0)
+
+=== Bootloader ===
+Activated: rootfs.0 (system0)
+
+=== Slot States ===
+o [rootfs.1] (/dev/ubi0_6, ubifs, inactive)
+        bootname: system1
+        boot status: good
+    [dtb.1] (/dev/ubi0_3, ubivol, inactive)
+    [kernel.1] (/dev/ubi0_2, ubivol, inactive)
+
+x [rootfs.0] (/dev/ubi0_5, ubifs, booted)
+        bootname: system0
+        boot status: good
+    [kernel.0] (/dev/ubi0_0, ubivol, active)
+    [dtb.0] (/dev/ubi0_1, ubivol, active)
+
+
+

To update the currently inactive system with the downloaded bundle, run:

+
target:~$ rauc install /tmp/phytec-headless-bundle-phyboard-polis-imx8mm-3.raucb
+
+
+

and reboot afterward:

+
target:~$ reboot
+
+
+

With the success of the update, RAUC automatically switches the active system to +the newly updated system. Now during reboot, RAUC counts the boot attempts of +the kernel and if it fails more often than specified in the state framework of +the system, RAUC switches back to the old system and marks the new system as +bad. If the boot attempt to the kernel is successful, the new system is marked +as good and the old system can now be updated with the same instructions. After +two successful rauc install and reboot, both systems are updated.

+
+

小技巧

+

When you update from a USB stick, make sure to remove the stick after a +successful update before rebooting. If not, an automatic update will be +started after each boot. This is due to the Automatic Update from USB Flash +Drive with RAUC you can find below.

+
+
+

6.1. Changing the Active Boot Slot

+

It is possible to switch the active system manually:

+
target:~$ rauc status mark-active other
+
+
+

After a reboot, the target now starts from the other system.

+
+
+
+

7. Switching RAUC Keyrings

+

PHYTEC's distribution comes with keys and certificates used for development and +demonstration purposes only. To change to a different PKI when devices are +already rolled out, RAUC's keyring must be changed. This chapter describes the +full procedure from a development state to a production state. Keep in mind, +that it is always a better idea to roll out your devices with a production +keyring in the first place, instead of relying on a development one for too +long. The following diagram shows the general process of switching keyrings for +RAUC:

+../_images/rauc-switching-keyrings.png +
+

7.1. Keyring Switching Process

+

Create new certificates and keys for your own PKI. See our security manual for a +detailed description on how to create a custom PKI. For this document, we refer +to this newly created PKI as "production", as opposed to the existing +"development" keys.

+

Move the generated keys and certificates, to your main Yocto build directory +root, alongside with build/ and sources/.

+
+

警告

+

Be careful where you store the private keys! These should in no way be made +publicly available. E.g. do not store the private keys in a public Git +repository. Otherwise, unauthorized entities could create RAUC bundles that +can be installed on your target system!

+
+

Now, a RAUC bundle must be created that contains the new "production" CA keyring +in its root filesystem but is still signed by the "development" CA. With this, +the system is converted from a "development" system to a "production" system. To +achieve this, exchange the file ca.cert.pem installed by the RAUC recipe in +the Yocto sources. Create a file rauc_%.bbappend in your own Yocto layer:

+
+
recipes-core/rauc/rauc_%.bbappend
+
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+RAUC_KEYRING_FILE = "${CERT_PATH}/rauc-customer/ca.cert.pem"
+
+
+
+

Build the same RAUC bundle as before, now with the exchanged keyring:

+
host:~$ TEMPLATECONF=../meta-phytec/conf/templates/default source source/poky/oe-init-build-env
+host:~$ bitbake phytec-headless-bundle  # Build the desired RAUC bundle
+
+
+

Install the resulting RAUC bundle as usual. The target now has the image with +the "production" keyring installed in its other slot ("System B" in the figure +above). Reboot to start that system.

+

All future RAUC bundles for the "production" system must now also be signed by +the "production" CA. For this, change the key and certificate to your newly +generated "production" ones in the bundle recipe:

+
+
recipes-images/bundles/customer-headless-bundle.bb
+
require phytec-base-bundle.inc
+
+RAUC_SLOT_rootfs ?= "phytec-headless-image"
+
+RAUC_KEY_FILE = "${CERT_PATH}/rauc-customer/private/production-1.key.pem"
+RAUC_CERT_FILE = "${CERT_PATH/rauc-customer/production-1.cert.pem"
+
+RAUC_INTERMEDIATE_CERT_FILE = ""
+
+
+
+

Rebuild the RAUC bundle:

+
host:~$ bitbake customer-headless-bundle
+
+
+

These and any future bundles are now ready to be installed on your "production" +target system and have been fully migrated away from the "development" system. +This also means that now only bundles signed by the "production" CA can be +installed on the target (and e.g. "development" bundles cannot).

+
+
+
+

8. Use Case Examples

+
+

8.1. Automatic Updates from USB Flash Drive with RAUC

+

One of the most prominent use cases for RAUC might be an automatic update system +from a USB flash drive. This use case is implemented in the BSP as a reference +example. We combine only standard Linux mechanisms with RAUC to build the +system. The kernel notifies udev when a device gets plugged into the USB port. +We use a custom udev rule to trigger a systemd service when this event +happens.

+
+
10-update-usb.rules
+
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"
+
+# Trigger systemd service
+ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}="update-usb@%k.service"
+
+# Exit
+LABEL="media_by_label_auto_mount_end"
+
+
+
+

The service automatically mounts the USB flash drive and notifies the +application.

+
+
update-usb@.service
+
[Unit]
+Description=usb media RAUC service
+After=multi-user.target
+Requires=rauc.service
+
+[Service]
+Type=oneshot
+Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket
+ExecStartPre=/bin/mkdir -p /media/%I
+ExecStartPre=/bin/mount -t auto /dev/%I /media/%I
+ExecStart=/usr/bin/update_usb.sh %I
+ExecStop=/bin/umount -l /media/%i
+ExecStopPost=-/bin/rmdir /media/%I
+
+
+
+

In our reference implementation, we simply use a shell script for the +application logic.

+
+
update_usb.sh
+
#!/bin/sh
+
+MOUNT=/media/$1
+
+NUMRAUCM=$(find ${MOUNT}/*.raucb -maxdepth 0 | wc -l)
+
+[ "$NUMRAUCM" -eq 0 ] && echo "${MOUNT}*.raucb not found" && exit
+[ "$NUMRAUCM" -ne 1 ] && echo "more than one ${MOUNT}/*.raucb" && exit
+
+rauc install $MOUNT/*.raucb
+if [ "$?" -ne 0 ]; then
+    echo "Failed to install RAUC bundle."
+else
+    echo "Update successful."
+fi
+exit $?
+
+
+
+

The update logic can be integrated into an application using the systemd D-Bus +API. RAUC does not need to be called by its command-line interface but can be +integrated with D-Bus.

+
+

小技巧

+

RAUC features a D-Bus API interface (see +https://rauc.readthedocs.io/en/latest/using.html#using-the-d-bus-api).

+
+
+
+

8.2. Security Measurement: Downgrade Barrier

+

As a second reference example, we will implement a security mechanism: a +downgrade barrier. When you detect a security vulnerability on your system, you +will fix it and update your system. The systems with the new software will now +be secure again. If an attacker gets a hold of the old software update bundle, +which still has a valid signature, the attacker might have the possibility to +install the old software and still take advantage of the previously fixed +security vulnerability. To prevent this from happening, you could revoke the +updated certificate for every single update and create a new one. This might be +difficult to handle, depending on the environment. A simpler solution would be +to allow updates only in one direction using a version check.

+
+
rauc_downgrade_barrier.sh
+
#!/bin/sh
+
+VERSION_FILE=/etc/rauc/downgrade_barrier_version
+MANIFEST_FILE=${RAUC_UPDATE_SOURCE}/manifest.raucm
+
+[ ! -f ${VERSION_FILE} ] && exit 1
+[ ! -f ${MANIFEST_FILE} ] && exit 2
+
+VERSION=`cat ${VERSION_FILE} | cut -d 'r' -f 2`
+BUNDLE_VERSION=`grep "version" -rI ${MANIFEST_FILE} | cut -d 'r' -f 3`
+
+# check from empty or unset variables
+[ -z "${VERSION}" ] && exit 3
+[ -z "${BUNDLE_VERSION}" ] && exit 4
+
+# developer mode, allow all updates if version is r0
+#[ ${VERSION} -eq 0 ] && exit 0
+
+# downgrade barrier
+if [ ${VERSION} -gt ${BUNDLE_VERSION} ]; then
+        echo "Downgrade barrier blocked rauc update! CODE5\n"
+else
+        exit 0
+fi
+exit 5
+
+
+
+

The script is installed on the target but it is not activated. You need to +remove the developer mode line in the script to activate it.

+
+
+

8.3. Streaming Bundles over HTTP

+

Instead of copying the bundle to the device, the bundle can be streamed over +HTTP. Using bundle streaming has the advantage of not requiring local storage on +the target. A simple approach to this is running NGINX inside a Docker +container. The following example shows how to implement a minimal download +server enabling HTTP range requests to support this feature.

+

Create a Dockerfile with the following content:

+
+
Dockerfile
+
FROM nginx
+
+COPY bundles /bundles
+COPY nginx.conf /etc/nginx/nginx.conf
+
+
+
+

Configure NGINX to enable HTTP range requests and point it to the bundle file.

+
+
nginx.conf
+
events {}
+http {
+    server {
+        proxy_force_ranges on;
+
+        location / {
+            root /bundles;
+        }
+    }
+}
+
+
+
+

Place a bundle in the bundles sub-directory. The folder structure looks like +the following after creating all configuration files:

+
user@host:rauc-bundle-streaming$ find
+.
+./bundles
+./bundles/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb
+./nginx.conf
+./Dockerfile
+
+
+

Build and run the docker container on the host system:

+
host:~$ sudo docker build -t rauc-bundle-streaming .
+host:~$ sudo docker run --name bundles -p 80:80 -d rauc-bundle-streaming
+
+
+

Install the bundle on the currently inactive target partitions:

+
target:~$ rauc install http://192.168.3.10/phytec-headless-bundle-phyboard-polis-imx8mn-1.raucb
+
+
+
+

备注

+

After the update finishes the target may display the following error which +has no impact on the success of the update:

+
[ 7416.336609] block nbd0: NBD_DISCONNECT
+[ 7416.340413] block nbd0: Send disconnect failed -32
+
+
+
+
+
+
+

9. Reference

+
+

9.1. Boot Logic Implementation

+
+

小技巧

+

The implementation details described in this chapter serve as a reference +guide. PHYTEC BSPs that have RAUC support include these by default and the +changes are already incorporated.

+
+
+

9.1.1. U-Boot Environment Variables

+

For U-Boot, the boot logic that selects the correct partitions to boot from is +implemented in its environment. As a reference, these are the most important +U-Boot variables that are used for the A/B system with RAUC:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

Function

BOOT_ORDER

Contains a space-separated list of boot targets in the +order they should be tried. This parameter is +automatically set by RAUC.

BOOT_<slot>_LEFT

Contains the number of remaining boot attempts to +perform for the respective slot. This parameter is +automatically set by RAUC.

raucinit

Contains the boot logic that sets the partitions so +the correct system is loaded.

doraucboot

Enables booting the A/B system if set to 1 and +disables it if set to 0.

raucargs

Sets the Kernel bootargs like console, root, and RAUC +slot.

raucrootpart

Sets the root filesystem partitions of the device.

raucbootpart

Sets the boot partitions of the device.

+

These environment variables are defined in include/env/phytec/rauc.env in +the u-boot source code.

+
+

备注

+

A change in the partition layout, e.g. when using an additional data +partition, may require changing the variables raucrootpart and +raucbootpart. Make sure to rebuild your image with the new bootloader +environment after you have made the appropriate changes.

+
+
+
+

9.1.2. Barebox Bootchooser Framework

+

For the barebox, the boot logic that selects the correct partitions to boot from +is implemented using the bootchooser and state framework. See the barebox +documentation for detailed information about these: Barebox Bootchooser +Framework, Barebox +State Framework.

+

First, the state framework configuration needs to be added to the barebox device +tree. Check out the Customizing the BSP +chapter in the Yocto reference manual. The state framework configuration is +already included with our BSP for the supported SoC and can be directly included +in the main barebox device tree. E.g. for i.MX6 based module:

+
#include "imx6qdl-phytec-state.dtsi"
+
+
+

Afterward, rebuild the image and flash the new bootloader.

+
+

警告

+

Be aware that by adding the state framework configuration, the first 160 +bytes of the EEPROM are occupied and can no longer be used for user-specific +purposes.

+
+

The following device tree snippet shows an example of the state framework +configuration used with the BSP. As can be seen, the EEPROM is used as a backend +for the state information:

+
/ {
+    aliases {
+        state = &state;
+    };
+
+    state: imx6qdl_phytec_boot_state {
+        magic = <0x883b86a6>;
+        compatible = "barebox,state";
+        backend-type = "raw";
+        backend = <&backend_update_eeprom>;
+        backend-stridesize = <54>;
+
+        #address-cells = <1>;
+        #size-cells = <1>;
+        bootstate {
+            #address-cells = <1>;
+            #size-cells = <1>;
+            last_chosen {
+                reg = <0x0 0x4>;
+                type = "uint32";
+            };
+            system0 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                remaining_attempts {
+                    reg = <0x4 0x4>;
+                    type = "uint32";
+                    default = <3>;
+                };
+                priority {
+                    reg = <0x8 0x4>;
+                    type = "uint32";
+                    default = <21>;
+                };
+                ok {
+                    reg = <0xc 0x4>;
+                    type = "uint32";
+                    default = <0>;
+                };
+            };
+            system1 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                remaining_attempts {
+                    reg = <0x10 0x4>;
+                    type = "uint32";
+                    default = <3>;
+                };
+                priority {
+                    reg = <0x14 0x4>;
+                    type = "uint32";
+                    default = <20>;
+                };
+                ok {
+                    reg = <0x18 0x4>;
+                    type = "uint32";
+                    default = <0>;
+                };
+            };
+        };
+    };
+};
+
+&eeprom {
+    status = "okay";
+    partitions {
+        compatible = "fixed-partitions";
+        #size-cells = <1>;
+        #address-cells = <1>;
+        backend_update_eeprom: state@0 {
+            reg = <0x0 0x100>;
+            label = "update-eeprom";
+        };
+    };
+};
+
+
+

To be able to boot from two systems alternately, the bootchooser needs to be +aware of the state framework configuration. For each system, a boot script is +required. For a system with NAND flash, the boot script of the first system may +look like the following:

+
+
/env/boot/system0
+
#!/bin/sh
+
+[ -e /env/config-expansions ] && /env/config-expansions
+
+[ ! -e /dev/nand0.root.ubi ] && ubiattach /dev/nand0.root
+
+global.bootm.image="/dev/nand0.root.ubi.kernel0"
+global.bootm.oftree="/dev/nand0.root.ubi.oftree0"
+global.linux.bootargs.dyn.root="root=ubi0:root0 ubi.mtd=root rootfstype=ubifs"
+
+
+
+

The second boot script has the same structure but uses the partitions containing +the second system. Machines with eMMC flash use similar boot scripts, albeit the +mounting and boot arguments look different.

+

Run the following commands to create the required bootchooser non-volatile +environment variables:

+
barebox$ nv bootchooser.state_prefix=state.bootstate
+barebox$ nv bootchooser.system0.boot=system0
+barebox$ nv bootchooser.system1.boot=system1
+barebox$ nv bootchooser.targets="system0 system1"
+
+
+
+
+
+

9.2. eMMC Boot Partitions

+

With eMMC flash storage it is possible to use the dedicated boot partitions for +redundantly storing the bootloader.

+

By default, bundles built with our BSP (e.g. phytec-headless-bundle) contain +the bootloader for updating eMMC boot partitions accordingly.

+

Note, that the U-Boot environment still resides in the user area before the +first partition. The user area also still contains the bootloader which the +image first shipped during its initialization process.

+

To manually write the bootloader to the eMMC boot partitions, first disable the +write protection:

+
target:~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
+target:~$ echo 0 > /sys/block/mmcblk2boot1/force_ro
+
+
+

Write the bootloader to the eMMC boot partitions:

+
target:~$ dd if=imx-boot of=/dev/mmcblk2boot0 bs=1k seek=33
+target:~$ dd if=imx-boot of=/dev/mmcblk2boot1 bs=1k seek=33
+
+
+

This example is valid for the i.MX 8M Mini SoC. Note, that other SoCs may have +different bootloader files and require different offsets where the bootloader is +expected, specified by the seek parameter. See the following table for the +different offsets being required by each SoC:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

SoC

Offset User Area

Offset Boot Partition

eMMC Device

Bootloader

i.MX 6

1 kiB

0 kiB

/dev/mmcblk3

barebox.bin

i.MX 6UL

1 kiB

0 kiB

/dev/mmcblk1

barebox.bin

i.MX 8M

33 kiB

33 kiB

/dev/mmcblk0

imx-boot

i.MX 8M Mini

33 kiB

33 kiB

/dev/mmcblk2

imx-boot

i.MX 8M Nano

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

i.MX 8M Plus

32 kiB

0 kiB

/dev/mmcblk2

imx-boot

i.MX 93

32 kiB

0 kiB

/dev/mmcblk0

imx-boot

AM62x +AM62Ax +AM64x

N/A

0 kiB +512 kiB +2560 kiB

/dev/mmcblk0

tiboot3.bin +tispl.bin +u-boot.img

+
+

9.2.1. Bootloader Offsets

+

Note that the offset is different, depending on whether the bootloader resides +in the user area or the boot partitions of the eMMC.

+

After a bootloader has been written to the eMMC boot partitions, booting from +these can be enabled by using the following command:

+
target:~$ mmc bootpart enable 1 0 /dev/mmcblk2
+
+
+

This also means that only the bootloaders written in the eMMC boot partitions +are used. The bootloader in the user area is not used anymore. These steps are +also executed by RAUC internally when updating the target system with a bundle.

+

To disable booting from the eMMC boot partitions simply enter the following +command:

+
target:~$ mmc bootpart enable 0 0 /dev/mmcblk2
+
+
+

After this command, the eMMC user area is used to provide the bootloader.

+

When using U-Boot, a similar command is also available in the bootloader:

+
u-boot=> mmc partconf 2 0 0 0  # disable
+u-boot=> mmc partconf 2 0 1 0  # enable
+
+
+
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/robots.txt b/previews/271/zh_CN/robots.txt new file mode 100644 index 000000000..ea27bb96d --- /dev/null +++ b/previews/271/zh_CN/robots.txt @@ -0,0 +1,3 @@ +User-agent: * + +Sitemap: https://phytec.github.io/doc-bsp-yocto/sitemap.xml diff --git a/previews/271/zh_CN/search.html b/previews/271/zh_CN/search.html new file mode 100644 index 000000000..13b4966ee --- /dev/null +++ b/previews/271/zh_CN/search.html @@ -0,0 +1,153 @@ + + + + + + + + 搜索 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+
    +
    • +
  • 搜索
    • +
  • +
    • +
+
+
+
+
+ + + + +
+ +
+ +
+
+
+ +
+ +
+

© 版权所有 2024, PHYTEC Messtechnik GmbH。

+
+ + + +
+
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + + + + + + \ No newline at end of file diff --git a/previews/271/zh_CN/searchindex.js b/previews/271/zh_CN/searchindex.js new file mode 100644 index 000000000..93a93dc52 --- /dev/null +++ b/previews/271/zh_CN/searchindex.js @@ -0,0 +1 @@ +Search.setIndex({"alltitles": {"ADC": [[23, "adc"], [24, "adc"]], "ALSA\u914d\u7f6e": [[1, "alsa-configuration"], [3, "alsa-configuration"], [4, "alsa-configuration"], [9, "alsa-configuration"], [11, "alsa-configuration"], [14, "alsa-configuration"], [15, "alsa-configuration"], [16, "alsa-configuration"], [17, "alsa-configuration"], [23, "alsa-configuration"], [24, "alsa-configuration"]], "Alsamixer": [[1, "alsamixer"], [3, "alsamixer"], [4, "alsamixer"], [9, "alsamixer"], [11, "alsamixer"], [14, "alsamixer"], [15, "alsamixer"], [16, "alsamixer"], [17, "alsamixer"], [22, "alsamixer"], [23, "alsamixer"], [23, "id3"], [24, "alsamixer"], [24, "id3"]], "Audio on phyBOARD-Nash i.MX 93": [[24, "audio-on-sbc-nash"]], "Audio on phyBOARD-Segin i.MX 93": [[24, "audio-on-sbc-segin"]], "Automatic Updates from USB Flash Drive with RAUC": [[27, "automatic-updates-from-usb-flash-drive-with-rauc"], [29, "automatic-updates-from-usb-flash-drive-with-rauc"], [30, "automatic-updates-from-usb-flash-drive-with-rauc"]], "BSP Workspace\u5b89\u88c5": [[31, "bsp-workspace-installation"], [33, "bsp-workspace-installation"], [34, "bsp-workspace-installation"]], "BSP \u4ee3\u7801\u6e90": [[31, "bsp-content"], [33, "bsp-content"], [34, "bsp-content"]], "BSP \u5143\u6570\u636e": [[31, "bsp-metadata"], [33, "bsp-metadata"], [34, "bsp-metadata"]], "BSP \u5305\u7ba1\u7406": [[31, "bsp-management"], [33, "bsp-management"], [34, "bsp-management"]], "BSP \u6846\u67b6": [[31, "bsp-structure"], [33, "bsp-structure"], [34, "bsp-structure"]], "BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1": [[12, "bsp-yocto-ampliphy-i-mx8mp-pd24-1-1"]], "BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2": [[12, "bsp-yocto-ampliphy-i-mx8mp-pd24-1-2"]], "BSP-Yocto-NXP-i.MX8MM-PD22.1.1": [[2, "bsp-yocto-nxp-i-mx8mm-pd22-1-1"], [6, "bsp-yocto-nxp-i-mx8mm-pd22-1-1"]], "BSP-Yocto-NXP-i.MX8MM-PD23.1.0": [[2, "bsp-yocto-nxp-i-mx8mm-pd23-1-0"], [6, "bsp-yocto-nxp-i-mx8mm-pd23-1-0"]], "BSP-Yocto-NXP-i.MX8MP-PD22.1.1": [[12, "bsp-yocto-nxp-i-mx8mp-pd22-1-1"]], "BSP-Yocto-NXP-i.MX8MP-PD22.1.2": [[12, "bsp-yocto-nxp-i-mx8mp-pd22-1-2"]], "BSP-Yocto-NXP-i.MX8MP-PD23.1.0": [[12, "bsp-yocto-nxp-i-mx8mp-pd23-1-0"]], "BSP-Yocto-NXP-i.MX8MP-PD24.1.0": [[12, "bsp-yocto-nxp-i-mx8mp-pd24-1-0"]], "BSP-Yocto-NXP-i.MX93-PD24.1.0": [[21, "bsp-yocto-nxp-i-mx93-pd24-1-0"]], "BSP-Yocto-NXP-i.MX93-PD24.1.1": [[21, "bsp-yocto-nxp-i-mx93-pd24-1-1"]], "BSP-Yocto-NXP-i.MX93-PD24.2.0": [[21, "bsp-yocto-nxp-i-mx93-pd24-2-0"]], "BSP\u6269\u5c55": [[1, "bsp-extensions"], [3, "bsp-extensions"], [4, "bsp-extensions"], [7, "bsp-extensions"], [14, "bsp-extensions"], [15, "bsp-extensions"], [16, "bsp-extensions"]], "BSP\u955c\u50cf": [[1, "bsp-images"], [3, "bsp-images"], [4, "bsp-images"], [5, "bsp-images"], [7, "bsp-images"], [8, "bsp-images"], [9, "bsp-images"], [11, "bsp-images"], [13, "bsp-images"], [14, "bsp-images"], [15, "bsp-images"], [16, "bsp-images"], [17, "bsp-images"], [18, "bsp-images"], [19, "bsp-images"], [22, "bsp-images"], [23, "bsp-images"], [24, "bsp-images"]], "Barebox": [[27, "barebox"], [29, "barebox"], [30, "barebox"]], "Barebox Bootchooser Framework": [[27, "barebox-bootchooser-framework"], [29, "barebox-bootchooser-framework"], [30, "barebox-bootchooser-framework"]], "Bitbake": [[31, "bitbake"], [33, "bitbake"], [34, "bitbake"]], "Boot Logic Implementation": [[27, "boot-logic-implementation"], [29, "boot-logic-implementation"], [30, "boot-logic-implementation"]], "Booting the A/B System by Default": [[27, "booting-the-a-b-system-by-default"], [29, "booting-the-a-b-system-by-default"], [30, "booting-the-a-b-system-by-default"]], "Bootloader": [[27, "bootloader"], [29, "bootloader"], [30, "bootloader"]], "Bootloader Offsets": [[27, "bootloader-offsets"], [29, "bootloader-offsets"], [30, "bootloader-offsets"]], "Buildinfo": [[31, "buildinfo"], [33, "buildinfo"], [34, "buildinfo"]], "CAN FD": [[1, "can-fd"], [3, "can-fd"], [4, "can-fd"], [5, "can-fd"], [7, "can-fd"], [8, "can-fd"], [9, "can-fd"], [11, "can-fd"], [13, "can-fd"], [14, "can-fd"], [15, "can-fd"], [16, "can-fd"], [17, "can-fd"], [18, "can-fd"], [19, "can-fd"], [22, "can-fd"], [23, "can-fd"], [24, "can-fd"]], "CPU\u6838\u5fc3\u7ba1\u7406": [[1, "cpu-core-management"], [3, "cpu-core-management"], [4, "cpu-core-management"], [5, "cpu-core-management"], [7, "cpu-core-management"], [8, "cpu-core-management"], [9, "cpu-core-management"], [11, "cpu-core-management"], [13, "cpu-core-management"], [14, "cpu-core-management"], [15, "cpu-core-management"], [16, "cpu-core-management"], [17, "cpu-core-management"], [18, "cpu-core-management"], [19, "cpu-core-management"], [22, "cpu-core-management"], [23, "cpu-core-management"], [24, "cpu-core-management"]], "CPU\u6838\u5fc3\u9891\u7387\u8c03\u8282": [[1, "cpu-core-frequency-scaling"], [3, "cpu-core-frequency-scaling"], [4, "cpu-core-frequency-scaling"], [5, "cpu-core-frequency-scaling"], [7, "cpu-core-frequency-scaling"], [8, "cpu-core-frequency-scaling"], [9, "cpu-core-frequency-scaling"], [11, "cpu-core-frequency-scaling"], [13, "cpu-core-frequency-scaling"], [14, "cpu-core-frequency-scaling"], [15, "cpu-core-frequency-scaling"], [16, "cpu-core-frequency-scaling"], [17, "cpu-core-frequency-scaling"], [18, "cpu-core-frequency-scaling"], [19, "cpu-core-frequency-scaling"], [22, "cpu-core-frequency-scaling"], [23, "cpu-core-frequency-scaling"], [24, "cpu-core-frequency-scaling"]], "Changes in U-Boot environment": [[1, "changes-in-u-boot-environment"], [9, "changes-in-u-boot-environment"], [11, "changes-in-u-boot-environment"], [17, "changes-in-u-boot-environment"]], "Changes in Yocto": [[1, "changes-in-yocto"], [9, "changes-in-yocto"], [11, "changes-in-yocto"], [17, "changes-in-yocto"]], "Changing the Active Boot Slot": [[27, "changing-the-active-boot-slot"], [29, "changing-the-active-boot-slot"], [30, "changing-the-active-boot-slot"]], "Chromium": [[1, "chromium"], [3, "chromium"], [4, "chromium"], [7, "chromium"], [14, "chromium"], [15, "chromium"], [16, "chromium"]], "Create your own layer": [[31, "create-your-own-layer"], [33, "create-your-own-layer"], [34, "create-your-own-layer"]], "Creating RAUC Bundles": [[27, "creating-rauc-bundles"], [29, "creating-rauc-bundles"], [30, "creating-rauc-bundles"]], "Creating transition bundles": [[30, "creating-transition-bundles"]], "DHCP\u670d\u52a1\u5668\u8bbe\u7f6e": [[1, "dhcp-server-setup"], [3, "dhcp-server-setup"], [4, "dhcp-server-setup"], [5, "dhcp-server-setup"], [7, "dhcp-server-setup"], [8, "dhcp-server-setup"], [9, "dhcp-server-setup"], [11, "dhcp-server-setup"], [13, "dhcp-server-setup"], [14, "dhcp-server-setup"], [15, "dhcp-server-setup"], [16, "dhcp-server-setup"], [17, "dhcp-server-setup"], [18, "dhcp-server-setup"], [19, "dhcp-server-setup"], [22, "dhcp-server-setup"], [23, "dhcp-server-setup"], [24, "dhcp-server-setup"]], "Design Considerations": [[27, "design-considerations"], [29, "design-considerations"], [30, "design-considerations"]], "Disable booting with efi": [[1, "disable-booting-with-efi"], [9, "disable-booting-with-efi"], [11, "disable-booting-with-efi"], [17, "disable-booting-with-efi"]], "EEPROM": [[1, "eeprom"], [3, "eeprom"], [4, "eeprom"], [5, "eeprom"], [7, "eeprom"], [8, "eeprom"], [9, "eeprom"], [11, "eeprom"], [13, "eeprom"], [14, "eeprom"], [15, "eeprom"], [16, "eeprom"], [17, "eeprom"], [18, "eeprom"], [19, "eeprom"], [22, "eeprom"], [23, "eeprom"], [24, "eeprom"]], "EEPROM SoM \u68c0\u6d4b": [[1, "eeprom-som-detection"], [3, "eeprom-som-detection"], [4, "eeprom-som-detection"], [5, "eeprom-som-detection"], [7, "eeprom-som-detection"], [8, "eeprom-som-detection"], [9, "eeprom-som-detection"], [11, "eeprom-som-detection"], [13, "eeprom-som-detection"], [14, "eeprom-som-detection"], [15, "eeprom-som-detection"], [16, "eeprom-som-detection"], [17, "eeprom-som-detection"], [18, "eeprom-som-detection"], [19, "eeprom-som-detection"], [22, "eeprom-som-detection"], [23, "eeprom-som-detection"], [24, "eeprom-som-detection"]], "EFI Boot": [[1, "efi-boot"], [9, "efi-boot"], [11, "efi-boot"], [17, "efi-boot"]], "Flash Storage": [[27, "flash-storage"], [29, "flash-storage"], [30, "flash-storage"]], "Framebuffer \u63a7\u5236\u53f0": [[31, "framebuffer-console"], [33, "framebuffer-console"], [34, "framebuffer-console"]], "GPIOs": [[1, "gpios"], [3, "gpios"], [4, "gpios"], [5, "gpios"], [7, "gpios"], [8, "gpios"], [9, "gpios"], [11, "gpios"], [13, "gpios"], [14, "gpios"], [15, "gpios"], [16, "gpios"], [17, "gpios"], [18, "gpios"], [19, "gpios"], [22, "gpios"], [23, "gpios"], [24, "gpios"]], "GPIO\u98ce\u6247": [[1, "gpio-fan"], [3, "gpio-fan"], [4, "gpio-fan"], [5, "gpio-fan"], [7, "gpio-fan"], [8, "gpio-fan"], [9, "gpio-fan"], [11, "gpio-fan"], [14, "gpio-fan"], [15, "gpio-fan"], [16, "gpio-fan"], [17, "gpio-fan"]], "Git \u4ed3\u5e93": [[1, "git-repositories"], [3, "git-repositories"], [4, "git-repositories"], [5, "git-repositories"], [7, "git-repositories"], [8, "git-repositories"], [9, "git-repositories"], [11, "git-repositories"], [13, "git-repositories"], [14, "git-repositories"], [15, "git-repositories"], [16, "git-repositories"], [17, "git-repositories"], [18, "git-repositories"], [19, "git-repositories"], [22, "git-repositories"], [23, "git-repositories"], [24, "git-repositories"]], "Git \u914d\u7f6e": [[31, "git-configuration"], [33, "git-configuration"], [34, "git-configuration"]], "Gparted": [[1, "gparted"], [3, "gparted"], [4, "gparted"], [5, "gparted"], [7, "gparted"], [8, "gparted"], [9, "gparted"], [11, "gparted"], [13, "gparted"], [14, "gparted"], [15, "gparted"], [16, "gparted"], [17, "gparted"], [18, "gparted"], [19, "gparted"], [22, "gparted"], [23, "gparted"], [24, "gparted"]], "HEAD": [[2, "head"], [6, "head"], [10, "head"], [12, "head"]], "ISP": [[9, "isp"], [11, "isp"], [14, "isp"], [15, "isp"], [16, "isp"], [17, "isp"]], "Images": [[31, "images"], [33, "images"], [34, "images"]], "Initial Setup": [[27, "initial-setup"], [29, "initial-setup"], [30, "initial-setup"]], "Installing a distro": [[1, "installing-a-distro"], [9, "installing-a-distro"], [11, "installing-a-distro"], [17, "installing-a-distro"]], "Introduction": [[27, null], [29, null], [30, null]], "I\u00b2C\u603b\u7ebf": [[1, "i2c-bus"], [3, "i2c-bus"], [4, "i2c-bus"], [5, "i2c-bus"], [7, "i2c-bus"], [8, "i2c-bus"], [9, "i2c-bus"], [11, "i2c-bus"], [13, "i2c-bus"], [14, "i2c-bus"], [15, "i2c-bus"], [16, "i2c-bus"], [17, "i2c-bus"], [18, "i2c-bus"], [19, "i2c-bus"], [22, "i2c-bus"], [23, "i2c-bus"], [24, "i2c-bus"]], "Kernel\u548cBootloader\u914d\u7f6e": [[31, "kernel-and-bootloader-configuration"], [33, "kernel-and-bootloader-configuration"], [34, "kernel-and-bootloader-configuration"]], "Keyring Switching Process": [[27, "keyring-switching-process"], [29, "keyring-switching-process"], [30, "keyring-switching-process"]], "Kirkstone": [[28, "kirkstone"], [32, "kirkstone"]], "LED\u706f": [[1, "leds"], [3, "leds"], [4, "leds"], [5, "leds"], [7, "leds"], [8, "leds"], [9, "leds"], [11, "leds"], [13, "leds"], [14, "leds"], [15, "leds"], [16, "leds"], [17, "leds"], [18, "leds"], [19, "leds"], [22, "leds"], [23, "leds"], [24, "leds"]], "Layers": [[31, "layers"], [33, "layers"], [34, "layers"]], "Libra i.MX 8M Plus FPSC Manuals": [[10, null]], "Libra \u5668\u4ef6": [[9, "sbc-components"]], "Linux\u4e3b\u673a\u5f00\u53d1\u73af\u5883": [[31, "compatible-linux-distributions"], [33, "compatible-linux-distributions"], [34, "compatible-linux-distributions"]], "Machine": [[31, "machine"], [33, "machine"], [34, "machine"]], "Mainline HEAD": [[12, "mainline-head"]], "Mickledore": [[28, "mickledore"], [32, "mickledore"]], "Mini": [[1, "mini"], [3, "mini"], [4, "mini"]], "NAND": [[27, "nand"], [29, "nand"], [30, "nand"]], "NFS\u670d\u52a1\u5668\u8bbe\u7f6e": [[1, "nfs-server-setup"], [3, "nfs-server-setup"], [4, "nfs-server-setup"], [5, "nfs-server-setup"], [7, "nfs-server-setup"], [8, "nfs-server-setup"], [9, "nfs-server-setup"], [11, "nfs-server-setup"], [13, "nfs-server-setup"], [14, "nfs-server-setup"], [15, "nfs-server-setup"], [16, "nfs-server-setup"], [17, "nfs-server-setup"], [18, "nfs-server-setup"], [19, "nfs-server-setup"], [22, "nfs-server-setup"], [23, "nfs-server-setup"], [24, "nfs-server-setup"]], "NPU": [[9, "npu"], [11, "npu"], [14, "npu"], [15, "npu"], [16, "npu"], [17, "npu"]], "NXP eIQ \u793a\u4f8b": [[14, "nxp-examples-for-eiq"], [15, "nxp-examples-for-eiq"]], "PCIe": [[1, "pcie"], [3, "pcie"], [4, "pcie"], [9, "pcie"], [11, "pcie"], [14, "pcie"], [15, "pcie"], [16, "pcie"], [17, "pcie"]], "PHYTEC BSP \u4ecb\u7ecd": [[31, "phytec-bsp-introduction"], [33, "phytec-bsp-introduction"], [34, "phytec-bsp-introduction"]], "PHYTEC i.MX 8M Mini BSP\u8bbe\u5907\u6811\u6982\u5ff5": [[1, "phytec-soc-bsp-device-tree-concept"], [3, "phytec-soc-bsp-device-tree-concept"], [4, "phytec-soc-bsp-device-tree-concept"]], "PHYTEC i.MX 8M Nano BSP\u8bbe\u5907\u6811\u6982\u5ff5": [[5, "phytec-soc-bsp-device-tree-concept"], [7, "phytec-soc-bsp-device-tree-concept"], [8, "phytec-soc-bsp-device-tree-concept"]], "PHYTEC i.MX 8M Plus BSP\u8bbe\u5907\u6811\u6982\u5ff5": [[9, "phytec-soc-bsp-device-tree-concept"], [11, "phytec-soc-bsp-device-tree-concept"], [13, "phytec-soc-bsp-device-tree-concept"], [14, "phytec-soc-bsp-device-tree-concept"], [15, "phytec-soc-bsp-device-tree-concept"], [16, "phytec-soc-bsp-device-tree-concept"], [17, "phytec-soc-bsp-device-tree-concept"], [18, "phytec-soc-bsp-device-tree-concept"], [19, "phytec-soc-bsp-device-tree-concept"]], "PHYTEC i.MX 93 BSP\u8bbe\u5907\u6811\u6982\u5ff5": [[22, "phytec-soc-bsp-device-tree-concept"], [23, "phytec-soc-bsp-device-tree-concept"], [24, "phytec-soc-bsp-device-tree-concept"]], "PHYTEC \u6587\u6863": [[1, null], [3, null], [4, null], [5, null], [7, null], [8, null], [9, null], [11, null], [13, null], [14, null], [15, null], [16, null], [17, null], [18, null], [19, null], [22, null], [23, null], [24, null], [31, "phytec-documentation"], [33, "phytec-documentation"], [34, "phytec-documentation"]], "PWM Fan": [[22, "pwm-fan"], [23, "pwm-fan"], [24, "pwm-fan"]], "PXP": [[22, "pxp"], [23, "pxp"], [24, "pxp"]], "Poky": [[31, "poky"], [31, "id1"], [33, "poky"], [33, "id1"], [34, "poky"], [34, "id1"]], "PulseAudio \u914d\u7f6e": [[1, "pulseaudio-configuration"], [3, "pulseaudio-configuration"], [4, "pulseaudio-configuration"], [9, "pulseaudio-configuration"], [11, "pulseaudio-configuration"], [14, "pulseaudio-configuration"], [15, "pulseaudio-configuration"], [16, "pulseaudio-configuration"], [17, "pulseaudio-configuration"], [23, "pulseaudio-configuration"], [24, "pulseaudio-configuration"]], "Qt Demo": [[1, "qt-demo"], [3, "qt-demo"], [4, "qt-demo"], [9, "qt-demo"], [11, "qt-demo"], [13, "qt-demo"], [14, "qt-demo"], [15, "qt-demo"], [16, "qt-demo"], [17, "qt-demo"], [18, "qt-demo"], [19, "qt-demo"], [22, "qt-demo"], [23, "qt-demo"], [24, "qt-demo"]], "RAM \u57fa\u51c6\u6d4b\u8bd5": [[31, "ram-benchmark"], [33, "ram-benchmark"], [34, "ram-benchmark"]], "RAUC": [[1, "rauc"], [3, "rauc"], [4, "rauc"], [5, "rauc"], [7, "rauc"], [8, "rauc"], [9, "rauc"], [11, "rauc"], [13, "rauc"], [14, "rauc"], [15, "rauc"], [16, "rauc"], [17, "rauc"], [18, "rauc"], [19, "rauc"], [22, "rauc"], [23, "rauc"], [24, "rauc"]], "RAUC BSP Example Setup": [[27, "rauc-bsp-example-setup"], [29, "rauc-bsp-example-setup"], [30, "rauc-bsp-example-setup"]], "RAUC Update & Device Management Manuals": [[28, null]], "RS232": [[1, "rs232"], [3, "rs232"], [4, "rs232"], [5, "rs232"], [7, "rs232"], [8, "rs232"], [9, "rs232"], [11, "rs232"], [13, "rs232"], [14, "rs232"], [15, "rs232"], [16, "rs232"], [17, "rs232"], [18, "rs232"], [19, "rs232"], [23, "rs232"], [24, "rs232"]], "RS232/RS485": [[1, "rs232-rs485"], [3, "rs232-rs485"], [4, "rs232-rs485"], [5, "rs232-rs485"], [7, "rs232-rs485"], [8, "rs232-rs485"], [9, "rs232-rs485"], [11, "rs232-rs485"], [13, "rs232-rs485"], [14, "rs232-rs485"], [15, "rs232-rs485"], [16, "rs232-rs485"], [17, "rs232-rs485"], [18, "rs232-rs485"], [19, "rs232-rs485"], [23, "rs232-rs485"], [24, "rs232-rs485"]], "RS485": [[1, "rs485"], [3, "rs485"], [4, "rs485"], [5, "rs485"], [7, "rs485"], [8, "rs485"], [9, "rs485"], [11, "rs485"], [13, "rs485"], [14, "rs485"], [15, "rs485"], [16, "rs485"], [17, "rs485"], [18, "rs485"], [19, "rs485"], [23, "rs485"], [24, "rs485"]], "RS485 full-duplex": [[9, "rs485-full-duplex"], [11, "rs485-full-duplex"], [13, "rs485-full-duplex"], [16, "rs485-full-duplex"], [17, "rs485-full-duplex"], [19, "rs485-full-duplex"]], "RS485 half-duplex": [[1, "rs485-half-duplex"], [4, "rs485-half-duplex"], [5, "rs485-half-duplex"], [8, "rs485-half-duplex"], [9, "rs485-half-duplex"], [11, "rs485-half-duplex"], [13, "rs485-half-duplex"], [16, "rs485-half-duplex"], [17, "rs485-half-duplex"], [19, "rs485-half-duplex"]], "RTC": [[1, "rtc"], [3, "rtc"], [4, "rtc"], [5, "rtc"], [7, "rtc"], [8, "rtc"], [9, "rtc"], [11, "rtc"], [13, "rtc"], [14, "rtc"], [15, "rtc"], [16, "rtc"], [17, "rtc"], [18, "rtc"], [19, "rtc"], [22, "rtc"], [23, "rtc"], [24, "rtc"]], "RTC\u53c2\u6570": [[1, "rtc-parameters"], [4, "rtc-parameters"], [5, "rtc-parameters"], [8, "rtc-parameters"], [9, "rtc-parameters"], [11, "rtc-parameters"], [13, "rtc-parameters"], [16, "rtc-parameters"], [17, "rtc-parameters"], [18, "rtc-parameters"], [19, "rtc-parameters"], [22, "rtc-parameters"], [23, "rtc-parameters"], [24, "rtc-parameters"]], "RTC\u5524\u9192alarm": [[1, "rtc-wakealarm"], [3, "rtc-wakealarm"], [4, "rtc-wakealarm"], [5, "rtc-wakealarm"], [7, "rtc-wakealarm"], [8, "rtc-wakealarm"], [9, "rtc-wakealarm"], [11, "rtc-wakealarm"], [14, "rtc-wakealarm"], [15, "rtc-wakealarm"], [16, "rtc-wakealarm"], [17, "rtc-wakealarm"], [22, "rtc-wakealarm"], [23, "rtc-wakealarm"], [24, "rtc-wakealarm"]], "Recipes": [[31, "recipes"], [33, "recipes"], [34, "recipes"]], "Reference": [[27, "reference"], [29, "reference"], [30, "reference"]], "Repo": [[31, "repo"], [33, "repo"], [34, "repo"]], "SD/MMC \u5361": [[1, "sd-mmc-card"], [3, "sd-mmc-card"], [4, "sd-mmc-card"], [5, "sd-mmc-card"], [7, "sd-mmc-card"], [8, "sd-mmc-card"], [9, "sd-mmc-card"], [11, "sd-mmc-card"], [13, "sd-mmc-card"], [14, "sd-mmc-card"], [15, "sd-mmc-card"], [16, "sd-mmc-card"], [17, "sd-mmc-card"], [18, "sd-mmc-card"], [19, "sd-mmc-card"], [22, "sd-mmc-card"], [23, "sd-mmc-card"], [24, "sd-mmc-card"]], "SPI NOR \u70e7\u5199": [[1, "spi-nor-flash"], [3, "spi-nor-flash"], [4, "spi-nor-flash"], [5, "spi-nor-flash"], [7, "spi-nor-flash"], [8, "spi-nor-flash"], [9, "spi-nor-flash"], [11, "spi-nor-flash"], [14, "spi-nor-flash"], [15, "spi-nor-flash"], [16, "spi-nor-flash"], [17, "spi-nor-flash"]], "SPI\u4e3b\u8bbe\u5907": [[1, "spi-master"], [3, "spi-master"], [4, "spi-master"], [5, "spi-master"], [7, "spi-master"], [8, "spi-master"], [9, "spi-master"], [11, "spi-master"], [13, "spi-master"], [14, "spi-master"], [15, "spi-master"], [16, "spi-master"], [17, "spi-master"], [18, "spi-master"], [19, "spi-master"]], "Scarthgap": [[28, "scarthgap"], [32, "scarthgap"]], "Security Measurement: Downgrade Barrier": [[27, "security-measurement-downgrade-barrier"], [29, "security-measurement-downgrade-barrier"], [30, "security-measurement-downgrade-barrier"]], "SoM Variants": [[1, "som-variants"], [9, "som-variants"], [11, "som-variants"], [17, "som-variants"]], "Streaming Bundles over HTTP": [[27, "streaming-bundles-over-http"], [29, "streaming-bundles-over-http"], [30, "streaming-bundles-over-http"]], "Switch back to legacyboot": [[1, "switch-back-to-legacyboot"], [9, "switch-back-to-legacyboot"], [11, "switch-back-to-legacyboot"], [17, "switch-back-to-legacyboot"]], "Switch to only efi boot": [[1, "switch-to-only-efi-boot"], [9, "switch-to-only-efi-boot"], [11, "switch-to-only-efi-boot"], [17, "switch-to-only-efi-boot"]], "Switching RAUC Keyrings": [[27, "switching-rauc-keyrings"], [29, "switching-rauc-keyrings"], [30, "switching-rauc-keyrings"]], "System Configuration": [[27, "system-configuration"], [29, "system-configuration"], [30, "system-configuration"]], "Systemd\u4e2d\u7684\u770b\u95e8\u72d7\u652f\u6301": [[1, "watchdog-support-in-systemd"], [3, "watchdog-support-in-systemd"], [4, "watchdog-support-in-systemd"], [5, "watchdog-support-in-systemd"], [7, "watchdog-support-in-systemd"], [8, "watchdog-support-in-systemd"], [9, "watchdog-support-in-systemd"], [11, "watchdog-support-in-systemd"], [13, "watchdog-support-in-systemd"], [14, "watchdog-support-in-systemd"], [15, "watchdog-support-in-systemd"], [16, "watchdog-support-in-systemd"], [17, "watchdog-support-in-systemd"], [18, "watchdog-support-in-systemd"], [19, "watchdog-support-in-systemd"], [22, "watchdog-support-in-systemd"], [23, "watchdog-support-in-systemd"], [24, "watchdog-support-in-systemd"]], "TFTP\u670d\u52a1\u8bbe\u7f6e": [[1, "tftp-server-setup"], [3, "tftp-server-setup"], [4, "tftp-server-setup"], [5, "tftp-server-setup"], [7, "tftp-server-setup"], [8, "tftp-server-setup"], [9, "tftp-server-setup"], [11, "tftp-server-setup"], [13, "tftp-server-setup"], [14, "tftp-server-setup"], [15, "tftp-server-setup"], [16, "tftp-server-setup"], [17, "tftp-server-setup"], [18, "tftp-server-setup"], [19, "tftp-server-setup"], [22, "tftp-server-setup"], [23, "tftp-server-setup"], [24, "tftp-server-setup"]], "TPM": [[23, "tpm"], [24, "tpm"]], "Table of Contents": [[28, null], [28, null], [28, null]], "Toaster": [[31, "toaster"], [33, "toaster"], [34, "toaster"]], "U-Boot": [[1, "u-boot"], [3, "u-boot"], [4, "u-boot"], [5, "u-boot"], [7, "u-boot"], [8, "u-boot"], [9, "u-boot"], [11, "u-boot"], [13, "u-boot"], [14, "u-boot"], [15, "u-boot"], [16, "u-boot"], [17, "u-boot"], [18, "u-boot"], [19, "u-boot"], [22, "u-boot"], [23, "u-boot"], [24, "u-boot"], [27, "u-boot"], [29, "u-boot"], [30, "u-boot"]], "U-Boot Environment Variables": [[27, "u-boot-environment-variables"], [29, "u-boot-environment-variables"], [30, "u-boot-environment-variables"]], "U-boot\u5916\u90e8\u73af\u5883": [[1, "u-boot-external-environment"], [3, "u-boot-external-environment"], [4, "u-boot-external-environment"], [5, "u-boot-external-environment"], [7, "u-boot-external-environment"], [8, "u-boot-external-environment"], [9, "u-boot-external-environment"], [11, "u-boot-external-environment"], [14, "u-boot-external-environment"], [15, "u-boot-external-environment"], [16, "u-boot-external-environment"], [17, "u-boot-external-environment"], [22, "u-boot-external-environment"], [23, "u-boot-external-environment"], [24, "u-boot-external-environment"]], "U-boot\u7f51\u7edc\u73af\u5883": [[1, "u-boot-network-environment"], [3, "u-boot-network-environment"], [4, "u-boot-network-environment"], [5, "u-boot-network-environment"], [7, "u-boot-network-environment"], [8, "u-boot-network-environment"], [9, "u-boot-network-environment"], [11, "u-boot-network-environment"], [13, "u-boot-network-environment"], [14, "u-boot-network-environment"], [15, "u-boot-network-environment"], [16, "u-boot-network-environment"], [17, "u-boot-network-environment"], [18, "u-boot-network-environment"], [19, "u-boot-network-environment"], [22, "u-boot-network-environment"], [23, "u-boot-network-environment"], [24, "u-boot-network-environment"]], "USB OTG": [[1, "usb-otg"], [3, "usb-otg"], [4, "usb-otg"], [5, "usb-otg"], [7, "usb-otg"], [8, "usb-otg"]], "USB\u4e3b\u63a7\u5236\u5668": [[1, "usb-host-controller"], [3, "usb-host-controller"], [4, "usb-host-controller"], [5, "usb-host-controller"], [7, "usb-host-controller"], [8, "usb-host-controller"], [9, "usb-host-controller"], [11, "usb-host-controller"], [13, "usb-host-controller"], [14, "usb-host-controller"], [15, "usb-host-controller"], [16, "usb-host-controller"], [17, "usb-host-controller"], [18, "usb-host-controller"], [19, "usb-host-controller"], [22, "usb-host-controller"], [23, "usb-host-controller"], [24, "usb-host-controller"]], "Updating with RAUC": [[27, "updating-with-rauc"], [29, "updating-with-rauc"], [30, "updating-with-rauc"]], "Use Case Examples": [[27, "use-case-examples"], [29, "use-case-examples"], [30, "use-case-examples"]], "Weston \u914d\u7f6e": [[9, "weston-configuration"], [11, "weston-configuration"], [13, "weston-configuration"], [14, "weston-configuration"], [15, "weston-configuration"], [16, "weston-configuration"], [17, "weston-configuration"], [18, "weston-configuration"], [19, "weston-configuration"]], "Yocto \u4ecb\u7ecd": [[31, "yocto-introduction"], [33, "yocto-introduction"], [34, "yocto-introduction"]], "Yocto \u53c2\u8003\u624b\u518c": [[32, null]], "Yocto \u6587\u6863": [[31, "yocto-documentation"], [33, "yocto-documentation"], [34, "yocto-documentation"]], "Yocto \u9879\u76ee": [[31, null], [33, null], [34, null]], "base layer\uff08fsl-community-bsp-base\uff09": [[31, "base-fsl-community-bsp-base"], [33, "base-fsl-community-bsp-base"], [34, "base-fsl-community-bsp-base"]], "bbnsm \u7535\u6e90\u952e": [[22, "bbnsm-power-key"], [23, "bbnsm-power-key"], [24, "bbnsm-power-key"]], "eMMC": [[27, "emmc"], [29, "emmc"], [30, "emmc"]], "eMMC Boot Partitions": [[27, "emmc-boot-partitions"], [29, "emmc-boot-partitions"], [30, "emmc-boot-partitions"]], "eMMC Boot\u5206\u533a": [[1, "emmc-boot-partitions"], [3, "emmc-boot-partitions"], [4, "emmc-boot-partitions"], [5, "emmc-boot-partitions"], [7, "emmc-boot-partitions"], [8, "emmc-boot-partitions"], [9, "emmc-boot-partitions"], [11, "emmc-boot-partitions"], [13, "emmc-boot-partitions"], [14, "emmc-boot-partitions"], [15, "emmc-boot-partitions"], [16, "emmc-boot-partitions"], [17, "emmc-boot-partitions"], [18, "emmc-boot-partitions"], [19, "emmc-boot-partitions"], [22, "emmc-boot-partitions"], [23, "emmc-boot-partitions"], [24, "emmc-boot-partitions"]], "eMMC\u8bbe\u5907": [[1, "emmc-devices"], [3, "emmc-devices"], [4, "emmc-devices"], [5, "emmc-devices"], [7, "emmc-devices"], [8, "emmc-devices"], [9, "emmc-devices"], [11, "emmc-devices"], [13, "emmc-devices"], [14, "emmc-devices"], [15, "emmc-devices"], [16, "emmc-devices"], [17, "emmc-devices"], [18, "emmc-devices"], [19, "emmc-devices"], [22, "emmc-devices"], [23, "emmc-devices"], [24, "emmc-devices"]], "i.MX 8 \u624b\u518c": [[0, null], [0, null]], "i.MX 8M Mini M4 Core": [[1, "soc-mcore"], [3, "soc-mcore"], [4, "soc-mcore"]], "i.MX 8M Mini \u5f15\u811a\u590d\u7528": [[1, "soc-pin-muxing"], [3, "soc-pin-muxing"], [4, "soc-pin-muxing"]], "i.MX 8M Mini \u624b\u518c": [[2, null]], "i.MX 8M Nano \u5f15\u811a\u590d\u7528": [[5, "soc-pin-muxing"], [7, "soc-pin-muxing"], [8, "soc-pin-muxing"]], "i.MX 8M Nano \u624b\u518c": [[6, null]], "i.MX 8M Plus M7 Core": [[9, "soc-mcore"], [11, "soc-mcore"], [14, "soc-mcore"], [15, "soc-mcore"], [16, "soc-mcore"], [17, "soc-mcore"]], "i.MX 8M Plus \u5f15\u811a\u590d\u7528": [[9, "soc-pin-muxing"], [11, "soc-pin-muxing"], [13, "soc-pin-muxing"], [14, "soc-pin-muxing"], [15, "soc-pin-muxing"], [16, "soc-pin-muxing"], [17, "soc-pin-muxing"], [18, "soc-pin-muxing"], [19, "soc-pin-muxing"]], "i.MX 8M Plus \u624b\u518c": [[12, null]], "i.MX 9 \u624b\u518c": [[20, null], [20, null]], "i.MX 93 M33 Core": [[22, "soc-mcore"], [23, "soc-mcore"], [24, "soc-mcore"]], "i.MX 93 \u5f15\u811a\u590d\u7528": [[22, "soc-pin-muxing"], [23, "soc-pin-muxing"], [24, "soc-pin-muxing"]], "i.MX 93 \u624b\u518c": [[21, null]], "kernel\u548cBootloader\u7684Recipe\u548c\u7248\u672c": [[31, "kernel-and-bootloader-recipe-and-version"], [33, "kernel-and-bootloader-recipe-and-version"], [34, "kernel-and-bootloader-recipe-and-version"]], "kmssink \u63d2\u4ef6 ID \u786e\u8ba4": [[3, "kmssink-plugin-id-evaluation"], [14, "kmssink-plugin-id-evaluation"], [15, "kmssink-plugin-id-evaluation"]], "meta-ampliphy": [[31, "meta-ampliphy"], [33, "meta-ampliphy"], [34, "meta-ampliphy"]], "meta-browser": [[31, "meta-browser"], [33, "meta-browser"], [34, "meta-browser"]], "meta-freescale": [[31, "meta-freescale"], [33, "meta-freescale"], [34, "meta-freescale"]], "meta-freescale-3rdparty": [[31, "meta-freescale-3rdparty"], [33, "meta-freescale-3rdparty"], [34, "meta-freescale-3rdparty"]], "meta-freescale-distro": [[31, "meta-freescale-distro"], [33, "meta-freescale-distro"], [34, "meta-freescale-distro"]], "meta-fsl-bsp-release": [[31, "meta-fsl-bsp-release"], [33, "meta-fsl-bsp-release"], [34, "meta-fsl-bsp-release"]], "meta-gstreamer1.0": [[31, "meta-gstreamer1-0"], [33, "meta-gstreamer1-0"], [34, "meta-gstreamer1-0"]], "meta-nodejs": [[31, "meta-nodejs"], [33, "meta-nodejs"], [34, "meta-nodejs"]], "meta-openembedded": [[31, "meta-openembedded"], [33, "meta-openembedded"], [34, "meta-openembedded"]], "meta-phytec": [[31, "meta-phytec"], [33, "meta-phytec"], [34, "meta-phytec"]], "meta-phytec \u548c meta-ampliphy \u7684\u7279\u70b9": [[31, "bsp-features-of-meta-phytec-and-meta-ampliphy"], [33, "bsp-features-of-meta-phytec-and-meta-ampliphy"], [34, "bsp-features-of-meta-phytec-and-meta-ampliphy"]], "meta-qt6": [[31, "meta-qt6"], [33, "meta-qt6"], [34, "meta-qt6"]], "meta-qt6-phytec": [[31, "meta-qt6-phytec"], [33, "meta-qt6-phytec"], [34, "meta-qt6-phytec"]], "meta-rauc": [[31, "meta-rauc"], [33, "meta-rauc"], [34, "meta-rauc"]], "meta-rust": [[31, "meta-rust"], [33, "meta-rust"], [34, "meta-rust"]], "meta-security": [[31, "meta-security"], [33, "meta-security"], [34, "meta-security"]], "meta-selinux": [[31, "meta-selinux"], [33, "meta-selinux"], [34, "meta-selinux"]], "meta-timesys": [[31, "meta-timesys"], [33, "meta-timesys"], [34, "meta-timesys"]], "meta-virtualization": [[31, "meta-virtualization"], [33, "meta-virtualization"], [34, "meta-virtualization"]], "phyBOARD-Nash i.MX 93 \u5668\u4ef6": [[22, "phyboard-nash-i-mx-93-components"], [23, "phyboard-nash-i-mx-93-components"], [24, "phyboard-nash-i-mx-93-components"]], "phyBOARD-Nash\u4e0a\u7684\u97f3\u9891": [[23, "audio-on-phyboard-nash"]], "phyBOARD-Polis \u5668\u4ef6": [[1, "sbc-components"], [3, "sbc-components"], [4, "sbc-components"], [5, "sbc-components"], [7, "sbc-components"], [8, "sbc-components"]], "phyBOARD-Pollux \u5668\u4ef6": [[11, "sbc-components"], [13, "sbc-components"], [14, "sbc-components"], [15, "sbc-components"], [16, "sbc-components"], [17, "sbc-components"], [18, "sbc-components"], [19, "sbc-components"]], "phyBOARD-Segin i.MX 93 \u5668\u4ef6": [[22, "phyboard-segin-i-mx-93-components"], [23, "phyboard-segin-i-mx-93-components"], [24, "phyboard-segin-i-mx-93-components"]], "phyBOARD-Segin\u4e0a\u7684\u97f3\u9891": [[23, "audio-on-phyboard-segin"]], "phyCORE-i.MX 6UL/ULL \u84dd\u7259": [[31, "phycore-i-mx-6ul-ull-bluetooth"], [33, "phycore-i-mx-6ul-ull-bluetooth"], [34, "phycore-i-mx-6ul-ull-bluetooth"]], "phyCORE-i.MX8MM \u4e0a\u7684I2C EEPROM": [[1, "i2c-eeprom-on-som"], [3, "i2c-eeprom-on-som"], [4, "i2c-eeprom-on-som"]], "phyCORE-i.MX8MN \u4e0a\u7684I2C EEPROM": [[5, "i2c-eeprom-on-som"], [7, "i2c-eeprom-on-som"], [8, "i2c-eeprom-on-som"]], "phyCORE-i.MX8MP \u4e0a\u7684I2C EEPROM": [[11, "i2c-eeprom-on-som"], [13, "i2c-eeprom-on-som"], [14, "i2c-eeprom-on-som"], [15, "i2c-eeprom-on-som"], [16, "i2c-eeprom-on-som"], [17, "i2c-eeprom-on-som"], [18, "i2c-eeprom-on-som"], [19, "i2c-eeprom-on-som"]], "phyCORE-i.MX8MP-FPSC \u4e0a\u7684I2C EEPROM": [[9, "i2c-eeprom-on-som"]], "phyCORE-i.MX93 \u4e0a\u7684I2C EEPROM": [[22, "i2c-eeprom-on-som"], [23, "i2c-eeprom-on-som"], [24, "i2c-eeprom-on-som"]], "phyLinux": [[31, "phylinux"], [33, "phylinux"], [34, "phylinux"]], "phyLinux \u6587\u6863": [[31, "phylinux-documentation"], [33, "phylinux-documentation"], [34, "phylinux-documentation"]], "setscene\u4efb\u52a1\u544a\u8b66": [[31, "setscene-task-warning"], [33, "setscene-task-warning"], [34, "setscene-task-warning"]], "site.conf \u8bbe\u7f6e": [[31, "site-conf-setup"], [33, "site-conf-setup"], [34, "site-conf-setup"]], "snvs\u7535\u6e90\u6309\u952e": [[9, "snvs-power-key"], [11, "snvs-power-key"], [13, "snvs-power-key"], [14, "snvs-power-key"], [15, "snvs-power-key"], [16, "snvs-power-key"], [17, "snvs-power-key"], [18, "snvs-power-key"], [19, "snvs-power-key"]], "\u4e09\u5c4f\u663e\u793a": [[16, "triple-display"]], "\u4e0b\u8f7d/\u62c9\u53d6\u5bb9\u5668": [[31, "download-pull-container"], [33, "download-pull-container"], [34, "download-pull-container"]], "\u4e0b\u8f7dBSP": [[1, "get-the-bsp"], [3, "get-the-bsp"], [4, "get-the-bsp"], [5, "get-the-bsp"], [7, "get-the-bsp"], [8, "get-the-bsp"], [9, "get-the-bsp"], [11, "get-the-bsp"], [13, "get-the-bsp"], [14, "get-the-bsp"], [15, "get-the-bsp"], [16, "get-the-bsp"], [17, "get-the-bsp"], [18, "get-the-bsp"], [19, "get-the-bsp"], [22, "get-the-bsp"], [23, "get-the-bsp"], [24, "get-the-bsp"]], "\u4e0b\u8f7d\u955c\u50cf": [[1, "get-the-image"], [3, "get-the-image"], [4, "get-the-image"], [5, "get-the-image"], [7, "get-the-image"], [8, "get-the-image"], [9, "get-the-image"], [11, "get-the-image"], [13, "get-the-image"], [14, "get-the-image"], [15, "get-the-image"], [16, "get-the-image"], [17, "get-the-image"], [18, "get-the-image"], [19, "get-the-image"], [22, "get-the-image"], [23, "get-the-image"], [24, "get-the-image"]], "\u4e0d\u540c\u7684\u5de5\u5177\u94fe": [[31, "different-toolchains"], [33, "different-toolchains"], [34, "different-toolchains"]], "\u4e3a BSP \u955c\u50cf\u6dfb\u52a0\u65b0\u7684\u8f6f\u4ef6\u5305": [[31, "add-additional-software-for-the-bsp-image"], [33, "add-additional-software-for-the-bsp-image"], [34, "add-additional-software-for-the-bsp-image"]], "\u4e3b\u673a\u7f51\u7edc\u51c6\u5907": [[1, "host-network-preparation"], [3, "host-network-preparation"], [4, "host-network-preparation"], [5, "host-network-preparation"], [7, "host-network-preparation"], [8, "host-network-preparation"], [9, "host-network-preparation"], [11, "host-network-preparation"], [13, "host-network-preparation"], [14, "host-network-preparation"], [15, "host-network-preparation"], [16, "host-network-preparation"], [17, "host-network-preparation"], [18, "host-network-preparation"], [19, "host-network-preparation"], [22, "host-network-preparation"], [23, "host-network-preparation"], [24, "host-network-preparation"]], "\u4ecb\u7ecd": [[1, "introduction"], [3, "introduction"], [4, "introduction"], [5, "introduction"], [7, "introduction"], [8, "introduction"], [9, "introduction"], [11, "introduction"], [13, "introduction"], [14, "introduction"], [15, "introduction"], [16, "introduction"], [17, "introduction"], [18, "introduction"], [19, "introduction"], [22, "introduction"], [23, "introduction"], [24, "introduction"]], "\u4eceSD\u5361\u70e7\u5199SPI NOR Flash": [[1, "flash-spi-nor-flash-from-sd-card"], [3, "flash-spi-nor-flash-from-sd-card"], [4, "flash-spi-nor-flash-from-sd-card"], [5, "flash-spi-nor-flash-from-sd-card"], [7, "flash-spi-nor-flash-from-sd-card"], [8, "flash-spi-nor-flash-from-sd-card"], [9, "flash-spi-nor-flash-from-sd-card"], [11, "flash-spi-nor-flash-from-sd-card"], [14, "flash-spi-nor-flash-from-sd-card"], [15, "flash-spi-nor-flash-from-sd-card"], [16, "flash-spi-nor-flash-from-sd-card"], [17, "flash-spi-nor-flash-from-sd-card"]], "\u4eceSD\u5361\u70e7\u5199eMMC": [[1, "flash-emmc-from-sd-card"], [3, "flash-emmc-from-sd-card"], [4, "flash-emmc-from-sd-card"], [5, "flash-emmc-from-sd-card"], [7, "flash-emmc-from-sd-card"], [8, "flash-emmc-from-sd-card"], [9, "flash-emmc-from-sd-card"], [11, "flash-emmc-from-sd-card"], [13, "flash-emmc-from-sd-card"], [14, "flash-emmc-from-sd-card"], [15, "flash-emmc-from-sd-card"], [16, "flash-emmc-from-sd-card"], [17, "flash-emmc-from-sd-card"], [18, "flash-emmc-from-sd-card"], [19, "flash-emmc-from-sd-card"], [22, "flash-emmc-from-sd-card"], [23, "flash-emmc-from-sd-card"], [24, "flash-emmc-from-sd-card"]], "\u4eceU-Boot\u8fd0\u884c\u793a\u4f8b": [[1, "running-examples-from-u-boot"], [3, "running-examples-from-u-boot"], [4, "running-examples-from-u-boot"], [9, "running-examples-from-u-boot"], [11, "running-examples-from-u-boot"], [14, "running-examples-from-u-boot"], [15, "running-examples-from-u-boot"], [16, "running-examples-from-u-boot"], [17, "running-examples-from-u-boot"], [22, "running-examples-from-u-boot"], [23, "running-examples-from-u-boot"], [24, "running-examples-from-u-boot"]], "\u4eceUSB\u5927\u5bb9\u91cf\u5b58\u50a8\u8bbe\u5907\u70e7\u5199eMMC": [[1, "flash-emmc-from-usb-stick"], [4, "flash-emmc-from-usb-stick"], [5, "flash-emmc-from-usb-stick"], [8, "flash-emmc-from-usb-stick"], [9, "flash-emmc-from-usb-stick"], [11, "flash-emmc-from-usb-stick"], [13, "flash-emmc-from-usb-stick"], [16, "flash-emmc-from-usb-stick"], [17, "flash-emmc-from-usb-stick"], [19, "flash-emmc-from-usb-stick"]], "\u4eceUSB\u70e7\u5199eMMC": [[3, "flash-emmc-from-usb"], [7, "flash-emmc-from-usb"], [14, "flash-emmc-from-usb"], [15, "flash-emmc-from-usb"], [18, "flash-emmc-from-usb"], [22, "flash-emmc-from-usb"], [23, "flash-emmc-from-usb"], [24, "flash-emmc-from-usb"]], "\u4ece\u5f00\u53d1\u677f\u542f\u52a8": [[1, "booting-from-an-embedded-board"], [3, "booting-from-an-embedded-board"], [4, "booting-from-an-embedded-board"], [5, "booting-from-an-embedded-board"], [7, "booting-from-an-embedded-board"], [8, "booting-from-an-embedded-board"], [9, "booting-from-an-embedded-board"], [11, "booting-from-an-embedded-board"], [13, "booting-from-an-embedded-board"], [14, "booting-from-an-embedded-board"], [15, "booting-from-an-embedded-board"], [16, "booting-from-an-embedded-board"], [17, "booting-from-an-embedded-board"], [18, "booting-from-an-embedded-board"], [19, "booting-from-an-embedded-board"], [22, "booting-from-an-embedded-board"], [23, "booting-from-an-embedded-board"], [24, "booting-from-an-embedded-board"]], "\u4ece\u7f51\u7edc\u542f\u52a8\u5185\u6838": [[1, "booting-the-kernel-from-a-network"], [3, "booting-the-kernel-from-a-network"], [4, "booting-the-kernel-from-a-network"], [5, "booting-the-kernel-from-a-network"], [7, "booting-the-kernel-from-a-network"], [8, "booting-the-kernel-from-a-network"], [9, "booting-the-kernel-from-a-network"], [11, "booting-the-kernel-from-a-network"], [13, "booting-the-kernel-from-a-network"], [14, "booting-the-kernel-from-a-network"], [15, "booting-the-kernel-from-a-network"], [16, "booting-the-kernel-from-a-network"], [17, "booting-the-kernel-from-a-network"], [18, "booting-the-kernel-from-a-network"], [19, "booting-the-kernel-from-a-network"], [22, "booting-the-kernel-from-a-network"], [23, "booting-the-kernel-from-a-network"], [24, "booting-the-kernel-from-a-network"]], "\u4ece\u7f51\u7edc\u70e7\u5199 eMMC": [[1, "flash-emmc-from-network"], [3, "flash-emmc-from-network"], [4, "flash-emmc-from-network"], [5, "flash-emmc-from-network"], [7, "flash-emmc-from-network"], [8, "flash-emmc-from-network"], [9, "flash-emmc-from-network"], [11, "flash-emmc-from-network"], [13, "flash-emmc-from-network"], [14, "flash-emmc-from-network"], [15, "flash-emmc-from-network"], [16, "flash-emmc-from-network"], [17, "flash-emmc-from-network"], [18, "flash-emmc-from-network"], [19, "flash-emmc-from-network"], [22, "flash-emmc-from-network"], [23, "flash-emmc-from-network"], [24, "flash-emmc-from-network"]], "\u4f5c\u4e3aUSB\u8bbe\u5907": [[1, "usb-device"], [3, "usb-device"], [4, "usb-device"], [5, "usb-device"], [7, "usb-device"], [8, "usb-device"]], "\u4f7f\u7528 Poky \u548c Bitbake": [[31, "working-with-poky-and-bitbake"], [33, "working-with-poky-and-bitbake"], [34, "working-with-poky-and-bitbake"]], "\u4f7f\u7528 SDK": [[31, "using-the-sdk"], [33, "using-the-sdk"], [34, "using-the-sdk"]], "\u4f7f\u7528 bbappend \u6587\u4ef6\u66f4\u6539 u-boot \u73af\u5883\u53d8\u91cf": [[31, "change-the-u-boot-environment-via-bbappend-files"], [33, "change-the-u-boot-environment-via-bbappend-files"], [34, "change-the-u-boot-environment-via-bbappend-files"]], "\u4f7f\u7528 dd": [[1, "using-dd"], [4, "using-dd"], [5, "using-dd"], [8, "using-dd"], [9, "using-dd"], [11, "using-dd"], [13, "using-dd"], [16, "using-dd"], [17, "using-dd"], [18, "using-dd"], [19, "using-dd"], [22, "using-dd"], [23, "using-dd"], [24, "using-dd"]], "\u4f7f\u7528 devtool \u4fee\u6539Kernel\u6216Bootloader": [[31, "patch-the-kernel-or-bootloader-with-devtool"], [33, "patch-the-kernel-or-bootloader-with-devtool"], [34, "patch-the-kernel-or-bootloader-with-devtool"]], "\u4f7f\u7528 imx-mkimage \u7f16\u8bd1\u6700\u7ec8\u7684 flash.bin": [[22, "build-final-flash-bin-with-imx-mkimage"], [23, "build-final-flash-bin-with-imx-mkimage"], [24, "build-final-flash-bin-with-imx-mkimage"]], "\u4f7f\u7528 lightpd \u5b89\u88c5\u6700\u5c0f\u7684 PHP Web \u8fd0\u884c\u73af\u5883": [[31, "add-minimal-php-web-runtime-with-lightpd"], [33, "add-minimal-php-web-runtime-with-lightpd"], [34, "add-minimal-php-web-runtime-with-lightpd"]], "\u4f7f\u7528 local.conf \u6587\u4ef6\u4e2d\u7684 SRC_URI \u6765\u914d\u7f6eKernel \u548cBootloader": [[31, "working-with-the-kernel-and-bootloader-using-src-uri-in-local-conf"], [33, "working-with-the-kernel-and-bootloader-using-src-uri-in-local-conf"], [34, "working-with-the-kernel-and-bootloader-using-src-uri-in-local-conf"]], "\u4f7f\u7528 udev": [[31, "working-with-udev"], [33, "working-with-udev"], [34, "working-with-udev"]], "\u4f7f\u7528J-Link\u8fdb\u884c\u8c03\u8bd5": [[1, "debugging-using-j-link"], [3, "debugging-using-j-link"], [4, "debugging-using-j-link"], [9, "debugging-using-j-link"], [11, "debugging-using-j-link"], [14, "debugging-using-j-link"], [15, "debugging-using-j-link"], [16, "debugging-using-j-link"], [17, "debugging-using-j-link"]], "\u4f7f\u7528Kernel\u6a21\u5757": [[31, "working-with-kernel-modules"], [33, "working-with-kernel-modules"], [34, "working-with-kernel-modules"]], "\u4f7f\u7528SDK": [[1, "using-the-sdk"], [3, "using-the-sdk"], [4, "using-the-sdk"], [5, "using-the-sdk"], [7, "using-the-sdk"], [8, "using-the-sdk"], [9, "using-the-sdk"], [11, "using-the-sdk"], [13, "using-the-sdk"], [14, "using-the-sdk"], [15, "using-the-sdk"], [16, "using-the-sdk"], [17, "using-the-sdk"], [18, "using-the-sdk"], [19, "using-the-sdk"], [22, "using-the-sdk"], [23, "using-the-sdk"], [24, "using-the-sdk"]], "\u4f7f\u7528UUU\u5de5\u5177": [[1, "working-with-uuu-tool"], [3, "working-with-uuu-tool"], [4, "working-with-uuu-tool"], [5, "working-with-uuu-tool"], [7, "working-with-uuu-tool"], [8, "working-with-uuu-tool"], [9, "working-with-uuu-tool"], [11, "working-with-uuu-tool"], [13, "working-with-uuu-tool"], [14, "working-with-uuu-tool"], [15, "working-with-uuu-tool"], [16, "working-with-uuu-tool"], [17, "working-with-uuu-tool"], [18, "working-with-uuu-tool"], [19, "working-with-uuu-tool"], [22, "working-with-uuu-tool"], [23, "working-with-uuu-tool"], [24, "working-with-uuu-tool"]], "\u4f7f\u7528UUU\u5de5\u5177\u7684\u51c6\u5907": [[1, "host-preparations-for-uuu-tool-usage"], [3, "host-preparations-for-uuu-tool-usage"], [4, "host-preparations-for-uuu-tool-usage"], [5, "host-preparations-for-uuu-tool-usage"], [7, "host-preparations-for-uuu-tool-usage"], [8, "host-preparations-for-uuu-tool-usage"], [9, "host-preparations-for-uuu-tool-usage"], [11, "host-preparations-for-uuu-tool-usage"], [13, "host-preparations-for-uuu-tool-usage"], [14, "host-preparations-for-uuu-tool-usage"], [15, "host-preparations-for-uuu-tool-usage"], [16, "host-preparations-for-uuu-tool-usage"], [17, "host-preparations-for-uuu-tool-usage"], [18, "host-preparations-for-uuu-tool-usage"], [19, "host-preparations-for-uuu-tool-usage"], [22, "host-preparations-for-uuu-tool-usage"], [23, "host-preparations-for-uuu-tool-usage"], [24, "host-preparations-for-uuu-tool-usage"]], "\u4f7f\u7528bmap-tools": [[1, "using-bmap-tools"], [4, "using-bmap-tools"], [5, "using-bmap-tools"], [8, "using-bmap-tools"], [9, "using-bmap-tools"], [11, "using-bmap-tools"], [13, "using-bmap-tools"], [16, "using-bmap-tools"], [17, "using-bmap-tools"], [18, "using-bmap-tools"], [19, "using-bmap-tools"], [22, "using-bmap-tools"], [23, "using-bmap-tools"], [24, "using-bmap-tools"]], "\u4f7f\u7528partup": [[1, "using-partup"], [4, "using-partup"], [5, "using-partup"], [8, "using-partup"], [9, "using-partup"], [11, "using-partup"], [13, "using-partup"], [16, "using-partup"], [17, "using-partup"], [18, "using-partup"], [19, "using-partup"], [22, "using-partup"], [23, "using-partup"], [24, "using-partup"]], "\u4f7f\u7528\u201c\u4e34\u65f6\u65b9\u6cd5\u201d\u4fee\u8865Kernel \u6216Bootloader": [[31, "patch-the-kernel-or-bootloader-using-the-temporary-method"], [33, "patch-the-kernel-or-bootloader-using-the-temporary-method"], [34, "patch-the-kernel-or-bootloader-using-the-temporary-method"]], "\u4f7f\u7528\u201c\u53ef\u6301\u7eed\u65b9\u6cd5\u201d\u6dfb\u52a0\u8f6f\u4ef6": [[31, "add-existing-software-with-sustainable-method"], [33, "add-existing-software-with-sustainable-method"], [34, "add-existing-software-with-sustainable-method"]], "\u4f7f\u7528\u56fa\u5b9a\u5185\u5b58\u5927\u5c0f\u7f16\u8bd1U-Boot": [[1, "build-u-boot-with-a-fixed-ram-size"], [3, "build-u-boot-with-a-fixed-ram-size"], [4, "build-u-boot-with-a-fixed-ram-size"], [9, "build-u-boot-with-a-fixed-ram-size"], [11, "build-u-boot-with-a-fixed-ram-size"], [13, "build-u-boot-with-a-fixed-ram-size"], [14, "build-u-boot-with-a-fixed-ram-size"], [15, "build-u-boot-with-a-fixed-ram-size"], [16, "build-u-boot-with-a-fixed-ram-size"], [17, "build-u-boot-with-a-fixed-ram-size"], [19, "build-u-boot-with-a-fixed-ram-size"]], "\u4f7f\u7528\u7f16\u8bd1\u5bb9\u5668": [[31, "using-build-container"], [33, "using-build-container"], [34, "using-build-container"]], "\u4f7f\u80fd\u540e\u53f0\u64cd\u4f5c (BKOPS)": [[1, "enabling-background-operations-bkops"], [3, "enabling-background-operations-bkops"], [4, "enabling-background-operations-bkops"], [5, "enabling-background-operations-bkops"], [7, "enabling-background-operations-bkops"], [8, "enabling-background-operations-bkops"], [9, "enabling-background-operations-bkops"], [11, "enabling-background-operations-bkops"], [13, "enabling-background-operations-bkops"], [14, "enabling-background-operations-bkops"], [15, "enabling-background-operations-bkops"], [16, "enabling-background-operations-bkops"], [17, "enabling-background-operations-bkops"], [18, "enabling-background-operations-bkops"], [19, "enabling-background-operations-bkops"], [22, "enabling-background-operations-bkops"], [23, "enabling-background-operations-bkops"], [24, "enabling-background-operations-bkops"]], "\u4fee\u6539\u73af\u5883\uff08\u4f9d\u8d56\u6240\u4f7f\u7528\u7684machine\uff09": [[31, "changing-the-environment-depending-on-machines"], [33, "changing-the-environment-depending-on-machines"], [34, "changing-the-environment-depending-on-machines"]], "\u5173\u4e8e\u8f6f\u4ef6\u5305\u548cRecipe\u7684\u8bf4\u660e": [[31, "notes-about-packages-and-recipes"], [33, "notes-about-packages-and-recipes"], [34, "notes-about-packages-and-recipes"]], "\u5185\u6838": [[1, "kernel"], [3, "kernel"], [4, "kernel"], [5, "kernel"], [7, "kernel"], [8, "kernel"], [9, "kernel"], [11, "kernel"], [13, "kernel"], [14, "kernel"], [15, "kernel"], [16, "kernel"], [17, "kernel"], [18, "kernel"], [19, "kernel"], [22, "kernel"], [23, "kernel"], [24, "kernel"]], "\u5185\u6838\u7f51\u7edc\u73af\u5883": [[1, "kernel-network-environment"], [3, "kernel-network-environment"], [4, "kernel-network-environment"], [5, "kernel-network-environment"], [7, "kernel-network-environment"], [8, "kernel-network-environment"], [9, "kernel-network-environment"], [11, "kernel-network-environment"], [13, "kernel-network-environment"], [14, "kernel-network-environment"], [15, "kernel-network-environment"], [16, "kernel-network-environment"], [17, "kernel-network-environment"], [18, "kernel-network-environment"], [19, "kernel-network-environment"], [22, "kernel-network-environment"], [23, "kernel-network-environment"], [24, "kernel-network-environment"]], "\u5207\u6362UART1\u7684RS485\u548cRS232\u6a21\u5f0f": [[1, "id12"], [1, "id15"], [3, "id11"], [3, "id14"], [4, "id11"], [4, "id14"], [5, "id19"], [7, "id18"], [8, "id18"]], "\u521b\u5efa WLAN \u63a5\u5165\u70b9": [[31, "creating-a-wlan-access-point"], [33, "creating-a-wlan-access-point"], [34, "creating-a-wlan-access-point"]], "\u521b\u5efa\u7b2c\u4e09\u4e2a\u5206\u533a": [[1, "create-the-third-partition"], [3, "create-the-third-partition"], [4, "create-the-third-partition"], [5, "create-the-third-partition"], [7, "create-the-third-partition"], [8, "create-the-third-partition"], [9, "create-the-third-partition"], [11, "create-the-third-partition"], [13, "create-the-third-partition"], [14, "create-the-third-partition"], [15, "create-the-third-partition"], [16, "create-the-third-partition"], [17, "create-the-third-partition"], [18, "create-the-third-partition"], [19, "create-the-third-partition"], [22, "create-the-third-partition"], [23, "create-the-third-partition"], [24, "create-the-third-partition"]], "\u521d\u59cb\u5316": [[31, "initialization"], [33, "initialization"], [34, "initialization"]], "\u5355\u4e00\u663e\u793a\u5668": [[9, "single-display"], [11, "single-display"], [14, "single-display"], [15, "single-display"], [16, "single-display"], [17, "single-display"]], "\u5355\u72ec\u7f16\u8bd1U-Boot": [[1, "u-boot-standalone-build"], [3, "u-boot-standalone-build"], [4, "u-boot-standalone-build"], [5, "u-boot-standalone-build"], [7, "u-boot-standalone-build"], [8, "u-boot-standalone-build"], [9, "u-boot-standalone-build"], [11, "u-boot-standalone-build"], [13, "u-boot-standalone-build"], [14, "u-boot-standalone-build"], [15, "u-boot-standalone-build"], [16, "u-boot-standalone-build"], [17, "u-boot-standalone-build"], [18, "u-boot-standalone-build"], [19, "u-boot-standalone-build"], [22, "u-boot-standalone-build"], [23, "u-boot-standalone-build"], [24, "u-boot-standalone-build"]], "\u5355\u72ec\u7f16\u8bd1\u5185\u6838": [[1, "kernel-standalone-build"], [3, "kernel-standalone-build"], [4, "kernel-standalone-build"], [5, "kernel-standalone-build"], [7, "kernel-standalone-build"], [8, "kernel-standalone-build"], [9, "kernel-standalone-build"], [11, "kernel-standalone-build"], [13, "kernel-standalone-build"], [14, "kernel-standalone-build"], [15, "kernel-standalone-build"], [16, "kernel-standalone-build"], [17, "kernel-standalone-build"], [18, "kernel-standalone-build"], [19, "kernel-standalone-build"], [22, "kernel-standalone-build"], [23, "kernel-standalone-build"], [24, "kernel-standalone-build"]], "\u5373\u5c06\u53d1\u5e03\u7248\u672c\u7684\u5f00\u53d1\u4e2d\u7248\u672c": [[1, "development-state-of-upcoming-release"], [3, "development-state-of-upcoming-release"], [4, "development-state-of-upcoming-release"], [5, "development-state-of-upcoming-release"], [7, "development-state-of-upcoming-release"], [8, "development-state-of-upcoming-release"], [9, "development-state-of-upcoming-release"], [11, "development-state-of-upcoming-release"], [13, "development-state-of-upcoming-release"], [14, "development-state-of-upcoming-release"], [15, "development-state-of-upcoming-release"], [16, "development-state-of-upcoming-release"], [17, "development-state-of-upcoming-release"], [18, "development-state-of-upcoming-release"], [19, "development-state-of-upcoming-release"]], "\u53cc\u663e\u793a\u5668": [[9, "dual-display"], [11, "dual-display"], [16, "dual-display"], [17, "dual-display"]], "\u53d1\u884c\u7248 (Distro)": [[31, "distribution-distro"], [33, "distribution-distro"], [34, "distribution-distro"]], "\u53ef\u7528\u5bb9\u5668": [[31, "available-container"], [33, "available-container"], [34, "available-container"]], "\u53ef\u89c1\u6027": [[1, "visibility"], [3, "visibility"], [4, "visibility"], [5, "visibility"], [7, "visibility"], [8, "visibility"], [9, "visibility"], [11, "visibility"], [14, "visibility"], [14, "id1"], [15, "visibility"], [16, "visibility"], [17, "visibility"]], "\u53ef\u9760\u5199\u5165": [[1, "reliable-write"], [3, "reliable-write"], [4, "reliable-write"], [5, "reliable-write"], [7, "reliable-write"], [8, "reliable-write"], [9, "reliable-write"], [11, "reliable-write"], [13, "reliable-write"], [14, "reliable-write"], [15, "reliable-write"], [16, "reliable-write"], [17, "reliable-write"], [18, "reliable-write"], [19, "reliable-write"], [22, "reliable-write"], [23, "reliable-write"], [24, "reliable-write"]], "\u5411Recipe\u6dfb\u52a0\u4e00\u4e2a\u5b8c\u6574\u914d\u7f6e (defconfig)": [[31, "add-a-complete-default-configuration-defconfig-to-a-recipe"], [33, "add-a-complete-default-configuration-defconfig-to-a-recipe"], [34, "add-a-complete-default-configuration-defconfig-to-a-recipe"]], "\u542f\u52a8\u6a21\u5f0f\u5f00\u5173 (S1)": [[1, "bootmode-switch-s1"], [3, "bootmode-switch-s1"], [4, "bootmode-switch-s1"], [5, "bootmode-switch-s1"], [7, "bootmode-switch-s1"], [8, "bootmode-switch-s1"]], "\u542f\u52a8\u6a21\u5f0f\u5f00\u5173 (S3)": [[9, "bootmode-switch-s3"], [11, "bootmode-switch-s3"], [13, "bootmode-switch-s3"], [14, "bootmode-switch-s3"], [15, "bootmode-switch-s3"], [16, "bootmode-switch-s3"], [17, "bootmode-switch-s3"], [18, "bootmode-switch-s3"], [19, "bootmode-switch-s3"], [22, "bootmode-switch-s3"], [23, "bootmode-switch-s3"], [24, "bootmode-switch-s3"]], "\u542f\u52a8\u6a21\u5f0f\u9009\u62e9": [[1, "id5"], [1, "id7"], [3, "id4"], [3, "id6"], [4, "id4"], [4, "id6"], [5, "id5"], [5, "id7"], [7, "id4"], [7, "id6"], [8, "id4"], [8, "id6"]], "\u542f\u7528\u4f2aSLC\u6a21\u5f0f": [[1, "enable-pseudo-slc-mode"], [3, "enable-pseudo-slc-mode"], [4, "enable-pseudo-slc-mode"], [5, "enable-pseudo-slc-mode"], [7, "enable-pseudo-slc-mode"], [8, "enable-pseudo-slc-mode"], [9, "enable-pseudo-slc-mode"], [11, "enable-pseudo-slc-mode"], [13, "enable-pseudo-slc-mode"], [14, "enable-pseudo-slc-mode"], [15, "enable-pseudo-slc-mode"], [16, "enable-pseudo-slc-mode"], [17, "enable-pseudo-slc-mode"], [18, "enable-pseudo-slc-mode"], [19, "enable-pseudo-slc-mode"], [22, "enable-pseudo-slc-mode"], [23, "enable-pseudo-slc-mode"], [24, "enable-pseudo-slc-mode"]], "\u5728Linux\u4e2d\u8bfb\u53d6fuse\u503c": [[1, "reading-fuse-values-in-linux"], [3, "reading-fuse-values-in-linux"], [4, "reading-fuse-values-in-linux"], [5, "reading-fuse-values-in-linux"], [7, "reading-fuse-values-in-linux"], [8, "reading-fuse-values-in-linux"], [9, "reading-fuse-values-in-linux"], [11, "reading-fuse-values-in-linux"], [13, "reading-fuse-values-in-linux"], [14, "reading-fuse-values-in-linux"], [15, "reading-fuse-values-in-linux"], [16, "reading-fuse-values-in-linux"], [17, "reading-fuse-values-in-linux"], [18, "reading-fuse-values-in-linux"], [19, "reading-fuse-values-in-linux"], [22, "reading-fuse-values-in-linux"], [23, "reading-fuse-values-in-linux"], [24, "reading-fuse-values-in-linux"]], "\u5728Linux\u4e3b\u673a\u4e0a\u901a\u8fc7\u7f51\u7edc\u70e7\u5199 eMMC": [[1, "flash-emmc-via-network-in-linux-on-host"], [3, "flash-emmc-via-network-in-linux-on-host"], [4, "flash-emmc-via-network-in-linux-on-host"], [5, "flash-emmc-via-network-in-linux-on-host"], [7, "flash-emmc-via-network-in-linux-on-host"], [8, "flash-emmc-via-network-in-linux-on-host"], [9, "flash-emmc-via-network-in-linux-on-host"], [11, "flash-emmc-via-network-in-linux-on-host"], [13, "flash-emmc-via-network-in-linux-on-host"], [14, "flash-emmc-via-network-in-linux-on-host"], [15, "flash-emmc-via-network-in-linux-on-host"], [16, "flash-emmc-via-network-in-linux-on-host"], [17, "flash-emmc-via-network-in-linux-on-host"], [18, "flash-emmc-via-network-in-linux-on-host"], [19, "flash-emmc-via-network-in-linux-on-host"], [22, "flash-emmc-via-network-in-linux-on-host"], [23, "flash-emmc-via-network-in-linux-on-host"], [24, "flash-emmc-via-network-in-linux-on-host"]], "\u5728Linux\u73af\u5883\u4e0b\u66f4\u6539\u5f00\u53d1\u677f\u4e0a\u7684U-boot\u73af\u5883\u53d8\u91cf": [[1, "change-u-boot-environment-from-linux-on-target"], [3, "change-u-boot-environment-from-linux-on-target"], [4, "change-u-boot-environment-from-linux-on-target"], [5, "change-u-boot-environment-from-linux-on-target"], [7, "change-u-boot-environment-from-linux-on-target"], [8, "change-u-boot-environment-from-linux-on-target"], [9, "change-u-boot-environment-from-linux-on-target"], [11, "change-u-boot-environment-from-linux-on-target"], [14, "change-u-boot-environment-from-linux-on-target"], [15, "change-u-boot-environment-from-linux-on-target"], [16, "change-u-boot-environment-from-linux-on-target"], [17, "change-u-boot-environment-from-linux-on-target"], [22, "change-u-boot-environment-from-linux-on-target"], [23, "change-u-boot-environment-from-linux-on-target"], [24, "change-u-boot-environment-from-linux-on-target"]], "\u5728u-boot\u4e0a\u4eceSD\u5361\u70e7\u5199eMMC": [[3, "flash-emmc-from-sd-card-in-u-boot-on-target"], [7, "flash-emmc-from-sd-card-in-u-boot-on-target"], [14, "flash-emmc-from-sd-card-in-u-boot-on-target"], [15, "flash-emmc-from-sd-card-in-u-boot-on-target"]], "\u5728u-boot\u4e0a\u4eceUSB\u70e7\u5199eMMC": [[3, "flash-emmc-from-usb-in-u-boot-on-target"], [7, "flash-emmc-from-usb-in-u-boot-on-target"], [14, "flash-emmc-from-usb-in-u-boot-on-target"], [15, "flash-emmc-from-usb-in-u-boot-on-target"]], "\u5728u-boot\u4e2d\u901a\u8fc7\u7f51\u7edc\u70e7\u5199eMMC u-boot\u955c\u50cf": [[3, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [7, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [14, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [15, "flash-emmc-u-boot-image-via-network-from-running-u-boot"]], "\u5728uBoot\u4e2d\u8bfb\u53d6fuse\u7684\u503c": [[1, "reading-fuse-values-in-uboot"], [3, "reading-fuse-values-in-uboot"], [4, "reading-fuse-values-in-uboot"], [5, "reading-fuse-values-in-uboot"], [7, "reading-fuse-values-in-uboot"], [8, "reading-fuse-values-in-uboot"], [9, "reading-fuse-values-in-uboot"], [11, "reading-fuse-values-in-uboot"], [13, "reading-fuse-values-in-uboot"], [14, "reading-fuse-values-in-uboot"], [15, "reading-fuse-values-in-uboot"], [16, "reading-fuse-values-in-uboot"], [17, "reading-fuse-values-in-uboot"], [18, "reading-fuse-values-in-uboot"], [19, "reading-fuse-values-in-uboot"], [22, "reading-fuse-values-in-uboot"], [23, "reading-fuse-values-in-uboot"], [24, "reading-fuse-values-in-uboot"]], "\u5728\u4e3b\u673a\u4e0a\u653e\u7f6e\u7f51\u7edc\u542f\u52a8\u7684\u955c\u50cf": [[1, "place-images-on-host-for-netboot"], [3, "place-images-on-host-for-netboot"], [4, "place-images-on-host-for-netboot"], [5, "place-images-on-host-for-netboot"], [7, "place-images-on-host-for-netboot"], [8, "place-images-on-host-for-netboot"], [9, "place-images-on-host-for-netboot"], [11, "place-images-on-host-for-netboot"], [13, "place-images-on-host-for-netboot"], [14, "place-images-on-host-for-netboot"], [15, "place-images-on-host-for-netboot"], [16, "place-images-on-host-for-netboot"], [17, "place-images-on-host-for-netboot"], [18, "place-images-on-host-for-netboot"], [19, "place-images-on-host-for-netboot"], [22, "place-images-on-host-for-netboot"], [23, "place-images-on-host-for-netboot"], [24, "place-images-on-host-for-netboot"]], "\u5728\u5f00\u53d1\u677flinux\u73af\u5883\u4e2d\u901a\u8fc7\u7f51\u7edc\u70e7\u5199SPI NOR Flash": [[1, "flash-spi-nor-from-network-in-kernel-on-target"], [3, "flash-spi-nor-from-network-in-kernel-on-target"], [4, "flash-spi-nor-from-network-in-kernel-on-target"], [5, "flash-spi-nor-from-network-in-kernel-on-target"], [7, "flash-spi-nor-from-network-in-kernel-on-target"], [8, "flash-spi-nor-from-network-in-kernel-on-target"], [9, "flash-spi-nor-from-network-in-kernel-on-target"], [11, "flash-spi-nor-from-network-in-kernel-on-target"], [14, "flash-spi-nor-from-network-in-kernel-on-target"], [15, "flash-spi-nor-from-network-in-kernel-on-target"], [16, "flash-spi-nor-from-network-in-kernel-on-target"], [17, "flash-spi-nor-from-network-in-kernel-on-target"]], "\u5728\u5f00\u53d1\u677f\u4e0a\u8fd0\u884cChromium": [[1, "get-chromium-running-on-the-target"], [3, "get-chromium-running-on-the-target"], [4, "get-chromium-running-on-the-target"], [7, "get-chromium-running-on-the-target"], [14, "get-chromium-running-on-the-target"], [15, "get-chromium-running-on-the-target"], [16, "get-chromium-running-on-the-target"]], "\u5728\u5f00\u53d1\u677f\u4e0a\u901a\u8fc7U-Boot\u4eceUSB\u70e7\u5199eMMC": [[1, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [4, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [5, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [8, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [9, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [11, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [13, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [16, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [17, "flash-emmc-from-usb-stick-in-u-boot-on-target"], [19, "flash-emmc-from-usb-stick-in-u-boot-on-target"]], "\u5728\u5f00\u53d1\u677f\u7684Linux\u7cfb\u7edf\u4e2d\u901a\u8fc7\u7f51\u7edc\u70e7\u5199eMMC": [[1, "flash-emmc-via-network-in-linux-on-target"], [3, "flash-emmc-via-network-in-linux-on-target"], [4, "flash-emmc-via-network-in-linux-on-target"], [5, "flash-emmc-via-network-in-linux-on-target"], [7, "flash-emmc-via-network-in-linux-on-target"], [8, "flash-emmc-via-network-in-linux-on-target"], [9, "flash-emmc-via-network-in-linux-on-target"], [11, "flash-emmc-via-network-in-linux-on-target"], [13, "flash-emmc-via-network-in-linux-on-target"], [14, "flash-emmc-via-network-in-linux-on-target"], [15, "flash-emmc-via-network-in-linux-on-target"], [16, "flash-emmc-via-network-in-linux-on-target"], [17, "flash-emmc-via-network-in-linux-on-target"], [18, "flash-emmc-via-network-in-linux-on-target"], [19, "flash-emmc-via-network-in-linux-on-target"], [22, "flash-emmc-via-network-in-linux-on-target"], [23, "flash-emmc-via-network-in-linux-on-target"], [24, "flash-emmc-via-network-in-linux-on-target"]], "\u5728\u5f00\u53d1\u677f\u7684U-Boot\u4e2d\u901a\u8fc7\u7f51\u7edc\u70e7\u5199eMMC": [[1, "flash-emmc-from-network-in-u-boot-on-target"], [4, "flash-emmc-from-network-in-u-boot-on-target"], [5, "flash-emmc-from-network-in-u-boot-on-target"], [8, "flash-emmc-from-network-in-u-boot-on-target"], [9, "flash-emmc-from-network-in-u-boot-on-target"], [11, "flash-emmc-from-network-in-u-boot-on-target"], [13, "flash-emmc-from-network-in-u-boot-on-target"], [16, "flash-emmc-from-network-in-u-boot-on-target"], [17, "flash-emmc-from-network-in-u-boot-on-target"], [18, "flash-emmc-from-network-in-u-boot-on-target"], [19, "flash-emmc-from-network-in-u-boot-on-target"]], "\u5728\u5f00\u53d1\u677f\u7684U-Boot\u73af\u5883\u4e2d\u4eceSD\u5361\u70e7\u5199SPI NOR": [[1, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [4, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [5, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [8, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [9, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [11, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [16, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [17, "flash-spi-nor-from-sd-card-in-u-boot-on-target"]], "\u5728\u5f00\u53d1\u677f\u7684U-Boot\u73af\u5883\u4e2d\u4eceUSB\u70e7\u5199eMMC": [[18, "flash-emmc-from-usb-in-u-boot-on-target"]], "\u5728\u5f00\u53d1\u677f\u7684U-Boot\u73af\u5883\u4e2d\u901a\u8fc7\u7f51\u7edc\u70e7\u5199SPI NOR": [[1, "flash-spi-nor-from-network-in-u-boot-on-target"], [4, "flash-spi-nor-from-network-in-u-boot-on-target"], [5, "flash-spi-nor-from-network-in-u-boot-on-target"], [8, "flash-spi-nor-from-network-in-u-boot-on-target"], [9, "flash-spi-nor-from-network-in-u-boot-on-target"], [11, "flash-spi-nor-from-network-in-u-boot-on-target"], [16, "flash-spi-nor-from-network-in-u-boot-on-target"], [17, "flash-spi-nor-from-network-in-u-boot-on-target"]], "\u5728\u5f00\u53d1\u677f\u7684linux\u73af\u5883\u4e2d\u4eceSD\u5361\u70e7\u5199SPI NOR": [[1, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [3, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [4, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [5, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [7, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [8, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [9, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [11, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [14, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [15, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [16, "flash-spi-nor-from-sd-card-in-kernel-on-target"], [17, "flash-spi-nor-from-sd-card-in-kernel-on-target"]], "\u5728\u5f00\u53d1\u677f\u7684linux\u73af\u5883\u4e2d\u901a\u8fc7SD\u5361\u70e7\u5199eMMC": [[1, "flash-emmc-from-sd-card-in-linux-on-target"], [3, "flash-emmc-from-sd-card-in-linux-on-target"], [4, "flash-emmc-from-sd-card-in-linux-on-target"], [5, "flash-emmc-from-sd-card-in-linux-on-target"], [7, "flash-emmc-from-sd-card-in-linux-on-target"], [8, "flash-emmc-from-sd-card-in-linux-on-target"], [9, "flash-emmc-from-sd-card-in-linux-on-target"], [11, "flash-emmc-from-sd-card-in-linux-on-target"], [13, "flash-emmc-from-sd-card-in-linux-on-target"], [14, "flash-emmc-from-sd-card-in-linux-on-target"], [15, "flash-emmc-from-sd-card-in-linux-on-target"], [16, "flash-emmc-from-sd-card-in-linux-on-target"], [17, "flash-emmc-from-sd-card-in-linux-on-target"], [18, "flash-emmc-from-sd-card-in-linux-on-target"], [19, "flash-emmc-from-sd-card-in-linux-on-target"], [22, "flash-emmc-from-sd-card-in-linux-on-target"], [23, "flash-emmc-from-sd-card-in-linux-on-target"], [24, "flash-emmc-from-sd-card-in-linux-on-target"]], "\u5728\u5f00\u53d1\u677f\u7684u-boot\u73af\u5883\u4e2d\u4eceSD\u5361\u70e7\u5199SPI NOR": [[3, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [7, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [14, "flash-spi-nor-from-sd-card-in-u-boot-on-target"], [15, "flash-spi-nor-from-sd-card-in-u-boot-on-target"]], "\u5728\u5f00\u53d1\u677f\u7684u-boot\u73af\u5883\u4e2d\u4ece\u7f51\u7edc\u70e7\u5199SPI NOR": [[3, "flash-spi-nor-from-network-in-u-boot-on-target"], [7, "flash-spi-nor-from-network-in-u-boot-on-target"], [14, "flash-spi-nor-from-network-in-u-boot-on-target"], [15, "flash-spi-nor-from-network-in-u-boot-on-target"]], "\u5728\u5f00\u53d1\u677f\u7684u-boot\u73af\u5883\u4e2d\u4ece\u7f51\u7edc\u70e7\u5199eMMC": [[3, "flash-emmc-from-network-in-u-boot-on-target"], [7, "flash-emmc-from-network-in-u-boot-on-target"], [14, "flash-emmc-from-network-in-u-boot-on-target"], [15, "flash-emmc-from-network-in-u-boot-on-target"]], "\u5728\u5f00\u53d1\u677f\u7684uboot\u73af\u5883\u4e2d\u901a\u8fc7SD\u5361\u70e7\u5199eMMC": [[1, "flash-emmc-from-sd-card-in-u-boot-on-target"], [4, "flash-emmc-from-sd-card-in-u-boot-on-target"], [5, "flash-emmc-from-sd-card-in-u-boot-on-target"], [8, "flash-emmc-from-sd-card-in-u-boot-on-target"], [9, "flash-emmc-from-sd-card-in-u-boot-on-target"], [11, "flash-emmc-from-sd-card-in-u-boot-on-target"], [13, "flash-emmc-from-sd-card-in-u-boot-on-target"], [16, "flash-emmc-from-sd-card-in-u-boot-on-target"], [17, "flash-emmc-from-sd-card-in-u-boot-on-target"], [18, "flash-emmc-from-sd-card-in-u-boot-on-target"], [19, "flash-emmc-from-sd-card-in-u-boot-on-target"]], "\u5728\u65e7\u7684 BSP \u7248\u672c\u5347\u7ea7 barebox \u73af\u5883": [[31, "upgrading-the-barebox-environment-from-previous-bsp-releases"], [33, "upgrading-the-barebox-environment-from-previous-bsp-releases"], [34, "upgrading-the-barebox-environment-from-previous-bsp-releases"]], "\u5728\u76ee\u6807\u4e3b\u673a\u4e0a\u8fdb\u884c\u7f16\u8bd1": [[31, "compiling-on-the-target"], [33, "compiling-on-the-target"], [34, "compiling-on-the-target"]], "\u5728\u8fd0\u884c\u7684Linux\u7cfb\u7edf\u4e2d\u4eceUSB\u70e7\u5199eMMC": [[1, "flash-emmc-from-usb-in-linux"], [3, "flash-emmc-from-usb-in-linux"], [4, "flash-emmc-from-usb-in-linux"], [5, "flash-emmc-from-usb-in-linux"], [7, "flash-emmc-from-usb-in-linux"], [8, "flash-emmc-from-usb-in-linux"], [9, "flash-emmc-from-usb-in-linux"], [11, "flash-emmc-from-usb-in-linux"], [13, "flash-emmc-from-usb-in-linux"], [14, "flash-emmc-from-usb-in-linux"], [15, "flash-emmc-from-usb-in-linux"], [16, "flash-emmc-from-usb-in-linux"], [17, "flash-emmc-from-usb-in-linux"], [18, "flash-emmc-from-usb-in-linux"], [19, "flash-emmc-from-usb-in-linux"], [22, "flash-emmc-from-usb-in-linux"], [23, "flash-emmc-from-usb-in-linux"], [24, "flash-emmc-from-usb-in-linux"]], "\u5728\u8fd0\u884c\u7684U-Boot\u4e2d\u901a\u8fc7\u7f51\u7edc\u70e7\u5199eMMC U-Boot\u955c\u50cf": [[1, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [4, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [5, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [8, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [9, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [11, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [13, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [16, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [17, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [18, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [19, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [22, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [23, "flash-emmc-u-boot-image-via-network-from-running-u-boot"], [24, "flash-emmc-u-boot-image-via-network-from-running-u-boot"]], "\u57fa\u672c\u7528\u6cd5": [[31, "basic-usage"], [33, "basic-usage"], [34, "basic-usage"]], "\u57fa\u672c\u8bbe\u7f6e": [[1, "basic-set-up"], [3, "basic-set-up"], [4, "basic-set-up"], [5, "basic-set-up"], [7, "basic-set-up"], [8, "basic-set-up"], [9, "basic-set-up"], [11, "basic-set-up"], [13, "basic-set-up"], [14, "basic-set-up"], [15, "basic-set-up"], [16, "basic-set-up"], [17, "basic-set-up"], [18, "basic-set-up"], [19, "basic-set-up"], [22, "basic-set-up"], [23, "basic-set-up"], [24, "basic-set-up"]], "\u5b89\u88c5": [[31, "installation"], [33, "installation"], [34, "installation"]], "\u5b89\u88c5SDK": [[1, "install-the-sdk"], [3, "install-the-sdk"], [4, "install-the-sdk"], [5, "install-the-sdk"], [7, "install-the-sdk"], [8, "install-the-sdk"], [9, "install-the-sdk"], [11, "install-the-sdk"], [13, "install-the-sdk"], [14, "install-the-sdk"], [15, "install-the-sdk"], [16, "install-the-sdk"], [17, "install-the-sdk"], [18, "install-the-sdk"], [19, "install-the-sdk"], [22, "install-the-sdk"], [23, "install-the-sdk"], [24, "install-the-sdk"]], "\u5b89\u88c5\u6240\u9700\u5de5\u5177": [[1, "installing-required-tools"], [3, "installing-required-tools"], [4, "installing-required-tools"], [5, "installing-required-tools"], [7, "installing-required-tools"], [8, "installing-required-tools"], [9, "installing-required-tools"], [11, "installing-required-tools"], [13, "installing-required-tools"], [14, "installing-required-tools"], [15, "installing-required-tools"], [16, "installing-required-tools"], [17, "installing-required-tools"], [18, "installing-required-tools"], [19, "installing-required-tools"], [22, "installing-required-tools"], [23, "installing-required-tools"], [24, "installing-required-tools"]], "\u5b89\u88c5\u64cd\u4f5c\u7cfb\u7edf": [[1, "installing-the-os"], [3, "installing-the-os"], [4, "installing-the-os"], [5, "installing-the-os"], [7, "installing-the-os"], [8, "installing-the-os"], [9, "installing-the-os"], [11, "installing-the-os"], [13, "installing-the-os"], [14, "installing-the-os"], [15, "installing-the-os"], [16, "installing-the-os"], [17, "installing-the-os"], [18, "installing-the-os"], [19, "installing-the-os"], [22, "installing-the-os"], [23, "installing-the-os"], [24, "installing-the-os"]], "\u5b98\u65b9\u6587\u6863": [[31, "official-documentation"], [33, "official-documentation"], [34, "official-documentation"]], "\u5bfb\u627e\u6b63\u786e\u7684\u8bbe\u5907": [[1, "finding-the-correct-device"], [4, "finding-the-correct-device"], [5, "finding-the-correct-device"], [8, "finding-the-correct-device"], [9, "finding-the-correct-device"], [11, "finding-the-correct-device"], [13, "finding-the-correct-device"], [16, "finding-the-correct-device"], [17, "finding-the-correct-device"], [18, "finding-the-correct-device"], [19, "finding-the-correct-device"], [22, "finding-the-correct-device"], [23, "finding-the-correct-device"], [24, "finding-the-correct-device"]], "\u5c06 Linux \u56fa\u4ef6\u6dfb\u52a0\u5230\u6839\u6587\u4ef6\u7cfb\u7edf": [[31, "add-linux-firmware-files-to-the-root-filesystem"], [33, "add-linux-firmware-files-to-the-root-filesystem"], [34, "add-linux-firmware-files-to-the-root-filesystem"]], "\u5c06 SDK \u4e0e GNU Autotools \u7ed3\u5408\u4f7f\u7528": [[31, "using-the-sdk-with-gnu-autotools"], [33, "using-the-sdk-with-gnu-autotools"], [34, "using-the-sdk-with-gnu-autotools"]], "\u5c06Chromium\u6dfb\u52a0\u5230\u60a8\u7684local.conf\u6587\u4ef6\u4e2d": [[1, "adding-chromium-to-your-local-conf"], [3, "adding-chromium-to-your-local-conf"], [4, "adding-chromium-to-your-local-conf"], [7, "adding-chromium-to-your-local-conf"], [14, "adding-chromium-to-your-local-conf"], [15, "adding-chromium-to-your-local-conf"], [16, "adding-chromium-to-your-local-conf"]], "\u5c06FIT\u955c\u50cf\u548c\u5185\u6838\u6a21\u5757\u590d\u5236\u5230SD\u5361": [[1, "copy-fit-image-and-kernel-modules-to-sd-card"], [9, "copy-fit-image-and-kernel-modules-to-sd-card"], [11, "copy-fit-image-and-kernel-modules-to-sd-card"], [17, "copy-fit-image-and-kernel-modules-to-sd-card"]], "\u5c06bootloader\u70e7\u5199\u5230\u5757\u8bbe\u5907\u4e0a": [[1, "flash-the-bootloader-to-a-block-device"], [3, "flash-the-bootloader-to-a-block-device"], [4, "flash-the-bootloader-to-a-block-device"], [5, "flash-the-bootloader-to-a-block-device"], [7, "flash-the-bootloader-to-a-block-device"], [8, "flash-the-bootloader-to-a-block-device"], [9, "flash-the-bootloader-to-a-block-device"], [11, "flash-the-bootloader-to-a-block-device"], [13, "flash-the-bootloader-to-a-block-device"], [14, "flash-the-bootloader-to-a-block-device"], [15, "flash-the-bootloader-to-a-block-device"], [16, "flash-the-bootloader-to-a-block-device"], [17, "flash-the-bootloader-to-a-block-device"], [18, "flash-the-bootloader-to-a-block-device"], [19, "flash-the-bootloader-to-a-block-device"], [22, "flash-the-bootloader-to-a-block-device"], [23, "flash-the-bootloader-to-a-block-device"], [24, "flash-the-bootloader-to-a-block-device"]], "\u5c06\u5185\u6838\u590d\u5236\u5230SD\u5361": [[3, "copy-kernel-to-sd-card"], [4, "copy-kernel-to-sd-card"], [5, "copy-kernel-to-sd-card"], [7, "copy-kernel-to-sd-card"], [8, "copy-kernel-to-sd-card"], [13, "copy-kernel-to-sd-card"], [14, "copy-kernel-to-sd-card"], [15, "copy-kernel-to-sd-card"], [16, "copy-kernel-to-sd-card"], [18, "copy-kernel-to-sd-card"], [19, "copy-kernel-to-sd-card"], [22, "copy-kernel-to-sd-card"], [23, "copy-kernel-to-sd-card"], [24, "copy-kernel-to-sd-card"]], "\u5c06\u5185\u6838\u6253\u5305\u6210FIT\u955c\u50cf": [[1, "package-the-kernel-in-a-fit-image"], [9, "package-the-kernel-in-a-fit-image"], [11, "package-the-kernel-in-a-fit-image"], [17, "package-the-kernel-in-a-fit-image"]], "\u5c06\u914d\u7f6e\u7247\u6bb5\u6dfb\u52a0\u5230Recipe": [[31, "add-a-configuration-fragment-to-a-recipe"], [33, "add-a-configuration-fragment-to-a-recipe"], [34, "add-a-configuration-fragment-to-a-recipe"]], "\u5c06\u955c\u50cf\u5199\u5165SD\u5361": [[1, "write-the-image-to-sd-card"], [3, "write-the-image-to-sd-card"], [4, "write-the-image-to-sd-card"], [5, "write-the-image-to-sd-card"], [7, "write-the-image-to-sd-card"], [8, "write-the-image-to-sd-card"], [9, "write-the-image-to-sd-card"], [11, "write-the-image-to-sd-card"], [13, "write-the-image-to-sd-card"], [14, "write-the-image-to-sd-card"], [15, "write-the-image-to-sd-card"], [16, "write-the-image-to-sd-card"], [17, "write-the-image-to-sd-card"], [18, "write-the-image-to-sd-card"], [19, "write-the-image-to-sd-card"], [22, "write-the-image-to-sd-card"], [23, "write-the-image-to-sd-card"], [24, "write-the-image-to-sd-card"]], "\u5e38\u89c1\u4efb\u52a1": [[31, "common-tasks"], [33, "common-tasks"], [34, "common-tasks"]], "\u5f00\u53d1": [[1, "development"], [3, "development"], [4, "development"], [5, "development"], [7, "development"], [8, "development"], [9, "development"], [11, "development"], [13, "development"], [14, "development"], [15, "development"], [16, "development"], [17, "development"], [18, "development"], [19, "development"], [22, "development"], [23, "development"], [24, "development"]], "\u5f00\u53d1\u677f\u4e0a\u7684\u7f51\u7edc\u8bbe\u7f6e": [[1, "network-settings-on-target"], [3, "network-settings-on-target"], [4, "network-settings-on-target"], [5, "network-settings-on-target"], [7, "network-settings-on-target"], [8, "network-settings-on-target"], [9, "network-settings-on-target"], [11, "network-settings-on-target"], [14, "network-settings-on-target"], [15, "network-settings-on-target"], [16, "network-settings-on-target"], [17, "network-settings-on-target"], [22, "network-settings-on-target"], [23, "network-settings-on-target"], [24, "network-settings-on-target"]], "\u5f00\u53d1\u677f\u51c6\u5907": [[1, "prepare-target"], [3, "prepare-target"], [4, "prepare-target"], [5, "prepare-target"], [7, "prepare-target"], [8, "prepare-target"], [9, "prepare-target"], [11, "prepare-target"], [13, "prepare-target"], [14, "prepare-target"], [15, "prepare-target"], [16, "prepare-target"], [17, "prepare-target"], [18, "prepare-target"], [19, "prepare-target"], [22, "prepare-target"], [23, "prepare-target"], [24, "prepare-target"]], "\u5f00\u59cb\u4f7f\u7528": [[1, "getting-started"], [3, "getting-started"], [4, "getting-started"], [5, "getting-started"], [7, "getting-started"], [8, "getting-started"], [9, "getting-started"], [11, "getting-started"], [13, "getting-started"], [14, "getting-started"], [15, "getting-started"], [16, "getting-started"], [17, "getting-started"], [18, "getting-started"], [19, "getting-started"], [22, "getting-started"], [23, "getting-started"], [24, "getting-started"]], "\u5f00\u59cb\u6784\u5efa": [[1, "starting-the-build-process"], [3, "starting-the-build-process"], [4, "starting-the-build-process"], [5, "starting-the-build-process"], [7, "starting-the-build-process"], [8, "starting-the-build-process"], [9, "starting-the-build-process"], [11, "starting-the-build-process"], [13, "starting-the-build-process"], [14, "starting-the-build-process"], [15, "starting-the-build-process"], [16, "starting-the-build-process"], [17, "starting-the-build-process"], [18, "starting-the-build-process"], [19, "starting-the-build-process"], [22, "starting-the-build-process"], [23, "starting-the-build-process"], [24, "starting-the-build-process"], [31, "start-the-build"], [33, "start-the-build"], [34, "start-the-build"]], "\u5f53\u524drelease\u7684\u5f00\u53d1\u4e2d\u7248\u672c": [[1, "development-state-of-current-release"], [3, "development-state-of-current-release"], [4, "development-state-of-current-release"], [5, "development-state-of-current-release"], [7, "development-state-of-current-release"], [8, "development-state-of-current-release"], [9, "development-state-of-current-release"], [11, "development-state-of-current-release"], [13, "development-state-of-current-release"], [14, "development-state-of-current-release"], [15, "development-state-of-current-release"], [16, "development-state-of-current-release"], [17, "development-state-of-current-release"], [18, "development-state-of-current-release"], [19, "development-state-of-current-release"]], "\u5f55\u97f3": [[1, "capture"], [3, "capture"], [4, "capture"], [9, "capture"], [11, "capture"], [14, "capture"], [15, "capture"], [16, "capture"], [17, "capture"], [22, "capture"], [23, "capture"], [23, "id6"], [24, "capture"], [24, "id6"]], "\u6062\u590dEEPROM\u6570\u636e": [[3, "rescue-eeprom-data"], [4, "rescue-eeprom-data"], [7, "rescue-eeprom-data"], [8, "rescue-eeprom-data"], [14, "rescue-eeprom-data"], [15, "rescue-eeprom-data"], [16, "rescue-eeprom-data"], [22, "rescue-eeprom-data"], [23, "rescue-eeprom-data"], [24, "rescue-eeprom-data"]], "\u6062\u590d\u9ed8\u8ba4\u97f3\u91cf": [[1, "restore-default-volumes"], [4, "restore-default-volumes"], [9, "restore-default-volumes"], [11, "restore-default-volumes"], [16, "restore-default-volumes"], [17, "restore-default-volumes"], [22, "restore-default-volumes"], [23, "restore-default-volumes"], [23, "id4"], [24, "restore-default-volumes"], [24, "id4"]], "\u6269\u5c55CSD\u5bc4\u5b58\u5668": [[1, "extended-csd-register"], [3, "extended-csd-register"], [4, "extended-csd-register"], [5, "extended-csd-register"], [7, "extended-csd-register"], [8, "extended-csd-register"], [9, "extended-csd-register"], [11, "extended-csd-register"], [13, "extended-csd-register"], [14, "extended-csd-register"], [15, "extended-csd-register"], [16, "extended-csd-register"], [17, "extended-csd-register"], [18, "extended-csd-register"], [19, "extended-csd-register"], [22, "extended-csd-register"], [23, "extended-csd-register"], [24, "extended-csd-register"]], "\u6269\u5c55\u547d\u4ee4": [[3, "extension-command"], [4, "extension-command"], [5, "extension-command"], [7, "extension-command"], [8, "extension-command"], [14, "extension-command"], [15, "extension-command"], [16, "extension-command"]], "\u6269\u5c55\u6839\u6587\u4ef6\u7cfb\u7edf": [[1, "expand-rootfs"], [3, "expand-rootfs"], [4, "expand-rootfs"], [5, "expand-rootfs"], [7, "expand-rootfs"], [8, "expand-rootfs"], [9, "expand-rootfs"], [11, "expand-rootfs"], [13, "expand-rootfs"], [14, "expand-rootfs"], [15, "expand-rootfs"], [16, "expand-rootfs"], [17, "expand-rootfs"], [18, "expand-rootfs"], [19, "expand-rootfs"], [22, "expand-rootfs"], [23, "expand-rootfs"], [24, "expand-rootfs"]], "\u6302\u8d77\u5230RAM": [[1, "suspend-to-ram"], [3, "suspend-to-ram"], [4, "suspend-to-ram"], [5, "suspend-to-ram"], [7, "suspend-to-ram"], [8, "suspend-to-ram"], [9, "suspend-to-ram"], [11, "suspend-to-ram"], [14, "suspend-to-ram"], [15, "suspend-to-ram"], [16, "suspend-to-ram"], [17, "suspend-to-ram"], [22, "suspend-to-ram"], [23, "suspend-to-ram"], [24, "suspend-to-ram"]], "\u64ad\u653e": [[1, "playback"], [3, "playback"], [4, "playback"], [9, "playback"], [11, "playback"], [14, "playback"], [15, "playback"], [16, "playback"], [17, "playback"], [22, "playback"], [23, "playback"], [23, "id5"], [24, "playback"], [24, "id5"]], "\u64e6\u9664\u8bbe\u5907": [[1, "erasing-the-device"], [3, "erasing-the-device"], [4, "erasing-the-device"], [5, "erasing-the-device"], [7, "erasing-the-device"], [8, "erasing-the-device"], [9, "erasing-the-device"], [11, "erasing-the-device"], [13, "erasing-the-device"], [14, "erasing-the-device"], [15, "erasing-the-device"], [16, "erasing-the-device"], [17, "erasing-the-device"], [18, "erasing-the-device"], [19, "erasing-the-device"], [22, "erasing-the-device"], [23, "erasing-the-device"], [24, "erasing-the-device"]], "\u652f\u6301\u7684\u786c\u4ef6": [[1, "supported-hardware"], [3, "supported-hardware"], [4, "supported-hardware"], [5, "supported-hardware"], [7, "supported-hardware"], [8, "supported-hardware"], [9, "supported-hardware"], [11, "supported-hardware"], [13, "supported-hardware"], [14, "supported-hardware"], [15, "supported-hardware"], [16, "supported-hardware"], [17, "supported-hardware"], [18, "supported-hardware"], [19, "supported-hardware"], [22, "supported-hardware"], [23, "supported-hardware"], [24, "supported-hardware"]], "\u6545\u969c\u6392\u9664": [[31, "troubleshooting"], [33, "troubleshooting"], [34, "troubleshooting"]], "\u65e0\u7ebf\u5c40\u57df\u7f51": [[1, "wlan"], [3, "wlan"], [4, "wlan"], [5, "wlan"], [7, "wlan"], [8, "wlan"], [9, "wlan"], [11, "wlan"], [14, "wlan"], [15, "wlan"], [16, "wlan"], [17, "wlan"], [24, "wlan"]], "\u663e\u793a": [[1, "display"], [3, "display"], [4, "display"], [9, "display"], [11, "display"], [13, "display"], [14, "display"], [15, "display"], [16, "display"], [17, "display"], [18, "display"], [19, "display"], [22, "display"], [23, "display"], [24, "display"]], "\u66f4\u6539\u65e0\u7ebf\u7f51\u7edc\u914d\u7f6e": [[31, "changing-the-wireless-network-configuration"], [33, "changing-the-wireless-network-configuration"], [34, "changing-the-wireless-network-configuration"]], "\u66f4\u6539\u7f51\u7edc\u914d\u7f6e": [[31, "changing-the-network-configuration"], [33, "changing-the-network-configuration"], [34, "changing-the-network-configuration"]], "\u6838\u5fc3\u7ec4\u4ef6": [[31, "core-components"], [33, "core-components"], [34, "core-components"]], "\u683c\u5f0f\u5316SD\u5361\u542f\u52a8\u76d8\u4ee5\u5141\u8bb8\u901a\u8fc7SD\u5361\u8fdb\u884c\u70e7\u5f55": [[1, "format-sd-card"], [3, "format-sd-card"], [4, "format-sd-card"], [5, "format-sd-card"], [7, "format-sd-card"], [8, "format-sd-card"], [9, "format-sd-card"], [11, "format-sd-card"], [13, "format-sd-card"], [14, "format-sd-card"], [15, "format-sd-card"], [16, "format-sd-card"], [17, "format-sd-card"], [18, "format-sd-card"], [19, "format-sd-card"], [22, "format-sd-card"], [23, "format-sd-card"], [24, "format-sd-card"]], "\u68c0\u67e5\u60a8\u7684\u7f16\u8bd1\u914d\u7f6e": [[31, "inspect-your-build-configuration"], [33, "inspect-your-build-configuration"], [34, "inspect-your-build-configuration"]], "\u6b22\u8fce\u9605\u8bfb PHYTEC BSP \u6587\u6863": [[26, null]], "\u6dfb\u52a0 OpenCV \u5e93\u548c\u793a\u4f8b": [[31, "add-opencv-libraries-and-examples"], [33, "add-opencv-libraries-and-examples"], [34, "add-opencv-libraries-and-examples"]], "\u6dfb\u52a0\u5176\u4ed6Layer": [[31, "add-an-additional-layer"], [33, "add-an-additional-layer"], [34, "add-an-additional-layer"]], "\u70e7\u5199 SPI NOR Flash": [[1, "flash-spi-nor-flash"], [3, "flash-spi-nor-flash"], [4, "flash-spi-nor-flash"], [5, "flash-spi-nor-flash"], [7, "flash-spi-nor-flash"], [8, "flash-spi-nor-flash"], [9, "flash-spi-nor-flash"], [11, "flash-spi-nor-flash"], [14, "flash-spi-nor-flash"], [15, "flash-spi-nor-flash"], [16, "flash-spi-nor-flash"], [17, "flash-spi-nor-flash"]], "\u70e7\u5199eMMC": [[1, "flash-emmc"], [3, "flash-emmc"], [4, "flash-emmc"], [5, "flash-emmc"], [7, "flash-emmc"], [8, "flash-emmc"], [9, "flash-emmc"], [11, "flash-emmc"], [13, "flash-emmc"], [14, "flash-emmc"], [15, "flash-emmc"], [16, "flash-emmc"], [17, "flash-emmc"], [18, "flash-emmc"], [19, "flash-emmc"], [22, "flash-emmc"], [23, "flash-emmc"], [24, "flash-emmc"]], "\u70e7\u5199\u542f\u52a8fuse": [[22, "burning-boot-fuses"], [23, "burning-boot-fuses"], [24, "burning-boot-fuses"]], "\u70e7\u5f55MAC\u5730\u5740": [[22, "burning-mac-addresses"], [23, "burning-mac-addresses"], [24, "burning-mac-addresses"]], "\u70ed\u7ba1\u7406": [[1, "thermal-management"], [3, "thermal-management"], [4, "thermal-management"], [5, "thermal-management"], [7, "thermal-management"], [8, "thermal-management"], [9, "thermal-management"], [11, "thermal-management"], [13, "thermal-management"], [14, "thermal-management"], [15, "thermal-management"], [16, "thermal-management"], [17, "thermal-management"], [18, "thermal-management"], [19, "thermal-management"], [22, "thermal-management"], [23, "thermal-management"], [24, "thermal-management"]], "\u7247\u4e0a\u4e00\u6b21\u6027\u53ef\u7f16\u7a0b\u63a7\u5236\u5668 (OCOTP_CTRL) - eFuse": [[1, "on-chip-otp-controller-ocotp-ctrl-efuses"], [3, "on-chip-otp-controller-ocotp-ctrl-efuses"], [4, "on-chip-otp-controller-ocotp-ctrl-efuses"], [5, "on-chip-otp-controller-ocotp-ctrl-efuses"], [7, "on-chip-otp-controller-ocotp-ctrl-efuses"], [8, "on-chip-otp-controller-ocotp-ctrl-efuses"], [9, "on-chip-otp-controller-ocotp-ctrl-efuses"], [11, "on-chip-otp-controller-ocotp-ctrl-efuses"], [13, "on-chip-otp-controller-ocotp-ctrl-efuses"], [14, "on-chip-otp-controller-ocotp-ctrl-efuses"], [15, "on-chip-otp-controller-ocotp-ctrl-efuses"], [16, "on-chip-otp-controller-ocotp-ctrl-efuses"], [17, "on-chip-otp-controller-ocotp-ctrl-efuses"], [18, "on-chip-otp-controller-ocotp-ctrl-efuses"], [19, "on-chip-otp-controller-ocotp-ctrl-efuses"], [22, "on-chip-otp-controller-ocotp-ctrl-efuses"], [23, "on-chip-otp-controller-ocotp-ctrl-efuses"], [24, "on-chip-otp-controller-ocotp-ctrl-efuses"]], "\u72ec\u7acb\u7f16\u8bd1\u51c6\u5907": [[1, "standalone-build-preparation"], [3, "standalone-build-preparation"], [4, "standalone-build-preparation"], [5, "standalone-build-preparation"], [7, "standalone-build-preparation"], [8, "standalone-build-preparation"], [9, "standalone-build-preparation"], [11, "standalone-build-preparation"], [13, "standalone-build-preparation"], [14, "standalone-build-preparation"], [15, "standalone-build-preparation"], [16, "standalone-build-preparation"], [17, "standalone-build-preparation"], [18, "standalone-build-preparation"], [19, "standalone-build-preparation"], [22, "standalone-build-preparation"], [23, "standalone-build-preparation"], [24, "standalone-build-preparation"]], "\u751f\u6210\u955c\u50cf\u6e90\uff0c\u5f00\u542f\u79bb\u7ebf\u6784\u5efa": [[31, "generating-source-mirrors-working-offline"], [33, "generating-source-mirrors-working-offline"], [34, "generating-source-mirrors-working-offline"]], "\u7535\u6e90\u7ba1\u7406": [[1, "power-management"], [3, "power-management"], [4, "power-management"], [5, "power-management"], [7, "power-management"], [8, "power-management"], [9, "power-management"], [11, "power-management"], [13, "power-management"], [14, "power-management"], [15, "power-management"], [16, "power-management"], [17, "power-management"], [18, "power-management"], [19, "power-management"], [22, "power-management"], [23, "power-management"], [24, "power-management"]], "\u76ee\u5f55": [[2, null], [2, null], [2, null], [6, null], [6, null], [6, null], [10, null], [12, null], [12, null], [12, null], [12, null], [12, null], [12, null], [12, null], [12, null], [21, null], [21, null], [21, null], [26, null], [32, null], [32, null], [32, null]], "\u770b\u95e8\u72d7": [[1, "watchdog"], [3, "watchdog"], [4, "watchdog"], [5, "watchdog"], [7, "watchdog"], [8, "watchdog"], [9, "watchdog"], [11, "watchdog"], [13, "watchdog"], [14, "watchdog"], [15, "watchdog"], [16, "watchdog"], [17, "watchdog"], [18, "watchdog"], [19, "watchdog"], [22, "watchdog"], [23, "watchdog"], [24, "watchdog"]], "\u7981\u7528 Qt \u793a\u4f8bdemo": [[31, "disable-qt-demo"], [33, "disable-qt-demo"], [34, "disable-qt-demo"]], "\u7c7b": [[31, "classes"], [33, "classes"], [34, "classes"]], "\u7f16\u8bd1BSP": [[1, "building-the-bsp"], [3, "building-the-bsp"], [4, "building-the-bsp"], [5, "building-the-bsp"], [7, "building-the-bsp"], [8, "building-the-bsp"], [9, "building-the-bsp"], [11, "building-the-bsp"], [13, "building-the-bsp"], [14, "building-the-bsp"], [15, "building-the-bsp"], [16, "building-the-bsp"], [17, "building-the-bsp"], [18, "building-the-bsp"], [19, "building-the-bsp"], [22, "building-the-bsp"], [23, "building-the-bsp"], [24, "building-the-bsp"]], "\u7f16\u8bd1SDK": [[18, "build-the-sdk"]], "\u7f16\u8bd1bootloader": [[1, "build-the-bootloader"], [3, "build-the-bootloader"], [4, "build-the-bootloader"], [5, "build-the-bootloader"], [7, "build-the-bootloader"], [8, "build-the-bootloader"], [9, "build-the-bootloader"], [11, "build-the-bootloader"], [13, "build-the-bootloader"], [14, "build-the-bootloader"], [15, "build-the-bootloader"], [16, "build-the-bootloader"], [17, "build-the-bootloader"], [18, "build-the-bootloader"], [19, "build-the-bootloader"], [22, "build-the-bootloader"], [23, "build-the-bootloader"], [24, "build-the-bootloader"]], "\u7f16\u8bd1\u5185\u6838": [[1, "build-the-kernel"], [3, "build-the-kernel"], [4, "build-the-kernel"], [5, "build-the-kernel"], [7, "build-the-kernel"], [8, "build-the-kernel"], [9, "build-the-kernel"], [11, "build-the-kernel"], [13, "build-the-kernel"], [14, "build-the-kernel"], [15, "build-the-kernel"], [16, "build-the-kernel"], [17, "build-the-kernel"], [18, "build-the-kernel"], [19, "build-the-kernel"], [22, "build-the-kernel"], [23, "build-the-kernel"], [24, "build-the-kernel"]], "\u7f16\u8bd1\u56fa\u4ef6": [[1, "building-the-firmware"], [3, "building-the-firmware"], [4, "building-the-firmware"], [9, "building-the-firmware"], [11, "building-the-firmware"], [14, "building-the-firmware"], [15, "building-the-firmware"], [16, "building-the-firmware"], [17, "building-the-firmware"]], "\u7f16\u8bd1\u56fa\u5b9a\u7684RAM\u9891\u7387\u7684U-Boot": [[11, "build-u-boot-with-a-fixed-ram-frequency"], [13, "build-u-boot-with-a-fixed-ram-frequency"], [17, "build-u-boot-with-a-fixed-ram-frequency"], [19, "build-u-boot-with-a-fixed-ram-frequency"]], "\u7f16\u8bd1\u652f\u6301\u56fa\u5b9aRAM\u5927\u5c0f\u4e0e\u9891\u7387\u7684U-Boot": [[11, "build-u-boot-with-a-fixed-ram-size-and-frequency"], [13, "build-u-boot-with-a-fixed-ram-size-and-frequency"], [17, "build-u-boot-with-a-fixed-ram-size-and-frequency"], [19, "build-u-boot-with-a-fixed-ram-size-and-frequency"]], "\u7f16\u8bd1\u914d\u7f6e": [[31, "build-configuration"], [33, "build-configuration"], [34, "build-configuration"]], "\u7f51\u7edc": [[1, "network"], [3, "network"], [4, "network"], [5, "network"], [7, "network"], [8, "network"], [9, "network"], [11, "network"], [13, "network"], [14, "network"], [15, "network"], [16, "network"], [17, "network"], [18, "network"], [19, "network"], [22, "network"], [23, "network"], [24, "network"]], "\u7f51\u7edc\u914d\u7f6e": [[1, "network-environment-customization"], [3, "network-environment-customization"], [4, "network-environment-customization"], [5, "network-environment-customization"], [7, "network-environment-customization"], [8, "network-environment-customization"], [9, "network-environment-customization"], [11, "network-environment-customization"], [13, "network-environment-customization"], [14, "network-environment-customization"], [15, "network-environment-customization"], [16, "network-environment-customization"], [17, "network-environment-customization"], [18, "network-environment-customization"], [19, "network-environment-customization"], [22, "network-environment-customization"], [23, "network-environment-customization"], [24, "network-environment-customization"]], "\u80cc\u5149\u63a7\u5236": [[1, "backlight-control"], [3, "backlight-control"], [4, "backlight-control"], [9, "backlight-control"], [11, "backlight-control"], [13, "backlight-control"], [14, "backlight-control"], [15, "backlight-control"], [16, "backlight-control"], [17, "backlight-control"], [18, "backlight-control"], [19, "backlight-control"], [22, "backlight-control"], [23, "backlight-control"], [24, "backlight-control"]], "\u81ea\u5b9a\u4e49BSP": [[31, "bsp-customization"], [33, "bsp-customization"], [34, "bsp-customization"]], "\u83b7\u53d6 phyLinux": [[31, "get-phylinux"], [33, "get-phylinux"], [34, "get-phylinux"]], "\u83b7\u53d6BSP\u5f00\u53d1\u4e2d\u7248\u672c": [[1, "accessing-the-development-states"], [3, "accessing-the-development-states"], [4, "accessing-the-development-states"], [5, "accessing-the-development-states"], [7, "accessing-the-development-states"], [8, "accessing-the-development-states"], [9, "accessing-the-development-states"], [11, "accessing-the-development-states"], [13, "accessing-the-development-states"], [14, "accessing-the-development-states"], [15, "accessing-the-development-states"], [16, "accessing-the-development-states"], [17, "accessing-the-development-states"], [18, "accessing-the-development-states"], [19, "accessing-the-development-states"]], "\u83b7\u53d6BSP\u957f\u671f\u7ef4\u62a4\u7248\u672c\u4e4b\u95f4\u7684\u4e2d\u95f4\u5f00\u53d1\u7248\u672c": [[31, "accessing-the-development-states-between-releases"], [33, "accessing-the-development-states-between-releases"], [34, "accessing-the-development-states-between-releases"]], "\u83b7\u53d6SDK": [[1, "get-the-sdk"], [3, "get-the-sdk"], [4, "get-the-sdk"], [5, "get-the-sdk"], [7, "get-the-sdk"], [8, "get-the-sdk"], [9, "get-the-sdk"], [11, "get-the-sdk"], [13, "get-the-sdk"], [14, "get-the-sdk"], [15, "get-the-sdk"], [16, "get-the-sdk"], [17, "get-the-sdk"], [19, "get-the-sdk"], [22, "get-the-sdk"], [23, "get-the-sdk"], [24, "get-the-sdk"]], "\u83b7\u53d6\u56fa\u4ef6\u793a\u4f8b": [[1, "getting-the-firmware-examples"], [3, "getting-the-firmware-examples"], [4, "getting-the-firmware-examples"], [9, "getting-the-firmware-examples"], [11, "getting-the-firmware-examples"], [14, "getting-the-firmware-examples"], [15, "getting-the-firmware-examples"], [16, "getting-the-firmware-examples"], [17, "getting-the-firmware-examples"]], "\u83b7\u53d6\u6240\u9700\u7684\u4e8c\u8fdb\u5236\u6587\u4ef6": [[1, "get-the-needed-binaries"], [3, "get-the-needed-binaries"], [4, "get-the-needed-binaries"], [5, "get-the-needed-binaries"], [7, "get-the-needed-binaries"], [8, "get-the-needed-binaries"], [9, "get-the-needed-binaries"], [11, "get-the-needed-binaries"], [13, "get-the-needed-binaries"], [14, "get-the-needed-binaries"], [15, "get-the-needed-binaries"], [16, "get-the-needed-binaries"], [17, "get-the-needed-binaries"], [18, "get-the-needed-binaries"], [19, "get-the-needed-binaries"], [22, "get-the-needed-binaries"], [23, "get-the-needed-binaries"], [24, "get-the-needed-binaries"]], "\u83b7\u53d6\u6700\u65b0\u7684Upstream\u652f\u6301": [[1, "accessing-the-latest-upstream-support"], [3, "accessing-the-latest-upstream-support"], [4, "accessing-the-latest-upstream-support"], [5, "accessing-the-latest-upstream-support"], [7, "accessing-the-latest-upstream-support"], [8, "accessing-the-latest-upstream-support"], [9, "accessing-the-latest-upstream-support"], [11, "accessing-the-latest-upstream-support"], [13, "accessing-the-latest-upstream-support"], [14, "accessing-the-latest-upstream-support"], [15, "accessing-the-latest-upstream-support"], [16, "accessing-the-latest-upstream-support"], [17, "accessing-the-latest-upstream-support"], [18, "accessing-the-latest-upstream-support"], [19, "accessing-the-latest-upstream-support"]], "\u83b7\u53d6\u6e90\u4ee3\u7801": [[1, "get-the-source-code"], [1, "getting-the-sources"], [3, "get-the-source-code"], [3, "getting-the-sources"], [4, "get-the-source-code"], [4, "getting-the-sources"], [5, "get-the-source-code"], [7, "get-the-source-code"], [8, "get-the-source-code"], [9, "get-the-source-code"], [9, "getting-the-sources"], [11, "get-the-source-code"], [11, "getting-the-sources"], [13, "get-the-source-code"], [14, "get-the-source-code"], [14, "getting-the-sources"], [15, "get-the-source-code"], [15, "getting-the-sources"], [16, "get-the-source-code"], [16, "getting-the-sources"], [17, "get-the-source-code"], [17, "getting-the-sources"], [18, "get-the-source-code"], [19, "get-the-source-code"], [22, "get-the-source-code"], [23, "get-the-source-code"], [24, "get-the-source-code"]], "\u83b7\u53d6\u955c\u50cf": [[1, "get-images"], [3, "get-images"], [4, "get-images"], [5, "get-images"], [7, "get-images"], [8, "get-images"], [9, "get-images"], [11, "get-images"], [13, "get-images"], [14, "get-images"], [15, "get-images"], [16, "get-images"], [17, "get-images"], [18, "get-images"], [19, "get-images"], [22, "get-images"], [23, "get-images"], [24, "get-images"]], "\u84dd\u7259": [[1, "bluetooth"], [3, "bluetooth"], [4, "bluetooth"], [5, "bluetooth"], [7, "bluetooth"], [8, "bluetooth"], [9, "bluetooth"], [11, "bluetooth"], [14, "bluetooth"], [15, "bluetooth"], [16, "bluetooth"], [17, "bluetooth"]], "\u89c6\u9891": [[1, "video"], [3, "video"], [4, "video"], [9, "video"], [11, "video"], [13, "video"], [14, "video"], [15, "video"], [16, "video"], [17, "video"], [18, "video"], [19, "video"], [22, "video"], [23, "video"], [24, "video"]], "\u89c6\u9891\u4e0eGstreamer": [[1, "videos-with-gstreamer"], [3, "videos-with-gstreamer"], [4, "videos-with-gstreamer"], [9, "videos-with-gstreamer"], [11, "videos-with-gstreamer"], [13, "videos-with-gstreamer"], [14, "videos-with-gstreamer"], [15, "videos-with-gstreamer"], [16, "videos-with-gstreamer"], [17, "videos-with-gstreamer"], [18, "videos-with-gstreamer"], [19, "videos-with-gstreamer"], [22, "videos-with-gstreamer"], [23, "videos-with-gstreamer"], [24, "videos-with-gstreamer"]], "\u8bbe\u5907\u6811 (DT)": [[1, "device-tree-dt"], [3, "device-tree-dt"], [4, "device-tree-dt"], [5, "device-tree-dt"], [7, "device-tree-dt"], [8, "device-tree-dt"], [9, "device-tree-dt"], [11, "device-tree-dt"], [13, "device-tree-dt"], [14, "device-tree-dt"], [15, "device-tree-dt"], [16, "device-tree-dt"], [17, "device-tree-dt"], [18, "device-tree-dt"], [19, "device-tree-dt"], [22, "device-tree-dt"], [23, "device-tree-dt"], [24, "device-tree-dt"]], "\u8bbe\u5907\u6811Overlay": [[1, "device-tree-overlay"], [3, "device-tree-overlay"], [4, "device-tree-overlay"], [5, "device-tree-overlay"], [7, "device-tree-overlay"], [8, "device-tree-overlay"], [9, "device-tree-overlay"], [11, "device-tree-overlay"], [13, "device-tree-overlay"], [14, "device-tree-overlay"], [15, "device-tree-overlay"], [16, "device-tree-overlay"], [17, "device-tree-overlay"], [18, "device-tree-overlay"], [19, "device-tree-overlay"], [22, "device-tree-overlay"], [23, "device-tree-overlay"], [24, "device-tree-overlay"]], "\u8bbe\u5907\u6811\u7ed3\u6784": [[1, "device-tree-structure"], [3, "device-tree-structure"], [4, "device-tree-structure"], [5, "device-tree-structure"], [7, "device-tree-structure"], [8, "device-tree-structure"], [9, "device-tree-structure"], [11, "device-tree-structure"], [13, "device-tree-structure"], [14, "device-tree-structure"], [15, "device-tree-structure"], [16, "device-tree-structure"], [17, "device-tree-structure"], [18, "device-tree-structure"], [19, "device-tree-structure"], [22, "device-tree-structure"], [23, "device-tree-structure"], [24, "device-tree-structure"]], "\u8bbe\u7f6e ${overlays} \u53d8\u91cf": [[1, "set-overlays-variable"], [3, "set-overlays-variable"], [4, "set-overlays-variable"], [5, "set-overlays-variable"], [7, "set-overlays-variable"], [8, "set-overlays-variable"], [9, "set-overlays-variable"], [11, "set-overlays-variable"], [14, "set-overlays-variable"], [15, "set-overlays-variable"], [16, "set-overlays-variable"], [17, "set-overlays-variable"], [22, "set-overlays-variable"], [23, "set-overlays-variable"], [24, "set-overlays-variable"]], "\u8bbe\u7f6e\u4e3b\u673a": [[31, "setting-up-the-host"], [33, "setting-up-the-host"], [34, "setting-up-the-host"]], "\u8bbe\u7f6e\u7f51\u7edc\u542f\u52a8\u7684bootenv.txt\u6587\u4ef6": [[1, "set-the-bootenv-txt-for-netboot"], [3, "set-the-bootenv-txt-for-netboot"], [4, "set-the-bootenv-txt-for-netboot"], [5, "set-the-bootenv-txt-for-netboot"], [7, "set-the-bootenv-txt-for-netboot"], [8, "set-the-bootenv-txt-for-netboot"], [9, "set-the-bootenv-txt-for-netboot"], [11, "set-the-bootenv-txt-for-netboot"], [14, "set-the-bootenv-txt-for-netboot"], [15, "set-the-bootenv-txt-for-netboot"], [16, "set-the-bootenv-txt-for-netboot"], [17, "set-the-bootenv-txt-for-netboot"], [22, "set-the-bootenv-txt-for-netboot"], [23, "set-the-bootenv-txt-for-netboot"], [24, "set-the-bootenv-txt-for-netboot"]], "\u8bbf\u95ee\u5916\u8bbe": [[1, "accessing-peripherals"], [3, "accessing-peripherals"], [4, "accessing-peripherals"], [5, "accessing-peripherals"], [7, "accessing-peripherals"], [8, "accessing-peripherals"], [9, "accessing-peripherals"], [11, "accessing-peripherals"], [13, "accessing-peripherals"], [14, "accessing-peripherals"], [15, "accessing-peripherals"], [16, "accessing-peripherals"], [17, "accessing-peripherals"], [18, "accessing-peripherals"], [19, "accessing-peripherals"], [22, "accessing-peripherals"], [23, "accessing-peripherals"], [24, "accessing-peripherals"]], "\u8bcd\u6c47": [[31, "vocabulary"], [33, "vocabulary"], [34, "vocabulary"]], "\u8c03\u6574 ext4 \u6839\u6587\u4ef6\u7cfb\u7edf\u7684\u5927\u5c0f": [[1, "resizing-ext4-root-filesystem"], [1, "id2"], [3, "resizing-ext4-root-filesystem"], [3, "id1"], [4, "resizing-ext4-root-filesystem"], [4, "id1"], [5, "resizing-ext4-root-filesystem"], [5, "id2"], [7, "resizing-ext4-root-filesystem"], [7, "id1"], [8, "resizing-ext4-root-filesystem"], [8, "id1"], [9, "resizing-ext4-root-filesystem"], [9, "id2"], [11, "resizing-ext4-root-filesystem"], [11, "id2"], [13, "resizing-ext4-root-filesystem"], [13, "id2"], [14, "resizing-ext4-root-filesystem"], [14, "id3"], [15, "resizing-ext4-root-filesystem"], [15, "id1"], [16, "resizing-ext4-root-filesystem"], [16, "id1"], [17, "resizing-ext4-root-filesystem"], [17, "id2"], [18, "resizing-ext4-root-filesystem"], [18, "id2"], [19, "resizing-ext4-root-filesystem"], [19, "id2"], [22, "resizing-ext4-root-filesystem"], [22, "id2"], [23, "resizing-ext4-root-filesystem"], [23, "id2"], [24, "resizing-ext4-root-filesystem"], [24, "id2"]], "\u8c03\u8bd5": [[31, "debugging-the-environment"], [33, "debugging-the-environment"], [34, "debugging-the-environment"]], "\u8c03\u8bd5\u7528\u6237\u7a7a\u95f4\u5e94\u7528\u7a0b\u5e8f": [[31, "debugging-a-user-space-application"], [33, "debugging-a-user-space-application"], [34, "debugging-a-user-space-application"]], "\u8d21\u732e": [[25, null], [26, null]], "\u8fd0\u884c M33 Core \u793a\u4f8b": [[22, "running-mcore-examples"], [23, "running-mcore-examples"], [24, "running-mcore-examples"]], "\u8fd0\u884c M4 Core \u793a\u4f8b": [[1, "running-mcore-examples"], [3, "running-mcore-examples"], [4, "running-mcore-examples"]], "\u8fd0\u884c M7 Core \u793a\u4f8b": [[9, "running-mcore-examples"], [11, "running-mcore-examples"], [14, "running-mcore-examples"], [15, "running-mcore-examples"], [16, "running-mcore-examples"], [17, "running-mcore-examples"]], "\u8fd0\u884c\u5bb9\u5668": [[31, "run-container"], [33, "run-container"], [34, "run-container"]], "\u8fde\u63a5": [[1, "connect"], [3, "connect"], [4, "connect"], [5, "connect"], [7, "connect"], [8, "connect"], [9, "connect"], [11, "connect"], [14, "connect"], [14, "id2"], [15, "connect"], [16, "connect"], [17, "connect"]], "\u8fde\u63a5\u5230WLAN\u7f51\u7edc": [[1, "connecting-to-a-wlan-network"], [3, "connecting-to-a-wlan-network"], [4, "connecting-to-a-wlan-network"], [5, "connecting-to-a-wlan-network"], [7, "connecting-to-a-wlan-network"], [8, "connecting-to-a-wlan-network"], [9, "connecting-to-a-wlan-network"], [11, "connecting-to-a-wlan-network"], [14, "connecting-to-a-wlan-network"], [15, "connecting-to-a-wlan-network"], [16, "connecting-to-a-wlan-network"], [17, "connecting-to-a-wlan-network"], [24, "connecting-to-a-wlan-network"]], "\u8fde\u63a5\u81f3 WLAN \u7f51\u7edc": [[31, "connecting-to-a-wlan-network"], [33, "connecting-to-a-wlan-network"], [34, "connecting-to-a-wlan-network"]], "\u901a\u8fc7 bbappend \u6587\u4ef6\u66f4\u6539 barebox \u73af\u5883\u53d8\u91cf": [[31, "change-the-barebox-environment-via-bbappend-files"], [33, "change-the-barebox-environment-via-bbappend-files"], [34, "change-the-barebox-environment-via-bbappend-files"]], "\u901a\u8fc7Remoteproc\u5728Linux\u4e0a\u8fd0\u884c\u793a\u4f8b": [[1, "running-examples-from-linux-using-remoteproc"], [3, "running-examples-from-linux-using-remoteproc"], [4, "running-examples-from-linux-using-remoteproc"], [9, "running-examples-from-linux-using-remoteproc"], [11, "running-examples-from-linux-using-remoteproc"], [14, "running-examples-from-linux-using-remoteproc"], [15, "running-examples-from-linux-using-remoteproc"], [16, "running-examples-from-linux-using-remoteproc"], [17, "running-examples-from-linux-using-remoteproc"], [22, "running-examples-from-linux-using-remoteproc"], [23, "running-examples-from-linux-using-remoteproc"], [24, "running-examples-from-linux-using-remoteproc"]], "\u901a\u8fc7UUU\u5de5\u5177\u542f\u52a8bootloader": [[1, "starting-bootloader-via-uuu-tool"], [3, "starting-bootloader-via-uuu-tool"], [4, "starting-bootloader-via-uuu-tool"], [5, "starting-bootloader-via-uuu-tool"], [7, "starting-bootloader-via-uuu-tool"], [8, "starting-bootloader-via-uuu-tool"], [9, "starting-bootloader-via-uuu-tool"], [11, "starting-bootloader-via-uuu-tool"], [13, "starting-bootloader-via-uuu-tool"], [14, "starting-bootloader-via-uuu-tool"], [15, "starting-bootloader-via-uuu-tool"], [16, "starting-bootloader-via-uuu-tool"], [17, "starting-bootloader-via-uuu-tool"], [18, "starting-bootloader-via-uuu-tool"], [19, "starting-bootloader-via-uuu-tool"], [22, "starting-bootloader-via-uuu-tool"], [23, "starting-bootloader-via-uuu-tool"], [24, "starting-bootloader-via-uuu-tool"]], "\u901a\u8fc7UUU\u5de5\u5177\u5c06U-boot\u955c\u50cf\u70e7\u5199\u5230eMMC": [[1, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [3, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [4, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [5, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [7, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [8, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [9, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [11, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [13, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [14, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [15, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [16, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [17, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [18, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [19, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [22, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [23, "flashing-u-boot-image-to-emmc-via-uuu-tool"], [24, "flashing-u-boot-image-to-emmc-via-uuu-tool"]], "\u901a\u8fc7UUU\u5de5\u5177\u5c06wic\u955c\u50cf\u70e7\u5199\u5230eMMC": [[1, "flashing-wic-image-to-emmc-via-uuu-tool"], [3, "flashing-wic-image-to-emmc-via-uuu-tool"], [4, "flashing-wic-image-to-emmc-via-uuu-tool"], [5, "flashing-wic-image-to-emmc-via-uuu-tool"], [7, "flashing-wic-image-to-emmc-via-uuu-tool"], [8, "flashing-wic-image-to-emmc-via-uuu-tool"], [9, "flashing-wic-image-to-emmc-via-uuu-tool"], [11, "flashing-wic-image-to-emmc-via-uuu-tool"], [13, "flashing-wic-image-to-emmc-via-uuu-tool"], [14, "flashing-wic-image-to-emmc-via-uuu-tool"], [15, "flashing-wic-image-to-emmc-via-uuu-tool"], [16, "flashing-wic-image-to-emmc-via-uuu-tool"], [17, "flashing-wic-image-to-emmc-via-uuu-tool"], [18, "flashing-wic-image-to-emmc-via-uuu-tool"], [19, "flashing-wic-image-to-emmc-via-uuu-tool"], [22, "flashing-wic-image-to-emmc-via-uuu-tool"], [23, "flashing-wic-image-to-emmc-via-uuu-tool"], [24, "flashing-wic-image-to-emmc-via-uuu-tool"]], "\u901a\u8fc7UUU\u5de5\u5177\u70e7\u5199SPI NOR Flash": [[1, "flashing-spi-nor-flash-via-uuu-tool"], [5, "flashing-spi-nor-flash-via-uuu-tool"], [9, "flashing-spi-nor-flash-via-uuu-tool"], [11, "flashing-spi-nor-flash-via-uuu-tool"], [17, "flashing-spi-nor-flash-via-uuu-tool"]], "\u901a\u8fc7sysfs\u8bbf\u95eeGPIO": [[1, "gpios-via-sysfs"], [3, "gpios-via-sysfs"], [4, "gpios-via-sysfs"], [5, "gpios-via-sysfs"], [7, "gpios-via-sysfs"], [8, "gpios-via-sysfs"], [9, "gpios-via-sysfs"], [11, "gpios-via-sysfs"], [13, "gpios-via-sysfs"], [14, "gpios-via-sysfs"], [15, "gpios-via-sysfs"], [16, "gpios-via-sysfs"], [17, "gpios-via-sysfs"], [18, "gpios-via-sysfs"], [19, "gpios-via-sysfs"], [22, "gpios-via-sysfs"], [23, "gpios-via-sysfs"], [24, "gpios-via-sysfs"]], "\u901a\u8fc7\u5f00\u5173(S1)\u7684\u7b2c4\u4f4d\u5728UART1\u7684RS485/RS232\u4e4b\u95f4\u5207\u6362\u3002": [[5, "id16"], [7, "id15"], [8, "id15"]], "\u901a\u8fc7\u5f00\u5173(S1)\u7684\u7b2c5\u4f4d\u5728USB HOST/OTG\u4e4b\u95f4\u5207\u6362\u3002": [[5, "id13"], [7, "id12"], [8, "id12"]], "\u901a\u8fc7\u7528\u6237\u7a7a\u95f4\u547d\u4ee4": [[1, "via-userspace-commands"], [3, "via-userspace-commands"], [4, "via-userspace-commands"], [5, "via-userspace-commands"], [7, "via-userspace-commands"], [8, "via-userspace-commands"], [9, "via-userspace-commands"], [11, "via-userspace-commands"], [13, "via-userspace-commands"], [14, "via-userspace-commands"], [15, "via-userspace-commands"], [16, "via-userspace-commands"], [17, "via-userspace-commands"], [18, "via-userspace-commands"], [19, "via-userspace-commands"], [22, "via-userspace-commands"], [23, "via-userspace-commands"], [24, "via-userspace-commands"]], "\u901a\u8fc7\u7f51\u7edc\u70e7\u5199SPI NOR Flash": [[1, "flash-spi-nor-flash-from-network"], [3, "flash-spi-nor-flash-from-network"], [4, "flash-spi-nor-flash-from-network"], [5, "flash-spi-nor-flash-from-network"], [7, "flash-spi-nor-flash-from-network"], [8, "flash-spi-nor-flash-from-network"], [9, "flash-spi-nor-flash-from-network"], [11, "flash-spi-nor-flash-from-network"], [14, "flash-spi-nor-flash-from-network"], [15, "flash-spi-nor-flash-from-network"], [16, "flash-spi-nor-flash-from-network"], [17, "flash-spi-nor-flash-from-network"]], "\u914d\u7f6e\u6e90\u4ee3\u7801": [[1, "setup-sources"], [3, "setup-sources"], [4, "setup-sources"], [5, "setup-sources"], [7, "setup-sources"], [8, "setup-sources"], [9, "setup-sources"], [11, "setup-sources"], [13, "setup-sources"], [14, "setup-sources"], [15, "setup-sources"], [16, "setup-sources"], [17, "setup-sources"], [18, "setup-sources"], [19, "setup-sources"], [22, "setup-sources"], [23, "setup-sources"], [24, "setup-sources"]], "\u97f3\u9891": [[1, "audio"], [3, "audio"], [4, "audio"], [9, "audio"], [11, "audio"], [14, "audio"], [15, "audio"], [16, "audio"], [17, "audio"], [22, "audio"]], "\u9884\u7f16\u8bd1\u955c\u50cf": [[31, "pre-built-images"], [33, "pre-built-images"], [34, "pre-built-images"]], "\u9884\u7f16\u8bd1\u955c\u50cf\u4e2d\u63d0\u4f9b\u7684\u5de5\u5177": [[31, "tools-provided-in-the-prebuild-image"], [33, "tools-provided-in-the-prebuild-image"], [34, "tools-provided-in-the-prebuild-image"]], "\u9996\u6b21\u542f\u52a8": [[1, "first-start-up"], [3, "first-start-up"], [4, "first-start-up"], [5, "first-start-up"], [7, "first-start-up"], [8, "first-start-up"], [9, "first-start-up"], [11, "first-start-up"], [13, "first-start-up"], [14, "first-start-up"], [15, "first-start-up"], [16, "first-start-up"], [17, "first-start-up"], [18, "first-start-up"], [19, "first-start-up"], [22, "first-start-up"], [23, "first-start-up"], [24, "first-start-up"]], "\u9ad8\u7ea7\u7528\u6cd5": [[31, "advanced-usage"], [33, "advanced-usage"], [34, "advanced-usage"]]}, "docnames": ["bsp/imx8/imx8", "bsp/imx8/imx8mm/head", "bsp/imx8/imx8mm/imx8mm", "bsp/imx8/imx8mm/pd22.1.1", "bsp/imx8/imx8mm/pd23.1.0", "bsp/imx8/imx8mn/head", "bsp/imx8/imx8mn/imx8mn", "bsp/imx8/imx8mn/pd22.1.1", "bsp/imx8/imx8mn/pd23.1.0", "bsp/imx8/imx8mp-libra-fpsc/head", "bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc", "bsp/imx8/imx8mp/head", "bsp/imx8/imx8mp/imx8mp", "bsp/imx8/imx8mp/mainline-head", "bsp/imx8/imx8mp/pd22.1.1", "bsp/imx8/imx8mp/pd22.1.2", "bsp/imx8/imx8mp/pd23.1.0", "bsp/imx8/imx8mp/pd24.1.0_nxp", "bsp/imx8/imx8mp/pd24.1.1", "bsp/imx8/imx8mp/pd24.1.2", "bsp/imx9/imx9", "bsp/imx9/imx93/imx93", "bsp/imx9/imx93/pd24.1.0", "bsp/imx9/imx93/pd24.1.1", "bsp/imx9/imx93/pd24.2.0", "contributing_links", "index", "rauc/kirkstone", "rauc/manual-index", "rauc/mickledore", "rauc/scarthgap", "yocto/kirkstone", "yocto/manual-index", "yocto/mickledore", "yocto/scarthgap"], "envversion": {"sphinx": 64, "sphinx.domains.c": 3, "sphinx.domains.changeset": 1, "sphinx.domains.citation": 1, "sphinx.domains.cpp": 9, "sphinx.domains.index": 1, "sphinx.domains.javascript": 3, "sphinx.domains.math": 2, "sphinx.domains.python": 4, "sphinx.domains.rst": 2, "sphinx.domains.std": 2}, "filenames": ["bsp/imx8/imx8.rst", "bsp/imx8/imx8mm/head.rst", "bsp/imx8/imx8mm/imx8mm.rst", "bsp/imx8/imx8mm/pd22.1.1.rst", "bsp/imx8/imx8mm/pd23.1.0.rst", "bsp/imx8/imx8mn/head.rst", "bsp/imx8/imx8mn/imx8mn.rst", "bsp/imx8/imx8mn/pd22.1.1.rst", "bsp/imx8/imx8mn/pd23.1.0.rst", "bsp/imx8/imx8mp-libra-fpsc/head.rst", "bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.rst", "bsp/imx8/imx8mp/head.rst", "bsp/imx8/imx8mp/imx8mp.rst", "bsp/imx8/imx8mp/mainline-head.rst", "bsp/imx8/imx8mp/pd22.1.1.rst", "bsp/imx8/imx8mp/pd22.1.2.rst", "bsp/imx8/imx8mp/pd23.1.0.rst", "bsp/imx8/imx8mp/pd24.1.0_nxp.rst", "bsp/imx8/imx8mp/pd24.1.1.rst", "bsp/imx8/imx8mp/pd24.1.2.rst", "bsp/imx9/imx9.rst", "bsp/imx9/imx93/imx93.rst", "bsp/imx9/imx93/pd24.1.0.rst", "bsp/imx9/imx93/pd24.1.1.rst", "bsp/imx9/imx93/pd24.2.0.rst", "contributing_links.rst", "index.rst", "rauc/kirkstone.rst", "rauc/manual-index.rst", "rauc/mickledore.rst", "rauc/scarthgap.rst", "yocto/kirkstone.rst", "yocto/manual-index.rst", "yocto/mickledore.rst", "yocto/scarthgap.rst"], "indexentries": {}, "objects": {}, "objnames": {}, "objtypes": {}, "terms": {"00": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "0000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0001": [31, 33, 34], "001": [31, 33, 34], "0050": [22, 23, 24], "0051": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "0052": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0058": [22, 23, 24], "0059": [3, 4, 7, 8, 14, 15, 16], "00d": [31, 33, 34], "01": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "010": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 23], "0100": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "012": [14, 15, 16], "0123456789": [1, 3, 4, 5, 7, 8], "02": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 29, 30, 31, 33, 34], "02013": 31, "02029": 33, "03": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "03123": 34, "03513": 31, "04": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "04729": 33, "04_2": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23], "05": [1, 3, 7, 9, 11, 14, 15, 16, 17, 23, 24, 27, 29, 30], "06": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 34], "063": 31, "0644": [31, 33, 34], "07": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 30, 34], "070": 15, "077": 33, "08": [15, 17, 18, 24, 27, 29, 30, 34], "09": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 27, 29, 30, 34], "0a": [27, 29, 30], "0b0010": [22, 23, 24], "0b01": [22, 23, 24], "0c": [27, 29, 30], "0d": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0f": 15, "0pointer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "0x00": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x000000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x000004cd": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0x000764": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x01": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x0104": [1, 3, 4, 5, 7, 8], "0x1": [1, 3, 4, 5, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x10": [27, 29, 30], "0x100": [27, 29, 30], "0x100000": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "0x11": [4, 8, 16], "0x14": [27, 29, 30], "0x140": [9, 11, 13, 16, 17, 18, 19], "0x16": [1, 3, 4, 5, 7, 8], "0x18": [27, 29, 30], "0x1c0b20": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "0x1d6b": [1, 3, 4, 5, 7, 8], "0x1f": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x1ffe0000": [22, 23, 24], "0x2": [1, 3, 4, 5, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x200": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x20000103": [22, 23, 24], "0x20020000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0x20020002": [22, 23, 24], "0x201e0000": [22, 23, 24], "0x30350000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "0x30e": [22, 23, 24], "0x31e": [22, 23, 24], "0x4": [27, 29, 30], "0x40": [5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "0x400000": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "0x40480000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "0x409": [1, 3, 4, 5, 7, 8], "0x42": [1, 3, 4], "0x43810080": [22, 23, 24], "0x43820080": [22, 23, 24], "0x43830080": [22, 23, 24], "0x47400080": [22, 23, 24], "0x47510000": [22, 23, 24], "0x48000000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0x49": [14, 15], "0x4ec": [22, 23, 24], "0x4f0": [22, 23, 24], "0x4f4": [22, 23, 24], "0x50": [22, 23, 24], "0x51": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "0x567890aa": [22, 23, 24], "0x58": [22, 23, 24], "0x58000000": [1, 5, 9, 11, 17], "0x59": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "0x60": [22, 23, 24], "0x64": [22, 23, 24], "0x640": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "0x650": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "0x660": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "0x68": [22, 23, 24], "0x6c": [22, 23, 24], "0x71": [1, 5, 9, 11, 13, 17, 18, 19, 22, 23, 24], "0x7e0000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0x8": [27, 29, 30], "0x80000000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0x80000539": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0x80400000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "0x883b86a6": [27, 29, 30], "0x920000": 3, "0x960000": 7, "0x970000": [14, 15], "0xbbccddee": [22, 23, 24], "0xc": [27, 29, 30], "0xffd01234": [22, 23, 24], "10": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "100": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "1000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1001m": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1002e": [1, 5], "1006e": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "101": [13, 18, 19], "1015e": [9, 11, 14, 15, 16, 17], "1017e": 11, "102": [31, 33, 34], "1021": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "1023": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1024": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1024000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "105c": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "10min": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "10sec": [9, 11, 13, 16, 17, 19], "10us": [1, 5, 9, 11, 13, 17, 18, 19], "11": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "110": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "110i": 31, "11231010i": 33, "114660": [9, 11, 13, 16, 17, 19], "115": [22, 23, 24], "115200": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "116224": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "118755": [9, 11, 13, 16, 17, 19], "1198": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "11x11": [22, 23, 24], "12": [4, 8, 14, 15, 16, 22, 23, 24, 27, 29, 30, 31, 33, 34], "120": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1200000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "1219619": [14, 15], "123": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "12345678": [31, 33, 34], "12410534": [27, 29, 30], "12411786": [27, 29, 30], "124396": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "125kb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "128": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1280": [3, 14, 15], "1280x800": [3, 14, 15], "128k": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "13": [1, 3, 4, 5, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "1305998": [14, 15], "131": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "131072": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "1380": [3, 14, 15], "1392": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "1399": [3, 14, 15], "14": [3, 4, 7, 8, 14, 15, 16, 27, 31, 33, 34], "140": [1, 3, 4, 9, 11, 14, 15, 16, 17], "140779": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "141312": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "141456": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1440": [3, 14, 15], "1472": [22, 23, 24], "14735216": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "148": [1, 3, 4, 9, 11, 14, 15, 16, 17], "14876671": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "14876672": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "14c9c3e477d4": [31, 33, 34], "15": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "1500": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1531": [1, 3, 4, 22, 23, 24], "1532": [4, 5, 7, 8], "1549": [11, 13, 16, 17, 19], "1552": [9, 11, 13, 14, 15, 16, 17, 18, 19], "15sec": [9, 11, 13, 16, 17, 19], "16": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "160": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 27, 29, 30, 31, 33, 34], "1600000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "1616": [23, 24], "163": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "16384": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "164": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1641248": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "168": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "17": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "175412": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "178": [31, 33, 34], "1780942": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "179": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "179846": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1799": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "18": [22, 23, 24, 31, 33, 34], "18000000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "180407809": [27, 29, 30], "18100000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "181fffff": [1, 3, 4, 9, 11, 14, 15, 16, 17], "18200000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "183": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1866": [22, 23, 24], "19": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 30, 31, 33, 34], "191657": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "192": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "196608": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "1970": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "1974": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "1d": [27, 29, 30], "1e": [1, 3, 4, 9, 11, 14, 15, 16, 17], "1gb": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 18], "1gib": [5, 7, 8, 22, 23, 24], "1k": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "1kzujiclznpyjckgozlfi1m7xjgsa9h1xdk6if": [23, 24], "1m": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "1w": [22, 23, 24], "20": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 24, 27, 29, 30, 31, 33, 34], "20000": [1, 3, 4, 9, 11, 14, 15, 16, 17], "20000000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "2010": [31, 33, 34], "2019": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "2020": [1, 3, 4, 9, 11, 14, 15, 16, 17], "20200624073212": [27, 29, 30], "20200624074335": [27, 29, 30], "2021": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "2022": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 31, 33, 34], "2023": [3, 4, 7, 8, 14, 16, 27, 31], "2024": [4, 8, 15, 16, 17, 18, 19, 22, 23, 24, 29, 30, 33, 34], "2050702": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "20910ci": 31, "20a": [1, 3, 4, 9, 11, 14, 15, 16, 17], "20v7_2": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "21": [13, 18, 19, 22, 23, 24, 27, 29, 30, 31, 34], "2160": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "216x135": [3, 14, 15], "218": [1, 3, 4, 9, 11, 14, 15, 16, 17], "2192013": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "22": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "225": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "23": [3, 7, 9, 11, 14, 17, 24, 27, 29, 30, 31, 34], "232": [9, 11, 13, 14, 15, 16, 17, 18, 19], "23231211i": 33, "23300ci": 31, "2331": [1, 3, 4, 9, 11, 14, 15, 16, 17], "23900ci": 31, "24": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "240": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "2400": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "2483": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "25": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 34], "255": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "256": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "2560": [27, 29, 30], "25mhz": [9, 11, 14, 15, 16, 17], "26": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 30, 31, 33, 34], "27": [30, 31, 34], "28": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 31, 34], "28800": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "28c73e13ab4f": [31, 33, 34], "28gb": [13, 19], "29": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 34], "29360128": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "2_addr": [22, 23, 24], "2avbmulvyyqf": [23, 24], "2ch": [3, 14, 15], "2d": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "2e": [27, 29, 30], "2f": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "2ghz": [11, 13, 16, 17, 19], "2gib": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19], "2mb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "30": [31, 34], "30000000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "30200000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "30210000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "30220000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "30230000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "30240000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "3028": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "30350000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "30370000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "30436": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "30bb0000": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "30be0000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "31": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 34], "310i": 31, "31577": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "31742492672b": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "32": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "32mb": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "33": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "336609": [27, 29, 30], "33c": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "34": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 34], "340413": [27, 29, 30], "342f67f7678d7af3f77710e1b68979f638c7f4d20393f6ffd0c36beff2789070": [27, 29, 30], "35": [3, 14, 15, 34], "36": 34, "3632": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "36599c00": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "36_2": 22, "37": [22, 23, 24, 27, 29, 30, 34], "3719168": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "3733": [22, 23, 24], "3782656": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "38": 34, "3840k": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "39": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30, 34], "39253": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "3932160": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "394459": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "3b": [27, 29, 30], "3c": [27, 29, 30], "3oqaubi4acj4jrp0kelwhc0": [23, 24], "3v": [22, 23, 24], "40": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "4000000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "40000000": [22, 23, 24], "4096": [22, 23, 24], "40c": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "41": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 34], "4194kb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "42": 34, "43": 34, "43810080": [22, 23, 24], "43820080": [22, 23, 24], "43830080": [22, 23, 24], "44": 34, "44100": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "44100hz": [3, 14, 15], "443a0000": [22, 23, 24], "443i": 15, "448": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "45": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 34], "454136": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "458908": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "46": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 34], "465mb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "467286": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "47": [23, 24, 27, 29, 30, 34], "47400080": [22, 23, 24], "47510000": [22, 23, 24], "48": [27, 29, 30, 34], "480": [1, 3, 4, 5, 7, 8, 22, 23, 24], "485": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "49": [23, 24, 27, 29, 30], "49000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "497444864": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "4gb": 34, "4kib": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "4mb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "4mib": [1, 9, 11, 17], "50": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "500000": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "504607": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "505012": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "5100": [1, 3, 4, 9, 11, 14, 15, 16, 17], "512": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "512b": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "512mb": 31, "5150": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "515283": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "52": [27, 29, 30], "523285": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "5250": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "528509": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "533889": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "5350": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "537mb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "54": [27, 29, 30], "5470": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "55": 23, "55_2": 23, "56": [22, 23, 24], "567": [31, 33, 34], "57": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "57000": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "5725": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "57330": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "58": [1, 3, 4, 9, 11, 14, 15, 16, 17], "59": [3, 14, 15, 27, 29, 30], "599": [31, 33, 34], "5a0ef4b41935": [31, 33, 34], "5c": [27, 29, 30], "5d": [3, 4, 7, 8, 14, 15, 16, 31, 33, 34], "5f": [27, 29, 30], "5g5cychprbbp8e0meokprzoihxxzgtxgpiahaiea": [23, 24], "5ghz": 16, "5mm": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "60": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "60704": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "609512": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "60s": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "61": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "62453760": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "625": [22, 23, 24], "627": [31, 33, 34], "63232": [31, 33, 34], "63652757504": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "63652757504b": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "64": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "64bit": [1, 3, 4, 9, 11, 14, 15, 16, 17], "64k": [1, 3, 4, 9, 11, 14, 15, 16, 17], "64m": [31, 33, 34], "65": [27, 29, 30], "65535": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "65536": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "6593e2c7b8f6": [31, 33, 34], "66000": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "665969": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "67": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "672284": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "68": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "680": [31, 33, 34], "682104": [1, 3, 4, 9, 11, 14, 15, 16, 17], "69": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "690822": [1, 3, 4, 9, 11, 14, 15, 16, 17], "696577": [1, 3, 4, 9, 11, 14, 15, 16, 17], "6f": [27, 29, 30], "6ul": [27, 29, 30], "70": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "70000": [3, 14, 15], "7194m": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "71_2": [1, 4, 5, 8, 16], "72": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "7264": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "72_2": [3, 7, 14, 15], "7367680": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "74": [9, 11, 14, 15, 16, 17, 27, 29, 30], "7416": [27, 29, 30], "75": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "7545mb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "76": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30], "7616856064": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "7617mb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "768s": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "777": [31, 33, 34], "78": [22, 23, 24], "7b": [27, 29, 30], "7btype": [33, 34], "7d": [33, 34], "7fe12e65d770f7e657e683849681f339a996418b": [31, 33, 34], "7m": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "7oymopvz5sd3ycrswcqlkwi": [23, 24], "80": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "800": [3, 14, 15], "8000": [31, 33, 34], "800mv": [22, 23, 24], "804": [3, 14, 15], "808": [3, 14, 15], "813e": [3, 7, 14, 15], "821": [27, 29, 30], "823": [3, 14, 15], "83": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "830": [27, 29, 30], "831022": [1, 3, 4, 9, 11, 14, 15, 16, 17], "839679": [1, 3, 4, 9, 11, 14, 15, 16, 17], "84": [1, 3, 4, 9, 11, 14, 15, 16, 17], "844e": [31, 33, 34], "845435": [1, 3, 4, 9, 11, 14, 15, 16, 17], "85": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "850385": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "850mv": [22, 23, 24], "875": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "88": [3, 4, 7, 8, 14, 15, 16, 27, 29, 30, 31, 33, 34], "8c": [27, 29, 30], "8c84465b4715cc142eca2785fea09804bd970755142c9ff57e08c791e2b71f28": [27, 29, 30], "8d": [27, 29, 30], "8k": [1, 3, 4, 9, 11, 14, 15, 16, 17], "8m": [0, 27, 29, 30, 31, 33, 34], "8mplus": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "8n1": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "90": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "900": [22, 23, 24, 31, 33, 34], "900mv": [22, 23, 24], "902797": [1, 3, 4, 9, 11, 14, 15, 16, 17], "91": [22, 23, 24], "911842304": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "92": [27, 29, 30], "93": [20, 29, 30], "935": [31, 33, 34], "94": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "95": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "96": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "97": [27, 29, 30], "970278": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "99942000": [27, 29, 30], "9999": [27, 29, 30], "99q3nbm7npnnzsjip0f6p62gjaieajf7qrfmf7uyt": [23, 24], "_4gb": 15, "_4gb_2ghz": 15, "_defconfig": [15, 16], "_left": [27, 29, 30], "a0": [14, 15, 31, 33, 34], "a1": [9, 11, 16, 17, 22, 23, 24, 31, 33], "a12": [7, 14, 15], "a13": 3, "a2": [27, 29, 30, 31], "a3": [3, 7, 14, 15, 34], "a4": [27, 29, 30], "a5": [4, 8, 16, 22, 23, 24, 31, 33, 34], "a53": [1, 3, 4, 9, 11, 14, 15, 16, 17], "a55": [22, 23, 24], "a6": [1, 5, 9, 11, 13, 17, 18, 19, 27, 29, 30], "a8": [27, 29, 30], "aa": [22, 23, 24, 27, 29, 30], "ab": [27, 29, 30], "abcd": [1, 3, 4, 9, 11, 14, 15, 16, 17], "abi": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "abl": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19, 27, 29, 30], "abort": [1, 5, 9, 11, 13, 17, 18, 19], "about": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "abov": [22, 23, 24, 27, 29, 30], "ac": [27, 29, 30], "accept": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "accept_fsl_eula": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "access": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "accord": [22, 23, 24, 27, 29, 30], "account": [9, 11, 13, 16, 17, 19], "achiev": [27, 29, 30], "acl": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 31, 33, 34], "acm": [1, 3, 4, 5, 7, 8], "action": [27, 29, 30], "activ": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28], "adapt": [24, 30, 31, 33, 34], "adc": 21, "adc_in0": [23, 24], "adc_in2": [23, 24], "add": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "added": [1, 9, 11, 17, 27, 29, 30], "adding": [27, 29, 30, 31, 33, 34], "addit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 24, 27, 29, 30, 31, 33, 34], "addr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "addrconf": [1, 3, 4, 9, 11, 14, 15, 16, 17], "address": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 24, 27, 29, 30, 31, 33, 34], "adjust": [1, 3, 4, 5, 8, 9, 11, 13, 16, 17, 19, 22, 23, 24], "admin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ads7846": [31, 33, 34], "adt": [31, 33, 34], "advanc": [1, 3, 4, 9, 11, 14, 15, 16, 17], "advantag": [27, 29, 30], "advis": [27, 29, 30, 31, 33, 34], "af0cigxlmp2pl8xfu1bwb282lsedqzudqwel": [23, 24], "affect": [27, 29, 30], "after": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "afterward": [22, 23, 24, 27, 29, 30], "again": [1, 9, 11, 17, 27, 29, 30], "agent": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "agn": [1, 3, 4, 9, 11, 14, 15, 16, 17], "ago": [31, 33, 34], "ahab": [22, 23, 24], "ai": [9, 11, 14, 15, 16, 17], "albeit": [27, 29, 30], "alia": [31, 33, 34], "alias": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "all": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "allmulti": [22, 23, 24], "alloc": [22, 23, 24], "allow": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30], "allow_color": [31, 33, 34], "almost": [9, 11, 13, 16, 17, 19], "along": [27, 29, 30], "alongsid": [27, 29, 30], "alpha1": [31, 33, 34], "alpha2": [31, 34], "alreadi": [22, 23, 24, 27, 29, 30], "alsa": 22, "alsa_output": [3, 14, 15], "alsactl": [1, 4, 9, 11, 16, 17, 22, 23, 24], "also": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "altern": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19, 27, 29, 30], "alway": [22, 23, 24, 27, 29, 30], "am335x": [31, 33, 34], "am57x": [31, 33, 34], "am62ax": [27, 29, 30, 31, 33, 34], "am62x": [27, 29, 30, 31, 33, 34], "am64x": [27, 29, 30, 31, 33, 34], "am68x": [31, 33, 34], "am6x": [27, 29, 30], "am6xx": 27, "amazonaw": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "amix": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "amount": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "ampliphi": [0, 1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "an": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 24, 27, 29, 30, 31, 33, 34], "an13829": [22, 23, 24], "an13917": [22, 23, 24], "and": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "ani": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "anoth": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "ansi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "anymor": [9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "anyth": [1, 9, 11, 17], "ap": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "api": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "aplay": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "app": [31, 33, 34], "append": [1, 4, 9, 11, 16, 17, 31, 33, 34], "appli": [1, 5, 9, 11, 13, 17, 18, 19], "applic": [1, 9, 11, 17, 22, 23, 24, 27, 29, 30], "approach": [27, 29, 30], "appropri": [27, 29, 30], "apt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "arbit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "arch": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "architectur": [31, 33, 34], "archlinux": [31, 33, 34], "are": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "area": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "arecord": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "argument": [27, 29, 30, 31, 33, 34], "arm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "arm64": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "armgcc": [1, 3, 4, 9, 11, 14, 15, 16, 17], "armgcc_dir": [1, 3, 4, 9, 11, 14, 15, 16, 17], "arp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "array": [14, 15], "artefact": [22, 23, 24], "articl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "as": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "ask": [1, 9, 11, 17], "asound": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "assum": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "asym": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "async": [3, 14, 15], "at": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "atf_load_addr": [3, 7, 14, 15], "attach": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "attack": [27, 29, 30], "attempt": [27, 29, 30, 31, 33, 34], "attr": [31, 33, 34], "audio": [9, 11, 17, 21, 23], "auto": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "auto_en": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "autogen": [31, 33, 34], "automat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28], "autorev": [31, 33, 34], "auxiliari": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "av": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "avail": [9, 11, 13, 14, 15, 16, 17, 18, 19, 24, 27, 29, 30, 31, 33, 34], "awar": [27, 29, 30], "away": [27, 29, 30], "ax": [1, 5, 11], "b1": [3, 4, 7, 8, 14, 15, 16, 27, 29, 30, 31, 33, 34], "b5": [27, 29, 30], "b5a26a86c39f": [31, 33, 34], "b6": [27, 29, 30], "b9": [27, 29, 30], "ba": [14, 15, 27, 29, 30], "back": [2, 10, 12, 27, 29, 30], "backend": [27, 29, 30], "backend_update_eeprom": [27, 29, 30], "background": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "backlight": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "backlight0": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "backlight1": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "backup": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "bad": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30], "bafe46679af8c6292dba22b9d402e3119ef78c6f8b458bcb6993326060de3aa4": [27, 29, 30], "bang": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "bank": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "banner": [1, 5, 9, 11, 13, 17, 18, 19], "bar": [1, 3, 4, 5, 7, 8], "bare": [22, 23, 24], "barebox_": [31, 33, 34], "barebox_2022": [31, 33, 34], "barrier": 28, "base": [27, 29, 30], "bash": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "bashrc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "basic": [1, 9, 11, 17], "bb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "bb_env_passthrough_addit": [31, 33, 34], "bb_generate_mirror_tarbal": [31, 33, 34], "bb_no_network": [31, 33, 34], "bbapend": [31, 33, 34], "bbappend": [27, 29, 30], "bbclass": [31, 33, 34], "bblayer": [31, 33, 34], "bbnsm": 21, "bbnsm_pwrkey": [22, 23, 24], "bbu": [27, 29, 30], "bd": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "be": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "beagleboneblack": [31, 33, 34], "been": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "befor": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19, 27, 29, 30], "begin": [1, 9, 11, 17, 23, 24], "behav": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "behavior": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "behind": [1, 3, 4, 9, 11, 14, 15, 16, 17], "being": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "below": [27, 29, 30], "berr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "best": [1, 9, 11, 17], "better": [27, 29, 30], "bias": [1, 5, 9, 11, 13, 17, 18, 19], "bibak": 22, "bin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30, 31, 33, 34], "bind": [22, 23, 24, 31, 33, 34], "binutil": [1, 3, 4, 9, 11, 14, 15, 16, 17], "bison": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bitbak": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "bitrat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bkops_en": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bkops_start": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bl31": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "blacklist": [31, 33, 34], "blkdiscard": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "blkid": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "blob": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "block": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "blog": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bluetooth": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "bluetoothctl": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "bluez": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "bmap": [3, 7, 14, 15], "bmaptool": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "board": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "boardenv": [31, 33, 34], "bodi": [31, 33, 34], "boot": [2, 6, 10, 12, 21, 28], "boot0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "boot1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "boot2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "boot_": [27, 29, 30], "boot_ack": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "boot_cfg0": [22, 23, 24], "boot_cfg1": [22, 23, 24], "boot_cfg2": [22, 23, 24], "boot_cfg3": [22, 23, 24], "boot_cfgx": [22, 23, 24], "boot_mod": [22, 23, 24], "boot_ord": [27, 29, 30], "boot_partition_en": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "boot_target": [1, 9, 11, 17], "bootabl": [1, 9, 11, 17, 24], "bootarg": [27, 29, 30, 31, 33, 34], "bootaux": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "bootcmd_mfg": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bootenv": [13, 18, 19], "bootfil": [3, 4, 5, 7, 8, 14, 15, 16, 22, 23, 24], "bootflow": [1, 9, 11, 17], "bootload": 28, "bootloader_seek": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bootloader_seek_emmc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bootm": [27, 29, 30], "bootmeth": [1, 9, 11, 17], "bootmod": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bootnam": [27, 29, 30], "bootp": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19], "bootpart": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "bootscript": [1, 9, 11, 17], "bootstat": [27, 29, 30], "bootswitch": [4, 8, 16, 18], "both": [9, 11, 13, 16, 17, 19, 27, 29, 30, 31, 33, 34], "bottom": 9, "bought": 24, "bound": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19], "br": [31, 33, 34], "branch": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "branch_pn": [31, 33, 34], "brd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bridg": [1, 3, 4, 9, 11, 14, 15, 16, 17], "brief": [31, 33, 34], "bright": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "broadcast": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "broken": 24, "brp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "brp_inc": [22, 23, 24], "bs": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "bsd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bsm": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "bsp": [0, 10, 20, 25, 28, 32], "bspdir": [31, 33, 34], "bsps": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "bt_fuse_sel": [22, 23, 24], "bug": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 24], "build": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "build_ddr_releas": [1, 3, 4, 9, 11, 14, 15, 16, 17], "build_releas": [1, 3, 4, 9, 11, 14, 15, 16, 17], "buildhistori": [31, 33, 34], "built": [24, 27, 29, 30], "bundl": [22, 23, 24, 28, 31, 33, 34], "bundle_vers": [27, 29, 30], "bus": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "but": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "button": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "by": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "byt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "byte": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "c1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23], "c2": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "c3": [5, 7, 8, 24], "c4": [1, 3, 4], "c6": [27, 29, 30], "c8": [1, 3, 4, 9, 11, 14, 15, 16, 17], "ca": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30], "cabl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "cach": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "calib3d2": [31, 33, 34], "call": [27, 29, 30, 31, 33, 34], "camera": [1, 9, 11, 17], "caminand": [3, 14, 15], "caminandes_3_llamigos_720p_vp9": [1, 4, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "can": [2, 6, 10, 12, 21, 27, 29, 30, 31, 33, 34], "can0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "can1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "candump": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cangen": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cannot": [27, 29, 30], "cansend": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "capabl": [1, 3, 4, 9, 11, 14, 15, 16, 17], "captur": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "card": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "care": [27, 29, 30], "cargo": [31, 33, 34], "carrier": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "carrierboard": [3, 5, 7, 8, 14, 15], "case": [28, 31, 33, 34], "cat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "catastroph": [27, 29, 30], "categori": [31, 33, 34], "caus": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cc": [22, 23, 24, 31, 33, 34], "cc3f65cd1c1993951d7a39bdb7b7d723617ac46460f8b640cd8d1622ad6e4c17": [27, 29, 30], "ccach": [31, 33, 34], "ccmp": [31, 33, 34], "cd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "cdc": [1, 3, 4, 5, 7, 8], "cdimag": [1, 9, 11, 17], "cell": [27, 29, 30], "cert": [27, 29, 30], "cert_path": [27, 29, 30], "certain": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "certif": [27, 29, 30], "cfg": [31, 33, 34], "cfj": [31, 33, 34], "cflag": [31, 33, 34], "cgi": [31, 33, 34], "chain": [27, 29, 30], "chang": [3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 22, 23, 24, 28, 31, 33, 34], "channel": [31, 33, 34], "chapter": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "charact": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "check": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "checklist": [27, 29, 30], "checkout": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "checksum": [27, 29, 30], "chip": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "chip0": [22, 23, 24], "chmod": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "choos": [1, 9, 11, 17, 31, 33, 34], "chosen": [31, 33, 34], "chromium": [2, 6, 12, 31, 33, 34], "chrpath": [31, 33, 34], "ci": [22, 23, 24, 31, 33, 34], "ci_hdrc": [1, 3, 4, 5, 7, 8], "class": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "clean": [1, 9, 11, 17, 31, 33, 34], "cleanal": [1, 9, 11, 17], "cleansstat": [31, 33, 34], "click": [1, 9, 11, 17], "client": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19], "clk": [14, 15], "clock": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "clone": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "closer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cma": [31, 33, 34], "cmake": [1, 3, 4, 9, 11, 14, 15, 16, 17], "cmd23": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cn": [27, 29, 30], "co": [31, 33, 34], "code": [27, 29, 30, 31, 33, 34], "code5": [27, 29, 30], "codec": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "collis": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "collsn": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "color": [31, 33, 34], "com": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "combin": [27, 29, 30], "come": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "command": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "commercial_libav": [31, 33, 34], "commercial_x264": [31, 33, 34], "commit": [31, 33, 34], "common": [31, 33, 34], "communiti": [14, 15], "compat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "compil": [31, 33, 34], "complet": [1, 3, 4, 7, 8, 9, 11, 14, 15, 16, 17, 24, 27, 29, 30, 31, 33, 34], "compon": [1, 9, 11, 17], "compress": 24, "comput": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "condit": [31, 33, 34], "conf": [5, 8, 9, 11, 13, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "config": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "config_expert": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "config_extra_env_set": [31, 33, 34], "config_gpio_sysf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "config_imx8mp_libra_ram_size_1gb": 9, "config_imx8mp_libra_ram_size_2gb": 9, "config_imx8mp_libra_ram_size_4gb": 9, "config_imx8mp_libra_ram_size_fix": 9, "config_iwlwifi": [1, 3, 4, 9, 11, 14, 15, 16, 17], "config_phycore_imx8mm_ram_size_1gb": [1, 3, 4], "config_phycore_imx8mm_ram_size_2gb": [1, 3, 4], "config_phycore_imx8mm_ram_size_4gb": [1, 3, 4], "config_phycore_imx8mm_ram_size_fix": [1, 3, 4], "config_phycore_imx8mp_ram_freq_fix": [11, 13, 17, 19], "config_phycore_imx8mp_ram_size_1gb": [11, 13, 14, 15, 16, 17, 19], "config_phycore_imx8mp_ram_size_2gb": [11, 13, 14, 15, 16, 17, 19], "config_phycore_imx8mp_ram_size_4gb": [11, 13, 14, 15, 16, 17, 19], "config_phycore_imx8mp_ram_size_4gb_2ghz": 15, "config_phycore_imx8mp_ram_size_fix": [11, 13, 14, 15, 16, 17, 19], "config_phycore_imx8mp_use_1_5ghz_ram_tim": [11, 13, 17, 19], "config_phycore_imx8mp_use_2ghz_ram_tim": [11, 13, 16, 17, 19], "config_target_imx8mp_libra": 9, "config_target_phycore_imx8mm": [1, 3, 4], "config_target_phycore_imx8mp": [11, 13, 14, 15, 16, 17, 19], "configf": [1, 3, 4, 5, 7, 8], "configur": [1, 3, 4, 5, 7, 8, 9, 11, 13, 16, 17, 18, 19, 24, 28, 31, 33, 34], "configure_flag": [31, 33, 34], "confirm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "confluenc": [31, 33, 34], "connect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "connector": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "conserv": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "consider": 28, "consol": [23, 24, 27, 29, 30, 31, 33, 34], "consoleblank": [31, 33, 34], "consum": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "contact": 24, "contain": [1, 9, 11, 17, 22, 23, 24, 27, 29, 30, 33, 34], "content": [1, 9, 11, 17, 27, 29, 30, 31, 33, 34], "continu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "contrib2": [31, 33, 34], "control": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "conv": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "convert": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19, 27, 29, 30], "copi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "core": [2, 5, 7, 8, 10, 12, 13, 18, 19, 21, 27, 29, 30, 31, 33, 34], "core2": [31, 33, 34], "corpor": [1, 3, 4, 9, 11, 14, 15, 16, 17], "correct": [1, 9, 11, 17, 22, 23, 24, 27, 29, 30, 31, 33, 34], "correspond": [27, 29, 30], "cortex": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "cortexa53": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "cortexa55": [22, 23, 24], "cortexa9hf": [31, 33, 34], "cost": [22, 23, 24], "could": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "count": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "counter": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "countri": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "country_cod": [31, 33, 34], "cp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "cp2105": [9, 11, 13, 14, 15, 16, 17, 18, 19], "cpio": [31, 33, 34], "cpp": [31, 33, 34], "cpu0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cpu1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cpu2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "cpu3": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "cpufreq": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "creat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28], "creation": [27, 29, 30], "creator": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "crt": [27, 29, 30], "crtscts": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "crypto": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "cs": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 24], "csc": [22, 23, 24], "csc2": [22, 23, 24], "csi": 15, "csi1": [1, 9, 11, 14, 15, 16, 17], "csi2": [1, 9, 11, 14, 15, 16, 17], "ctrl": [31, 33, 34], "curr": [1, 3, 4], "current": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24, 27, 29, 30, 31, 33, 34], "custom": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "cut": [27, 29, 30], "cve": [31, 33, 34], "cxx": [31, 33, 34], "cxxflag": [31, 33, 34], "cycl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "cylind": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "d0": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "d4": [27, 29, 30], "d6": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "d626178e448d": [31, 33, 34], "d_": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "daemon": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dak5l8pu55": [23, 24], "data": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "databas": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "datasheet": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "date": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "db": [3, 4, 7, 8, 14, 15, 16, 27, 29, 30, 31, 33, 34], "dbatch": [31, 33, 34], "dbg": [31, 33, 34], "dbitrat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dbrp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dbrp_inc": [22, 23, 24], "dbus": [27, 29, 30], "dbus_session_bus_address": [27, 29, 30], "dc": [1, 3, 4, 27, 29, 30], "dcach": [1, 3, 4, 9, 11, 14, 15, 16, 17], "dd": [3, 7, 14, 15, 27, 29, 30, 31, 33, 34], "ddr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ddr_releas": [1, 3, 4, 9, 11, 14, 15, 16, 17], "de": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "deb": [31, 33, 34], "debian": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "debianutil": [31, 33, 34], "debug": [22, 23, 24, 31, 33, 34], "debug_build": [31, 33, 34], "debug_optim": [31, 33, 34], "dec": [27, 29, 30], "decod": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "decodebin": [1, 4, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "dedic": [27, 29, 30], "def": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "default": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "defconfig": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "defin": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "definit": [1, 9, 11, 17], "del": [31, 33, 34], "delay": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "delet": [1, 4, 9, 11, 17, 31, 33, 34], "demo": [5, 7, 8], "demonstr": [27, 29, 30], "depend": [23, 27, 29, 30, 31, 33, 34], "deploy": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "deploy_dir": 27, "deploydir": [1, 9, 11, 17], "deprec": [1, 9, 11, 17, 27, 29, 30], "describ": [1, 4, 5, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "descript": [1, 9, 11, 17, 27, 29, 30, 31, 33, 34], "descriptor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "design": 28, "desir": [1, 9, 11, 17, 27, 29, 30], "desktop": [1, 3, 4, 7, 14, 15, 16], "destdir": [31, 33, 34], "detach": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "detail": [27, 29, 30], "detect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "determin": [27, 29, 30], "dev": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "develop": [1, 3, 4, 9, 11, 14, 15, 16, 17, 27, 29, 30, 31, 33, 34], "devic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 26, 27, 29, 30, 31, 33, 34], "devicetre": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "devicex": [23, 24], "devsel": [1, 3, 4, 9, 11, 14, 15, 16, 17], "devshel": [31, 33, 34], "devtool": [14, 15], "dfs": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "dhcp": [31, 33, 34], "dhcp4": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dhcpserver": [31, 33, 34], "diagram": [27, 29, 30], "didn": [31, 33, 34], "diff": [31, 33, 34], "diffconfig": [31, 33, 34], "differ": [1, 9, 11, 13, 16, 17, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "difficult": [27, 29, 30], "diffstat": [31, 33, 34], "direct": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "directori": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "dirti": [31, 33, 34], "disabl": [3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "disc": [1, 9, 11, 17], "disconnect": [27, 29, 30], "discover": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "disk": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "display": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "distribut": [27, 29, 30, 31, 33, 34], "distro": [3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 22, 23, 24, 27, 29, 30], "dit4y1zbcks1ocwt": [23, 24], "dl_dir": [31, 33, 34], "dmesg": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dnl80211": [31, 33, 34], "dnopaus": [31, 33, 34], "do": [1, 3, 4, 7, 8, 9, 11, 13, 14, 15, 16, 17, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "do_env": [31, 33, 34], "do_env_append_phyboard": [31, 33, 34], "do_env_writ": [31, 33, 34], "do_instal": [31, 33, 34], "doc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 31, 33, 34], "docker": [27, 29, 30, 31, 33, 34], "dockerfil": [27, 29, 30], "document": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "doe": [1, 9, 11, 17, 27, 29, 30], "doefiboot": [1, 9, 11, 17], "doesn": [31, 33, 34], "dolegacyboot": [1, 9, 11, 17], "don": [1, 5, 9, 11, 13, 17, 18, 19, 31, 33, 34], "done": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "dont": [31, 33, 34], "doraucboot": [27, 29, 30], "dos": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "down": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "downgrad": 28, "downgrade_barrier_vers": [27, 29, 30], "download": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "dpms": [3, 14, 15], "dpython_execut": [14, 15], "dr_mode": [1, 3, 4], "drain": [1, 5, 9, 11, 13, 17, 18, 19], "dram": [1, 3, 4, 9, 11, 14, 15, 16, 17], "dri": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "drive": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28], "driven": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "driver": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "drm": [3, 14, 15], "drop": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ds": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "dsampl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dsi": [3, 7, 14, 15], "dsjw": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dsm": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "dsnoop": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "dt": [2, 6, 10, 12, 21], "dtb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "dtbo": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dtbs": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dtc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dts": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "dtseg1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dtseg2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dtsi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "dtso": [1, 3, 4, 5, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dual": [1, 3, 4, 5, 7, 8], "duckerhub": [31, 33, 34], "due": [9, 11, 13, 14, 15, 16, 17, 18, 19, 24, 27, 29, 30], "dummi": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24, 31, 33, 34], "dump": [31, 33, 34], "dumpimag": [1, 9, 11, 17], "dunfel": 34, "dure": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "duti": [22, 23, 24], "dvd": [1, 9, 11, 17], "dvfs": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dwc3": [1, 3, 4, 9, 11, 14, 15, 16, 17], "dyn": [27, 29, 30], "dynam": [3, 4, 5, 7, 8, 14, 15, 16, 22, 23, 31, 33, 34], "e0": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "e1": [27, 29, 30], "e2": [27, 29, 30], "e29a88b7172a": [31, 33, 34], "e6": [27, 29, 30], "eabi": [1, 3, 4, 9, 11, 14, 15, 16, 17], "each": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24, 27, 29, 30], "easiest": [1, 9, 11, 17], "east": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "ecc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "echo": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "eclips": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "ecm": [1, 3, 4, 5, 7, 8], "ecspi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ed": [27, 29, 30], "edid": [3, 14, 15], "edit": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 19, 27, 29, 30], "editor": [31, 33, 34], "edt": [9, 11, 14, 15, 16, 17, 22, 23, 24], "ee": [22, 23, 24, 27, 29, 30], "eeprom": [2, 6, 10, 12, 21, 27, 29, 30], "effect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "efi": [2, 10, 12], "efi_mgr": [1, 9, 11, 17], "eficonfig": [1, 9, 11, 17], "efus": [2, 6, 10, 12, 21], "egl": [31, 33, 34], "eglf": [31, 33, 34], "egrep": [31, 33, 34], "ehci": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "either": [1, 9, 11, 17], "elf": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "els": [27, 29, 30], "emac": [31, 33, 34], "email": [31, 33, 34], "emitdn": [31, 33, 34], "emmc": [2, 6, 10, 12, 21, 28, 31, 33], "emmc_al": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "emmcboot": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "emp": [1, 3, 4], "empti": [1, 9, 11, 17, 27, 29, 30, 31, 33, 34], "en": [27, 29, 30, 31, 33, 34], "enabl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "encap": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "encod": [3, 14, 15], "end": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "endch": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "endlba": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "endpoint": [1, 3, 4, 9, 11, 14, 15, 16, 17], "enet0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "enet1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "engin": [23, 24, 31, 33, 34], "enh_area": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "enh_size_mult": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "enh_usr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "enhanc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "enough": [27, 29, 30], "ent": [3, 4, 7, 8, 14, 15, 16, 31, 33, 34], "enter": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "entiti": [27, 29, 30], "enum": [3, 14, 15], "env": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "env_add": [31, 33, 34], "env_redund": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "env_rm": [31, 33, 34], "env_verbos": [31, 33, 34], "environ": [3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 22, 23, 24, 31, 33, 34], "eq": [27, 29, 30], "eqo": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "equival": [1, 5, 9, 11, 13, 17, 18, 19], "eras": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "eraseblock": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "err": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "error": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "es": [31, 33, 34], "essenti": [31, 33, 34], "etc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "eth": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 23, 24], "eth0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "eth1": [9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "ethernet": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "ethernet0": [9, 11, 13, 14, 15, 16, 17, 18, 19], "ethernet1": [9, 11, 13, 14, 15, 16, 17, 18, 19], "etm0700g0edh6": [22, 23, 24], "etml1010g0dka": [9, 11, 14, 15, 16, 17], "etml1010g3dra": [22, 23, 24], "etsi": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "eula": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "eval": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "even": [1, 5, 9, 11, 13, 17, 18, 19], "event": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30, 31, 33, 34], "everi": [1, 9, 11, 17, 27, 29, 30, 31, 33, 34], "everyth": [31, 33, 34], "evk_m33_": [22, 23, 24], "evk_m33_tcm_": [22, 23, 24], "evk_m33_tcm_rpmsg_lite_str_echo_rto": [22, 23, 24], "exampl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 19, 22, 23, 24, 28, 31, 33, 34], "example_categori": [1, 3, 4, 9, 11, 14, 15, 16, 17], "excel": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "except": [31, 33, 34], "exchang": [27, 29, 30], "exec": [31, 33, 34], "execstart": [27, 29, 30], "execstartpr": [27, 29, 30], "execstop": [27, 29, 30], "execstoppost": [27, 29, 30], "execut": [1, 9, 11, 17, 27, 29, 30, 31, 33, 34], "exemplari": [31, 33, 34], "exist": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "exit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "expans": [1, 3, 4, 9, 11, 14, 15, 16, 17, 24, 27, 29, 30, 31, 33, 34], "expect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "export": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "exportf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "express": [1, 3, 4, 9, 11, 14, 15, 16, 17], "ext4": [27, 29, 30], "ext4load": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "ext_csd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ext_csd_wr_rel_set": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "extcsd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "extend": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "extens": [3, 4, 5, 7, 8, 14, 15, 16], "extension_board_scan": [3, 4, 5, 7, 8, 14, 15, 16], "extern": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "externalsrc": [31, 33, 34], "externalsrc_build": [31, 33, 34], "extra_image_featur": [31, 33, 34], "extra_oecmak": [14, 15], "extract": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "f4": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "fail": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30, 31, 33, 34], "failur": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fair": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "fallback": [3, 14, 15], "fals": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 19, 31, 33, 34], "fan": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "fancontrol": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "fast": [1, 3, 4, 9, 11, 14, 15, 16, 17], "fastboot": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fat": [3, 7, 14, 15, 18], "fat16": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fat32": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fatal": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fatload": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fb": [27, 29, 30, 31, 33, 34], "fbcon": [31, 33, 34], "fd": [2, 6, 10, 12, 21], "fdatasync": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fdisk": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fdt_file": [3, 4, 5, 7, 8, 14, 15, 16, 22, 23, 24], "featur": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "feb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fec": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fedora": [1, 9, 11, 17], "fetch": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "ff": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30], "fi": [27, 29, 30, 31, 33, 34], "fido": [31, 33, 34], "field": [1, 9, 11, 17], "figur": [27, 29, 30], "file": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "filenam": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "files": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "filesextrapath": [31, 33, 34], "filesextrapaths_prepend": [27, 29, 30], "filesrc": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "filesystem": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "fill": [31, 33, 34], "final": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "find": [1, 9, 11, 17, 22, 23, 24, 27, 29, 30, 31, 33, 34], "finish": [4, 8, 16, 27, 29, 30], "firefox": [31, 33, 34], "firmwar": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "firmware_": [31, 33, 34], "first": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "fit": [27, 29, 30], "fit_extens": [1, 9, 11, 17], "fitimag": [1, 9, 11, 17], "fix": [11, 13, 17, 19, 27, 29, 30], "flag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "flann2": [31, 33, 34], "flash": [2, 6, 10, 12, 13, 18, 19, 28], "flash_eras": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "flash_evk_flexspi": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "flash_singleboot": [22, 23, 24], "flashcp": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "flex": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "flexcan": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "flexibl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "flexspi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "float": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "flow": 24, "flush": [1, 3, 4, 9, 11, 14, 15, 16, 17], "focus": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "folder": [1, 9, 11, 17, 27, 29, 30, 31, 33, 34], "follow": [1, 3, 4, 9, 11, 14, 15, 16, 17, 27, 29, 30, 31, 33, 34], "foo": [1, 3, 4, 5, 7, 8], "for": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "forc": [1, 9, 11, 17, 31, 33, 34], "force_ro": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "format": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "former": [27, 29, 30], "found": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "fpdlink": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "fpsc": 0, "fragment": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 31, 33, 34], "frame": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "framework": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "freedesktop": [31, 33, 34], "freerto": [22, 23, 24], "freescal": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "frequenc": [11, 13, 17, 19, 22, 23, 24], "from": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "fs": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fsb_s400_fuse0": [22, 23, 24], "fsck": [31, 33, 34], "fsl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "fsl_sdhc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "fspi": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "fstab": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fsync": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "ftl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ftp": [31, 33, 34], "full": [27, 29, 30], "full_optim": [31, 33, 34], "fulli": [27, 29, 30], "fullscreen": [13, 18, 19], "function": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "fusemap": [22, 23, 24], "futur": [1, 9, 11, 17, 27, 29, 30], "fw_env": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "fw_printenv": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30], "fw_setenv": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30], "g1": [1, 3, 4, 5, 7, 8], "gadget": [1, 3, 4, 5, 7, 8], "gateway": [31, 33, 34], "gatewayip": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "gawk": [31, 33, 34], "gb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "gbit": [9, 11, 13, 14, 15, 16, 17, 18, 19], "gcc": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "gdb": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "gen": [1, 3, 4, 9, 11, 14, 15, 16, 17], "general": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "generat": [27, 29, 30], "genrsa": [23, 24], "get": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "ghostscript": [31, 33, 34], "ghz": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gib": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "git": [25, 27, 29, 30, 32], "git2": [31, 33, 34], "gitconfig": [31, 33, 34], "github": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25], "gitignor": [31, 33, 34], "given": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gl": [1, 3, 4, 7, 14, 15, 16], "glibc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "global": [27, 29, 30, 31, 33, 34], "gmbh": [27, 29, 30], "gmt": [27, 29, 30], "gnd": [22, 23, 24], "gnome": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gnu": [1, 3, 4, 9, 11, 14, 15, 16, 17], "gnueabi": [31, 33, 34], "gnuplot": [31, 33, 34], "go": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "good": [3, 14, 15, 27, 29, 30], "googl": [31, 33, 34], "goto": [27, 29, 30], "governor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpio": [2, 6, 10, 12, 21], "gpio1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpio4": [22, 23, 24], "gpio4_07": [22, 23, 24], "gpio5": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "gpio5_07": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "gpiochip": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiochip0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiochip1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiochip128": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "gpiochip2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiochip3": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiochip32": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiochip4": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiochip64": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiochip96": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpiodetect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpioget": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpioinfo": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpioset": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gplay": [3, 14, 15], "gpt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "gpu2": [31, 33, 34], "grade": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "graphic": [31, 33, 34], "green": [22, 23, 24], "grep": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "gro_max_s": [22, 23, 24], "group": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "grub": [1, 9, 11, 17], "grubaa64": [1, 9, 11, 17], "gs": [31, 33, 34], "gs0": [1, 3, 4, 5, 7, 8], "gso_max_s": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gso_max_seg": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gst": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gstreamer": [31, 33, 34], "gt": [27, 29, 30], "gtk": [31, 33, 34], "guarante": [1, 5, 9, 11, 13, 17, 18, 19], "gui": [31, 33, 34], "guid": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "gz": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "h264pars": [3, 14, 15], "handl": [27, 29, 30, 31, 33, 34], "handlepowerkey": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "handler": [27, 29, 30], "handshak": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hap": [1, 3, 4, 9, 11, 14, 15, 16, 17], "happen": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "hard": 24, "hardknott": [3, 7, 14, 15, 27, 29, 30], "hardnkott": 34, "hardwar": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "has": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "have": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "hci0": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "hciconfig": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "hcitool": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "hdisp": [3, 14, 15], "hdmi": [9, 11, 14, 15, 16, 17], "hdrc": [22, 23, 24], "head": [0, 1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "headless": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "heartbeat": [22, 23, 24], "help": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "henc": [22, 23, 24], "here": [1, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "hex": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "hexdump": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hh": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "high": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "highgui2": [31, 33, 34], "hit": [27, 29, 30], "hold": [1, 5, 9, 11, 13, 17, 18, 19, 27, 29, 30], "home": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "hook": [27, 29, 30], "host": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "host0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hostapd": [31, 33, 34], "hostnam": [31, 33, 34], "hosttool": [31, 33, 34], "how": [9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30], "howev": [24, 27, 29, 30], "howto": [31, 33, 34], "hpa": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hs": [1, 3, 4, 5, 7, 8, 22, 23, 24], "hse": [3, 14, 15], "hss": [3, 14, 15], "html": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "htop": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "htot": [3, 14, 15], "http": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "https": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "hub": [31, 33, 34], "hw": 24, "hw_mode": [31, 33, 34], "hwaddr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hwclock": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "hwmon": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "hz": [3, 14, 15], "i2c0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "i2s": [1, 3, 4, 22, 23, 24], "i386": [31, 33, 34], "i7": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "i8mbswidaqabakboy8wrynhmp": [23, 24], "ic": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "id": [1, 4, 5, 7, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "id_str": [3, 4, 7, 8, 14, 15, 16, 31, 33, 34], "idea": [27, 29, 30], "identifi": [1, 5, 9, 11, 13, 17, 18, 19], "idproduct": [1, 3, 4, 5, 7, 8], "idvendor": [1, 3, 4, 5, 7, 8], "ieee80211d": [31, 33, 34], "ieee80211n": [31, 33, 34], "if": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "ifconfig": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "iio": [23, 24], "imag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "image_boot_fil": [1, 9, 11, 17], "image_featur": [31, 33, 34], "image_instal": [1, 4, 16, 31, 33, 34], "image_install_append": [3, 7, 14, 15], "imageext": [1, 5, 9, 11, 17], "imagenam": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "img": [1, 3, 4, 5, 7, 8, 22, 23, 24, 27, 29, 30], "imgproc2": [31, 33, 34], "iminfo": [1, 9, 11, 17], "immedi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 19, 22, 23, 24], "immut": [3, 14, 15], "impact": [27, 29, 30], "implement": 28, "import": [27, 29, 30, 31, 33, 34], "imx": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30, 31, 33, 34], "imx6": [31, 33, 34], "imx6qdl": [27, 29, 30], "imx6qdl_phytec_boot_st": [27, 29, 30], "imx6ul": [27, 29, 30, 31, 33, 34], "imx7": [31, 33, 34], "imx8": [31, 33, 34], "imx8_phytec_defconfig": [1, 9, 11, 17], "imx8_phytec_distro": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "imx8_phytec_platform": [3, 4, 5, 7, 8, 14, 15, 16], "imx8m": [31, 33, 34], "imx8mm": [1, 3, 4, 5, 7, 8, 14, 15, 27, 29, 30, 31, 33, 34], "imx8mm_defconfig": [1, 3, 4, 7], "imx8mn": [5, 7, 8, 27, 29, 30], "imx8mn_defconfig": [5, 7, 8], "imx8mp": [1, 9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "imx8mp_clk_ocotp_root": [14, 15], "imx8mp_defconfig": [11, 13, 14, 15, 16, 17, 18, 19], "imx8mp_libra": 9, "imx8x": [31, 33, 34], "imx9": [22, 23, 24], "imx93": [22, 23, 24, 27, 29, 30, 31, 33, 34], "imx9301": [22, 23, 24], "imx9302": [22, 23, 24], "imx93_defconfig": 22, "imx9_phytec_defconfig": 24, "imx9_phytec_distro": [22, 23, 24], "imx9_phytec_platform": [22, 23], "imx_": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "imx_rpmsg_tti": [22, 23, 24], "imx_therm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "imx_v7_defconfig": [31, 33, 34], "imx_v8_defconfig": [3, 4, 5, 7, 8, 14, 15, 16, 22, 23], "imxdrm": [31, 33, 34], "in": [3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "in_voltagey_raw": [23, 24], "inact": [1, 5, 9, 11, 13, 17, 18, 19, 27, 29, 30], "inc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "includ": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "incom": [22, 23, 24], "incorpor": [27, 29, 30], "index": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "individu": [27, 29, 30], "industri": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "inet": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "info": [27, 29, 30, 31, 33, 34], "inform": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "inherit": [31, 33, 34], "ini": [9, 11, 13, 14, 15, 16, 17, 18, 19], "init": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "init_rauc": 27, "initi": [1, 5, 9, 11, 17, 24, 28], "input": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 31, 33, 34], "insert": [1, 9, 11, 17], "insid": [27, 29, 30, 31, 33, 34], "instal": [3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "install_mod_path": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "instead": [1, 9, 11, 17, 22, 23, 24, 27, 29, 30, 31, 33, 34], "instruct": [1, 3, 4, 9, 11, 14, 15, 16, 17, 27, 29, 30], "integr": [27, 29, 30], "intel": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "interfac": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "intern": [27, 29, 30], "interpret": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "into": [1, 9, 11, 17, 27, 29, 30, 31, 33, 34], "introduct": 28, "io": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "ioctl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "ip": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "ip_dyn": [13, 18, 19], "ipaddr": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "ipk": [31, 33, 34], "iputil": [31, 33, 34], "ipv6": [1, 3, 4, 9, 11, 14, 15, 16, 17], "irq": [1, 3, 4, 9, 11, 14, 15, 16, 17], "is": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "isi": [1, 9, 11, 14, 15, 16, 17], "iso": [1, 9, 11, 17], "isp": [1, 10, 12], "issu": 25, "issuer": [27, 29, 30], "it": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "its": [1, 9, 11, 17, 27, 29, 30], "iw": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "iwlan0": [31, 33, 34], "iwlwifi": [1, 3, 4, 9, 11, 14, 15, 16, 17], "jan": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "jedec": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "jethro": [31, 33], "jinja2": [31, 33, 34], "jlink": [1, 3, 4, 9, 11, 14, 15, 16, 17], "jlinkgdbserv": [1, 3, 4, 9, 11, 14, 15, 16, 17], "journal": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "journalctl": [31, 33, 34], "jp3": [9, 11, 13, 14, 15, 16, 17, 18, 19], "jp4": [9, 11, 13, 14, 15, 16, 17, 18, 19], "js": [31, 33, 34], "jtag": [1, 3, 4, 9, 11, 14, 15, 16, 17, 24], "just": [1, 9, 11, 17], "kde": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "kea": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "keep": [27, 29, 30, 31, 33, 34], "kept": [1, 9, 11, 17], "kernel": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "kernel0": [27, 29, 30], "kernel_devicetre": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "kernel_devicetree_deploy": [1, 9, 11, 17], "kernel_module_autoload": [31, 33, 34], "kernel_module_probeconf": [31, 33, 34], "key": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 23, 24, 27, 29, 30, 31, 33, 34], "key_pow": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "keymap": [31, 33, 34], "keyr": 28, "kib": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "kill": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "kirkston": [4, 5, 8, 16, 27, 31, 34], "kit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "krogoth": [31, 33], "kvm": [31, 33, 34], "l1": [1, 3, 4, 9, 11, 14, 15, 16, 17], "l105": 24, "l106": [13, 18, 19], "l113": [9, 11, 17, 24], "l114": 24, "l122": 24, "l130": [13, 18, 19], "l133": [9, 11, 17], "l145": [13, 18, 19], "l147": 24, "l151": 24, "l155": 24, "l160": [13, 18, 19], "l169": [13, 18, 19], "l172": 24, "l173": 24, "l174": 24, "l175": [13, 18, 19], "l179": [9, 11, 17], "l181": [13, 18, 19, 24], "l182": [13, 18, 19], "l193": 24, "l194": 24, "l201": [9, 11, 17], "l202": 24, "l203": [9, 11, 17], "l208": [9, 11, 17], "l213": 24, "l214": [9, 11, 17], "l218": [9, 11, 17], "l220": [13, 18, 19], "l239": [9, 11, 17], "l251": [13, 18, 19], "l255": [9, 11, 17], "l259": 24, "l261": [13, 18, 19], "l294": [9, 11, 17], "l33": 24, "l345": [9, 11, 17], "l35": [9, 11, 17], "l373": [9, 11, 17], "l380": [9, 11, 17], "l387": [13, 18, 19], "l41": [13, 18, 19], "l412": [9, 11, 17], "l422": [9, 11, 17], "l5": [14, 15], "l50": [9, 11, 17], "l56": 24, "l58": [9, 11, 17], "l61": 24, "l62": 24, "l67": [13, 18, 19], "l76": [9, 11, 17], "l81": [13, 18, 19], "l83": 24, "l88": 24, "lab": [9, 11, 13, 14, 15, 16, 17, 18, 19], "label": [22, 23, 24, 27, 29, 30], "larger": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "last": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "last_chosen": [27, 29, 30], "latenc": [1, 3, 4, 9, 11, 14, 15, 16, 17], "later": [27, 29, 30, 31, 33, 34], "latest": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "latin1": [31, 33, 34], "launch": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "layer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "layerindex": [31, 33, 34], "layerscap": [31, 33, 34], "layout": [27, 29, 30], "lb": [1, 9, 11, 17], "lba": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lcd": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ld": [22, 23, 24, 31, 33, 34], "ldd": [31, 33, 34], "ldflag": [31, 33, 34], "lead": [31, 33, 34], "leas": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "least": [31, 33, 34], "leav": [1, 5, 9, 11, 13, 17, 18, 19], "led": [2, 6, 10, 12, 21], "led1": [3, 7, 14, 15], "led2": [3, 7, 14, 15], "led3": [3, 7, 14, 15], "leds1grp": [1, 3, 4, 5, 7, 8], "left": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24, 27, 29, 30], "legacy2": [31, 33, 34], "legacyboot": [2, 10, 12], "legacyfb_depth": [31, 33, 34], "len": [22, 23, 24], "let": [27, 29, 30], "level": [1, 3, 4], "lf": [22, 23, 24], "lib": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "libcomposit": [1, 3, 4, 5, 7, 8], "libcrypto": [31, 33, 34], "libegl1": [31, 33, 34], "libexec": 34, "libgl": [31, 33, 34], "libgpiod": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "liblz4": [31, 33, 34], "libopencv": [31, 33, 34], "libra": 0, "libra_defconfig": 9, "librari": [31, 33, 34], "libsdl1": [31, 33, 34], "libssl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "libtpm2tss": [23, 24], "libubootenv": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "libvirt": [31, 33, 34], "libyaml": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "license_flags_accept": [31, 33, 34], "lifetim": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lighttpd": [31, 33, 34], "like": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "lilo": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "line": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "link": [5, 7, 8, 13, 18, 19, 22, 23, 24, 31, 33, 34], "linux": [27, 29, 30, 32], "list": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24, 27, 29, 30, 31, 33, 34], "lmsensor": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "ln": [1, 3, 4, 5, 7, 8, 9, 11, 17, 31, 33, 34], "load": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30, 31, 33, 34], "loadaddr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "loadkey": [31, 33, 34], "loadraucfdt": 27, "loadraucimag": 27, "local": [5, 8, 9, 11, 13, 17, 18, 19, 22, 23, 24, 27, 29, 30], "localhost": [1, 3, 4, 9, 11, 14, 15, 16, 17], "locat": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "lock": [27, 29, 30], "log": [31, 33, 34], "logic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28], "logind": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "long": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "longer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24, 27, 29, 30], "look": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "lost": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lot": 27, "low": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "low_power_mode_use_cas": [22, 23, 24], "lowdriv": [22, 23, 24], "lower_up": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lpddr4_": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lpddr4_dmem_1d_": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lpddr4_dmem_1d_v202201": [22, 23, 24], "lpddr4_dmem_2d_": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lpddr4_dmem_2d_v202201": [22, 23, 24], "lpddr4_imem_1d_": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lpddr4_imem_1d_v202201": [22, 23, 24], "lpddr4_imem_2d_": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lpddr4_imem_2d_v202201": [22, 23, 24], "lpddr4_pmu_train_1d_dmem_202006": [13, 18, 19], "lpddr4_pmu_train_1d_imem_202006": [13, 18, 19], "lpddr4_pmu_train_2d_dmem_202006": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "lpddr4_pmu_train_2d_imem_202006": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "lpm": [22, 23, 24], "lpuart1_rx": [22, 23, 24], "lpyod3ib": [23, 24], "lqihanjzsvg": [23, 24], "ls": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lsblk": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lsm": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "lsof": [31, 33, 34], "lspci": [1, 3, 4, 9, 11, 14, 15, 16, 17], "lsr": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "ltr": [1, 3, 4, 9, 11, 14, 15, 16, 17], "lts": [31, 33, 34], "lun": [1, 3, 4, 5, 7, 8], "lvds": [3, 7, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "lvds0": [9, 11, 14, 15, 16, 17], "lvds1": [9, 11, 13, 14, 15, 16, 17, 18, 19], "lwb": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "lxi7": [23, 24], "m33": 21, "m4": [2, 5, 7, 8], "m7": [10, 12, 13, 18, 19], "mac": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "mac1": [22, 23, 24], "mac1_addr": [22, 23, 24], "mac2": [22, 23, 24], "mac2_addr": [22, 23, 24], "machin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "machineenv": [31, 33, 34], "machinenam": [1, 5, 9, 11, 17], "made": [27, 29, 30], "magic": [27, 29, 30], "mail": [31, 33, 34], "main": [27, 29, 30, 31, 33, 34], "mainca": [27, 29, 30], "mainlin": [0, 11, 13, 17, 18, 19, 29, 30, 31, 33, 34], "mainline_": [31, 33, 34], "maintain": [1, 5, 9, 11, 13, 17, 18, 19], "major": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30], "make": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "makefil": [31, 33, 34], "man": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "manag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 26, 27, 29, 30], "manifest": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30, 31, 33, 34], "manifest_fil": [27, 29, 30], "manual": [0, 1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 26, 27, 29, 30, 31, 33, 34], "manual_en": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "manualhead": [9, 11, 13], "manufactur": [1, 3, 4, 5, 7, 8, 14, 15, 16], "map": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "mar": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "march": [31, 33, 34], "mark": [27, 29, 30], "maskabl": [1, 3, 4, 9, 11, 14, 15, 16, 17], "mass": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mass_storag": [1, 3, 4, 5, 7, 8], "master": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "match": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "max": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "max_bright": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "max_enh_size_mult": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "maxdepth": [27, 29, 30], "maxmtu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "may": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "mayb": [31, 33, 34], "mb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "mbps": [1, 3, 4, 5, 7, 8, 22, 23, 24], "mbr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mcast": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mcp2518fd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "mcp25xxfd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "mcu": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "mcux": [1, 3, 4, 9, 11, 14, 15, 16, 17], "mcuxpresso": [1, 3, 4, 9, 11, 14, 15, 16, 17], "mcuxsdk": [1, 3, 4, 9, 11, 14, 15, 16, 17], "mean": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "measur": 28, "mechan": [27, 29, 30], "media": [1, 9, 11, 17, 27, 29, 30], "media_by_label_auto_mount_end": [27, 29, 30], "medium": [1, 9, 11, 17], "mem": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "mem_": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "memfil": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "memori": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "menu": [1, 9, 11, 17], "menuconfig": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "merg": [31, 33, 34], "mesa": [31, 33, 34], "meson": 34, "messag": [3, 4, 7, 8, 9, 11, 13, 14, 15, 16, 17, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "messtechnik": [27, 29, 30], "meta": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "metadata": [31, 33, 34], "metal": [22, 23, 24], "method": [27, 29, 30], "metric": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mfgtool": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mfloat": [31, 33, 34], "mfwwdqyjkozihvcnaqebbqadswawsajbambl5ng8y8lip2hrmdgfqzri72mqhfy6": [23, 24], "mhz": [22, 23, 24], "mib": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "mic3r": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "mickledor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 29, 33, 34], "micro": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "micron": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "microsecond": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "might": [1, 9, 11, 17, 27, 29, 30], "migrat": [27, 29, 30], "miibvqibadanbgkqhkig9w0baqefaascat8wgge7ageaakeaxsvmcbxjwuknyeuz": [23, 24], "milli": [31, 33, 34], "millisecond": [1, 5, 9, 11, 13, 17, 18, 19], "mimx8ml8_m7": [9, 11, 13, 14, 15, 16, 17, 18, 19], "mimx8mm6_m4": [1, 3, 4, 22, 23, 24], "mimx8mm_phyboard_poli": [1, 3, 4], "mimx8mp_phyboard_pollux": [9, 11, 13, 14, 15, 16, 17, 18, 19], "mind": [27, 29, 30], "mini": [0, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30, 31, 33, 34], "minicom": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "minim": [27, 29, 30], "minimum": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "minmtu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "minnow": [31, 33, 34], "minor": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30], "mipi": [3, 7, 14, 15, 16], "mira": [31, 33, 34], "mirror": [31, 33, 34], "miscellan": [31, 33, 34], "miss": [22, 23, 24], "mixer": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "mkdir": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "mkimag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ml": [14, 15], "ml2": [31, 33, 34], "mlc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mlxkjcxrhpo4hsxaloswdy9": [23, 24], "mm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mmc": [2, 6, 10, 12, 21, 27, 29, 30, 31, 33, 34], "mmc0": [3, 7, 14, 15, 22, 23, 24], "mmc1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mmc2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "mmcarg": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "mmcblk0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "mmcblk0boot0": [22, 23, 24], "mmcblk0boot1": [22, 23, 24], "mmcblk0p1": [22, 23, 24], "mmcblk0p2": [22, 23, 24], "mmcblk0rpmb": [22, 23, 24], "mmcblk1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "mmcblk1p": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mmcblk1p1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mmcblk1p2": [3, 7, 14, 15, 18, 22, 23, 24], "mmcblk2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "mmcblk2boot0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "mmcblk2boot1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "mmcblk2p1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "mmcblk2p2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "mmcblk2p5": [27, 29, 30], "mmcblk2p6": [27, 29, 30], "mmcblk2rpmb": [3, 7, 14, 15, 18], "mmcblk3": [27, 29, 30], "mmcblkp1": [3, 7, 14, 15], "mmcblkxp0": [22, 23, 24], "mmcdev": [1, 9, 11, 17], "mnt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "modalia": [31, 33, 34], "mode": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "model": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "modetest": [3, 14, 15], "modif": [31, 33, 34], "modifi": [31, 33, 34], "modprob": [1, 3, 4, 5, 7, 8, 22, 23, 24, 31, 33, 34], "modul": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "module_conf_your": [31, 33, 34], "modules_instal": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "monitor": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "month": [31, 33, 34], "more": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "mospuyg6vxvgg9xp4fcciqdhb01rohr": [23, 24], "most": [4, 8, 16, 27, 29, 30], "mount": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "mountprefix": [27, 29, 30], "move": [27, 29, 30], "mp3": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "mp4": [3, 14, 15], "mr": [1, 3, 4, 9, 11, 14, 15, 16, 17], "ms": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "msdos": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "msi": [1, 3, 4, 9, 11, 14, 15, 16, 17], "mt": [22, 23, 24], "mt25qu512a": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "mtd": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30], "mtd0": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "mtd1": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "mtd2": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "mtd3": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "mtdinfo": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "mtdpart": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "mtu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "multi": [27, 29, 30], "multiarch": [1, 3, 4, 9, 11, 14, 15, 16, 17], "multicast": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "multipl": 27, "must": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "mux": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mv": [31, 33, 34], "mx": [26, 27, 29, 30], "mx6": [27, 29, 30, 31, 33, 34], "mx6ul": [27, 29, 30, 31, 34], "mx7": 31, "mx8": [22, 23, 24, 27, 29, 30], "mx8m": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 31, 33, 34], "mx8mm": [0, 5, 7, 8, 27, 29, 30, 31], "mx8mm_iomuxc_gpio1_io01_gpio1_io1": [1, 3, 4], "mx8mm_iomuxc_gpio1_io14_gpio1_io14": [1, 3, 4], "mx8mm_iomuxc_gpio1_io15_gpio1_io15": [1, 3, 4], "mx8mm_iomuxc_sai2_rxc_uart1_dce_rx": [1, 3, 4], "mx8mm_iomuxc_sai2_rxd0_uart1_dce_rts_b": [1, 3, 4], "mx8mm_iomuxc_sai2_rxfs_uart1_dce_tx": [1, 3, 4], "mx8mm_iomuxc_sai2_txfs_uart1_dce_cts_b": [1, 3, 4], "mx8mn_iomuxc_gpio1_io01_gpio1_io1": [5, 7, 8], "mx8mn_iomuxc_gpio1_io14_gpio1_io14": [5, 7, 8], "mx8mn_iomuxc_gpio1_io15_gpio1_io15": [5, 7, 8], "mx8mn_iomuxc_sai2_rxc_uart1_dce_rx": [5, 7, 8], "mx8mn_iomuxc_sai2_rxd0_uart1_dce_rts_b": [5, 7, 8], "mx8mn_iomuxc_sai2_rxfs_uart1_dce_tx": [5, 7, 8], "mx8mn_iomuxc_sai2_txfs_uart1_dce_cts_b": [5, 7, 8], "mx8mp": [0, 1, 3, 4, 5, 7, 8, 27, 30, 31, 34], "mx8mp_iomuxc_uart1_rxd_uart1_dce_rx": [9, 11, 13, 14, 15, 16, 17, 18, 19], "mx8mp_iomuxc_uart1_txd_uart1_dce_tx": [9, 11, 13, 14, 15, 16, 17, 18, 19], "mx9": [29, 30], "mx93": [20, 29, 30, 33, 34], "mx93_fusemap": [22, 23, 24], "mx93_pad_uart1_rxd__lpuart1_rx": [22, 23, 24], "mx93_pad_uart1_txd__lpuart1_tx": [22, 23, 24], "mx93a1": [22, 23, 24], "n102": 3, "n104": 7, "n105": [14, 15, 23], "n106": [3, 5, 8], "n110": 16, "n113": 23, "n114": [22, 23], "n119": [1, 4], "n122": 23, "n125": [5, 8], "n132": [14, 15], "n133": 16, "n141": [14, 15], "n147": [7, 22, 23], "n149": 3, "n150": 16, "n151": 23, "n155": [22, 23], "n165": [14, 15], "n166": 7, "n172": 23, "n173": [22, 23], "n175": [1, 4, 16], "n180": [14, 15, 23], "n188": 3, "n190": [22, 23], "n191": 16, "n194": 23, "n195": 22, "n196": [5, 8], "n199": 16, "n201": [14, 15, 23], "n206": 7, "n207": [14, 15, 16], "n212": 16, "n216": [14, 15, 22, 23], "n220": [5, 8, 14, 15], "n223": 16, "n228": 3, "n229": 16, "n238": 7, "n240": 3, "n244": [1, 4], "n248": 7, "n254": 7, "n255": [14, 15], "n257": 1, "n259": [5, 8], "n25q256ax1": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "n26": [14, 15], "n262": 23, "n264": [5, 8, 16], "n266": 3, "n267": [5, 8, 22], "n271": 3, "n277": [3, 14, 15], "n287": 16, "n291": [1, 4], "n293": 7, "n301": [5, 8], "n309": [5, 8], "n311": [1, 4], "n315": 3, "n319": [1, 4], "n33": [16, 22, 23], "n331": [14, 15], "n335": [1, 4], "n341": [14, 15, 16], "n347": [1, 4], "n35": 7, "n351": 16, "n36": [1, 4], "n367": [14, 15], "n37": 3, "n380": 16, "n383": [1, 4], "n41": [14, 15], "n45": [5, 8], "n47": 7, "n50": [5, 8, 16], "n53": 3, "n536": 16, "n54": [1, 4], "n56": 3, "n57": [14, 15, 23], "n58": 16, "n59": [1, 4], "n61": [22, 23], "n62": [22, 23], "n71": 3, "n72": [14, 15], "n75": 7, "n76": 16, "n78": [5, 8], "n83": 23, "n87": [1, 4], "n88": [22, 23], "n98": 7, "name": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "nameservic": [22, 23, 24], "nand": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31], "nand0": [27, 29, 30], "nano": [0, 1, 3, 4, 27, 29, 30], "nash": [21, 33], "nash_defconfig": 23, "nativ": [14, 15, 31, 33, 34], "nbd0": [27, 29, 30], "nbd_disconnect": [27, 29, 30], "nblk": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "nd": [22, 23, 24], "ne": [27, 29, 30], "necessari": [27, 29, 30], "need": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "neon": [31, 33, 34], "net": [31, 33, 34], "netarg": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "netboot": [3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 22, 23, 24], "netdev_up": [1, 3, 4, 9, 11, 14, 15, 16, 17], "netmask": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "network": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "networkctl": [31, 33, 34], "networkd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "never": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "new": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "new_desc_block": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "newer": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "newli": [27, 29, 30], "newvari": [31, 33, 34], "next": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "nfsroot": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "nfssrc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "nginx": [27, 29, 30], "nice": [31, 33, 34], "night": [31, 33, 34], "nl80211": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "nmap": [31, 33, 34], "no": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "no_bootenv": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "no_extens": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "no_overlay": [3, 4, 5, 7, 8, 14, 15, 16, 22, 23, 24], "no_root_squash": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "no_subtree_check": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "noarp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "node": [4, 31, 33, 34], "nomin": [22, 23, 24], "nominaldr": [22, 23, 24], "non": [1, 3, 4, 5, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "none": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "nonfree2": [31, 33, 34], "noout": [23, 24], "nor": [2, 6, 10, 12, 13, 18, 19], "normal": [1, 3, 4, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30], "noscan": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "nostop": [31, 33, 34], "not": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "note": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "noth": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "notifi": [27, 29, 30], "now": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "nproc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "npu": [10, 12], "nslegnc23ckttnfkypjm0scaweaaq": [23, 24], "number": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "numraucm": [27, 29, 30], "numrxqueu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "numtxqueu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "nv": [27, 29, 30, 31, 33, 34], "nvmem": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "nvmem_imx_ocotp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "nvram": [1, 9, 11, 17], "nxp": [0, 1, 3, 4, 5, 7, 8, 9, 11, 13, 16, 17, 18, 19, 20, 22, 23, 24, 27, 29, 30, 31, 33, 34], "objdetect2": [31, 33, 34], "obtain": [27, 29, 30], "occupi": [27, 29, 30], "occur": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "ocl2": [31, 33, 34], "ocotp0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ocotp_ctrl": [2, 6, 10, 12, 21], "ocotp_mac_addr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ocotp_mac_addr0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ocotp_mac_addr1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ocotp_mac_addr2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ocotp_root_clk": [14, 15], "octo": [31, 33, 34], "od": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "oe": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "oecore_native_sysroot": 34, "of": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "off": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "offici": [27, 29, 30], "offset": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "offset1": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "offset2": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "often": [27, 29, 30], "oftre": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "oftree0": [27, 29, 30], "ohm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "ok": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24, 27, 29, 30], "okay": [1, 3, 4, 27, 29, 30], "old": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "old_desc_block": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "omtp": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "on": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 21, 22, 23, 27, 29, 30, 31, 33, 34], "ondemand": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "one": [1, 3, 4, 5, 7, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "oneshot": [27, 29, 30], "onli": [3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 22, 23, 24, 27, 29, 30], "onlin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "open": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "opencl": [31, 33, 34], "opencv": [14, 15], "opengl": [31, 33, 34], "openssl": [23, 24, 27, 29, 30, 31, 33, 34], "opensus": [1, 9, 11, 17], "oper": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "oppos": [27, 29, 30], "opt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "opte": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "option": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "or": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "order": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30], "ordinari": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "org": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "origin": [31, 33, 34], "os": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "oss": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "otg": [2, 6, 15, 22, 23, 24], "other": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "otherwis": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "otp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "our": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "out": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "outdoor": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "output": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "over": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28], "overdr": [22, 23, 24], "overlay1": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "overlay2": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "overlayconfignam": [1, 9, 11, 17], "overlayfilenam": [3, 4, 5, 7, 8, 14, 15, 16, 22, 23, 24], "overrun": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "overwrit": [1, 9, 11, 17], "overwritten": [1, 9, 11, 17], "own": [27, 29, 30], "ozon": [1, 3, 4, 7, 14, 15, 16], "p1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "p2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "packag": [27, 29, 30, 31, 33, 34], "package1": [31, 33, 34], "package2": [31, 33, 34], "packagegroup": [14, 15], "packet": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "pactl": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "pad": 24, "page": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "pairabl": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "param": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "paramet": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "parameternam": [31, 33, 34], "parametervalu": [31, 33, 34], "parent": [27, 29, 30], "parentbus": [22, 23, 24], "parentdev": [22, 23, 24], "pars": [1, 5, 9, 11, 13, 17, 18, 19], "part": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "partconf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "particular": [1, 5, 9, 11, 13, 17, 18, 19, 27, 29, 30], "partit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28], "partition_access": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "partition_config": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "partition_setting_complet": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "partup": [3, 7, 14, 15, 27, 29, 30], "pass": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "past": [31, 33, 34], "patch": [31, 33, 34], "path": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "path_to_fil": [3, 7, 14, 15, 18, 22, 23, 24], "pb": [31, 33, 34], "pc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "pcb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "pci": [1, 3, 4, 9, 11, 14, 15, 16, 17], "pcie": [2, 10, 12, 31, 33, 34], "pcl": [31, 33], "pcm": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "pd15": [31, 33, 34], "pd16": [31, 33, 34], "pd17": 31, "pd19": 31, "pd20": [27, 29, 30], "pd21": [31, 34], "pd22": [0, 3, 7, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 31, 34], "pd23": [0, 1, 4, 5, 8, 11, 13, 16, 17, 19, 27, 31, 34], "pd24": [0, 1, 9, 11, 13, 17, 18, 19, 20, 22, 23, 24, 29, 30, 33, 34], "pd25": 9, "pdf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "pdxx": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 34], "peb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "pebav10": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "pem": [23, 24, 27, 29, 30], "per": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "perat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "perform": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "period": [1, 5, 9, 11, 13, 17, 18, 19, 22, 23, 24], "perl": [31, 33, 34], "perm": [31, 33, 34], "persist": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "pexpect": [31, 33, 34], "pfifo_fast": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "pga": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "phase": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "phi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "phoni": [31, 33, 34], "photo2": [31, 33, 34], "phpinfo": [31, 33, 34], "phsync": [3, 14, 15], "phy1": [13, 18, 19, 22, 31, 33, 34], "phy10": [9, 11, 17], "phy13": [3, 7, 14], "phy17": [3, 7, 14, 15], "phy18": 15, "phy2": [31, 33, 34], "phy3": [1, 4, 5, 8, 16, 18, 23], "phy4": [13, 19], "phy5": [1, 4, 5, 8, 16], "phy6": 24, "phy7": [9, 11, 17], "phy8": 24, "phy9": [3, 7], "phyboard": [9, 21, 27, 29, 30, 31, 33, 34], "phyboard_mira_imx6_11": [31, 33, 34], "phybuild": [31, 33, 34], "phycore_": 27, "phycore_defconfig": 24, "phycore_fitimage_env_bootlog": [31, 33, 34], "phycore_imx8m": [31, 33, 34], "phycore_imx8mm": [1, 3, 4], "phycore_imx8mn": [5, 7, 8], "phycore_imx8mp": [11, 13, 14, 15, 16, 17, 18, 19], "phycore_imx93": [22, 23, 24], "phyflex": [31, 33, 34], "phygat": 31, "phylinux": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 32], "phylinx": [31, 33, 34], "physic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "phytec": [2, 6, 10, 12, 21, 25, 27, 29, 30, 32], "phytec_": [13, 18, 19], "pick": [31, 33, 34], "picophi": [1, 3, 4], "pid": [31, 33, 34], "pin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "pinctrl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "pinctrl_l": [1, 3, 4, 5, 7, 8], "pinctrl_uart1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ping": [31, 33, 34], "pinmux": [9, 11, 17, 24], "pip": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "pip3": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "pipelin": [22, 23, 24], "piscan": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "pixel": [22, 23, 24], "pkey": [23, 24], "pkgs": [31, 33, 34], "pki": [27, 29, 30], "pl1552": 34, "place": [27, 29, 30, 31, 33, 34], "platform": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "play": [1, 4, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "playback": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "playbin": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "pleas": [24, 31, 33, 34], "plot": [31, 33, 34], "plug": [27, 29, 30], "plus": [0, 27, 29, 30, 34], "pm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "pmbw": [31, 33, 34], "pmic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "pn": [31, 33, 34], "png": [31, 33, 34], "png16m": [31, 33, 34], "podman": [31, 33, 34], "point": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "poki": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 32], "poli": [14, 15, 27, 29, 30], "poll": [22, 23, 24], "pollux": [1, 3, 4, 5, 7, 8, 9, 34], "pool": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "popul": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "populate_sdk": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "port": [1, 3, 4, 9, 11, 14, 15, 16, 17, 24, 27, 29, 30], "port0": [1, 9, 11, 17], "port1": [1, 9, 11, 17], "posit": [31, 33, 34], "possibl": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 24, 27, 29, 30, 31, 33, 34], "post": [27, 29, 30], "power": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "poweroff": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "powersav": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "pq": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "pre": [1, 3, 4, 27, 29, 30], "prebuilt": [27, 29, 30], "prefer": [3, 9, 11, 14, 15, 17, 27, 29, 30], "preferred_provider_virtu": [31, 33, 34], "prefetch": [1, 3, 4, 9, 11, 14, 15, 16, 17], "prepare_mcor": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "prepend": [31, 33, 34], "present": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "press": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "prevent": [1, 9, 11, 17, 27, 29, 30], "previous": [27, 29, 30, 31, 33, 34], "primari": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "print": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "printenv": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "prioriti": [27, 29, 30], "priv_key": [23, 24], "privat": [23, 24, 27, 29, 30], "probe": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "problem": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "proc": [27, 29, 30], "procedur": [27, 29, 30], "proceed": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "process": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "processor": [14, 15, 22, 23, 24, 31, 33, 34], "product": [1, 3, 4, 5, 7, 8, 27, 29, 30], "produkt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "prog": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "program": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 19, 22, 23, 24, 31, 33, 34], "programm": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "progress": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "project": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "promin": [27, 29, 30], "promiscu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "prompt": [1, 9, 11, 17], "prop": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "properti": 4, "protect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "proto": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "provid": [1, 5, 9, 11, 13, 17, 18, 19, 24, 27, 29, 30, 31, 33, 34], "provis": [31, 34], "proxy_force_rang": [27, 29, 30], "pscan": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "psci": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "psk": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "pub_key": [23, 24], "pubin": [23, 24], "public": [23, 24, 27, 29, 30], "pubout": [23, 24], "pull": [1, 5, 9, 11, 13, 17, 18, 19, 25, 31, 33, 34], "pulseaudio": [5, 7, 8], "purpos": [27, 29, 30], "push": [1, 5, 9, 11, 13, 17, 18, 19, 31, 33, 34], "pvsync": [3, 14, 15], "pwd": [31, 33, 34], "pwm": [9, 11, 13, 14, 15, 16, 17, 18, 19], "pxp": 21, "pybind11": [14, 15], "pyeiq": [14, 15], "pylint3": 31, "python": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "python2": [31, 33, 34], "python3": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "q2j55l": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "q4": [1, 3, 4, 9, 11, 14, 15, 16, 17], "qdisc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "qemu": [31, 33, 34], "qlen": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "qml": [31, 33, 34], "qoriq": [31, 33, 34], "qos": [3, 14, 15], "qspi": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "qt": [5, 7, 8], "qt5demo": [3, 14, 15, 23, 31], "qt6": [1, 4, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "qt6demo": [1, 4, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "qtdemo": [3, 14, 15, 31, 33, 34], "qtdemo_git": [31, 33, 34], "qtdemux": [3, 14, 15], "qtphi": [1, 4, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "question": [31, 33, 34], "queue": [3, 14, 15], "quick": [33, 34], "quickstart": 24, "quit": [1, 9, 11, 17], "quot": [1, 5, 9, 11, 13, 17, 18, 19], "qwertz": [31, 33, 34], "qxjwxiu3": [23, 24], "r0": [27, 29, 30, 31, 33, 34], "r150": [31, 33, 34], "r7": [31, 33, 34], "r8169": [31, 33, 34], "ra": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "racer": [31, 33, 34], "radio": [1, 3, 4, 9, 11, 14, 15, 16, 17], "ram": [18, 27], "rand": [23, 24], "rang": [3, 14, 15, 27, 29, 30], "rauc": [2, 6, 10, 12, 21, 26], "rauc_": [27, 29, 30], "rauc_cert_fil": [27, 29, 30], "rauc_downgrade_barri": [27, 29, 30], "rauc_flash_nand_from_mmc": [27, 29, 30], "rauc_flash_nand_from_tftp": [27, 29, 30], "rauc_image_fstyp": 30, "rauc_init_nand": [27, 29, 30], "rauc_intermediate_cert_fil": [27, 29, 30], "rauc_key_fil": [27, 29, 30], "rauc_keyring_fil": [27, 29, 30], "rauc_slot_rootf": [27, 29, 30], "rauc_update_sourc": [27, 29, 30], "raucarg": [27, 29, 30], "raucb": [27, 29, 30], "raucboot": 27, "raucbootpart": [27, 29, 30], "raucdev": 27, "raucinit": [29, 30], "raucm": [27, 29, 30], "raucpart": 27, "raucrootpart": [27, 29, 30], "raucslot": 27, "raw": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24, 27, 29, 30], "rc": [31, 33, 34], "rc1": [31, 33, 34], "rc2": [31, 33, 34], "rc3": [31, 33, 34], "rc4": [31, 34], "rc5": [31, 34], "rc6": 34, "rdk": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19], "re": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "read": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "readi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "readm": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "readthedoc": [27, 29, 30], "real": [31, 33, 34], "realli": [31, 33, 34], "reboot": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "rebuild": [27, 29, 30], "receiv": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "recip": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "recipe_sysroot_n": [14, 15], "recogn": [22, 23, 24, 31, 33, 34], "recommend": [27, 29, 30], "recompil": [31, 33, 34], "redund": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30], "ref": [3, 4, 7, 8, 14, 15, 16, 18, 31, 33, 34], "refer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "referenc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "refresh": [3, 14, 15], "reg": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 27, 29, 30, 31, 33, 34], "reg_usdhc2_vmmc": 4, "regist": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "regul": [4, 22, 23, 24], "regular": [27, 29, 30], "regulator_summari": [22, 23, 24], "relat": [1, 9, 11, 17], "releas": [22, 23, 24, 27, 29, 30], "reli": [27, 29, 30], "reliabl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "reload": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "remain": [27, 29, 30], "remaining_attempt": [27, 29, 30], "rememb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "remot": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "remoteproc0": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "remov": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "repair": [31, 33, 34], "repeat": [1, 5, 9, 11, 13, 17, 18, 19], "replac": [1, 9, 11, 17, 22, 23, 24], "repo": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "reporepo": [31, 33, 34], "reporepo_branch": [31, 33, 34], "report": [1, 3, 4, 9, 11, 14, 15, 16, 17], "repositori": [27, 29, 30, 31, 33, 34], "repres": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "represent": [9, 11, 17, 24], "req_meta": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "request": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 25, 27, 29, 30], "requir": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "rerun": [31, 33, 34], "reset": [1, 3, 4, 5, 9, 11, 14, 15, 16, 17, 27, 29, 30, 31, 33, 34], "resid": [27, 29, 30], "resistor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "resiz": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "resize2f": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "resizepart": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "respect": [27, 29, 30], "restart": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "restor": [1, 4, 9, 11, 16, 17, 22, 23, 24], "restrict": [1, 5, 9, 11, 13, 17, 18, 19], "result": [27, 29, 30], "resum": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "rev": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "revert": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "revis": [24, 33], "revok": [27, 29, 30], "rf": [31, 33, 34], "ri": [27, 29, 30], "right": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "river": [31, 33, 34], "rk3288": [31, 33, 34], "rkejwbl2t5z868fnarggmvxzt4x": [23, 24], "rm": [31, 33, 34], "rmdir": [27, 29, 30], "ro": [31, 33, 34], "robust": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "role": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "roll": [27, 29, 30], "rom": [1, 3, 4, 9, 11, 14, 15, 16, 17], "root": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "root0": [27, 29, 30], "rootf": [1, 5, 9, 11, 13, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "rootfspath": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rootfstyp": [27, 29, 30], "rootwait": [31, 33, 34], "rout": [31, 33, 34], "rpmb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rpmsg": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 18, 22, 23, 24], "rs": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "rs232": [2, 6, 10, 12, 21, 22], "rs485": [2, 6, 10, 12, 21], "rs485conf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "rs485test": [9, 11, 13, 14, 15, 16, 17, 18, 19], "rsa": [23, 24, 27, 29, 30], "rst": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "rsync": [31, 33, 34], "rt": [31, 33, 34], "rtc": [2, 6, 10, 12, 21], "rtc0": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "rtc_bsm_direct": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_bsm_disabl": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_bsm_level": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_bsm_standbi": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_feature_alarm": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_feature_alarm_res_2": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_feature_alarm_res_minut": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_feature_alarm_wakeup_on": [1, 5, 9, 11, 13, 17, 18, 19, 22, 23, 24], "rtc_feature_backup_switch_mod": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_feature_cnt": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_feature_correct": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_feature_need_week_day": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtc_feature_update_interrupt": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rtcs": [1, 4, 7, 9, 11, 13, 16, 17, 18, 19, 24], "rtos": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "rts": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "rule": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "run": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "run1": [31, 33, 34], "runal": [31, 33, 34], "runtimewatchdogsec": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rv": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "rv3028": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rw": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rwx": [31, 33, 34], "rx": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rxd": [22, 23, 24], "s0j58x": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "s1": [2, 6], "s16_le": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "s16le": [3, 14, 15], "s2": [22, 23, 24], "s3": [1, 3, 4, 5, 7, 8, 10, 12, 21], "s5": [1, 3, 4, 5, 7, 8], "s_cmd_set": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "safe": [31, 33, 34], "sai2_rxf": [1, 3, 4, 5, 7, 8], "same": [1, 5, 9, 11, 13, 17, 18, 19, 27, 29, 30, 31, 33, 34], "sampl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "sandbox": [1, 3, 4, 7, 14, 15, 16], "saniti": [31, 33, 34], "save": [1, 9, 11, 17, 24, 31, 33, 34], "savedefconfig": [31, 33, 34], "saveenv": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "sbc": [9, 11, 14, 15, 16, 17], "scale": [22, 23, 24], "scaling_available_frequ": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "scaling_available_governor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "scaling_cur_freq": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "scaling_governor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "scaling_setspe": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "scan": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 24, 31, 33, 34], "scarthgap": [1, 9, 11, 13, 17, 18, 19, 24, 30, 34], "scenario": [27, 29, 30], "schedutil": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "scl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "scm": [31, 33, 34], "sco": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "sconf_vers": [31, 33, 34], "scope": [1, 5, 9, 11, 13, 17, 18, 19], "scp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "scr": [1, 9, 11, 17], "script": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "scsi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sd": [2, 6, 10, 12, 21, 27, 29, 30, 31, 33, 34], "sda": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sda1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sdb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sdb1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sdb2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sdcard": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sde": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "sde1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sde2": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "sde3": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sdevic": [31, 33, 34], "sdktargetsysroot": [31, 33, 34], "sdl": [31, 33, 34], "sdp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sdx": [1, 3, 7, 9, 11, 14, 15, 17], "se": [31, 33, 34], "search": [1, 9, 11, 17, 31, 33, 34], "sec": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 19, 22, 23, 24], "second": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24, 27, 29, 30], "secondari": [1, 3, 4, 9, 11, 14, 15, 16, 17], "sect": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "section": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "sector": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "secur": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28], "securiphi": 34, "see": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "seek": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "seen": [27, 29, 30], "seg": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "seg1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "seg2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "segger": [1, 3, 4, 9, 11, 14, 15, 16, 17], "segin": [21, 27, 29, 30, 31, 33], "segin_defconfig": 23, "select": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "self": [27, 29, 30], "send": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19, 27, 29, 30], "sensor": [22, 23, 24], "sent": [1, 9, 11, 13, 16, 17, 19, 22, 23, 24], "separ": [1, 9, 11, 17, 24, 27, 29, 30], "sequenc": [1, 5, 9, 11, 13, 17, 18, 19], "serial": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "serialnumb": [1, 3, 4, 5, 7, 8], "serv": [27, 29, 30], "server": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "serveraddr": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "serverip": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "servic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "session": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "set": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "setenv": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "setexpr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "setfacl": [31, 33, 34], "setscen": 32, "setup": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "sf": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "sh": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "sha256": [27, 29, 30], "shadow": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "share": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "shell": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "ship": [27, 29, 30], "short": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "should": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "show": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "shutdownwatchdogsec": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "side": [22, 23, 24], "sigil": [31, 33, 34], "sigint": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "sign": [1, 9, 11, 17, 27, 29, 30], "signal": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "signatur": [27, 29, 30], "sigterm": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "silicon": [9, 11, 13, 14, 15, 16, 17, 18, 19, 33], "similar": [27, 29, 30], "simpl": [27, 29, 30], "simpler": [27, 29, 30], "simpli": [27, 29, 30], "simultan": [9, 11, 13, 16, 17, 19], "sinc": [27, 29, 30], "singl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "singleindex": [31, 33, 34], "sink": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "sink_numb": [1, 4, 9, 11, 16, 17, 23, 24], "site": 32, "size": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "sjw": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "skeleton": [31, 33, 34], "skip": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "sleep": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "slot": [1, 3, 4, 9, 11, 14, 15, 16, 17, 24, 28], "slotclass": [27, 29, 30], "small": [9, 11, 13, 16, 17, 19], "snd_dummi": [3, 14, 15], "sndpebav10": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "snippet": [27, 29, 30, 31, 33, 34], "snvs": [1, 3, 4, 5, 7, 8, 10, 12, 22, 23, 24], "snvs_pwrkey": [9, 11, 13, 14, 15, 16, 17, 18, 19], "snvs_rtc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "so": [1, 9, 11, 13, 16, 17, 19, 27, 29, 30, 31, 33, 34], "soc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "socat": [31, 33, 34], "softvol_hdmi": [14, 15], "softvol_pebav10": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "softwar": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "solder": 24, "solut": [27, 29, 30], "som": [27, 29, 30, 31, 33, 34], "some": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "someth": [1, 9, 11, 17, 27, 29, 30], "souc": [31, 33, 34], "sound": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "sourc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "source_mirror_url": [31, 33, 34], "soutputfil": [31, 33, 34], "space": [27, 29, 30], "speaker": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "special": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 30, 31, 33, 34], "specif": [27, 29, 30], "specifi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "speed": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "spi": [2, 6, 10, 12, 22, 23, 24], "spiflash": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "spki": [27, 29, 30], "spl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "src_mirror": [31, 33, 34], "srcrev": [31, 33, 34], "srctreecoveredtask": [31, 33, 34], "srv": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ss": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ssds": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sset": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "ssh": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "ssid": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "sstate": [31, 33, 34], "sstate_dir": [31, 33, 34], "st": [31, 33, 34], "stabl": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "stack": [1, 3, 4, 9, 11, 14, 15, 16, 17], "stackexchang": [31, 33, 34], "stage": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "standard": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "standardboot": [1, 9, 11, 17], "standbi": [3, 14, 15], "start": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "startch": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "startlba": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "startup": [1, 5, 9, 11, 13, 17, 18, 19], "stat": [31, 33, 34], "state": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "state_prefix": [27, 29, 30], "static": [31, 33, 34], "stats2gnuplot": [31, 33, 34], "status": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "step": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "step_wis": [22, 23, 24], "stereo": [3, 14, 15], "sterl": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "sterlinglwb": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "stick": [1, 9, 11, 17, 24, 27, 29, 30], "still": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "stitching2": [31, 33, 34], "stm32mp13x": [31, 33, 34], "stm32mp15x": [31, 33, 34], "stop": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "storag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28], "store": [1, 4, 9, 11, 16, 17, 22, 23, 24, 27, 29, 30], "strace": [31, 33, 34], "straightforward": [1, 9, 11, 17], "stream": 28, "strict": [1, 5, 9, 11, 13, 17, 18, 19], "strides": [27, 29, 30], "string": [1, 3, 4, 5, 7, 8, 22, 23, 24, 31, 33, 34], "strip": [31, 33, 34], "structur": [27, 29, 30], "stti": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "sub": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 27, 29, 30], "subdev25": [31, 33, 34], "subject": [27, 29, 30], "subnet": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "subnet4": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "subordin": [1, 3, 4, 9, 11, 14, 15, 16, 17], "subsect": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "substat": [1, 3, 4, 9, 11, 14, 15, 16, 17], "subsystem": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "subunit": [31, 33, 34], "succeed": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 31, 33, 34], "success": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "such": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sudo": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "summari": [31, 33, 34], "sumo": [31, 33, 34], "superres2": [31, 33, 34], "suppli": 4, "support": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "sure": [1, 9, 11, 17, 27, 29, 30], "surnam": [31, 33, 34], "suspend": [3, 14, 15], "svb2": [23, 24], "swffc": [22, 23, 24], "switch": [2, 3, 4, 5, 7, 8, 10, 12, 13, 14, 15, 16, 18, 19, 22, 23, 24, 28, 31, 33], "switchov": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "symlink": [31, 33, 34], "sync": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "synopsi": [1, 3, 4, 9, 11, 14, 15, 16, 17], "sys": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "sysroot": [31, 33, 34], "system": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "system0": [27, 29, 30], "system1": [27, 29, 30], "system_bus_socket": [27, 29, 30], "systemctl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "systemd": [27, 29, 30, 31, 33, 34], "systemd_auto_en": [31, 33, 34], "systemd_w": [27, 29, 30, 31, 33, 34], "t5": [14, 15], "tab": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "tabl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "tag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "tail": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "take": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "taken": [1, 5, 9, 11, 13, 17, 18, 19], "tar": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "target": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "target1": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "target2": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "targettool": [31, 33, 34], "task": [31, 33, 34], "tauri": 31, "tcm": [1, 3, 4, 9, 11, 14, 15, 16, 17], "technolog": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tee": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tell": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "temp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "temperatur": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "templat": [27, 29, 30], "templateconf": [27, 29, 30], "tera": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "term": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "termin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "test": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "test_key": [23, 24], "texinfo": [31, 33, 34], "text": [31, 33, 34], "tftp_address": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tftp_directori": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tftp_option": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tftp_usernam": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tftpd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tftproot": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "than": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "that": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "the": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "their": [1, 9, 11, 17], "them": [1, 9, 11, 17, 31, 33, 34], "then": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30], "there": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "thermal": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "thermal_zone0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "these": [24, 27, 29, 30], "they": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24, 27, 29, 30], "thing": [27, 29, 30], "this": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "thisdir": [27, 29, 30, 31, 33, 34], "those": [22, 23, 24], "threshold": [22, 23, 24], "through": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "thu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "thus": [22, 23, 24], "ti": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "ti33x": [31, 33, 34], "ti_": [31, 33, 34], "tiboot3": [27, 29, 30], "tile": [3, 14, 15], "time": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "tio": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "tiocsrs485": [9, 11, 13, 14, 15, 16, 17, 18, 19], "tispl": [27, 29, 30], "titl": [27, 29, 30, 31, 33, 34], "tlc": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "tlv320": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "tlv320aic3007": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "tmp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "tmpdir": 27, "to": [2, 3, 4, 5, 7, 8, 10, 12, 13, 14, 15, 16, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "toggl": [1, 5, 9, 11, 13, 17, 18, 19], "too": [27, 29, 30], "tool": [3, 7, 14, 15, 27, 29, 30, 31, 33, 34], "toolchain": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "top": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "topdir": [27, 31, 33, 34], "topic": [22, 23, 24, 31, 33, 34], "total": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "touch": [31, 33, 34], "touchscreen": [31, 33, 34], "touchscreen0": [31, 33, 34], "tpm": 21, "tpm2": [23, 24], "tpm2_getrandom": [23, 24], "tpm2tss": [23, 24], "tq": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "track": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "transfer": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "transit": 28, "transmiss": 24, "transmit": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "transmitt": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "treat": [1, 5, 9, 11, 13, 17, 18, 19], "tree": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "tri": [27, 29, 30], "trigger": [27, 29, 30], "trip_point_0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "trip_point_1": [22, 23, 24], "true": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "trust": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tseg1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tseg2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tso_max_s": [22, 23, 24], "tso_max_seg": [22, 23, 24], "tti": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "ttl": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ttygs0": [1, 3, 4, 5, 7, 8], "ttylp0": [22, 23, 24], "ttylp6": [23, 24], "ttymxc0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "ttymxc1": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "ttymxc2": [1, 3, 4, 5, 7, 8], "ttyrpmsg30": [22, 23, 24], "ttyusb": [1, 3, 4, 9, 11, 14, 15, 16, 17], "ttyusb2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "tweak": [31, 33, 34], "two": [9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30, 31, 33, 34], "tx": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "txd": [22, 23, 24], "txqueuelen": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "txt": [13, 18, 19, 31, 33, 34], "type": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "uart": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "uart1": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "uart1_dce_rx": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "uart1_rxd": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "uart1grp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "uart2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "uart3": [9, 11, 13, 14, 15, 16, 17, 18, 19], "uart4": [9, 11, 13, 14, 15, 16, 17, 18, 19], "ubi": [27, 29, 30], "ubi0": [27, 29, 30], "ubi0_0": [27, 29, 30], "ubi0_1": [27, 29, 30], "ubi0_2": [27, 29, 30], "ubi0_3": [27, 29, 30], "ubi0_5": [27, 29, 30], "ubi0_6": [27, 29, 30], "ubiattach": [27, 29, 30], "ubif": [27, 29, 30], "ubivol": [27, 29, 30], "uboot": [27, 29, 30], "ubuntu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "udc": [1, 3, 4, 5, 7, 8], "udev": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "udevadm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "ufs": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "ui": [31, 33, 34], "uimg": [1, 9, 11, 17], "uint32": [27, 29, 30], "uj": [23, 24], "ultim": [1, 3, 4, 9, 11, 14, 15, 16, 17], "ultralit": 31, "umask": [31, 33, 34], "umount": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "unauthor": [27, 29, 30], "unchang": [1, 5, 9, 11, 13, 17, 18, 19], "uncom": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "undefin": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "under": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "uniniti": [31, 33, 34], "uniqu": [1, 5, 9, 11, 13, 17, 18, 19], "unit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "unix": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30, 31, 33, 34], "unknown": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "unless": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "unquot": [1, 5, 9, 11, 13, 17, 18, 19], "unrevers": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "unset": [1, 9, 11, 17, 27, 29, 30], "unstag": [31, 33, 34], "until": [1, 5, 9, 11, 13, 17, 18, 19], "unxz": [1, 5, 9, 11, 13, 17, 19, 22, 23, 24], "unzip": [31, 33, 34], "up": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "updat": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 26, 31, 33, 34], "update_usb": [27, 29, 30], "upon": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "upper": [9, 11, 13, 14, 15, 16, 17, 18, 19], "upstream": [2, 6, 10, 12], "uri": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "url": [31, 33, 34], "us": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 24], "usag": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "usb": [2, 6, 10, 12, 21, 28, 31, 33, 34], "usb0": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "usb2": [1, 3, 4, 22, 23, 24], "usb_gadget": [1, 3, 4, 5, 7, 8], "usbdevic": [9, 11, 13, 14, 15, 16, 17, 18, 19], "usbotg2": [1, 3, 4], "use": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 28, 31, 33, 34], "usec": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "user": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "usern": [31, 33, 34], "usernam": [31, 33, 34], "userspac": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "usr": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "usual": [27, 29, 30], "utc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "util": [27, 29, 30, 31, 33, 34], "uuid": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "uuu": [2, 6, 10, 12, 21], "v2015": [31, 33, 34], "v2021": [3, 7, 14, 15], "v2022": [1, 4, 5, 8, 16, 31, 33, 34], "v2023": [22, 23], "v2024": [9, 11, 13, 17, 18, 19, 24], "v3": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "v4": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "v4l": [31, 33, 34], "v5": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "v6": [9, 11, 13, 17, 18, 19, 22, 23, 24], "v7": [1, 3, 4, 9, 11, 14, 15, 16, 17], "vaapivideodecod": [1, 3, 4, 7, 14, 15, 16], "val": [31, 33, 34], "valid": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "valu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "value1": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "value2": [3, 4, 7, 8, 14, 15, 16, 22, 23, 24], "var": [1, 4, 9, 11, 16, 17, 22, 23, 24, 31, 33, 34], "variabl": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "variant": [22, 23, 24, 27, 29, 30], "various": [27, 29, 30], "vdd_soc": [22, 23, 24], "vdisp": [3, 14, 15], "vendor": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30, 31, 33, 34], "vendor_id": [31, 33, 34], "venv": [1, 3, 4, 9, 11, 14, 15, 16, 17], "verbos": [31, 33, 34], "veri": [31, 33, 34], "verifi": [27, 29, 30], "version": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "version_fil": [27, 29, 30], "vfat": [27, 29, 30], "vfp": [31, 33, 34], "vfs": [22, 23, 24], "vi": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24, 31, 33, 34], "via": [24, 27, 29, 30, 31, 33, 34], "video": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "video2": [31, 33, 34], "videoconvert": [1, 4, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "videosink": [1, 4, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "videostab2": [31, 33, 34], "view": [27, 29, 30], "vigil": [31, 33, 34], "vim": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "vimdiff": [31, 33, 34], "virtual": [1, 3, 4, 9, 11, 14, 15, 16, 17], "vision": [31, 33, 34], "visit": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "vm": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "vm016": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24], "vm017": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "vm020": [1, 9, 11, 17], "vmmc": 4, "vol": [1, 3, 4], "volatil": [27, 29, 30], "volum": [27, 29, 30], "vpu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "vpudec": [3, 14, 15], "vse": [3, 14, 15], "vss": [3, 14, 15], "vtcon1": [31, 33, 34], "vtconsol": [31, 33, 34], "vtot": [3, 14, 15], "vulner": [27, 29, 30], "w1": [31, 33, 34], "wait": [1, 3, 4, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "wakealarm": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "wakeup": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "want": [1, 9, 11, 17, 31, 33, 34], "warn": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "warrior": 34, "was": [24, 27, 29, 30], "watchdog": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "wav": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "way": [1, 9, 11, 17, 27, 29, 30, 31, 33, 34], "wayland": [1, 3, 4, 7, 14, 15, 16, 22, 23, 24, 33], "waylandsink": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "wc": [27, 29, 30], "wdg9yaf7": [23, 24], "we": [1, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "webm": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "websit": [1, 9, 11, 17], "wed": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "wega": [31, 33, 34], "well": [27, 29, 30], "wep": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "were": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19, 27, 29, 30], "west": [1, 3, 4, 9, 11, 14, 15, 16, 17], "weston": [1, 3, 4, 7, 22, 23, 24], "wget": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "what": [1, 3, 4, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30, 31, 33, 34], "whatev": [1, 9, 11, 17], "when": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "where": [1, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "whether": [27, 29, 30], "which": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "while": [27, 29, 30], "wic": [31, 33, 34], "widget": [31, 33, 34], "wifi": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "wiki": [31, 33, 34], "will": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "win95": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "wind": [31, 33, 34], "wire": 24, "wireless": [1, 3, 4, 9, 11, 14, 15, 16, 17, 31, 33, 34], "wise": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "with": [3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 22, 23, 24, 28, 31, 33, 34], "without": [27, 29, 30], "wlan0": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "wlbt": [1, 9, 11, 14, 15, 16, 17, 24], "wlp1s0": [1, 3, 4, 9, 11, 14, 15, 16, 17], "won": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "word": [22, 23, 24], "work": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19, 24, 31, 33, 34], "workdir": [31, 33, 34], "workflow": [31, 33, 34], "workspac": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 32], "would": [1, 5, 9, 11, 13, 17, 18, 19, 27, 29, 30], "wpa": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "wpa2": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "wpa_key_mgmt": [31, 33, 34], "wpa_pairwis": [31, 33, 34], "wpa_passphras": [31, 33, 34], "wpa_supplic": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "wr_rel_set": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "writabl": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "write": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "write_reli": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "written": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 27, 29, 30, 31, 33, 34], "wrong": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "www": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "x1": [9, 11, 13, 14, 15, 16, 17, 18, 19], "x16": [22, 23, 24], "x2": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "x30": [1, 3, 4, 5, 7, 8], "x48": [22, 23, 24], "x5": [9, 11, 13, 14, 15, 16, 17, 18, 19], "x6": [9, 11, 13, 14, 15, 16, 17, 18, 19], "x8": [1, 3, 4, 22, 23, 24], "x86_64": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "x_onoff": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "x_uart2_rx": [22, 23, 24], "x_uart2_tx": [22, 23, 24], "xdg": [9, 11, 13, 14, 15, 16, 17, 18, 19], "xen": [31, 33, 34], "xlsx": [22, 23, 24], "xml": [31, 33, 34], "xterm": 31, "xvzf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "xwayland": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "xx": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 27, 29, 30, 31, 33, 34], "xxx": [9, 11, 16, 17], "xxxx": [1, 5, 9, 11, 13, 27, 29, 30, 31, 33, 34], "xxxxx": [9, 13], "xz": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "xzcat": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "yaml": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "yamltre": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "yellow": [22, 23, 24], "yes": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "yet": 24, "yocto": [0, 3, 4, 5, 7, 8, 13, 14, 15, 16, 18, 19, 20, 22, 23, 24, 25, 26, 27, 29, 30], "yocto_dir": [1, 3, 4, 7, 14, 15, 16], "yocto_download": [31, 33, 34], "yocto_sst": [31, 33, 34], "yoctoproject": [31, 33, 34], "yoctoprojectq": [31, 33, 34], "yogurt": [27, 29, 30], "you": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "your": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "your_devic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "your_directori": [31, 33, 34], "your_email": [31, 33, 34], "your_imag": [31, 33, 34], "yourself": [27, 29, 30], "yveolxdggmjiflecu6xz1j3": [23, 24], "yyyi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "zephyr": [1, 3, 4, 9, 11, 14, 15, 16, 17], "zephyrproject": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19], "zero": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "zeus": 34, "zimag": [27, 29, 30], "zstd": [31, 33, 34], "zstdcat": [22, 23, 24]}, "titles": ["i.MX 8 \u624b\u518c", "1. PHYTEC \u6587\u6863", "i.MX 8M Mini \u624b\u518c", "1. PHYTEC \u6587\u6863", "1. PHYTEC \u6587\u6863", "1. PHYTEC \u6587\u6863", "i.MX 8M Nano \u624b\u518c", "1. PHYTEC \u6587\u6863", "1. PHYTEC \u6587\u6863", "1. PHYTEC \u6587\u6863", "Libra i.MX 8M Plus FPSC Manuals", "1. PHYTEC \u6587\u6863", "i.MX 8M Plus \u624b\u518c", "1. PHYTEC \u6587\u6863", "1. PHYTEC \u6587\u6863", "1. PHYTEC \u6587\u6863", "1. PHYTEC \u6587\u6863", "1. PHYTEC \u6587\u6863", "1. PHYTEC \u6587\u6863", "1. PHYTEC \u6587\u6863", "i.MX 9 \u624b\u518c", "i.MX 93 \u624b\u518c", "1. PHYTEC \u6587\u6863", "1. PHYTEC \u6587\u6863", "1. PHYTEC \u6587\u6863", "\u8d21\u732e", "\u6b22\u8fce\u9605\u8bfb PHYTEC BSP \u6587\u6863", "1. Introduction", "RAUC Update & Device Management Manuals", "1. Introduction", "1. Introduction", "1. Yocto \u9879\u76ee", "Yocto \u53c2\u8003\u624b\u518c", "1. Yocto \u9879\u76ee", "1. Yocto \u9879\u76ee"], "titleterms": {"3rdparti": [31, 33, 34], "6ul": [31, 33, 34], "8m": [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19], "93": [21, 22, 23, 24], "activ": [27, 29, 30], "adc": [23, 24], "alarm": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "alsa": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "alsamix": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "ampliphi": [12, 31, 33, 34], "audio": 24, "automat": [27, 29, 30], "autotool": [31, 33, 34], "back": [1, 9, 11, 17], "barebox": [27, 29, 30, 31, 33, 34], "barrier": [27, 29, 30], "base": [31, 33, 34], "bbappend": [31, 33, 34], "bbnsm": [22, 23, 24], "bin": [22, 23, 24], "bitbak": [31, 33, 34], "bkop": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "bmap": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "boot": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "bootchoos": [27, 29, 30], "bootenv": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "bootload": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30, 31, 33, 34], "browser": [31, 33, 34], "bsp": [1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 12, 13, 14, 15, 16, 17, 18, 19, 21, 22, 23, 24, 26, 27, 29, 30, 31, 33, 34], "buildinfo": [31, 33, 34], "bundl": [27, 29, 30], "by": [27, 29, 30], "can": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "case": [27, 29, 30], "chang": [1, 9, 11, 17, 27, 29, 30], "chromium": [1, 3, 4, 7, 14, 15, 16], "communiti": [31, 33, 34], "conf": [1, 3, 4, 7, 14, 15, 16, 31, 33, 34], "configur": [27, 29, 30], "consider": [27, 29, 30], "content": 28, "core": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "cpu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "creat": [27, 29, 30, 31, 33, 34], "csd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "dd": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "default": [27, 29, 30], "defconfig": [31, 33, 34], "demo": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "design": [27, 29, 30], "devic": 28, "devtool": [31, 33, 34], "dhcp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "disabl": [1, 9, 11, 17], "distro": [1, 9, 11, 17, 31, 33, 34], "downgrad": [27, 29, 30], "drive": [27, 29, 30], "dt": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "duplex": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "eeprom": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "efi": [1, 9, 11, 17], "efus": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "eiq": [14, 15], "emmc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "environ": [1, 9, 11, 17, 27, 29, 30], "exampl": [27, 29, 30], "ext4": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fan": [22, 23, 24], "fd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "fit": [1, 9, 11, 17], "flash": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24, 27, 29, 30], "fpsc": [9, 10], "framebuff": [31, 33, 34], "framework": [27, 29, 30], "freescal": [31, 33, 34], "from": [27, 29, 30], "fsl": [31, 33, 34], "full": [9, 11, 13, 16, 17, 19], "fuse": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "git": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "gnu": [31, 33, 34], "gpart": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gpio": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gstreamer": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "gstreamer1": [31, 33, 34], "half": [1, 4, 5, 8, 9, 11, 13, 16, 17, 19], "head": [2, 6, 10, 12], "host": [5, 7, 8], "http": [27, 29, 30], "i2c": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "id": [3, 14, 15], "imag": [31, 33, 34], "implement": [27, 29, 30], "imx": [22, 23, 24], "in": [1, 9, 11, 17], "initi": [27, 29, 30], "instal": [1, 9, 11, 17], "introduct": [27, 29, 30], "isp": [9, 11, 14, 15, 16, 17], "kernel": [31, 33, 34], "keyr": [27, 29, 30], "kirkston": [28, 32], "kmssink": [3, 14, 15], "layer": [31, 33, 34], "led": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "legacyboot": [1, 9, 11, 17], "libra": [9, 10], "lightpd": [31, 33, 34], "link": [1, 3, 4, 9, 11, 14, 15, 16, 17], "linux": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "local": [1, 3, 4, 7, 14, 15, 16, 31, 33, 34], "logic": [27, 29, 30], "m33": [22, 23, 24], "m4": [1, 3, 4], "m7": [9, 11, 14, 15, 16, 17], "mac": [22, 23, 24], "machin": [31, 33, 34], "mainlin": 12, "manag": 28, "manual": [10, 28], "measur": [27, 29, 30], "meta": [31, 33, 34], "mickledor": [28, 32], "mini": [1, 2, 3, 4], "mkimag": [22, 23, 24], "mmc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "mx": [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 31, 33, 34], "mx8mm": [1, 2, 3, 4, 6], "mx8mn": [5, 7, 8], "mx8mp": [9, 11, 12, 13, 14, 15, 16, 17, 18, 19], "mx93": [21, 22, 23, 24], "nand": [27, 29, 30], "nano": [5, 6, 7, 8], "nash": [22, 23, 24], "nfs": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "nodej": [31, 33, 34], "nor": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17], "npu": [9, 11, 14, 15, 16, 17], "nxp": [2, 6, 12, 14, 15, 21], "ocotp_ctrl": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "of": 28, "offset": [27, 29, 30], "on": 24, "onli": [1, 9, 11, 17], "opencv": [31, 33, 34], "openembed": [31, 33, 34], "otg": [1, 3, 4, 5, 7, 8], "over": [27, 29, 30], "overlay": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "own": [31, 33, 34], "partit": [27, 29, 30], "partup": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "pcie": [1, 3, 4, 9, 11, 14, 15, 16, 17], "pd22": [2, 6, 12], "pd23": [2, 6, 12], "pd24": [12, 21], "php": [31, 33, 34], "phyboard": [1, 3, 4, 5, 7, 8, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "phycor": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "phylinux": [31, 33, 34], "phytec": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 26, 31, 33, 34], "plus": [9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19], "poki": [31, 33, 34], "poli": [1, 3, 4, 5, 7, 8], "pollux": [11, 13, 14, 15, 16, 17, 18, 19], "process": [27, 29, 30], "pulseaudio": [1, 3, 4, 9, 11, 14, 15, 16, 17, 23, 24], "pwm": [22, 23, 24], "pxp": [22, 23, 24], "qt": [1, 3, 4, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "qt6": [31, 33, 34], "ram": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 19, 22, 23, 24, 31, 33, 34], "rauc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 28, 29, 30, 31, 33, 34], "recip": [31, 33, 34], "refer": [27, 29, 30], "releas": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 31, 33, 34], "remoteproc": [1, 3, 4, 9, 11, 14, 15, 16, 17, 22, 23, 24], "repo": [31, 33, 34], "rs232": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "rs485": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 23, 24], "rtc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "rust": [31, 33, 34], "s1": [1, 3, 4, 5, 7, 8], "s3": [9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "scarthgap": [28, 32], "sd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "sdk": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 31, 33, 34], "secur": [27, 29, 30, 31, 33, 34], "segin": [22, 23, 24], "selinux": [31, 33, 34], "setscen": [31, 33, 34], "setup": [27, 29, 30], "site": [31, 33, 34], "slc": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "slot": [27, 29, 30], "snvs": [9, 11, 13, 14, 15, 16, 17, 18, 19], "som": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "spi": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "src_uri": [31, 33, 34], "storag": [27, 29, 30], "stream": [27, 29, 30], "switch": [1, 9, 11, 17, 27, 29, 30], "sysf": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "system": [27, 29, 30], "systemd": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "tabl": 28, "tftp": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "the": [27, 29, 30], "timesi": [31, 33, 34], "to": [1, 9, 11, 17], "toaster": [31, 33, 34], "tool": [1, 4, 5, 8, 9, 11, 13, 16, 17, 18, 19, 22, 23, 24], "tpm": [23, 24], "transit": 30, "txt": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 22, 23, 24], "uart1": [1, 3, 4, 5, 7, 8], "uboot": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "udev": [31, 33, 34], "ull": [31, 33, 34], "updat": [27, 28, 29, 30], "upstream": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19], "usb": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24, 27, 29, 30], "use": [27, 29, 30], "uuu": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "variabl": [27, 29, 30], "variant": [1, 9, 11, 17], "virtual": [31, 33, 34], "web": [31, 33, 34], "weston": [9, 11, 13, 14, 15, 16, 17, 18, 19], "wic": [1, 3, 4, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 22, 23, 24], "with": [1, 9, 11, 17, 27, 29, 30], "wlan": [1, 3, 4, 5, 7, 8, 9, 11, 14, 15, 16, 17, 24, 31, 33, 34], "workspac": [31, 33, 34], "yocto": [1, 2, 6, 9, 11, 12, 17, 21, 31, 32, 33, 34], "your": [31, 33, 34]}}) \ No newline at end of file diff --git a/previews/271/zh_CN/sitemap.xml b/previews/271/zh_CN/sitemap.xml new file mode 100644 index 000000000..95a4928d7 --- /dev/null +++ b/previews/271/zh_CN/sitemap.xml @@ -0,0 +1,2 @@ + +https://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mm/head.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mm/imx8mm.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mm/pd22.1.1.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mm/pd23.1.0.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mn/head.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mn/imx8mn.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mn/pd22.1.1.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mn/pd23.1.0.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp-libra-fpsc/head.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp-libra-fpsc/imx8mp-libra-fpsc.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/head.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/imx8mp.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/mainline-head.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/pd22.1.1.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/pd22.1.2.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/pd23.1.0.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx9/imx93/imx93.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/pd24.1.0_nxp.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx9/imx93/pd24.1.0.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/pd24.1.1.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx8/imx8mp/pd24.1.2.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx9/imx9.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx9/imx93/pd24.1.1.htmlhttps://phytec.github.io/doc-bsp-yocto/yocto/kirkstone.htmlhttps://phytec.github.io/doc-bsp-yocto/yocto/manual-index.htmlhttps://phytec.github.io/doc-bsp-yocto/bsp/imx9/imx93/pd24.2.0.htmlhttps://phytec.github.io/doc-bsp-yocto/contributing_links.htmlhttps://phytec.github.io/doc-bsp-yocto/index.htmlhttps://phytec.github.io/doc-bsp-yocto/rauc/kirkstone.htmlhttps://phytec.github.io/doc-bsp-yocto/rauc/manual-index.htmlhttps://phytec.github.io/doc-bsp-yocto/yocto/mickledore.htmlhttps://phytec.github.io/doc-bsp-yocto/rauc/mickledore.htmlhttps://phytec.github.io/doc-bsp-yocto/rauc/scarthgap.htmlhttps://phytec.github.io/doc-bsp-yocto/yocto/scarthgap.htmlhttps://phytec.github.io/doc-bsp-yocto/genindex.htmlhttps://phytec.github.io/doc-bsp-yocto/search.html \ No newline at end of file diff --git a/previews/271/zh_CN/yocto/kirkstone.html b/previews/271/zh_CN/yocto/kirkstone.html new file mode 100644 index 000000000..72044cdd1 --- /dev/null +++ b/previews/271/zh_CN/yocto/kirkstone.html @@ -0,0 +1,2327 @@ + + + + + + + + + 1. Yocto 项目 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + +

Yocto Reference Manual

文档标题

Yocto Reference Manual Kirkstone

文档类型

Yocto手册

发布日期

XXXX/XX/XX

母文档

Yocto Reference Manual

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

适用BSP

BSP发布类型

BSP发布日期

BSP 状态

BSP-Yocto-Ampliphy-i.MX6-PD22.1.0

大版本

2022 年 12 月 14 日

已发布

BSP-Yocto-Ampliphy-i.MX6-PD22.1.1

小更新

2023 年 6 月 20 日

已发布

BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.0

大版本

2022 年 8 月 11 日

已发布

BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1

小更新

2023 年 5 月 23 日

已发布

BSP-Yocto-Ampliphy-AM335x-PD23.1.0

大版本

2023 年 4 月 25 日

已发布

BSP-Yocto-NXP-i.MX8MM-PD23.1.0

大版本

2023 年 12 月 12 日

已发布

BSP-Yocto-NXP-i.MX8MP-PD23.1.0

大版本

2023 年 12 月 12 日

已发布

BSP-Yocto-Ampliphy-AM62x-PD23.2.0

大版本

2023 年 9 月 28 日

已发布

BSP-Yocto-Ampliphy-AM62Ax-PD23.1.0

大版本

2023 年 9 月 28 日

已发布

BSP-Yocto-Ampliphy-AM64x-PD23.2.0

大版本

2023 年 9 月 28 日

已发布

BSP-Yocto-NXP-i.MX7-PD23.1.0

大版本

2023 年 12 月 15 日

已发布

+

本手册适用于所有基于 Kirkstone 的 PHYTEC BSP版本。

+
+

1. Yocto 项目

+
+

1.1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 手册：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的应用开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大多数文档都可以在我们产品的下载页面中找到。

+
+
+

1.2. Yocto 介绍

+

Yocto 是最小的国际单位制前缀。就像milli是描述 10^-3 一样，yocto 是描述 10^-24 。Yocto 也是 Linux 基金会 支持的项目，因此得到了该领域几家主流公司的支持。在 Yocto 项目网站 上您可以阅读官方的介绍：

+
+

Yocto 项目是一个开源协作项目，它提供模板、工具和方法，为您的嵌入式产品创建基于 Linux 的自定义系统，同时不用过多的关注底层硬件架构。该项目由众多硬件制造商、开源操作系统供应商和电子公司合作开发，成立于2010年，旨在引导嵌入式 Linux系统开发走向标准化。

+
+

如前所述，该项目希望为嵌入式开发人员提供工具集。它建立在长期维护的 OpenEmbedded 项目之上。它不是一个Linux 发行版，但它包含创建定制化的Linux 发行版的所有工具。维护工具集的最重要步骤是定义一个通用的版本控制方案和一个参考系统。然后，所有子项目都必须兼容参考系统，并且遵守他的版本控制方案。

+

发布过程类似于 Linux kernel 的发布机制。Yocto 每六个月增加一次版本号，并为发布版本指定版本代号。发布列表可在此处找到：https://wiki.yoctoproject.org/wiki/Releases

+
+
+

1.3. 核心组件

+

Yocto 项目最重要的工具或子项目是：

+
    +

  • Bitbake：构建引擎，是一个类似 make 的任务调度程序，解析元数据

    • +

  • OpenEmbedded-Core，Yocto 核心Layer，包含软件元数据

    • +

  • Yocto kernel

    +
      +

    • 针对嵌入式设备进行了优化

      • +

    • 包括许多子项目：rt-kernel、供应商补丁

      • +

    • Wind River 提供的基础框架

      • +

    • Yocto kernel的替代方案：经典的内核编译方式→Phytec使用这种方式将我们的kernel集成到 Yocto

      • +
    +
    • +

  • Yocto 参考 BSP： beagleboneblack、 minnow max

    • +

  • Poky：Yocto参考系统，是项目和工具的集合，是创建基于 Yocto 的Linux发行版的基石

    • +
+
+
+

1.4. 词汇

+
+

1.4.1. Recipes

+

Recipe包含有关软件项目的信息（作者、主页和许可证）。Recipe 有版本控制，它定义了依赖项，包含源代码的 URL，并描述如何获取、配置和编译源代码。它也描述了如何打包软件，例如打包成不同的 .deb 包，安装到目标系统不同的路径。Recipe是用 Bitbake 自己的编程语言编写的，语法很简单。但是，Recipe 可以包含 Python 以及 bash 代码

+
+
+

1.4.2. 类

+

类将Recipe中的各个方法组合成可重复使用的代码块。

+
+
+

1.4.3. Layers

+

layer是Recipe、类和配置元数据的集合。Layer可以依赖于其他Layer, 它封装了特定的功能。每个Layer都属于一个特别的category：

+
    +

  • Base

    • +

  • Machine（BSP）

    • +

  • Software

    • +

  • Distribution

    • +

  • Miscellaneous

    • +
+

Yocto 的版本控制方案在每一个Layer中以版本分支的形式体现。对于每个 Yocto 版本，每个Layer在其 Git 仓库中都有一个对应分支。您可以在Yocto工程中添加一个或多个Layer。

+

可以在这里https://layers.openembedded.org/layerindex/branch/kirkstone/layers/找到 OpenEmbedded Layer的集合。搜索功能非常有用，可以查看是否可以轻松检索和集成软件包。

+
+
+

1.4.4. Machine

+

Machine是用来描述所使用的目标硬件(核心板/开发套件)的变量。

+
+
+

1.4.5. 发行版 (Distro)

+

发行版描述了软件配置以及一系列的软件特性。

+
+
+
+

1.5. Poky

+

Poky 是定义 Yocto 项目的参考系统。它将几个子项目组合成发行版：

+
    +

  • Bitbake

    • +

  • Toaster

    • +

  • OpenEmbedded Core

    • +

  • Yocto 文档

    • +

  • Yocto 参考 BSP

    • +
+
+

1.5.1. Bitbake

+

Bitbake 是任务调度器。它是一个Python脚本，解析用 Bitbake 自己的编程语言、 Python 或者 bash 代码编写的recipe。官方文档可在此处找到：https://docs.yoctoproject.org/bitbake/2.0/index.html

+
+
+

1.5.2. Toaster

+

Toaster 是 Bitbake 的用于启动和分析工程构建的Web 前端。它提供有关编译历史和所生成镜像的统计信息。在多个案例中，安装和维护 Toaster 是有十分有益的。PHYTEC 未对 Poky 提供的 Toaster 作任何功能增减。如果想了解更多，请参考官方文档：https://docs.yoctoproject.org/4.0.6/toaster-manual/index.html

+
+
+
+

1.6. 官方文档

+

有关 Bitbake 和 Poky 的更多常见问题，请参阅手册：https://docs.yoctoproject.org/4.0.6/singleindex.html

+
+
+
+

2. Linux主机开发环境

+

构建 Yocto，您需要一台合适的 Linux 主机开发环境。支持的Linux发行版列表可在参考手册中找到：https://docs.yoctoproject.org/4.0.6/ref-manual/system-requirements.html#supported-linux-distributions

+
+
+

3. PHYTEC BSP 介绍

+
+

3.1. BSP 框架

+

BSP 大致由三部分组成。BSP 包管理、BSP 元数据和 BSP 代码源。包管理包括 Repo 和 phyLinux，而元数据取决于 SOC，它描述了如何构建软件。BSP 内容源来自 PHYTEC 的 Git 仓库和外部源。

+
+

3.1.1. BSP 包管理

+

Yocto 是一个综合项目。通常情况下，这意味着会强制用户将他们的Yocto项目建立在几个外部仓库上。这些库需要以特定的方式进行管理。我们使用包含 XML 数据结构的清单文件来描述不同版本的 git 仓库。 Repo 工具和我们的 phyLinux 脚本用于管理清单文件并配置 BSP工程。

+
+

3.1.1.1. phyLinux

+

phyLinux 是 Repo 的包装器，用于下载和配置 BSP，提供“开箱即用”的体验。

+
+
+

3.1.1.2. Repo

+

Repo 是 Repo 工具集的包装器。phyLinux 脚本将把Repo安装在全局PATH中。当您首次运行 repo init -u <url>，它会从 Googles Git 服务器下载特定版本的 Repo 工具集到 .repo/repo 目录。下次运行 Repo 时， Repo 工具集相关的指令就可以直接被使用了。请注意，如果您不运行 Repo sync，不同构建目录中的 Repo 工具集版本可能会随着时间的推移而有所不同。此外，如果您要保存您的完整BSP工程信息，也需要保存完整的 .repo 文件夹。

+

Repo 需要一个 Git 仓库，该仓库信息是从Repo命令中解析得来。在 PHYTEC BSP 中，该仓库被称为 phy²octo。在此仓库中，有关软件 BSP 版本的所有信息都以XML形式的 Repo 清单存储。清单文件定义了 Git 服务器（称为“Remote”）的URL、 Git 仓库及其状态（称为“projects”）。 Git 仓库可以呈现不同的状态。这其中的状态变化涉及仓库的分支、标签或commit ID。这意味着仓库的状态不一定是唯一的，可以随时间而变化。这就是我们仅使用标签或commit ID 进行发布的原因。这样的话git工作目录的状态就是唯一的，不会改变。

+

BSP的清单文件与BSP版本号同名。它是 BSP 的唯一标识符。发布的BSP会按 SoC 平台排序。所选 SoC 将定义 phy²octo Git 仓库的分支，该分支将用于选择对应的清单文件。

+
+
+
+

3.1.2. BSP 元数据

+

我们在 BSP 中包含了几个第三方Layer，无需集成其他外部项目即可运行完整的 Linux 发行版。以下描述了所有使用的git仓库。

+
+

3.1.2.1. Poky

+

PHYTEC BSP 建立在 Poky 之上。每个Poky有对应的版本，在 Repo 清单中定义。Poky 包含对应版本的 Bitbake。OpenEmbedded Core 的Layer-“meta”是我们自定义 Linux 系统的基石。

+
+
+

3.1.2.2. meta-openembedded

+

OpenEmbedded 是一组Layer，包含有许多开源软件项目的元数据。我们的 BSP 提供了所有的 OpenEmbedded Layer，但并非所有Layer都已使能。我们的示例镜像包含了几个 OpenEmbedded Layer中的Recipe所生成的软件包。

+
+
+

3.1.2.3. meta-qt6

+

该Layer在 Poky 根文件系统的基础上集成了 Qt6 ，我们的BSP已经包含了该Layer。

+
+
+

3.1.2.4. meta-nodejs

+

这是用于添加最新版本 Node.js 的Layer。

+
+
+

3.1.2.5. meta-gstreamer1.0

+

这是用于添加最新版本 GStreamer 的Layer。

+
+
+

3.1.2.6. meta-rauc

+

这一Layer包含搭建 RAUC 系统更新服务所需的工具. 与其他系统更新机制的对比可以在这里找到：Yocto 系统更新工具.

+
+
+

3.1.2.7. meta-phytec

+

这一Layer包含我们 BSP 的所有machine和通用特性。它是 PHYTEC 的 Yocto BSP （从Yocto fido 版本开始），适用于PHYTEC所有支持的硬件，并且从设计上和 Poky Layer相互独立。如果您想将 PHYTEC 的硬件集成到现有的 Yocto 项目中，只需要这两个Layer即可。其中包括：

+
    +

  • recipes-bsp/barebox/ 和 recipes-bsp/u-boot/ 中的Bootloader

    • +

  • recipes-kernel/linux/ 和 dynamic-layers/fsl-bsp-release/recipes-kernel/linux/ 中的kernel

    • +

  • conf/machine/ 中有许多machine

    • +

  • 适配 AM335x 和 i.MX 6 平台的 OpenGL ES/EGL 上层库

    • +

  • 适配 i.MX 6 平台的 OpenCL 库

    • +
+
+
+

3.1.2.8. meta-ampliphy

+

这是我们的发行版示例 layer。它扩展了 Poky 的基础配置，为您的特定开发场景提供了基础。当前功能包括：

+
    +

  • systemd 初始化系统

    • +

  • 镜像：用于非图形应用的 phytec-headless-image

    • +

  • 基于i.MX 6 平台 的相机、OpenCV 和 GStreamer 集成示例，包含在 phytec-vision-image 中

    • +

  • 集成RAUC：我们为 A/B 系统镜像更新提供了基础支持，该更新可在本地和远程进行

    • +
+
+
+

3.1.2.9. meta-qt6-phytec

+

这是我们用于集成 Qt6 和展示Qt6 demo的Layer。其特点是：

+
    +

  • 针对 PHYTEC AM335x、i.MX 6 和 RK3288 平台的 带有 eglfs 后台的 Qt6

    • +

  • 镜像：带有 Qt6 以及视频应用的 phytec-qt6demo-image

    • +

  • Qt6 示例程序演示如何使用 QML widgets 和 一个 Bitbake recipe在 Yocto 搭建 Qt6 项目并集成到 systemd 中。该示例程序可以在 sources/meta-qt6-phytec/recipes-qt/examples/phytec-qtdemo_git.bb 中找到

    • +
+
+
+

3.1.2.10. meta-virtualization

+
    +

  • 该Layer为构建Xen、KVM、Libvirt以及其他基于OpenEmbedded的虚拟化解决方案提供必要的支持。

    • +
+
+
+

3.1.2.11. meta-security

+
    +

  • 该Layer提供安全工具、Linux内核的强化工具以及实现安全机制的库。

    • +
+
+
+

3.1.2.12. meta-selinux

+
    +

  • 此Layer的目的是启用 SE Linux 支持。此Layer的大部分工作是在 bbappend 文件中完成的，用于在现有Recipe中启用 SE Linux 支持。

    • +
+
+
+

3.1.2.13. meta-browser

+
    +

  • 这是用于添加常用 Web 浏览器（Chromium、Firefox 等）的Layer。

    • +
+
+
+

3.1.2.14. meta-rust

+
    +

  • 包括 Rust 编译器和 Rust 的 Cargo 包管理器。

    • +
+
+
+

3.1.2.15. meta-timesys

+
    +

  • Timesys Layer用于 Vigiles Yocto CVE 监控、安全提醒和镜像清单的生成。

    • +
+
+
+

3.1.2.16. meta-freescale

+
    +

  • 该Layer为i.MX、Layerscape和QorIQ产品线提供支持。

    • +
+
+
+

3.1.2.17. meta-freescale-3rdparty

+
    +

  • 为来自不同供应商的主板提供支持。

    • +
+
+
+

3.1.2.18. meta-freescale-distro

+
    +

  • 该Layer为freescale的演示镜像提供支持，以便与 OpenEmbedded 和/或 Yocto Freescale 的 BSP Layer一起使用。

    • +
+
+
+

3.1.2.19. base layer（fsl-community-bsp-base）

+
    +

  • 该layer提供NXP的基础BSP文件。

    • +
+
+
+

3.1.2.20. meta-fsl-bsp-release

+
    +

  • 这是 i.MX Yocto 项目发行版的Layer。

    • +
+
+
+
+

3.1.3. BSP 代码源

+

当您首次开始使用 Bitbake 时，BSP 代码会从不同的线上源提取。所有相关的源文件都会被下载并拷贝到在 Yocto 中被配置为 DL_DIR 的本地目录中。如果您想备份包含完整内容源的 BSP，您也必须备份这些源文件。在 生成镜像源，开启离线构建 一章中会作出进一步解释。

+
+
+
+

3.2. 编译配置

+

BSP 初始化一个编译文件夹，该文件夹将包含运行 Bitbake 命令所生成的所有文件。它也包含一个用于处理用户输入的 conf 文件夹。

+
    +

  • bblayers.conf 定义使能的元 layers，

    • +

  • local.conf 可以自定义Yocto工程的用户输入变量

    • +

  • site.conf 自定义与编译主机相关的输入变量

    • +
+

两个最顶层的用户输入变量是 DISTRO 和 MACHINE 。当您使用 phyLinux 的方式获取 BSP 时，它们会体现在BSP预先配置的 local.conf 文件中。

+

我们在 BSP 中使用“Ampliphy”作为软件发行版 DISTRO 。此DISTRO将被预先选定，并为您提供实现自定义软件发行版的起点。

+

MACHINE 定义支持特定核心板和底板的二进制镜像。请查看 machine.conf 文件或我们的网页以了解硬件的描述。

+
+
+
+

4. 预编译镜像

+

对于每个 BSP，我们都提供了预编译的目标镜像，可以从 PHYTEC FTP 服务器下载：https://download.phytec.de/Software/Linux/

+

这些镜像也可用于 BSP 测试，他们会在生产时烧写到产品中。您可以使用提供的 .wic 镜像创建 SD 卡启动盘。识别您的硬件Machine并使用 dd 将下载的镜像文件烧写到格式化的 SD 卡中。有关该命令的正确用法的信息，请参阅镜像部分。

+
+
+

5. BSP Workspace安装

+
+

5.1. 设置主机

+

您可以设置主机或使用我们的编译容器来进行 Yocto 工程构建。您需要有一个运行中的 Linux 发行版系统，它应该在一台性能和存储空间强大的机器上运行，因为Yocto需要进行大量编译。

+

如果您想使用编译容器，您只需要在主机上安装以下软件包

+
host:~$ sudo apt install wget git
+
+
+

之后继续下一步 Git 配置。关于如何使用编译容器 ，您可以在本文档phyLinux 高级用法 之后章节找到。

+

如果您不想使用编译容器， Yocto 需要在您主机上安装一些其他的软件包。对于 Ubuntu 20.04，您需要

+
host:~$ sudo apt install gawk wget git diffstat unzip texinfo \
+      gcc build-essential chrpath socat cpio python3 python3-pip \
+      python3-pexpect xz-utils debianutils iputils-ping python3-git \
+      python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm \
+      python3-subunit mesa-common-dev zstd liblz4-tool
+
+
+

对于其他发行版，您可以在 Yocto 快速编译:https://docs.yoctoproject.org/4.0.6/brief-yoctoprojectqs/index.html 中找到所需要的信息。

+
+
+

5.2. Git 配置

+

BSP 大量使用 Git。 Git 需要您提供一些信息来识别谁对文件进行了更改。如果您没有 ~/.gitconfig 这个文件，请创建一个包含以下内容的文件

+
[user]
+    name = <Your Name>
+    email = <Your Mail>
+[core]
+    editor = vim
+[merge]
+    tool = vimdiff
+[alias]
+    co = checkout
+    br = branch
+    ci = commit
+    st = status
+    unstage = reset HEAD --
+    last = log -1 HEAD
+[push]
+    default = current
+[color]
+    ui = auto
+
+
+

您应该在 Git 配置中设置 name 和 email，否则， Bitbake 会在第一次构建时报错。您可以使用这两个命令直接设置它们，而无需手动编辑 ~/.gitconfig

+
host:~$ git config --global user.email "your_email@example.com"
+host:~$ git config --global user.name "name surname"
+
+
+
+
+

5.3. site.conf 设置

+

在开始编译 Yocto 之前，建议进行初步配置。有两个配置最为重要：下载目录和缓存目录的配置。PHYTEC 强烈建议对这两个配置项进行配置，因为它将减少您后续编译的时间。

+

下载目录是 Yocto 存储从互联网获取的所有源文件/源代码的地方。它可以包含 tar.gz、 Git 镜像源等。建议将下载目录设置为编译主机上用户可以共享的目录。我们首先要给这个目录赋予777访问权限，因为如果要让不同用户共享此目录，则所有文件都需要具有组写入访问权限。这很可能与默认 umask 设置冲突。一种可能的解决方案是对此目录使用 ACL

+
host:~$ sudo apt-get install acl
+host:~$ sudo setfacl -R -d -m g::rwx <dl_dir>
+
+
+

如果您已经创建了下载目录，但是后续想要更改权限，可以使用

+
host:~$ sudo find /home/share/ -perm /u=r ! -perm /g=r -exec chmod g+r \{\} \;
+host:~$ sudo find /home/share/ -perm /u=w ! -perm /g=w -exec chmod g+w \{\} \;
+host:~$ sudo find /home/share/ -perm /u=x ! -perm /g=x -exec chmod g+x \{\} \;
+
+
+

缓存目录存储编译过程的所有阶段产物。 Poky 具有相当复杂的缓存架构。建议创建一个共享目录，这样所有构建都可以访问此缓存目录，这被称为共享状态缓存。

+

在大约有 50 GB 空闲空间的硬盘上创建这两个目录，并在 build/conf/local.conf 中修改对应的变量值

+
DL_DIR ?= "<your_directory>/yocto_downloads"
+SSTATE_DIR ?= "<your_directory>/yocto_sstate"
+
+
+

如果您想了解更多有关如何配置Yocto工程的信息，请参阅Yocto工程中的文档示例设置

+
sources/poky/meta-yocto/conf/local.conf.sample
+sources/poky/meta-yocto/conf/local.conf.sample.extended
+
+
+
+
+
+

6. phyLinux 文档

+

phyLinux 脚本是使用 Python 编写，用来管理 PHYTEC Yocto BSP 版本。它主要是帮助用户快速上手PHYTEC BSP。您无需与 Repo 或 Git 交互，只使用phyLinux可以获取所有 BSP 源文件

+

phyLinux 脚本只有一个依赖项，那就是它需要您在主机上安装 wget 工具。执行后它会将 Repo 工具 安装到您主机上的全局PATH (/usr/local/bin) 中。您也可以手动安装到其他位置。如果已经在 PATH 中找到 Repo，phyLinux 将自动检测到并使用它。 Repo 工具被用来管理 Yocto BSP 的众多 Git 仓库。

+
+

6.1. 获取 phyLinux

+

phyLinux 脚本可以在 PHYTEC 下载服务器上找到：https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux

+
+
+

6.2. 基本用法

+

对于 phyLinux 的基本用法，请输入

+
host:~$ ./phyLinux --help
+
+
+

这将导致

+
usage: phyLinux [-h] [-v] [--verbose] {init,info,clean} ...
+
+This Programs sets up an environment to work with The Yocto Project on Phytecs
+Development Kits. Use phyLinx <command> -h to display the help text for the
+available commands.
+
+positional arguments:
+  {init,info,clean}  commands
+    init             init the phytec bsp in the current directory
+    info             print info about the phytec bsp in the current directory
+    clean            Clean up the current working directory
+
+optional arguments:
+  -h, --help         show this help message and exit
+  -v, --version      show program's version number and exit
+  --verbose
+
+
+
+
+

6.3. 初始化

+

创建一个新的项目文件夹

+
host:~$ mkdir ~/yocto
+
+
+

调用 phyLinux 将使用系统上安装的默认Python版本。从 Ubuntu 20.04 开始，默认是 Python3。如果您想启动与 Python3 不兼容的 BSP，您需要在运行 phyLinux 之前将 Python2 设置为默认值（临时）

+
host:~$ ln -s \`which python2\` python && export PATH=`pwd`:$PATH
+
+
+

现在在新文件夹下运行 phyLinux

+
host:~$ ./phyLinux init
+
+
+

空的文件夹很重要，因为 phyLinux 将会清空该目录。在非空目录运行 phyLinux 会有以下 告警:

+
This current directory is not empty. It could lead to errors in the BSP configuration
+process if you continue from here. At the very least, you have to check your build directory
+for settings in bblayers.conf and local.conf, which will not be handled correctly in
+all cases. It is advisable to start from an empty directory of call:
+$ ./phyLinux clean
+Do you really want to continue from here?
+[yes/no]:
+
+
+

在第一次初始化时，phyLinux 脚本会要求您在 /usr/local/bin 目录中安装 Repo 工具。在执行 init 命令期间，您需要选择处理器平台 (SoC)、PHYTEC 的 BSP 版本号以及您正在使用的Machine

+
***************************************************
+* Please choose one of the available SoC Platforms:
+*
+*   1: am335x
+*   2: am57x
+*   3: am62ax
+*   4: am62x
+*   5: am64x
+*   6: am68x
+*   7: imx6
+*   8: imx6ul
+*   9: imx7
+*   10: imx8
+*   11: imx8m
+*   12: imx8mm
+*   13: imx8mp
+*   14: imx8x
+*   15: imx93
+*   16: nightly
+*   17: rk3288
+*   18: stm32mp13x
+*   19: stm32mp15x
+*   20: topic
+
+# Exemplary output for chosen imx6ul
+***************************************************
+* Please choose one of the available Releases:
+*
+*   1: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc1
+*   2: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc2
+*   3: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc3
+*   4: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc4
+*   5: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2-rc5
+*   6: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2.0
+*   7: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2.1-rc1
+*   8: BSP-Yocto-Ampliphy-i.MX6UL-PD21.2.1
+*   9: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1-rc2
+*   10: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1-rc3
+*   11: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1-rc4
+*   12: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.0
+*   13: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1-rc1
+*   14: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1
+*   15: BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.y
+*   16: BSP-Yocto-Vendor-phyBOARD-Segin-PD17.1.0
+*   17: BSP-Yocto-Vendor-phyBOARD-Segin-PD17.1.1
+*   18: BSP-Yocto-Vendor-phyBOARD-Segin-PD17.1.2
+*   19: BSP-Yocto-i.MX6UL-PD19.1-rc1
+*   20: BSP-Yocto-i.MX6UL-PD19.1-rc2
+*   21: BSP-Yocto-i.MX6UL-PD19.1-rc3
+*   22: BSP-Yocto-i.MX6UL-PD19.1.0
+*   23: BSP-Yocto-i.MX6UL-PD19.1.1-rc1
+*   24: BSP-Yocto-i.MX6UL-PD19.1.1
+*   25: BSP-Yocto-i.MX6UL-PD19.1.2-rc1
+*   26: BSP-Yocto-i.MX6UL-PD19.1.2-rc2
+*   27: BSP-Yocto-i.MX6UL-PD19.1.2
+*   28: BSP-Yocto-i.MX6UL-PD21.1.0
+*   29: BSP-Yocto-i.MX6UL-PD21.1.y
+*   30: BSP-Yocto-phyBOARD-Segin-PD17.2.0
+*   31: BSP-Yocto-phyBOARD-Segin-i.MX6UL-ALPHA1
+*   32: BSP-Yocto-phyBOARD-Segin-i.MX6UL-ALPHA2
+
+# Exemplary output for chosen BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1
+*********************************************************************
+* Please choose one of the available builds:
+*
+no:                 machine: description and article number
+                             distro: supported yocto distribution
+                             target: supported build target
+
+ 1: phyboard-segin-imx6ul-2: PHYTEC phyBOARD-Segin i.MX6 UltraLite
+                             512MB RAM, NAND
+                             PB-02013-001.A2, PB-02013-110I.A2, PCL-063-23300CI.A2
+                             distro: ampliphy
+                             target: phytec-headless-image
+                             target: phytec-qt5demo-image
+ 2: phyboard-segin-imx6ul-6: PHYTEC phyBOARD-Segin i.MX6 ULL
+                             512MB RAM, NAND
+                             PB-02013-001.A5, PB-02013-310I.A0, PCL-063-23900CI.A0
+                             distro: ampliphy
+                             target: -c populate_sdk phytec-qt5demo-image
+                             target: phytec-headless-image
+                             target: phytec-qt5demo-image
+                             target: phytec-vision-image
+ 3: phyboard-segin-imx6ul-6: PHYTEC phyBOARD-Segin i.MX6 ULL
+                             512MB RAM, NAND
+                             PB-02013-001.A5, PB-02013-310I.A0, PCL-063-23900CI.A0
+                             distro: ampliphy-rauc
+                             target: phytec-headless-bundle
+                             target: phytec-headless-image
+...
+
+10: phygate-tauri-s-imx6ul-1: PHYTEC phyGATE-Tauri-S i.MX6 ULL
+                             512MB RAM, eMMC
+                             PB-03513.A1, PCL-063-20910CI.A0
+                             distro: ampliphy
+                             target: phytec-headless-image
+11: phygate-tauri-s-imx6ul-1: PHYTEC phyGATE-Tauri-S i.MX6 ULL
+                             512MB RAM, eMMC
+                             PB-03513.A1, PCL-063-20910CI.A0
+                             distro: ampliphy-provisioning
+                             target: phytec-provisioning-image
+12: phygate-tauri-s-imx6ul-1: PHYTEC phyGATE-Tauri-S i.MX6 ULL
+                             512MB RAM, eMMC
+                             PB-03513.A1, PCL-063-20910CI.A0
+                             distro: ampliphy-secure
+                             target: phytec-security-bundle
+                             target: phytec-security-image
+
+
+

如果您无法通过以上phyLinux选择器提供的信息识别您的所使用的硬件，请查看PHYTEC产品发票。配置完成后，您可以运行

+
host:~$ ./phyLinux info
+
+# Exemplary output
+***********************************************
+* The current BSP configuration is:
+*
+* SoC:  refs/heads/imx6ul
+* Release:  BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1
+*
+***********************************************
+
+
+

查看当前BSP选择了哪款 SoC 和 BSP版本。如果您不想使用phyLinux提供的选择器，phyLinux 还支持多种命令行参数去设置Soc和BSP版本

+
host:~$ MACHINE=phyboard-segin-imx6ul-2 ./phyLinux init -p imx6ul -r BSP-Yocto-Ampliphy-i.MX6UL-PD22.1.1
+
+
+

或者查看帮助命令以获取更多信息

+
host:~$ ./phyLinux  init --help
+
+usage: phyLinux init [-h] [--verbose] [--no-init] [-o REPOREPO] [-b REPOREPO_BRANCH] [-x XML] [-u URL] [-p PLATFORM] [-r RELEASE]
+
+options:
+  -h, --help          show this help message and exit
+  --verbose
+  --no-init           dont execute init after fetch
+  -o REPOREPO         Use repo tool from another url
+  -b REPOREPO_BRANCH  Checkout different branch of repo tool
+  -x XML              Use a local XML manifest
+  -u URL              Manifest git url
+  -p PLATFORM         Processor platform
+  -r RELEASE          Release version
+
+
+

执行 init 命令后，phyLinux 将打印一些重要说明以及后续构建步骤的信息。

+
+
+

6.4. 高级用法

+

phyLinux 可用于通过多种媒介传输软件状态。软件状态在 manifest.xml 有特定标识。您可以创建一个清单文件，将其发送到另一个地方，然后使用以下方式来恢复软件状态，得到目标软件版本

+
host:~$ ./phyLinux init -x manifest.xml
+
+
+

您还可以创建一个包含软件状态的 Git 仓库。该 Git 仓库需要有除了master以外的分支，因为我们保留了master分支用于其他用途。使用 phyLinux 检查软件状态

+
host:~$ ./phyLinux -u <url-of-your-git-repo>
+
+
+
+
+
+

7. 使用编译容器

+
+

警告

+

目前，无法在容器内运行 phyLinux 脚本。在主机上使用 phyLinux 脚本完成初始化后，您可以使用容器进行编译。如果您的机器上没有 phyLinux 脚本，请参阅 phyLinux 文档。

+
+

运行编译容器有多种实现方式。常用的是 docker 和 podman，但我们更喜欢 podman，因为它不需要 root 权限即可运行。

+
+

7.1. 安装

+

如何安装 podman：https://podman.io 如何安装 docker：https://docs.docker.com/engine/install/

+
+
+

7.2. 可用容器

+

目前我们基于 Ubuntu LTS 版本提供了4个不同版本的容器：https://hub.docker.com/u/phybuilder

+
    +

  • yocto-ubuntu-16.04

    • +

  • yocto-ubuntu-18.04

    • +

  • yocto-ubuntu-20.04

    • +

  • yocto-ubuntu-22.04

    • +
+

这些容器可以使用 podman 或 docker 运行。对于 Yocto Kirkstone 版本，容器“yocto-ubuntu-20.04”是首选。

+
+
+

7.3. 下载/拉取容器

+
host:~$ podman pull docker.io/phybuilder/yocto-ubuntu-20.04
+
+OR
+
+host:~$ docker pull docker.io/phybuilder/yocto-ubuntu-20.04
+
+
+

在末尾添加以冒号分隔的容器标签，您还可以拉取或运行带有特殊标签的容器。

+
+

podman pull docker.io/phybuilder/yocto-ubuntu-20.04:phy2

+
+

您可以在我们的 duckerhub 空间中找到所有可用的标签：

+ +

如果您尝试运行尚未拉取/下载的容器，它将被自动拉取/下载。

+

您可以使用以下命令查看所有已下载/拉取的容器：

+
$USERNAME@$HOSTNAME:~$ podman images
+REPOSITORY                               TAG         IMAGE ID      CREATED       SIZE
+docker.io/phybuilder/yocto-ubuntu-22.04  latest      d626178e448d  4 months ago  935 MB
+docker.io/phybuilder/yocto-ubuntu-22.04  phy2        d626178e448d  4 months ago  935 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  phy2        e29a88b7172a  4 months ago  900 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  latest      e29a88b7172a  4 months ago  900 MB
+docker.io/phybuilder/yocto-ubuntu-18.04  phy1        14c9c3e477d4  7 months ago  567 MB
+docker.io/phybuilder/yocto-ubuntu-18.04  latest      14c9c3e477d4  7 months ago  567 MB
+docker.io/phybuilder/yocto-ubuntu-16.04  phy1        28c73e13ab4f  7 months ago  599 MB
+docker.io/phybuilder/yocto-ubuntu-16.04  latest      28c73e13ab4f  7 months ago  599 MB
+docker.io/phybuilder/yocto-ubuntu-22.04  phy1        5a0ef4b41935  8 months ago  627 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  phy1        b5a26a86c39f  8 months ago  680 MB
+
+
+
+
+

7.4. 运行容器

+

要运行并使用容器进行 Yocto 构建，首先进入您之前运行 phyLinux init 的文件夹。然后启动容器

+
host:~$ podman run --rm=true -v /home:/home --userns=keep-id --workdir=$PWD -it docker.io/phybuilder/yocto-ubuntu-20.04 bash
+
+
+
+

备注

+

要使用 docker 运行和使用容器，并不像使用 podman 那么简单，必须先定义和配置容器用户。此外，默认情况下docker不支持转发信任凭据，所以必须对信任凭据进行配置。

+
+

现在您的命令行看起来应该是这样的（其中 $USERNAME 是调用“podman run”的用户，并且每次启动容器时容器代码都会有所不同）

+
$USERNAME@6593e2c7b8f6:~$
+
+
+
+

警告

+

如果进入容器的用户名是“root”，您将无法运行 bitbake。请确保使用您自己的用户名运行容器。

+
+

现在您可以在容器中开始构建。要停止/关闭容器，只需调用

+
$USERNAME@6593e2c7b8f6:~$ exit
+
+
+
+
+
+

8. 使用 Poky 和 Bitbake

+
+

8.1. 开始构建

+

使用 phyLinux init 下载所有元数据后，您必须设置 shell 环境变量。每次打开新 shell 开始构建时都需要执行此操作。我们使用 Poky 默认提供的 shell 脚本。在项目的根目录输入

+
host:~$ source sources/poky/oe-init-build-env
+
+
+

source命令的缩写是一个 .

+
host:~$ . sources/poky/oe-init-build-env
+
+
+

shell 的当前工作目录会被改为 build/。在第一次构建之前，您应该查看主配置文件

+
host:~$ vim conf/local.conf
+
+
+

您当前构建的所有产物存储在这里。根据您使用的芯片平台，可能需要接受许可协议。例如，对于Freescale/NXP 的芯片平台，您需要接受 GPU 和 VPU 二进制许可协议。通过取消注释相应的行来接受许可协议

+
# Uncomment to accept NXP EULA # EULA can be found under
+../sources/meta-freescale/EULA ACCEPT_FSL_EULA = "1"
+
+
+

现在您可以构建第一个镜像了。我们建议从较小的非图形镜像 phytec-headless-image 开始，看看一切是否正常工作

+
host:~$ bitbake phytec-headless-image
+
+
+

在 Intel Core i7 上，首次编译大约需要 40 分钟。但是所有的后续构建都将复用之前的缓存，编译大约需要 3 分钟。

+
+
+

8.2. Images

+

如果一切顺利，可以在以下位置找到镜像

+
host:~$ cd deploy/images/<MACHINE>
+
+
+

测试镜像最简单的方法是将核心板配置为 SD 卡启动，并将构建所得镜像烧写到 SD 卡中

+
host:~$ sudo dd if=phytec-headless-image-<MACHINE>.wic of=/dev/<your_device> bs=1M conv=fsync
+
+
+

这里<your_device>可以是“sde”，具体取决于您的系统。选择硬盘驱动时要非常小心！选择错误的硬盘驱动可能会擦除您的硬盘！参数 conv=fsync 强制数据缓冲区在 dd 返回之前写入硬盘。

+

启动后，您可以使用串口或通过网口 ssh 登录。root账户没有密码。这是因为 conf/local.conf 中开启了调试模式。如果您取消注释该行

+
#EXTRA_IMAGE_FEATURES = "debug-tweaks"
+
+
+

调试模式（例如设置空的 root 密码）将不会生效。

+
+
+

8.3. 获取BSP长期维护版本之间的中间开发版本

+

您也可以访问 Yocto BSP 最新的开发中版本，这属于特殊版本，并不是正式的长期维护版本，所以它们不会显示在 phyLinux 选择菜单中，需要手动选择。可以使用以下命令行来获取BSP

+
host:~$ ./phyLinux init -p master -r kirkstone
+
+
+

这将初始化一个最新的BSP开发版本。运行

+
host:~$ repo sync
+
+
+

该文件夹将从我们的 Git 仓库中提取所有最新更改。

+
+
+

8.4. 检查您的编译配置

+

Poky 包含多个工具来检查您的Yocto工程。您可以查询Layer工具支持的指令

+
host:~$ bitbake-layers
+
+
+

例如，它可以用来查看特定Recipe在哪一个Layer被修改了

+
host:~$ bitbake-layers show-appends
+
+
+

在运行构建之前，您还可以启动 Toaster，以便能够使用 Toaster Web GUI 图形界面检查构建的详细信息

+
host:~$ source toaster start
+
+
+

但是您可能需要先安装一些依赖才能运行toaster

+
host:~$ pip3 install -r
+../sources/poky/bitbake/toaster-requirements.txt
+
+
+

然后，您可以将浏览器指向 http://0.0.0.0:8000/ 并继续使用 Bitbake。可以从此 Web 服务器监控和分析所有构建活动。如果您想了解有关 Toaster 的更多信息，请查看 https://docs.yoctoproject.org/4.0.6/toaster-manual/index.html。要关闭 Toaster Web GUI，请执行"控制台，请通过串口或网

+
host:~$ source toaster stop
+
+
+
+
+

8.5. meta-phytec 和 meta-ampliphy 的特点

+
+

8.5.1. Buildinfo

+

Buildinfo 任务是我们Recipe中的一个函数，可打印从公共仓库获取源代码的过程。因此您不必亲自查看对应的Recipe，用 Buildinfo 即可查看过程说明（例如 barebox 包的说明），请执行

+
host:~$ bitbake barebox -c buildinfo
+
+
+

在您的 shell 中，会打印如下类似信息

+
(mini) HOWTO: Use a local git repository to build barebox:
+
+To get source code for this package and version (barebox-2022.02.0-phy1), execute
+
+$ mkdir -p ~/git
+$ cd ~/git
+$ git clone git://git.phytec.de/barebox barebox
+$ cd ~/git/barebox
+$ git switch --create v2022.02.0-phy1-local-development 7fe12e65d770f7e657e683849681f339a996418b
+
+You now have two possible workflows for your changes:
+
+1. Work inside the git repository:
+Copy and paste the following snippet to your "local.conf":
+
+SRC_URI:pn-barebox = "git://${HOME}/git/barebox;branch=${BRANCH}"
+SRCREV:pn-barebox = "${AUTOREV}"
+BRANCH:pn-barebox = "v2022.02.0-phy1-local-development"
+
+After that you can recompile and deploy the package with
+
+$ bitbake barebox -c compile
+$ bitbake barebox -c deploy
+
+Note: You have to commit all your changes. Otherwise yocto doesn't pick them up!
+
+2. Work and compile from the local working directory
+To work and compile in an external source directory we provide the
+externalsrc.bbclass. To use it, copy and paste the following snippet to your
+"local.conf":
+
+INHERIT += "externalsrc"
+EXTERNALSRC:pn-barebox = "${HOME}/git/barebox"
+EXTERNALSRC_BUILD:pn-barebox = "${HOME}/git/barebox"
+
+Note: All the compiling is done in the EXTERNALSRC directory. Every time
+you build an Image, the package will be recompiled and build.
+
+NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded.
+NOTE: Writing buildhistory
+
+
+

正如您所见，控制台输出了清楚地说明了构建信息。

+
+

警告

+

使用 外部源 会破坏 Yocto 的许多内部依赖机制。在构建过程中，源目录下的更改并不能保证被自动抓取并合并到根文件系统或 SD 卡镜像中。您必须始终使用 --force。例如，在编译 barebox 并将其重新部署到 deploy/images/<machine> 时需要执行

+
host:~$ bitbake barebox -c compile --force
+host:~$ bitbake barebox -c deploy
+
+
+
+

要使用新内核或镜像更新 SD 卡镜像，首先强制编译它，然后强制重建根文件系统。使用

+
host:~$ bitbake phytec-qt6demo-image -c rootfs --force
+
+
+

请注意，Yocto构建系统不会对外部源文件目录进行修改。如果要将 Yocto Recipe携带的所有补丁应用到外部源目录，请运行以下指令

+
SRCTREECOVEREDTASKS="" BB_ENV_PASSTHROUGH_ADDITIONS="$BB_ENV_PASSTHROUGH_ADDITIONS SRCTREECOVEREDTASKS" bitbake <recipe> -c patch
+
+
+
+
+
+

8.6. 自定义BSP

+

为了帮助您开始使用 BSP，我们从 Yocto 官方文档中总结了一些基本任务。它描述了如何向镜像添加其他软件、更改kernel和Bootloader配置，以及应用kernel和Bootloader的补丁。

+

诸如添加软件之类的小修改是在文件 build/conf/local.conf 中完成的。在那里，您可以覆盖全局变量并对recipe进行小修改。

+

有两种方法可以进行重大更改：

+
    +

  1. 创建您自己的Layer并使用 bbappend 文件。

    2. +

  2. 将所有新增内容添加到 PHYTEC 的 Distro Layer meta-ampliphy。

    3. +
+

创建您自己的Layer部分描述了如何创建您自己的Layer。

+
+

8.6.1. 禁用 Qt 示例demo

+

默认情况下，BSP 映像 phytec-qt6demo-image 会在连接的显示器或监视器上启动 Qt6 示例应用程序。如果要停止示例并使用后台得 Linux framebuffer 控制台，请通过串口或网络 ssh 连接到目标并执行 shell 命令

+
target:~$ systemctl stop phytec-qtdemo.service
+
+
+

此命令暂时停止演示app。要重新启动，请重启主板或执行

+
target:~$ systemctl start phytec-qtdemo.service
+
+
+

您可以永久禁用该服务，这样它就不会在开机时自启动

+
target:~$ systemctl disable phytec-qtdemo.service
+
+
+
+

小技巧

+

最后一个命令仅禁用了服务，但是它不会立即停止。要查看当前服务状态，请执行

+
target:~$ systemctl status phytec-qtdemo.service
+
+
+
+

如果要默认禁用该服务，请编辑文件 build/conf/local.conf 并添加以下行

+
# file build/conf/local.conf
+SYSTEMD_AUTO_ENABLE:pn-phytec-qtdemo = "disable"
+
+
+

之后重新编译镜像

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

8.6.2. Framebuffer 控制台

+

在具有显示接口的核心板上，默认启用Framebuffer控制台。您可以连接 USB 键盘并登录。要将键盘布局从默认的英语更改为德语，请键入

+
target:~$ loadkeys /usr/share/keymaps/i386/qwertz/de-latin1.map.gz
+
+
+

如果要退出Framebuffer控制台，请运行

+
target:~$ echo 0 > sys/class/vtconsole/vtcon1/bind
+
+
+

要完全停用Framebuffer控制台，请禁用以下内核配置选项

+
Device Drivers->Graphics Support->Support for framebuffer devices->Framebuffer Console Support
+
+
+

更多信息请访问：https://www.kernel.org/doc/Documentation/fb/fbcon.txt

+
+
+

8.6.3. 预编译镜像中提供的工具

+
+

8.6.3.1. RAM 基准测试

+

RAM 和缓存性能测试的最佳方法是使用 pmbw （并行内存带宽基准测试/测量工具）。 Pmbw 运行多个汇编例程，这些例程都使用不同的访问模式来访问 SoC 的缓存和 RAM。在运行测试之前，请确保设备上有大约 2 MiB 的空间用于存储日志文件。我们还降低了基准测试的级别，以便于更积极地向内核请求资源。基准测试将花费几个小时。

+

要开始测试，请键入

+
target:~$ nice -n -2 pmbw
+
+
+

测试完成后，日志文件可以转换为 gnuplot 脚本，运行

+
target:~$ stats2gnuplot stats.txt > run1.gnuplot
+
+
+

现在您可以将日志文件传输到主机并安装任意版本的 gnuplot

+
host:~$ sudo apt-get install gnuplot host:~$ gnuplot run1.gnuplot
+
+
+

生成的 plots-<machine> .pdf 文件包含所有图表。要将单个图表渲染为 png 文件，您可以使用 Ghostscript

+
host:~$ sudo apt-get install ghostscript
+host:~$ gs -dNOPAUSE -dBATCH -sDEVICE=png16m -r150 -sOutputFile='page-%00d.png' plots-phyboard-wega-am335x-1.pdf
+
+
+
+
+
+

8.6.4. 为 BSP 镜像添加新的软件包

+

要向镜像添加其他软件，请查看 OpenEmbedded Layer索引：https://layers.openembedded.org/layerindex/branch/kirkstone/layers/

+

首先，从左上角的下拉列表中选择您拥有的 BSP 的 Yocto 版本，然后单击 Recipes。现在您可以搜索软件项目名称并找到它所在的Layer。在某些情况下，程序位于 meta-openembedded、 openembedded-core 或 Poky 中，这意味着Recipe已在您的Yocto工程中。本节介绍在这种情况下如何添加软件。如果软件包位于另一个Layer，请参阅下一部分。

+

您还可以搜索可用Recipe列表

+
host:~$ bitbake -s | grep <program name> # fill in program name, like in
+host:~$ bitbake -s | grep lsof
+
+
+

当程序的Recipe已在 Yocto 工程中时，您只需将他添加到文件 build/conf/local.conf 即可。向镜像添加其他软件的一般语法是

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " <package1> <package2>"
+
+
+

例如，这一行

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " ldd strace file lsof"
+
+
+

在目标镜像上安装一些辅助程序。

+
+

警告

+

程序包名称前的空格非常重要。

+
+

local.conf 中的配置项均适用于所有镜像。因此，新增的这些软件工具将被同时包含在 phytec-headless-image 和 phytec-qt6demo-image 镜像中。

+
+

8.6.4.1. 关于软件包和Recipe的说明

+

您正在将软件包添加到 IMAGE_INSTALL 变量中。这些不一定等同于Layer的Recipe名称。Recipe默认定义一个具有相同名称的软件包。但Recipe也可以将 PACKAGES 变量设置为其他名称，并能够生成具有任意名称的软件包。当您查找软件时，严格来说，都必须搜索软件包名称，而不是Recipe。在最坏的情况下，您必须查看所有 PACKAGES 变量。这会有点繁琐， Toaster 之类的工具可能对查找有所帮助。

+

如果您在文件夹 sources 提供的Layer中找不到您的软件，请参阅下一部分以将一个新的Layer包含到 Yocto 构建中。

+

参考资料：Yocto 4.0.6 文档 - 自定义 Yocto 构建

+
+
+
+

8.6.5. 添加其他Layer

+

这是关于如何在您的 Yocto 构建中添加另一Layer并从中安装软件的详细上手指南。例如，我们将网络安全扫描器 nmap 包含在Layer meta-security 中。首先，您必须找到包含该软件的Layer。查看 OpenEmbedded MetaData 索引 网络扫描器 nmap 位于 meta-security Layer。请参阅 layer.openembedded.org 上的 meta-security。将其集成到 Yocto 构建中，您必须拉取git仓库，然后切换到正确的稳定分支。由于 BSP 是基于 Yocto “sumo”版本构建，您也应该尝试在Layer中使用“sumo”分支。

+
host:~$ cd sources
+host:~$ git clone git://git.yoctoproject.org/meta-security
+host:~$ cd meta-security
+host:~$ git branch -r
+
+
+

所有可用的远程分支都会显示出来。通常应该有“fido”、“jethro”、“krogoth”、“master”……

+
host:~$ git checkout kirkstone
+
+
+

现在我们通过把以下代码添加到 build/conf/bblayers.conf 文件末尾的方式来将Layer包含到构建中

+
# file build/conf/bblayers.conf
+BBLAYERS += "${BSPDIR}/sources/meta-security"
+
+
+

然后，您可以通过执行以下代码来检查该Layer是否在构建配置中可用

+
host:~$ bitbake-layers show-layers
+
+
+

如果出现类似以下错误

+
ERROR: Layer 'security' depends on layer 'perl-layer', but this layer is not enabled in your configuration
+
+
+

如果您要添加的Layer（这里是 meta-security）依赖于另一个Layer，您需要先启用被依赖的Layer。例如，此处所需的依赖项是 meta-openembedded 中的Layer（在 PHYTEC BSP 中，它位于路径 sources/meta-openembedded/meta-perl/ 中）。要启用它，请将以下行添加到 build/conf/bblayers.conf

+
# file build/conf/bblayers.conf
+BBLAYERS += "${BSPDIR}/sources/meta-openembedded/meta-perl"
+
+
+

执行命令 bitbake-layers show-layers 应该会打印所有已启用Layer的列表，包括 meta-security 和 meta-perl。包含该Layer后，您可以按照之前的描述安装Layer中的软件包。最简单的方法是添加以下行（这里是包 nmap）

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " nmap"
+
+
+

到您的 build/conf/local.conf。不要添加后忘记重新构建镜像

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

8.6.6. Create your own layer

+

创建Layer应该是自定义 BSP 的首要任务之一。您有两个选择。您可以复制并重命名 meta-ampliphy，也可以创建一个包含修改的新Layer。哪个选择更好取决于您的使用场景。 meta-ampliphy 是我们自定义 Linux 发行版的示例，该发行版也会在未来持续更新。如果您想从这些更新中受益，并且总体上对它的用户空间配置感到满意，那么在 Ampliphy 基础上创建自己的Layer可能是最佳解决方案。如果您需要重建用户空间架构并且只需要 PHYTEC 的基本硬件支持，最好复制 meta-ampliphy，给Layer重新命名并修改其内容以使其适应您的需求。您还可以查看 OpenEmbedded Layer索引以查找不同的发行版 Layer。如果您只需要将自己的应用程序添加到镜像中，请创建自己的Layer。

+

在下一章中，我们有一个名为“racer”的嵌入式项目，我们将使用我们的 Ampliphy Linux 发行版来集成它。首先，我们需要创建一个新的Layer。

+

Yocto 提供了一个脚本来实现Layer创建。如果您已经配置好 BSP 并且 shell 已准备就绪，请输入

+
host:~$ bitbake-layers create-layer meta-racer
+
+
+

目前来说，默认选项是可行的。将该Layer移动到source目录下

+
host:~$ mv meta-racer ../sources/
+
+
+

在此Layer创建一个 Git 仓库来跟踪您的更改

+
host:~$ cd ../sources/meta-racer
+host:~$ git init && git add . && git commit -s
+
+
+

现在您可以将该Layer直接添加到 build/conf/bblayers.conf

+
BBLAYERS += "${BSPDIR}/sources/meta-racer"
+
+
+

或者使用 Yocto 提供的脚本

+
host:~$ bitbake-layers add-layer meta-racer
+
+
+
+
+

8.6.7. kernel和Bootloader的Recipe和版本

+

首先，您需要知道目标Machine使用哪个kernel和对应的版本。PHYTEC 提供多个kernel recipe linux-mainline、 linux-ti 和 linux-imx。第一个为 PHYTEC 的 i.MX 6 和 AM335x SOM提供支持，他是基于 kernel.org 的 Linux kernel稳定版本。 Git 仓库 URL 为：

+
    +

  • linux-mainline：git://git.phytec.de/linux-mainline

    • +

  • linux-ti: git://git.phytec.de/linux-ti

    • +

  • linux-imx: git://git.phytec.de/linux-imx

    • +

  • barebox：git://git.phytec.de/barebox

    • +

  • u-boot-imx: git://git.phytec.de/u-boot-imx

    • +
+

要找出您最终所使用的kernel recipe，请执行以下命令

+
host:~$ bitbake virtual/kernel -e | grep "PREFERRED_PROVIDER_virtual/kernel"
+
+
+

该命令打印变量 PREFERRED_PROVIDER_virtual/kernel 的值。该变量在 Yocto 构建过程被用来选择要使用的kernel recipe。以下几行是您可能会看到的不同输出值

+
PREFERRED_PROVIDER_virtual/kernel="linux-mainline"
+PREFERRED_PROVIDER_virtual/kernel="linux-ti"
+PREFERRED_PROVIDER_virtual/kernel="linux-imx"
+
+
+

要查看使用的是哪个版本，请执行 bitbake -s。例如

+
host:~$ bitbake -s | egrep -e "linux-mainline|linux-ti|linux-imx|barebox|u-boot-imx"
+
+
+

参数 -s 打印所有相关Recipe和它的版本。输出左侧包含Recipe名称，右侧包含版本

+
barebox                      :2022.02.0-phy1-r7.0
+barebox-hosttools-native     :2022.02.0-phy1-r7.0
+barebox-targettools          :2022.02.0-phy1-r7.0
+linux-mainline               :5.15.102-phy1-r0.0
+
+
+

如您所见，recipe linux-mainline 的版本为 5.15.102-phy1。在 PHYTEC 的 linux-mainline Git 仓库中，您将找到相应的标签 v5.15.102-phy1。 barebox recipe的版本为 2022.02.0-phy1。在 i.MX8M* 模块上，输出将包含 linux-imx 和 u-boot-imx。

+
+
+

8.6.8. Kernel和Bootloader配置

+

PHYTEC 所使用的bootloader barebox 采用与 Linux kernel相同的编译系统。因此，本节中的所有指令均可用于配置kernel以及bootloader。要配置kernel或bootloader，请执行以下命令中的一条。

+
host:~$ bitbake -c menuconfig virtual/kernel  # Using the virtual provider name
+host:~$ bitbake -c menuconfig linux-ti        # Or use the recipe name directly
+host:~$ bitbake -c menuconfig linux-mainline  # Or use the recipe name directly (If you use an i.MX 6 or RK3288 Module)
+host:~$ bitbake -c menuconfig linux-imx       # Or use the recipe name directly (If you use an i.MX 8M*)
+host:~$ bitbake -c menuconfig barebox         # Or change the configuration of the bootloader
+host:~$ bitbake -c menuconfig u-boot-imx      # Or change the configuration of the bootloader (If you use an i.MX 8M*)
+
+
+

之后，您可以重新编译并部署kernel或bootloader

+
host:~$ bitbake virtual/kernel -c compile  # Or 'barebox' for the bootloader
+host:~$ bitbake virtual/kernel -c deploy   # Or 'barebox' for the bootloader
+
+
+

或者，您也可以使用以下命令重新进行完整的构建

+
host:~$ bitbake phytec-headless-image  # To update the kernel/bootloader, modules and the images
+
+
+

在最后一个命令中，您可以将镜像名称替换为您选择的镜像名称。新镜像和二进制文件位于 build/deploy/images/<machine> /.

+
+

警告

+

之前对kernel的配置并不是永久生效的。执行 bitbake virtual/kernel -c clean 可以清除所有内容。

+
+

要使更改在构建系统中永久生效，您需要将配置修改整合到Layer中。您有两种选择：

+
    +

  • 仅包含配置差异片段（新旧配置之间的最小 差异）

    • +

  • 修改后的完整配置（defconfig）。

    • +
+

使用配置片段可以使开发者对不同阶段所做的更改更加清晰。您可以选择启用或禁用这些配置，对不同条件下的配置作管理，这有助于更迅速地将更改的配置迁移到新的kernel版本。您还可以对配置片段进行分组，以在不同的特定场景下使用。生成的完整kernel配置将被放在目录 build/deploy/images/<machine> 中。如果您没有上述这些需求，选择维护完整的 defconfig 文件可能会更加简单。

+
+

8.6.8.1. 将配置片段添加到Recipe

+

以下步骤适用于kernel和bootloader。只需将命令中的recipe名称 linux-mainline 替换为 linux-ti，或者将bootloader替换为 barebox。如果您对这个命令作用还不熟悉，请从一个干净的Yocto工程重新开始。否则，配置的差异可能会导致错误。

+
host:~$ bitbake linux-mainline -c clean
+host:~$ bitbake linux-mainline -c menuconfig
+
+
+

在菜单中更改配置并生成配置片段

+
host:~$ bitbake linux-mainline -c diffconfig
+
+
+

他将会打印生成的配置片段文件路径

+
Config fragment has been dumped into:
+/home/<path>/build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg
+
+
+

所有的配置修改都记录在文件 fragment.cfg 中，该文件仅包含少量配置行。以下示例展示了如何创建 bbappend 文件，以及如何为配置片段添加所需的行。您只需根据特定Recipe调整目录和名称： linux-mainline、 linux-ti、linux-imx、u-boot-imx 或 barebox。

+
sources/<layer>/recipes-kernel/linux/linux-mainline_%.bbappend     # For the recipe linux-mainline
+sources/<layer>/recipes-kernel/linux/linux-ti_%.bbappend           # For the recipe linux-ti
+sources/<layer>/recipes-kernel/linux/linux-imx_%.bbappend          # For the recipe linux-imx
+sources/<layer>/recipes-bsp/barebox/barebox_%.bbappend             # For the recipe barebox
+sources/<layer>/recipes-bsp/u-boot/u-boot-imx_%.bbappend           # For the recipe u-boot-imx
+
+
+

将字符串 layer 替换为您自己创建的layer（如上所示）（例如 meta-racer），或者直接使用 meta-ampliphy。要使用 meta-ampliphy，首先，需要为配置片段创建目录并为其指定一个新名称（此处为 enable-r8169.cfg），然后将片段放到这个Layer中。

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features
+# copy the path from the output of *diffconfig*
+host:~$ cp /home/<path>/build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg \
+    sources/meta-ampliphy/recipes-kernel/linux/features/enable-r8169.cfg
+
+
+

之后使用您喜欢的编辑器打开 bbappend 文件（在本例中为 sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend ）并添加以下几行

+
# contents of the file linux-mainline_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://enable-r8169.cfg \
+"
+
+
+
+

警告

+

不要忘记使用正确的 bbappend 文件名： linux-ti_%.bbappend 用于 linux-ti recipe， barebox_%.bbappend 用于文件夹 recipes-bsp/barebox/ 中的bootloader！

+
+

保存 bbappend 文件后，您需要重新编译镜像。 Yocto 会自动识别recipe的更改并生成新的镜像。

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+
+
+

8.6.8.2. 向Recipe添加一个完整配置 (defconfig)

+

这种方法与之前的方法相似，但不是添加一个片段，而是采用 defconfig。首先，在您想要使用的Layer中创建所需的文件夹，这可以是您自己的Layer，或者是 meta-ampliphy。

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features/ # For both linux-mainline and linux-ti
+host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features/ # Or for the bootloader
+
+
+

然后您需要创建一个合适的 defconfig 文件。使用 menuconfig 进行配置更改，然后将 defconfig 文件保存到Layer中。

+
host:~$ bitbake linux-mainline -c menuconfig # Or use recipe name linux-ti or barebox
+host:~$ bitbake linux-mainline -c savedefconfig # Create file 'defconfig.temp' in the work directory
+
+
+

这将打印defconfig的保存路径

+
Saving defconfig to ..../defconfig.temp
+
+
+

然后，按照前面的说明，将生成的完整配置文件复制到您的Layer中，重命名为 defconfig，并在 bbappend 文件中添加以下行（此处为 sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend）。

+
# contents of the file linux-mainline_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://defconfig \
+"
+
+
+
+

小技巧

+

不要忘记使用正确的 bbappend 文件名： linux-ti_%.bbappend 用于 linux-ti recipe ， barebox_%.bbappend 用于文件夹 recipes-bsp/barebox/ 中的bootloader ！

+
+

这样，在重编镜像时，新的镜像将会包含所作的配置修改。

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+
+
+
+

8.6.9. 使用 devtool 修改Kernel或Bootloader

+

除了使用recipes中提供的标准kernel和bootloader外，您可以选择在yocto中用devtool直接修改源代码或单独下载我们的git仓库来构建您的自定义kernel 。 以下是两种修改方式的优劣对比

+ + + + + + + + + + + + +

优势

劣势

Yocto 官方文档的标准工作流程

重复的源文件包，造成了不必要的硬盘空间浪费。

工具链无需重新编译所有内容。

未能有效利用缓存，导致构建成本增加。

+

Devtool 是一套辅助工具，旨在提升 Yocto 用户的工作效率。它与 1.8 版本相兼容。只需配置好 shell 环境，您就可以使用它。 Devtool 的功能包括：

+
    +

  • 修改现有资源文件

    • +

  • 将其他软件项目纳入您的构建配置中

    • +

  • 编译软件并将修改后的软件部署到目标硬件中。

    • +
+

这里我们将利用 devtool 来修改kernel。我们以 linux-mainline 作为 AM335x kernel的实现示例。我们首先使用的命令是 devtool modify - x <recipe><directory>

+
host:~$ devtool modify -x linux-mainline linux-mainline
+
+
+

Devtool 将在 build/workspace 目录下创建一个layer ，您可以在这个Layer下查看 devtool 命令进行的所有更改。它将与recipe 相关的源代码下载到一个指定的文件夹中以及在workspace生成一个 bbappend 文件，其中的 SRC_URI 指向上述下载文件夹。使用 Bitbake 构建镜像时，将会使用此文件夹中的源代码。现在您可以对kernel进行修改。

+
host:~$ vim linux-mainline/arch/arm/boot/dts/am335x-phycore-som.dtsi
+      -> make a change
+host:~$ bitbake phytec-qt6demo-image
+
+
+

您的更改现在将被重新编译并添加到镜像中。如果您希望永久保存这些更改，建议您根据更改创建一个补丁，存储和备份该补丁。您可以进入 linux-mainline 目录并使用 Git 来创建补丁。有关如何创建补丁的详细信息，请参阅 使用“临时方法”修补Kernel 或Bootloader。

+

如果您想了解有关 devtool 的更多信息，请访问：

+

Yocto 4.0.6 - Devtool 或 Devtool 快速指南

+
+
+

8.6.10. 使用“临时方法”修补Kernel 或Bootloader

+ + + + + + + + + + + + +

优势

劣势

无开销，无额外配置

Yocto 非常容易覆盖您所作的修改（所有内容都会丢失！！）。

工具链无需重新编译所有内容。

+

Yocto 允许在 Bitbake 配置和编译recipe之前，更改源代码。使用 Bitbake 的 devshell 命令跳转到recipe的源目录。这是 barebox recipe

+
host:~$ bitbake barebox -c devshell # or linux-mainline, linux-ti, linux-imx, u-boot-imx
+
+
+

执行命令后，将打开一个 shell 窗口。shell 的当前工作目录将更改为 tmp 文件夹中recipe的资源文件目录。在这里，您可以使用您最喜欢的编辑器（例如 vim、 emacs 或任何其他图形编辑器）来更改源代码。完成后，通过键入 exit 或按 CTRL-D 退出 devshell。

+

离开 devshell 后，您可以重新编译软件包

+
host:~$ bitbake barebox -c compile --force # or linux-mainline, linux-ti, linux-imx, u-boot-imx
+
+
+

参数“--force”很重要，因为 Yocto 无法识别源代码是否已被更改。

+
+

小技巧

+

您无法在 devshell 中执行 bitbake 命令。您必须先退出devshell模式。

+
+

如果构建失败，请再次执行 devshell 命令并修复。如果构建成功，则可以部署包并创建新的 SD 卡镜像

+
host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox.bin
+host:~$ bitbake phytec-headless-image # new WIC image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic
+
+
+
+

警告

+

如果您进行clean操作，比如 bitbake barebox -c clean，或者 Yocto 重新下载源码，您所做的所有更改将会丢失！！！

+

为了防止这种情况发生，您可以制作一个补丁并将其添加到 bbappend 文件中。这与配置修改章节中提到的工作流程相似。

+

如果您采用临时方法，让修改永久生效需要在 devshell 中生成补丁；如果您使用 devtool，则必须在 devtool 创建的子目录中生成补丁。

+
+
host:~$ bitbake barebox -c devshell            # Or linux-mainline, linux-ti
+host(devshell):~$ git status                   # Show changes files
+host(devshell):~$ git add <file>               # Add a special file to the staging area
+host(devshell):~$ git commit -m "important modification"   # Creates a commit with a not so useful commit message
+host(devshell):~$ git format-patch -1 -o ~/    # Creates a patch of the last commit and saves it in your home folder
+/home/<user>/0001-important-modification.patch  # Git prints the path of the written patch file
+host(devshell):~$ exit
+
+
+

创建补丁后，必须为其创建一个 bbappend 文件。三个不同recipe文件（linux-mainline、 linux-ti 和 barebox）的位置如下：

+
sources/<layer>/recipes-kernel/linux/linux-mainline_%.bbappend     # For the recipe linux-mainline
+sources/<layer>/recipes-kernel/linux/linux-ti_%.bbappend           # For the recipe linux-ti
+sources/<layer>/recipes-kernel/linux/linux-imx_%.bbappend        # For the recipe linux-imx
+sources/<layer>/recipes-bsp/barebox/barebox_%.bbappend             # For the recipe barebox
+sources/<layer>/recipes-bsp/u-boot/u-boot-imx_%.bbappend           # For the recipe u-boot-imx
+
+
+

以下示例适用于recipe barebox。但是必须根据您的实际情况调整补丁路径。首先，创建文件夹并将补丁移入其中。然后创建 bbappend 文件

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features   # Or use your own layer instead of *meta-ampliphy*
+host:~$ cp ~/0001-important-modification.patch sources/meta-ampliphy/recipes-bsp/barebox/features  # copy patch
+host:~$ touch sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend
+
+
+
+

小技巧

+

注意您当前的工作目录。您必须在BSP根目录中执行命令，而不是在 build 目录中！

+
+

之后，使用您最喜欢的编辑器将以下内容添加到 bbappend 文件中（此处为 sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend）

+
# contents of the file barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://0001-important-modification.patch \
+"
+
+
+

保存文件并使用以下方法重新编译 barebox recipe

+
host:~$ bitbake barebox -c clean # Or linux-ti, linux-mainline, linux-imx, u-boot-imx
+host:~$ bitbake barebox
+
+
+

如果构建成功，您可以通过以下方法重新生成最终镜像。

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+

更多资源：

+

Yocto 项目为软件开发人员提供了一些文档。请参考“Kernel开发手册”以获取有关Kernel配置的详细信息。请注意，并非所有 Yocto 手册中的内容都适用于 PHYTEC BSP，因为我们采用了传统的内核编译方法，而大部分文档会假设使用的是 Yocto 的内核编译方式。

+ +
+
+

8.6.11. 使用 local.conf 文件中的 SRC_URI 来配置Kernel 和Bootloader

+

在这里，我们提供了第三个选项来修改kernel和Bootloader 。您可以从外部拉取 linux-mainline、linux-ti 或 barebox Git 仓库。您将需要重写源代码URL（变量 SRC_URI），以指向您的本地仓库而不是远程仓库。

+ + + + + + + + + + + + + + + +

优势

劣势

所有更改均使用 Git 保存

build/tmp-glibc/work/ 中有许多工作目录<machine>/<package> /

重新编译之前必须提交所有更改

对于每次更改，工具链都会从头开始编译所有内容（可以使用 ccache 避免）

+

首先，您需要一个 Git 仓库 barebox 或kernel的本地副本。如果您还没有，请使用以下命令。

+
host:~$ mkdir ~/git
+host:~$ cd ~/git
+host:~$ git clone git://git.phytec.de/barebox
+host:~$ cd barebox
+host:~$ git switch --create v2022.02.0-phy remotes/origin/v2022.02.0-phy
+
+
+

将以下代码片段添加到 build/conf/local.conf

+
# Use your own path to the git repository
+# NOTE: Branch name in variable "BRANCH_pn-barebox" should be the same as the
+# branch which is used in the repository folder. Otherwise your commits won't be recognized later.
+BRANCH:pn-barebox = "v2022.02.0-phy"
+SRC_URI:pn-barebox = "git:///${HOME}/git/barebox;branch=${BRANCH}"
+SRCREV:pn-barebox = "${AUTOREV}"
+
+
+

您需要在文件中正确设置git仓库分支名称。无论您是选择在 Git 仓库中创建自己的分支，还是使用默认的分支（这里是“v2015.02.0-phy”）。现在，您都可以用自己的源代码重新编译 barebox。

+
host:~$ bitbake barebox -c clean
+host:~$ bitbake barebox -c compile
+
+
+

由于源代码尚未被修改，因此构建应该能够成功。

+

您可以在 ~/git/barebox 或默认的 defconfig 中修改源代码（例如 ~/git/barebox/arch/arm/configs/imx_v7_defconfig）。一旦您完成了代码更改，您需要对 Yocto 进行本地提交。如果您不这样做， Yocto 将无法检测到您在git仓库中的源代码已被更改（例如 ~/git/barebox/）。

+
host:~$ git status  # show modified files
+host:~$ git diff    # show changed lines
+host:~$ git commit -a -m "dummy commit for yocto"   # This command is important!
+
+
+

本地提交后尝试编译。 Yocto 将自动注意到源代码已更改，并从头开始进行源代码获取和工程配置工作。

+
host:~$ bitbake barebox -c compile
+
+
+

如果构建失败，请返回源目录，修复问题并重新提交更改。如果构建成功，您可以获取 barebox，甚至创建一个新的 SD 卡镜像。.

+
host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox-phyflex-imx6-2.bin
+host:~$ bitbake phytec-headless-image # new sd-card image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic
+
+
+

如果您想进行其他更改，只需在git仓库中进行另一次提交并再次重新编译 barebox。

+
+
+

8.6.12. 使用“可持续方法”添加软件

+

现在您已经创建了自己的Layer，您有第二个方式可以将现有软件添加到目标镜像中。我们的标准镜像在 meta-ampliphy 中定义

+
meta-ampliphy/recipes-images/images/phytec-headless-image.bb
+
+
+

在您的layer中，可以使用 bbappend 修改recipe，无需改动源recipe文件

+
meta-racer/recipes-images/images/phytec-headless-image.bbappend
+
+
+

bbappend文件内容将与源recipe一起解析。因此，您可以轻松覆盖源recipe中设置的所有变量。如果我们想要包含一些其他软件，需要在bbapend中将其追加到 IMAGE_INSTALL 变量中

+
IMAGE_INSTALL:append = " rsync"
+
+
+
+
+

8.6.13. 将 Linux 固件添加到根文件系统

+

将额外的固件放入根文件系统的 /lib/firmware/ 目录是一项常见的需求。例如，WiFi适配器或PCIe网卡可能需要专有的固件。为了解决这个问题，我们可以在Layer中使用 bbappend 。首先要创建所需的文件夹，在文件夹中创建bbapend文件并拷贝固件到对应的文件夹中。

+
host:~$ cd meta-racer   # go into your layer
+host:~$ mkdir -p recipes-kernel/linux-firmware/linux-firmware/
+host:~$ touch recipes-kernel/linux-firmware/linux-firmware_%.bbappend
+host:~$ cp ~/example-firmware.bin recipes-kernel/linux-firmware/linux-firmware/    # adapt filename
+
+
+

然后将以下内容添加到 bbappend 文件中，用您的固件名替换每个出现的 example-firmware.bin。

+
# file recipes-kernel/linux-firmware/linux-firmware_%.bbappend
+
+FILESEXTRAPATHS:prepend := "${THISDIR}/linux-firmware:"
+SRC_URI += "file://example-firmware.bin"
+
+do_install:append () {
+        install -m 0644 ${WORKDIR}/example-firmware.bin ${D}/lib/firmware/example-firmware.bin
+}
+
+# NOTE: Use "=+" instead of "+=". Otherwise file is placed into the linux-firmware package.
+PACKAGES =+ "${PN}-example"
+FILES:${PN}-example = "/lib/firmware/example-firmware.bin"
+
+
+

现在尝试构建 linux-firmware recipe

+
host:~$ . sources/poky/oe-init-build-env
+host:~$ bitbake linux-firmware
+
+
+

这会生成一个新的软件包 deploy/ipk/all/linux-firmware-example。

+

最后一步，您必须将固件包安装到您的镜像中。您可以通过在 local.conf 或镜像recipe中添加对应的代码行来实现

+
# file local.conf or image recipe
+IMAGE_INSTALL += "linux-firmware-example"
+
+
+
+

警告

+

确保您已将包名 linux-firmware-example 调整为您在 linux-firmware_%.bbappend 中指定的名称。

+
+
+
+

8.6.14. 使用 bbappend 文件更改 u-boot 环境变量

+

所有 i.MX8M* 产品均使用 u-boot 作为bootloader。可以使用临时方法修改 u-boot 环境变量。对 u-boot-imx 来说，环境变量定义位于 include/configs/phycore_imx8m* 中与处理器名称对应的头文件。新的环境变量应添加在 CONFIG_EXTRA_ENV_SETTINGS 的末尾

+
#define CONFIG_EXTRA_ENV_SETTINGS \
+[...]
+PHYCORE_FITIMAGE_ENV_BOOTLOGIC \
+"newvariable=1\0"
+
+
+

提交修改并在您的layer中创建文件 u-boot-imx_%.bbappend <layer> /recipes-bsp/u-boot/u-boot-imx_%.bbappend

+
# contents of the file u-boot-imx_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://0001-environment-addition.patch \
+"
+
+
+
+
+

8.6.15. 通过 bbappend 文件更改 barebox 环境变量

+

从 BSP-Yocto-AM335x-16.2.0 和 BSP-Yocto-i.MX6-PD16.1.0 开始， meta-phytec 中的 barebox 环境变量已经采用新的机制。现在可以通过 Python bitbake 任务 do_env 在 barebox 环境中添加、更改和删除文件。有两个 Python 函数可以更改环境。它们是：

+
    +

  • env_add(d, ***filename as string*, ***file content as string*): 添加新文件或覆盖现有文件

    • +

  • env_rm(d, ***filename as string*): 删除文件

    • +
+

自定义layer meta-racer 的第一个示例中用 bbappend 文件中展示了如何在 barebox 环境文件夹 /env/nv/ 中加入新的非易失性变量 linux.bootargs.fb。

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_add(d, "nv/linux.bootargs.fb", "imxdrm.legacyfb_depth=32\n")
+}
+
+
+

第二个示例显示如何替换网络配置文件 /env/network/eth0

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_add(d, "network/eth0",
+"""#!/bin/sh
+
+# ip setting (static/dhcp)
+ip=static
+global.dhcp.vendor_id=barebox-${global.hostname}
+
+# static setup used if ip=static
+ipaddr=192.168.178.5
+netmask=255.255.255.0
+gateway=192.168.178.1
+serverip=192.168.178.1
+""")
+}
+
+
+

在上述示例中， Python 的多行字符串语法 """ text """ 可以避免在 Python 代码中插入多个换行符 \n。 Python 函数 env_add 可以用于添加和替换环境文件。

+

下一个示例显示如何删除已添加的环境文件，例如 , /env/boot/mmc

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_rm(d, "boot/mmc")
+}
+
+
+
+

8.6.15.1. 调试

+

如果您想查看在构建过程中添加的所有环境文件，您可以在 local.conf 中启用调试标志

+
# file local.conf
+ENV_VERBOSE = "1"
+
+
+

之后，您必须重新构建 barebox recipe才能看到调试输出

+
host:~$ bitbake barebox -c clean
+host:~$ bitbake barebox -c configure
+
+
+

最后一个命令的输出如下所示

+
[...]
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/allow_color' content "false"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.base' content "consoleblank=0"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.fb' content "imxdrm.legacyfb_depth=32"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.rootfs' content "rootwait ro fsck.repair=yes"
+
+
+
+
+

8.6.15.2. 修改环境（依赖所使用的machine）

+

如果您只需将一些 barebox 环境设置应用于一台或多台设备，您可以利用 Bitbake 的machine覆盖语法。这个语法是，将machine名称或 SoC 名称（例如 mx6、 ti33x 或 rk3288）通过下划线附加到变量或任务上。

+
DEPENDS:remove:mx6 = "virtual/libgl" or
+python do_env_append_phyboard-mira-imx6-4().
+
+
+

下一个示例仅当 MACHINE 设置为 phyboard-mira-imx6-4 时才添加环境变量

+
# file meta-phytec/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append:phyboard-mira-imx6-4() {
+    env_add(d, "nv/linux.bootargs.cma", "cma=64M\n")
+}
+
+
+

Bitbake 变量覆盖语法的更详细解释如下：https://docs.yoctoproject.org/bitbake/2.0/bitbake-user-manual/bitbake-user-manual-metadata.html#conditional-metadata

+
+
+

8.6.15.3. 在旧的 BSP 版本升级 barebox 环境

+

在 BSP 版本 BSP-Yocto-AM335x-16.2.0 和 BSP-Yocto-i.MX6-PD16.1.0 之前，通过 bbappend 文件进行的 barebox 环境更改的机制和现在有所不同。例如，meta-layer（此处为 meta-skeleton ）中的目录结构可能如下所示

+
$ tree -a sources/meta-skeleton/recipes-bsp/barebox/
+sources/meta-skeleton/recipes-bsp/barebox
+├── barebox
+│   └── phyboard-wega-am335x-3
+│       ├── boardenv
+│       │   └── .gitignore
+│       └── machineenv
+│           └── nv
+│               └── linux.bootargs.cma
+└── barebox_%.bbappend
+
+
+

并且文件 barebox_%.bbappend 包含

+
# file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:"
+
+
+

在这个示例中，将会忽略Layer meta-phytec 中目录 boardenv 下的所有环境变量更改，并添加文件 nv/linux.bootargs.cma 。而在 barebox 环境最新的处理机制下，您可以在 Python 任务 do_env 中使用 Python 函数 env_add 和 env_rm 来添加和删除环境。现在，上述示例被转换为文件 barebox_%.bbappend 中的一个单独的 Python 函数，如下所示。

+
# file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:"
+python do_env:append() {
+    # Removing files (previously boardenv)
+    env_rm(d, "config-expansions")
+    # Adding new files (previously machineenv)
+    env_add(d, "nv/linux.bootargs.cma", "cma=64M\n")
+}
+
+
+
+
+
+

8.6.16. 更改网络配置

+

要在系统运行时调整 IP 地址、路由和网关，可以使用工具 ifconfig 和 ip 。以下是一些示例

+
target:~$ ip addr                                         # Show all network interfaces
+target:~$ ip route                                        # Show all routes
+target:~$ ip addr add 192.168.178.11/24 dev eth0          # Add static ip and route to interface eth0
+target:~$ ip route add default via 192.168.178.1 dev eth0 # Add default gateway 192.168.178.1
+target:~$ ip addr del 192.168.178.11/24 dev eth0          # Remove static ip address from interface eth0
+
+
+

网络配置由 systemd-networkd 管理。要查询当前状态，请使用

+
target:~$ networkctl status
+target:~$ networkctl list
+
+
+

网络守护进程从目录 /etc/systemd/network/ 、 /run/systemd/network/ 和 /lib/systemd/network/ 读取配置（从高到低优先级）。 /lib/systemd/network/10-eth0.network 中的示例配置如下所示

+
# file /lib/systemd/network/10-eth0.network
+[Match]
+Name=eth0
+
+[Network]
+Address=192.168.3.11/24
+Gateway=192.168.3.10
+
+
+

这些文件 *.network 取代了其他发行版中的 /etc/network/interfaces。您可以直接编辑文件 10-eth0.network，或者将其复制到 /etc/systemd/network/ 并进行修改。修改文件后，您需要重启守护进程以使更改生效。

+
target:~$ systemctl restart systemd-networkd
+
+
+

要查看网络守护进程的系统日志消息，请使用

+
target:~$ journalctl --unit=systemd-networkd.service
+
+
+

要在编译时修改网络配置，请查看recipe sources/meta-ampliphy/recipes-core/systemd/systemd-machine-units.bb 和文件夹 meta-ampliphy/recipes-core/systemd/systemd-machine-units/ 中的接口文件，其中定义了 eth0 （以及可选的 eth1 ）的静态 IP 地址配置。

+

有关更多信息，请参阅https://wiki.archlinux.org/title/Systemd-networkd 和 https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html。

+
+
+

8.6.17. 更改无线网络配置

+
+

8.6.17.1. 连接至 WLAN 网络

+
    +

  • 请首先为您的国家或地区选择合适的网络地域。

    • +
+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

您会看到

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+
    +

  • 设置无线接口

    • +
+
target:~$ ip link    # list all interfaces. Search for wlan*
+target:~$ ip link set up dev wlan0
+
+
+
    +

  • 现在您可以扫描可用网络

    • +
+
target:~$ iw wlan0 scan | grep SSID
+
+
+

您可以使用支持 WEP、 WPA 和 WPA2 的跨平台身份认证客户端（称为 wpa_supplicant）来建立加密连接。

+
    +

  • 为此，请将网络凭据添加到文件 /etc/wpa_supplicant.conf

    • +
+
Confluence country=DE network={ ssid="<SSID>" proto=WPA2 psk="<KEY>" }
+
+
+
    +

  • 现在可以建立连接

    • +
+
target:~$ wpa_supplicant -Dnl80211 -c/etc/wpa_supplicant.conf -iwlan0 -B
+
+
+

这会有以下结果

+
ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

最后，您可以配置 DHCP 以获取 IP 地址（大多数 WLAN 接入点都支持此功能）。有关其他可能的 IP 配置，请参考 更改网络配置 部分。

+
    +

  • 首先，创建目录

    • +
+
target:~$ mkdir -p /etc/systemd/network/
+
+
+
    +

  • 然后在 /etc/systemd/network/10-wlan0.network 中添加以下配置片段

    • +
+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+
    +

  • 现在，重新启动网络守护程序以使配置生效

    • +
+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+

8.6.17.2. 创建 WLAN 接入点

+

本节提供基本的 WPA2 网络接入点 (AP) 的配置。

+

使用以下命令查找 WLAN 接口名称

+
target:~$ ip link
+
+
+

编辑 /etc/hostapd.conf 文件中的设置。这在很大程度上依赖于具体的应用场景。以下是一些示例。

+
# file /etc/hostapd.conf
+interface=wlan0
+driver=nl80211
+ieee80211d=1
+country_code=DE
+hw_mode=g
+ieee80211n=1
+ssid=Test-Wifi
+channel=2
+wpa=2
+wpa_passphrase=12345678
+wpa_key_mgmt=WPA-PSK
+wpa_pairwise=CCMP
+
+
+

通过 systemd-networkd 配置并启用网络接口 wlan0 的 DHCP 服务

+
target:~$ mkdir -p /etc/systemd/network/
+target:~$ vi /etc/systemd/network/10-wlan0.network
+
+
+

将以下文本插入到文件中

+
[Match]
+Name=wlan0
+
+[Network]
+Address=192.168.0.1/24
+DHCPServer=yes
+
+[DHCPServer]
+EmitDNS=yes
+target:~$ systemctl restart systemd-networkd
+target:~$ systemctl status  systemd-networkd -l   # check status and see errors
+
+
+

启动用户空间后台进程 hostapd

+
target:~$ systemctl start hostapd
+target:~$ systemctl status hostapd -l # check for errors
+
+
+

现在，您应该可以在终端设备（笔记本电脑、智能手机等）上看到 WLAN 网络 Test-Wifi。

+

如果接入点出现问题，您可以使用

+
target:~$ journalctl --unit=hostapd
+
+
+

或者从命令行以调试模式启动守护进程

+
target:~$ systemctl stop hostapd
+target:~$ hostapd -d /etc/hostapd.conf -P /var/run/hostapd.pid
+
+
+

您会看到

+
...
+wlan0: interface state UNINITIALIZED->ENABLED
+wlan0: AP-ENABLED
+
+
+

有关 AP 设置和用户空间守护进程 hostapd 的更多信息，请访问

+
https://wireless.wiki.kernel.org/en/users/documentation/hostapd
+https://w1.fi/hostapd/
+
+
+
+
+

8.6.17.3. phyCORE-i.MX 6UL/ULL 蓝牙

+

在使用 phyCORE-i.MX 6UL/ULL 的蓝牙功能时，需要特别谨慎。了解更多详情，请参考 L-844e.A5 i.MX 6UL/ULL BSP手册 - 蓝牙。

+
+
+
+

8.6.18. 添加 OpenCV 库和示例

+

OpenCV （开源计算机视觉 https://opencv.org/）是一个计算机视觉应用的开源库。

+

要安装库和示例，请编辑 Yocto 工程中的文件 conf/local.conf 并添加

+
# file conf/local.conf
+# Installing OpenCV libraries and examples
+LICENSE_FLAGS_ACCEPTED += "commercial_libav"
+LICENSE_FLAGS_ACCEPTED += "commercial_x264"
+IMAGE_INSTALL:append = " \
+    opencv \
+    opencv-samples \
+    libopencv-calib3d2.4 \
+    libopencv-contrib2.4 \
+    libopencv-core2.4 \
+    libopencv-flann2.4 \
+    libopencv-gpu2.4 \
+    libopencv-highgui2.4 \
+    libopencv-imgproc2.4 \
+    libopencv-legacy2.4 \
+    libopencv-ml2.4 \
+    libopencv-nonfree2.4 \
+    libopencv-objdetect2.4 \
+    libopencv-ocl2.4 \
+    libopencv-photo2.4 \
+    libopencv-stitching2.4 \
+    libopencv-superres2.4 \
+    libopencv-video2.4 \
+    libopencv-videostab2.4 \
+"
+
+
+

然后重编译镜像

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+

小技巧

+

大多数示例无法开箱即用，因为它们依赖于 GTK 图形库。此BSP 仅支持 Qt6 。

+
+
+
+

8.6.19. 使用 lightpd 安装最小的 PHP Web 运行环境

+

这个示例说明如何在目标镜像上添加 PHP 应用程序和 Web 服务。Lighttpd 可以通过 cgi 与 PHP 命令行工具一起使用。此解决方案仅占用 5.5 MiB 的磁盘空间。它已在 meta-ampliphy 中预先配置。只需调整yocto工程构建配置即可将其安装到镜像中。

+
# file conf/local.conf
+# install lighttpd with php cgi module
+IMAGE_INSTALL:append = " lighttpd"
+
+
+

启动镜像后，您会在 /www/pages 目录下找到示例网页内容。为了测试 php，您可以删除 index.html 并将其替换为 index.php 文件。

+
<html>
+  <head>
+    <title>PHP-Test</title>
+  </head>
+  <body>
+    <?php phpinfo(); ?>
+  </body>
+</html>
+
+
+

在您的主机上，您可以将浏览器指向主板的 IP（例如 192.168.3.11），然后 phpinfo 就会显示出来。

+
+
+
+

8.7. 常见任务

+
+

8.7.1. 调试用户空间应用程序

+

phytec-qt6demo-image 无需任何调整就可以进行交叉调试。您只需确保主机的 sysroot 与所使用的镜像相匹配。因此，您需要为该镜像创建一个编译工具链。

+
host:~$ bitbake -c populate_sdk phytec-qt6demo-image
+
+
+

此外，如果您希望对镜像中的所有程序和库具有完整的调试和回溯功能，您可以添加

+
DEBUG_BUILD = "1"
+
+
+

到 conf/local.conf。这在某些情况下并不是必需的。这样配置之后，编译器选项将从 FULL_OPTIMIZATION 切换到 DEBUG_OPTIMIZATION。查看 Poky 源代码以了解 DEBUG_OPTIMIZATION 的默认设置。

+

要开始交叉调试，请按照之前的说明安装 SDK，设置 SDK 环境，然后在同一个 shell 中启动 Qt Creator。如果您不使用 Qt Creator，可以在souce SDK环境脚本后直接运行 arm-<..>-gdb 调试器，该gdb调试器在source后会默认配置到您的PATH中。

+

如果您使用 Qt Creator，请查看随产品提供的相应文档（快速入门或应用程序指南），以获取有关如何设置工具链的信息。

+

使用调试器启动用户空间的应用程序时，您可能会遇到 SIGILL，这是来自 libcrypto 的非法指令。 Openssl 通过捕获这些非法指令来检测系统功能，这将导致 GDB 中断被触发。您可以选择忽略此操作并点击 继续 （命令c）。如果希望永久忽略此信号，可以添加

+
handle SIGILL nostop
+
+
+

到您的 GDB 启动脚本或 Qt Creator GDB 配置面板中。其次，您可以禁用安全功能，这通过添加

+
set auto-load safe-path /
+
+
+

到同一个启动脚本，它允许从任何位置自动加载库。

+

如果您想要进行本地调试，需要在目标设备上安装调试符号表。您可以通过在 conf/local.conf 中添加以下行来实现这一点。

+
EXTRA_IMAGE_FEATURES += "dbg-pkgs"
+
+
+

对于交叉调试，这并不是必需的，因为调试符号表会从PC侧加载，并且 dbg-pkgs 也会包含在镜像的 SDK 中。

+
+
+

8.7.2. 生成镜像源，开启离线构建

+

参照如下方式，修改您的 site.conf (如果您不使用 site.conf,请修改 local.conf )

+
#DL_DIR ?= "" don't set it! It will default to a directory inside /build
+SOURCE_MIRROR_URL = "file:///home/share/yocto_downloads/"
+INHERIT += "own-mirrors"
+BB_GENERATE_MIRROR_TARBALLS = "1"
+
+
+

现在运行

+
host:~$ bitbake --runall=fetch <image>
+
+
+

这适用于所有镜像及您希望提供镜像源的所有MACHINE。它将生成所需的所有 tar 文件。我们可以移除所有 SCM 子文件夹，因为它们是和 tar 文件重复的。

+
host:~$ rm -rf build/download/git2/
+etc...
+
+
+

请注意，我们使用本地镜像源来生成 dl_dir。这样，有一些文件是本地链接文件。

+

首先，我们需要将所有文件包括符号链接的源文件拷贝到新的镜像源目录中。

+
host:~$ rsync -vaL <dl_dir> ${TOPDIR}/../src_mirror/
+
+
+

Now we clean the /build directory by deleting everything except /build/conf/ +but including /build/conf/sanity. We change site.conf as follows

+
SOURCE_MIRROR_URL = "file://${TOPDIR}/../src_mirror"
+INHERIT += "own-mirrors"
+BB_NO_NETWORK = "1"
+SCONF_VERSION = "1"
+
+
+

BSP 目录现在可以使用以下方式压缩

+
host:~$ tar cfJ <filename>.tar.xz <folder>
+
+
+

其中文件名和文件夹应该以完整的 BSP 版本命名。

+
+
+

8.7.3. 在目标主机上进行编译

+

在您的 local.conf 中添加

+
IMAGE_FEATURES:append = " tools-sdk dev-pkgs"
+
+
+
+
+

8.7.4. 不同的工具链

+

在 Poky 中有多种方法可以创建工具链安装程序。一种方法是运行

+
host:~$ bitbake meta-toolchain
+
+
+

这将在 build/deploy/sdk 中生成一个工具链安装程序，可用于交叉编译目标应用。但是，这个安装程序不包含添加到您自定义镜像中的库，因此它只是一个单纯的 GCC 编译器。这适用于bootloader和kernel开发。

+

另一种方法是运行

+
host:~$ bitbake -c populate_sdk <your_image>
+
+
+

这将创建一个工具链安装程序，包含所有安装在目标根文件系统上的软件开发包。该安装程序涵盖开发应用程序所需的所有组件，可以被用户空间应用程序开发团队所使用。如果镜像中包含 QT 库，那么所有相关依赖库也将随安装程序提供。

+

第三个选项是创建 ADT（应用程序开发工具包）安装程序。它将包含交叉工具链和一些帮助软件开发人员的工具，例如 Eclipse 插件和 QEMU 系统模拟器。

+
host:~$ bitbake adt-installer
+
+
+

目前，我们的 BSP 尚未使用 ADT 进行测试。

+
+

8.7.4.1. 使用 SDK

+

使用以下方式生成 SDK 后

+
host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
+
+

使用以下方式运行生成的二进制文件

+
host:~$ deploy/sdk/ampliphy-glibc-x86_64-phytec-qt6demo-image-cortexa9hf-vfp-neon-toolchain-i.MX6-PD15.3-rc.sh
+Enter target directory for SDK (default: /opt/ampliphy/i.MX6-PD15.3-rc):
+You are about to install the SDK to "/opt/ampliphy/i.MX6-PD15.3-rc". Proceed[Y/n]?
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
+
+

您可以通过source 工具链目录中的 environment-setup 脚本来激活当前shell的工具链环境

+
host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+
+
+

然后，交叉编译器和链接器等必要工具就在您的 PATH 中了。要编译一个简单的 C 程序，请使用

+
host:~$ $CC main.c -o main
+
+
+

环境变量 $CC 包含 ARM 交叉编译器的路径和其他所需的编译器参数，如 -march、-sysroot 和 --mfloat-abi。

+
+

小技巧

+

您不能仅使用编译器名称来编译程序，例如

+
host:~$ arm-phytec-linux-gnueabi-gcc main.c -o main
+
+
+

在许多情况下它会导致编译失败。请使用 CC、CFLAGS、LDFLAGS 等。

+
+

为了方便起见， environment-setup 脚本会导出其他环境变量，如 CXX、LD、SDKTARGETSYSROOT。

+

编译 C 和 C++ 程序的一个简单的 makefile 可能如下所示

+
# Makefile
+TARGETS=c-program cpp-program
+
+all: $(TARGETS)
+
+c-program: c-program.c
+    $(CC) $(CFLAGS) $(LDFLAGS) $< -o $@
+
+cpp-program: cpp-program.cpp
+    $(CXX) $(CXXFLAGS) $(LDFLAGS) $< -o $@
+
+.PHONY: clean
+clean:
+    rm -f $(TARGETS)
+
+
+

要对目标进行编译，只需在执行 make 之前在当前 shell 中 source 工具链即可

+
host:~$ make     # Compiling with host CC, CXX for host architecture
+host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+host:~$ make     # Compiling with target CC, CXX for target architecture
+
+
+

如果您需要在工具链的 sysroot 中指定额外包含的目录，则可以在 -I 参数中使用“=”符号，例如

+
-I=/usr/include/SDL
+
+
+

GCC 会用工具链中的 sysroot 路径替换它（此处为 /opt/ampliphy/i.MX6-PD15.3-rc/sysroots/cortexa9hf-vfp-neon-phytec-linux-gnueabi/）。有关更多信息，请参阅 GCC 主页。

+
+

小技巧

+

变量 $CFLAGS 和 $CXXFLAGS 默认会包含编译器的调试标志“-g”。这会在二进制文件中加入调试信息，从而使文件变得更大。应该从正式生产的镜像中去除这个标志。如果您编写 Bitbake recipe，默认情况下也会启用“-g”。调试符号在 SDK 根文件系统 中是有用的，以便在主机调用 GDB 时获取调试信息。但是在将软件包安装到目标 根文件系统 之前， Bitbake 会在程序上执行 strip 命令，以去除调试符号。因为默认情况下，这些符号在目标根文件系统中是不需要的。

+
+
+
+

8.7.4.2. 将 SDK 与 GNU Autotools 结合使用

+

Yocto SDK 是 GNU Autotools 项目会用到的一个工具。传统的主机编译过程通常是

+
host:~$ ./autogen.sh # maybe not needed
+host:~$ ./configure
+host:~$ make
+host:~$ make install DESTDIR=$PWD/build/
+
+
+

用 Yocto SDK 对目标machine进行构建的命令也是非常相似的。以下命令假设 SDK 已解压到目录 /opt/phytec-ampliphy/i.MX6-PD15.3.0/ （可根据实际情况修改路径）

+
host:~$ source /opt/phytec-ampliphy/i.MX6-PD15.3.0/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+host:~$ ./autogen.sh  # maybe not needed
+host:~$ ./configure ${CONFIGURE_FLAGS}
+host:~$ make
+host:~$ make install DESTDIR=$PWD/build/
+
+
+

有关更多信息，请参阅官方 Yocto 文档：https://docs.yoctoproject.org/4.0.6/singleindex.html#autotools-based-projects

+
+
+
+

8.7.5. 使用Kernel模块

+

如果您需要为内核模块配置一些选项，或者将一个模块加入黑名单。您可以通过 udev 进行，并写入 *.conf 文件中。

+
/etc/modprobe.d/\*.conf.
+
+
+

如果您希望在构建过程中指定kernel模块的一些选项，则有三个相关的变量。如果您仅想自动加载那些没有自动加载功能的模块，请将其添加到

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+
+
+

无论是在kernel recipe中还是涉及到全局变量。如果您需要为模块指定选项，您可以这样做

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+KERNEL_MODULE_PROBECONF += "your-module"
+module_conf_your-module = "options your-module parametername=parametervalue"
+
+
+

如果您想将某个模块列入自动加载黑名单，您可以直接使用

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+KERNEL_MODULE_PROBECONF += "your-module"
+module_conf_your-module = "blacklist your-module"
+
+
+
+
+

8.7.6. 使用 udev

+

Udev（Linux 动态设备管理）是一个系统守护进程，用于处理 /dev 中的动态设备管理。它由位于 /etc/udev/rules.d （系统管理员配置空间）和 /lib/udev/rules.d/ （供应商提供）中的 udev 规则控制。以下是 udev 规则文件的示例

+
# file /etc/udev/rules.d/touchscreen.rules
+# Create a symlink to any touchscreen input device
+SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="input:*-e0*,3,*a0,1,*18,*", SYMLINK+="input/touchscreen0"
+SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="ads7846", SYMLINK+="input/touchscreen0"
+
+
+

有关语法和用法的更详细信息，请访问 https://www.freedesktop.org/software/systemd/man/latest/udev.html。要获取可以在 udev 规则中使用的设备属性列表，您可以利用 udevadm info 工具。该工具将打印出设备节点及其父节点的所有现有属性。输出中的键值对可以直接复制并粘贴到规则文件中。以下是一些示例。

+
target:~$ udevadm info -a /dev/mmcblk0
+target:~$ udevadm info -a /dev/v4l-subdev25
+target:~$ udevadm info -a -p /sys/class/net/eth0
+
+
+

更改 udev 规则后，您必须通知udev守护进程。否则，您的更改不会生效。使用以下命令

+
target:~$ udevadm control --reload-rules
+
+
+

在制定 udev 规则时，您应该监视事件，以便查看设备何时连接到系统或从系统断开连接。使用

+
target:~$ udevadm monitor
+
+
+

在另一个 shell 中监控系统日志也是非常有帮助的，尤其是在udev规则中执行了外部脚本的情况下。执行

+
target:~$ journalctl -f
+
+
+
+

小技巧

+

您无法在 RUN 属性中启动守护进程或大型脚本。请参阅 https://www.freedesktop.org/software/systemd/man/latest/udev.html 。

+

这仅适用于执行时间非常短的前台任务。长时间运行的事件进程可能会阻碍此设备或从设备的后续所有事件。启动守护进程或其他长时间运行的进程并不适合 udev；派生进程（无论是否和母进程分离）都将在母进程事件处理完成后无条件被终止。如果需要执行其他任务，您可以考虑使用特殊属性 ENV {SYSTEMD_WANTS} ="service-name.service" 和 systemd 服务。

+

请参阅https://unix.stackexchange.com/questions/63232/what-is-the-correct-way-to-write-a-udev-rule-to-stop-a-service-under-systemd。

+
+
+
+
+
+

9. 故障排除

+
+

9.1. setscene任务告警

+

当 Yocto 缓存处于dirty状态时会出现此告警。

+
WARNING: Setscene task X ([...]) failed with exit code '1' - real task
+
+
+

但是请避免强制取消构建，或者如果必须取消，请按一次 Ctrl-C 并等待构建过程停止。要删除所有这些告警，请清除 sstate 缓存并删除build文件夹。

+
host:~$ bitbake phytec-headless-image -c cleansstate && rm -rf tmp deploy/ipk
+
+
+
+
+
+

10. Yocto 文档

+

对于 BSP 用户来说，最重要的文档可能是开发人员手册。https://docs.yoctoproject.org/4.0.6/dev-manual/index.html

+

关于常见任务的部分是一个很好的起点。https://docs.yoctoproject.org/4.0.6/dev-manual/common-tasks.html#common-tasks

+

完整的文档可以在一个单独的 HTML 页面上找到，用户可以在页面上搜索功能或变量名称。https://docs.yoctoproject.org/4.0.6/singleindex.html

+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/yocto/manual-index.html b/previews/271/zh_CN/yocto/manual-index.html new file mode 100644 index 000000000..e97084341 --- /dev/null +++ b/previews/271/zh_CN/yocto/manual-index.html @@ -0,0 +1,360 @@ + + + + + + + + + Yocto 参考手册 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

Yocto 参考手册

+
+

Kirkstone

+
+

目录

+ +
+
+
+

Mickledore

+
+

目录

+ +
+
+
+

Scarthgap

+
+

目录

+ +
+
+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/yocto/mickledore.html b/previews/271/zh_CN/yocto/mickledore.html new file mode 100644 index 000000000..a675a3547 --- /dev/null +++ b/previews/271/zh_CN/yocto/mickledore.html @@ -0,0 +1,2251 @@ + + + + + + + + + 1. Yocto 项目 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + +

Yocto Reference Manual

文档标题

Yocto Reference Manual Mickledore

文档类型

Yocto手册

发布日期

XXXX/XX/XX

母文档

Yocto Reference Manual

+ + + + + + + + + + + + + + + + + + + + +

适用BSP

BSP发布类型

BSP发布日期

BSP 状态

BSP-Yocto-NXP-i.MX93-PD24.1.0

大版本

2024 年 5 月 2 日

已发布

BSP-Yocto-NXP-i.MX93-PD24.1.1

小更新

2024 年 5 月 8 日

已发布

+

本手册适用于所有基于 Mickledore 的 PHYTEC BSP版本。

+
+

1. Yocto 项目

+
+

1.1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 手册：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的应用开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大多数文档都可以在我们产品的下载页面中找到。

+
+
+

1.2. Yocto 介绍

+

Yocto 是最小的国际单位制前缀。就像milli是描述 10^-3 一样，yocto 是描述 10^-24 。Yocto 也是 Linux 基金会 支持的项目，因此得到了该领域几家主流公司的支持。在 Yocto 项目网站 上您可以阅读官方的介绍：

+
+

Yocto 项目是一个开源协作项目，它提供模板、工具和方法，为您的嵌入式产品创建基于 Linux 的自定义系统，同时不用过多的关注底层硬件架构。该项目由众多硬件制造商、开源操作系统供应商和电子公司合作开发，成立于2010年，旨在引导嵌入式 Linux系统开发走向标准化。

+
+

如前所述，该项目希望为嵌入式开发人员提供工具集。它建立在长期维护的 OpenEmbedded 项目之上。它不是一个Linux 发行版，但它包含创建定制化的Linux 发行版的所有工具。维护工具集的最重要步骤是定义一个通用的版本控制方案和一个参考系统。然后，所有子项目都必须兼容参考系统，并且遵守他的版本控制方案。

+

发布过程类似于 Linux kernel 的发布机制。Yocto 每六个月增加一次版本号，并为发布版本指定版本代号。发布列表可在此处找到：https://wiki.yoctoproject.org/wiki/Releases

+
+
+

1.3. 核心组件

+

Yocto 项目最重要的工具或子项目是：

+
    +

  • Bitbake：构建引擎，是一个类似 make 的任务调度程序，解析元数据

    • +

  • OpenEmbedded-Core，Yocto 核心Layer，包含软件元数据

    • +

  • Yocto kernel

    +
      +

    • 针对嵌入式设备进行了优化

      • +

    • 包括许多子项目：rt-kernel、供应商补丁

      • +

    • Wind River 提供的基础框架

      • +

    • Yocto kernel的替代方案：经典的内核编译方式→Phytec使用这种方式将我们的kernel集成到 Yocto

      • +
    +
    • +

  • Yocto 参考 BSP： beagleboneblack、 minnow max

    • +

  • Poky：Yocto参考系统，是项目和工具的集合，是创建基于 Yocto 的Linux发行版的基石

    • +
+
+
+

1.4. 词汇

+
+

1.4.1. Recipes

+

Recipe包含有关软件项目的信息（作者、主页和许可证）。Recipe 有版本控制，它定义了依赖项，包含源代码的 URL，并描述如何获取、配置和编译源代码。它也描述了如何打包软件，例如打包成不同的 .deb 包，安装到目标系统不同的路径。Recipe是用 Bitbake 自己的编程语言编写的，语法很简单。但是，Recipe 可以包含 Python 以及 bash 代码

+
+
+

1.4.2. 类

+

类将Recipe中的各个方法组合成可重复使用的代码块。

+
+
+

1.4.3. Layers

+

layer是Recipe、类和配置元数据的集合。Layer可以依赖于其他Layer, 它封装了特定的功能。每个Layer都属于一个特别的category：

+
    +

  • Base

    • +

  • Machine（BSP）

    • +

  • Software

    • +

  • Distribution

    • +

  • Miscellaneous

    • +
+

Yocto 的版本控制方案在每一个Layer中以版本分支的形式体现。对于每个 Yocto 版本，每个Layer在其 Git 仓库中都有一个对应分支。您可以在Yocto工程中添加一个或多个Layer。

+

可以在这里https://layers.openembedded.org/layerindex/branch/mickledore/layers/找到 OpenEmbedded Layer的集合。搜索功能非常有用，可以轻松检索和集成软件包。

+
+
+

1.4.4. Machine

+

Machine是用来描述所使用的目标硬件(核心板/开发套件)的变量。

+
+
+

1.4.5. 发行版 (Distro)

+

发行版描述了软件配置以及一系列的软件特性。

+
+
+
+

1.5. Poky

+

Poky 是定义 Yocto 项目的参考系统。它将几个子项目组合成发行版：

+
    +

  • Bitbake

    • +

  • Toaster

    • +

  • OpenEmbedded Core

    • +

  • Yocto 文档

    • +

  • Yocto 参考 BSP

    • +
+
+

1.5.1. Bitbake

+

Bitbake 是任务调度器。它是一个Python脚本，解释用 Bitbake 自己的编程语言、 Python 或者 bash 代码编写的recipe。官方文档可在此处找到：https://docs.yoctoproject.org/bitbake/2.4/index.html

+
+
+

1.5.2. Toaster

+

Toaster 是 Bitbake 的用于启动和分析工程构建的Web 前端。它提供有关编译历史和所生成镜像的统计信息。在多个案例中，安装和维护 Toaster 实例是有益的。PHYTEC 未对 Poky 提供的 Toaster 作任何功能添加或删除。如果想了解更多，请参考官方文档：https://docs.yoctoproject.org/4.2.4/toaster-manual/index.html

+
+
+
+

1.6. 官方文档

+

有关 Bitbake 和 Poky 的更多常见问题，请参阅手册：https://docs.yoctoproject.org/4.2.4/singleindex.html

+
+
+
+

2. Linux主机开发环境

+

要编译 Yocto，您需要一台合适的 Linux 主机开发环境。支持的Linux发行版列表可在参考手册中找到：https://docs.yoctoproject.org/4.2.4/ref-manual/system-requirements.html#supported-linux-distributions

+
+
+

3. PHYTEC BSP 介绍

+
+

3.1. BSP 框架

+

BSP 大致由三部分组成。BSP 包管理、BSP 元数据和 BSP 代码源。包管理包括 Repo 和 phyLinux，而元数据取决于 SOC，它描述了如何构建软件。BSP 内容源来自 PHYTEC 的 Git 仓库和外部源。

+
+

3.1.1. BSP 包管理

+

Yocto 是一个综合项目。通常情况下，这意味着会强制用户将他们的Yocto项目建立在几个外部仓库上。这些库需要以特定的方式进行管理。我们使用包含 XML 数据结构的清单文件来描述不同版本的 git 仓库。 Repo 工具和我们的 phyLinux 脚本用于管理清单文件并配置 BSP工程。

+
+

3.1.1.1. phyLinux

+

phyLinux 是 Repo 的包装器，用于下载和配置 BSP，提供“开箱即用”的体验。

+
+
+

3.1.1.2. Repo

+

Repo 是 Repo 工具集的包装器。phyLinux 脚本将把Repo安装在全局PATH中。当您首次运行 repo init -u <url>，它会从 Googles Git 服务器下载特定版本的 Repo 工具集到 .repo/repo 目录。下次运行 Repo 时， Repo 工具集相关的指令就可以直接被使用了。请注意，如果您不运行 Repo sync，不同构建目录中的 Repo 工具集版本可能会随着时间的推移而有所不同。此外，如果您要保存您的完整BSP工程信息，也需要保存完整的 .repo 文件夹。

+

Repo 需要一个 Git 仓库，该仓库信息是从Repo命令中解析得来。在 PHYTEC BSP 中，该仓库被称为 phy²octo。在此仓库中，有关软件 BSP 版本的所有信息都以XML形式的 Repo 清单存储。清单文件定义了 Git 服务器（称为“Remote”）的URL、 Git 仓库及其状态（称为“projects”）。 Git 仓库可以呈现不同的状态。这其中的状态变化涉及仓库的分支、标签或commit ID。这意味着仓库的状态不一定是唯一的，可以随时间而变化。这就是我们仅使用标签或commit ID 进行发布的原因。这样的话git工作目录的状态就是唯一的，不会改变。

+

BSP的清单文件与BSP版本号同名。它是 BSP 的唯一标识符。发布的BSP会按 SoC 平台排序。所选 SoC 将定义 phy²octo Git 仓库的分支，该分支将用于选择对应的清单文件。

+
+
+
+

3.1.2. BSP 元数据

+

我们在 BSP 中包含了几个第三方Layer，无需集成其他外部项目即可运行完整的 Linux 发行版。以下描述了所有使用的git仓库。

+
+

3.1.2.1. Poky

+

PHYTEC BSP 建立在 Poky 之上。每个Poky有对应的版本，在 Repo 清单中定义。Poky 包含对应版本的 Bitbake。OpenEmbedded Core 的Layer-“meta”是我们自定义 Linux 系统的基石。

+
+
+

3.1.2.2. meta-openembedded

+

OpenEmbedded 是一组Layer，包含有许多开源软件项目的元数据。我们的 BSP 提供了所有的 OpenEmbedded Layer，但并非所有Layer都已使能。我们的示例镜像包含了几个 OpenEmbedded Layer中的Recipe所生成的软件包。

+
+
+

3.1.2.3. meta-qt6

+

该Layer在 Poky 根文件系统的基础上集成了 Qt6 ，我们的BSP已经包含了该Layer。

+
+
+

3.1.2.4. meta-nodejs

+

这是用于添加最新版本 Node.js 的Layer。

+
+
+

3.1.2.5. meta-gstreamer1.0

+

这是用于添加最新版本 GStreamer 的Layer。

+
+
+

3.1.2.6. meta-rauc

+

这一Layer包含搭建 RAUC 系统更新服务所需的工具. 与其他系统更新机制的对比可以在这里找到：Yocto 系统更新工具.

+
+
+

3.1.2.7. meta-phytec

+

这一Layer包含我们所有 BSP 的所有machine和通用特性。它是 PHYTEC 的 Yocto BSP 适用于所有受支持的硬件（从 fido 开始），并且设计为与 Poky Layer相互独立。如果您想将 PHYTEC 的硬件集成到现有的 Yocto 项目中，只需要这两个Layer即可。其特点是：

+
    +

  • recipes-bsp/barebox/ 和 recipes-bsp/u-boot/ 中的Bootloader

    • +

  • recipes-kernel/linux/ 和 dynamic-layers/fsl-bsp-release/recipes-kernel/linux/ 中的kernel

    • +

  • conf/machine/ 中有许多machine

    • +

  • 适配 AM335x 和 i.MX 6 平台的 OpenGL ES/EGL 上层库

    • +

  • 适配 i.MX 6 平台的 OpenCL 库

    • +
+
+
+

3.1.2.8. meta-ampliphy

+

这是我们的发行版示例 layer。它扩展了 Poky 的基础配置，为您的特定开发场景提供了基础。当前功能包括：

+
    +

  • systemd 初始化系统

    • +

  • 镜像：用于非图形应用的 phytec-headless-image

    • +

  • 基于i.MX 6 平台 的相机、OpenCV 和 GStreamer 集成示例，包含在 phytec-vision-image 中

    • +

  • 集成RAUC：我们为 A/B 系统镜像更新提供了基础支持，该更新可在本地和远程进行

    • +
+
+
+

3.1.2.9. meta-qt6-phytec

+

这是我们用于集成 Qt6 和展示Qt6 demo的Layer。其特点是：

+
    +

  • 针对 PHYTEC AM335x、i.MX 6 和 RK3288 平台的 带有 eglfs 后台的 Qt6

    • +

  • 镜像：带有 Qt6 以及视频应用的 phytec-qt6demo-image

    • +

  • Qt6 示例程序演示如何使用 QML widgets 和 一个 Bitbake recipe在 Yocto 搭建 Qt6 项目并集成到 systemd 中。该示例程序可以在 sources/meta-qt6-phytec/recipes-qt/examples/phytec-qtdemo_git.bb 中找到

    • +
+
+
+

3.1.2.10. meta-virtualization

+
    +

  • 该Layer为构建Xen、KVM、Libvirt以及其他基于OpenEmbedded的虚拟化解决方案提供必要的支持。

    • +
+
+
+

3.1.2.11. meta-security

+
    +

  • 该Layer提供安全工具、Linux内核的强化工具以及实现安全机制的库。

    • +
+
+
+

3.1.2.12. meta-selinux

+
    +

  • 此Layer的目的是启用 SE Linux 支持。此Layer的大部分工作是在 bbappend 文件中完成的，用于在现有Recipe中启用 SE Linux 支持。

    • +
+
+
+

3.1.2.13. meta-browser

+
    +

  • 这是用于添加常用 Web 浏览器（Chromium、Firefox 等）的Layer。

    • +
+
+
+

3.1.2.14. meta-rust

+
    +

  • 包括 Rust 编译器和 Rust 的 Cargo 包管理器。

    • +
+
+
+

3.1.2.15. meta-timesys

+
    +

  • Timesys Layer用于 Vigiles Yocto CVE 监控、安全提醒和镜像清单的生成。

    • +
+
+
+

3.1.2.16. meta-freescale

+
    +

  • 该Layer为i.MX、Layerscape和QorIQ产品线提供支持。

    • +
+
+
+

3.1.2.17. meta-freescale-3rdparty

+
    +

  • 为来自不同供应商的主板提供支持。

    • +
+
+
+

3.1.2.18. meta-freescale-distro

+
    +

  • 该Layer为freescale的演示镜像提供支持，以便与 OpenEmbedded 和/或 Yocto Freescale 的 BSP Layer一起使用。

    • +
+
+
+

3.1.2.19. base layer（fsl-community-bsp-base）

+
    +

  • 该layer提供NXP的基础BSP文件。

    • +
+
+
+

3.1.2.20. meta-fsl-bsp-release

+
    +

  • 这是 i.MX Yocto 项目发行版的Layer。

    • +
+
+
+
+

3.1.3. BSP 代码源

+

当您首次开始使用 Bitbake 时，BSP Content会从不同的线上源提取。所有文件都将下载并拷贝到在 Yocto 中配置为``DL_DIR``的本地目录中。如果您想备份包含完整内容的 BSP，则也必须备份这些源文件。在 生成镜像源，开启离线构建 一章中会作出进一步解释。

+
+
+
+

3.2. 编译配置

+

BSP 初始化一个编译文件夹，该文件夹将包含运行 Bitbake 命令所生成的所有文件。它也包含一个用于处理用户输入的 conf 文件夹。

+
    +

  • bblayers.conf 定义使能的元 layers，

    • +

  • local.conf 可以自定义Yocto工程的用户输入变量

    • +

  • site.conf 自定义与编译主机相关的输入变量

    • +
+

两个最顶层的用户输入变量是 DISTRO 和 MACHINE 。当您使用 phyLinux 的方式获取 BSP 时，它们会体现在BSP预先配置的 local.conf 文件中。

+

我们在 BSP 中使用“Ampliphy”作为软件发行版 DISTRO 。此DISTRO将被预先选定，并为您提供实现自定义软件发行版的起点。

+

MACHINE 定义支持特定核心板和底板的二进制镜像。请查看 machine.conf 文件或我们的网页以了解硬件的描述。

+
+
+
+

4. 预编译镜像

+

对于每个 BSP，我们都提供了预编译的目标镜像，可以从 PHYTEC FTP 服务器下载：https://download.phytec.de/Software/Linux/

+

这些镜像也可用于 BSP 测试，他们会在生产时烧写到产品中。您可以使用提供的 .wic 镜像创建 SD 卡启动盘。识别您的硬件Machine并使用 dd 将下载的镜像文件烧写到格式化的 SD 卡中。有关该命令的正确用法的信息，请参阅镜像部分。

+
+
+

5. BSP Workspace安装

+
+

5.1. 设置主机

+

您可以设置主机或使用我们的编译容器来进行 Yocto 工程构建。您需要有一个运行中的 Linux 发行版系统，它应该在一台性能和存储空间强大的机器上运行，因为Yocto需要进行大量编译。

+

如果您想使用编译容器，您只需要在主机上安装以下软件包

+
host:~$ sudo apt install wget git
+
+
+

之后继续下一步 Git 配置。关于如何使用 编译-container ，您可以在 本文档phyLinux 的 高级用法 之后章节找到。

+

如果您不想使用编译container， Yocto 需要在您主机上安装一些其他的软件包。对于 Ubuntu，您需要

+
host:~$ sudo apt install gawk wget git diffstat unzip texinfo \
+      gcc build-essential chrpath socat cpio python3 python3-pip \
+      python3-pexpect xz-utils debianutils iputils-ping python3-git \
+      python3-jinja2 libegl1-mesa libsdl1.2-dev \
+      python3-subunit mesa-common-dev zstd liblz4-tool file locales
+
+
+

对于其他发行版，您可以在 Yocto Quick Build 中找到信息：https://docs.yoctoproject.org/4.2.4/brief-yoctoprojectqs/index.html

+
+
+

5.2. Git 配置

+

BSP 大量使用 Git。 Git 需要您提供一些信息来识别谁对文件进行了更改。如果您没有 ~/.gitconfig 这个文件，请创建一个包含以下内容的文件

+
[user]
+    name = <Your Name>
+    email = <Your Mail>
+[core]
+    editor = vim
+[merge]
+    tool = vimdiff
+[alias]
+    co = checkout
+    br = branch
+    ci = commit
+    st = status
+    unstage = reset HEAD --
+    last = log -1 HEAD
+[push]
+    default = current
+[color]
+    ui = auto
+
+
+

您应该在 Git 配置中设置 name 和 email，否则， Bitbake 会在第一次构建时报错。您可以使用这两个命令直接设置它们，而无需手动编辑 ~/.gitconfig

+
host:~$ git config --global user.email "your_email@example.com"
+host:~$ git config --global user.name "name surname"
+
+
+
+
+

5.3. site.conf 设置

+

在开始编译 Yocto 之前，建议进行初步配置。有两个配置最为重要：下载目录和缓存目录的配置。PHYTEC 强烈建议对这两个配置项进行配置，因为它将减少您后续编译的时间。

+

下载目录是 Yocto 存储从互联网获取的所有源文件/源代码的地方。它可以包含 tar.gz、 Git 镜像源等。建议将下载目录设置为编译主机上用户可以共享的目录。我们首先要给这个目录赋予777访问权限，因为如果要让不同用户共享此目录，则所有文件都需要具有组写入访问权限。这很可能与默认 umask 设置冲突。一种可能的解决方案是对此目录使用 ACL

+
host:~$ sudo apt-get install acl
+host:~$ sudo setfacl -R -d -m g::rwx <dl_dir>
+
+
+

如果您已经创建了下载目录，但是后续想要更改权限，可以使用

+
host:~$ sudo find /home/share/ -perm /u=r ! -perm /g=r -exec chmod g+r \{\} \;
+host:~$ sudo find /home/share/ -perm /u=w ! -perm /g=w -exec chmod g+w \{\} \;
+host:~$ sudo find /home/share/ -perm /u=x ! -perm /g=x -exec chmod g+x \{\} \;
+
+
+

缓存目录存储编译过程的所有阶段产物。 Poky 具有相当复杂的缓存架构。建议创建一个共享目录，这样所有构建都可以访问此缓存目录，这被称为共享状态缓存。

+

在大约有 50 GB 空闲空间的硬盘上创建这两个目录，并在``build/conf/local.conf``中分配两个变量

+
DL_DIR ?= "<your_directory>/yocto_downloads"
+SSTATE_DIR ?= "<your_directory>/yocto_sstate"
+
+
+

如果您想了解更多有关如何配置Yocto工程的信息，请参阅Yocto工程中的文档示例设置

+
sources/poky/meta-yocto/conf/local.conf.sample
+sources/poky/meta-yocto/conf/local.conf.sample.extended
+
+
+
+
+
+

6. phyLinux 文档

+

phyLinux 脚本是使用 Python 编写，用来管理 PHYTEC Yocto BSP 版本。它主要是帮助用户快速上手PHYTEC BSP。您无需与 Repo 或 Git 交互，只使用phyLinux可以获取所有 BSP 源文件

+

phyLinux 脚本只有一个依赖项，那就是它需要您在主机上安装 wget 工具。执行后它会将 Repo 工具 安装到您主机上的全局PATH (/usr/local/bin) 中。您也可以手动安装到其他位置。如果已经在 PATH 中找到 Repo，phyLinux 将自动检测到并使用它。 Repo 工具被用来管理 Yocto BSP 的众多 Git 仓库。

+
+

6.1. 获取 phyLinux

+

phyLinux 脚本可以在 PHYTEC 下载服务器上找到：https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux

+
+
+

6.2. 基本用法

+

对于 phyLinux 的基本用法，请输入

+
host:~$ ./phyLinux --help
+
+
+

这将导致

+
usage: phyLinux [-h] [-v] [--verbose] {init,info,clean} ...
+
+This Programs sets up an environment to work with The Yocto Project on Phytecs
+Development Kits. Use phyLinx <command> -h to display the help text for the
+available commands.
+
+positional arguments:
+  {init,info,clean}  commands
+    init             init the phytec bsp in the current directory
+    info             print info about the phytec bsp in the current directory
+    clean            Clean up the current working directory
+
+optional arguments:
+  -h, --help         show this help message and exit
+  -v, --version      show program's version number and exit
+  --verbose
+
+
+
+
+

6.3. 初始化

+

创建一个新的项目文件夹

+
host:~$ mkdir ~/yocto
+
+
+

调用 phyLinux 将使用系统上安装的默认Python版本。从 Ubuntu 20.04 开始，默认是 Python3。如果您想启动与 Python3 不兼容的 BSP，您需要在运行 phyLinux 之前将 Python2 设置为默认值（临时）

+
host:~$ ln -s \`which python2\` python && export PATH=`pwd`:$PATH
+
+
+

现在在新文件夹下运行 phyLinux

+
host:~$ ./phyLinux init
+
+
+

空的文件夹很重要，因为 phyLinux 将会清空该目录。在非空目录运行 phyLinux 会有以下 告警:

+
This current directory is not empty. It could lead to errors in the BSP configuration
+process if you continue from here. At the very least, you have to check your build directory
+for settings in bblayers.conf and local.conf, which will not be handled correctly in
+all cases. It is advisable to start from an empty directory of call:
+$ ./phyLinux clean
+Do you really want to continue from here?
+[yes/no]:
+
+
+

在第一次初始化时，phyLinux 脚本会要求您在 /usr/local/bin 目录中安装 Repo 工具。在执行 init 命令期间，您需要选择处理器平台 (SoC)、PHYTEC 的 BSP 版本号以及您正在使用的Machine

+
***************************************************
+* Please choose one of the available SoC Platforms:
+*
+*   1: am335x
+*   2: am57x
+*   3: am62ax
+*   4: am62x
+*   5: am64x
+*   6: am68x
+*   7: imx6
+*   8: imx6ul
+*   9: imx7
+*   10: imx8
+*   11: imx8m
+*   12: imx8mm
+*   13: imx8mp
+*   14: imx8x
+*   15: imx93
+*   16: nightly
+*   17: rk3288
+*   18: stm32mp13x
+*   19: stm32mp15x
+*   20: topic
+
+# Exemplary output for chosen imx93
+***************************************************
+* Please choose one of the available Releases:
+*
+*   1: BSP-Yocto-NXP-i.MX93-ALPHA1
+*   2: BSP-Yocto-NXP-i.MX93-PD24.1-rc1
+*   3: BSP-Yocto-NXP-i.MX93-PD24.1.0
+*   4: BSP-Yocto-NXP-i.MX93-PD24.1.1-rc1
+*   5: BSP-Yocto-NXP-i.MX93-PD24.1.1-rc2
+*   6: BSP-Yocto-NXP-i.MX93-PD24.1.1-rc3
+*   7: BSP-Yocto-NXP-i.MX93-PD24.1.1
+
+# Exemplary output for chosen BSP-Yocto-NXP-i.MX93-PD24.1.1
+*********************************************************************
+* Please choose one of the available builds:
+*
+no:                 machine: description and article number
+                             distro: supported yocto distribution
+                             target: supported build target
+
+1: phyboard-nash-imx93-1:  PHYTEC phyBOARD-Nash i.MX93
+                           2 GB RAM, eMMC
+                           PB-04729-001, PCL-077-23231211I
+                           distro: ampliphy-vendor
+                           target: phytec-headless-image
+2: phyboard-nash-imx93-1:  PHYTEC phyBOARD-Nash i.MX93
+                           2 GB RAM, eMMC
+                           PB-04729-001, PCL-077-23231211I
+                           distro: ampliphy-vendor-rauc
+                           target: phytec-headless-bundle
+3: phyboard-nash-imx93-1:  PHYTEC phyBOARD-Nash i.MX93
+                           2 GB RAM, eMMC
+                           PB-04729-001, PCL-077-23231211I
+                           distro: ampliphy-vendor-wayland
+                           target: -c populate_sdk phytec-qt6demo-image
+                           target: phytec-qt6demo-image
+4: phyboard-segin-imx93-2: PHYTEC phyBOARD-Segin i.MX93
+                           1 GB RAM, eMMC, silicon revision A1
+                           PB-02029-001, PCL-077-11231010I
+                           distro: ampliphy-vendor
+                           target: phytec-headless-image
+5: phyboard-segin-imx93-2: PHYTEC phyBOARD-Segin i.MX93
+                           1 GB RAM, eMMC, silicon revision A1
+                           PB-02029-001, PCL-077-11231010I
+                           distro: ampliphy-vendor-rauc
+                           target: phytec-headless-bundle
+6: phyboard-segin-imx93-2: PHYTEC phyBOARD-Segin i.MX93
+                           1 GB RAM, eMMC, silicon revision A1
+                           PB-02029-001, PCL-077-11231010I
+                           distro: ampliphy-vendor-wayland
+                           target: phytec-qt6demo-image
+
+
+

如果您无法通过以上phyLinux选择器提供的信息识别您的所使用的硬件，请查看PHYTEC产品发票。配置完成后，您可以运行

+
host:~$ ./phyLinux info
+
+# Exemplary output
+**********************************************
+* The current BSP configuration is:
+*
+* SoC:  refs/heads/imx93
+* Release:  BSP-Yocto-NXP-i.MX93-PD24.1.1
+* Machine:  phyboard-segin-imx93-2
+*
+**********************************************
+
+
+

查看当前BSP选择了哪款 SoC 和 BSP版本。如果您不想使用phyLinux提供的选择器，phyLinux 还支持多种命令行参数去设置Soc和BSP版本

+
host:~$ MACHINE=phyboard-segin-imx93-2 ./phyLinux init -p imx93 -r BSP-Yocto-NXP-i.MX93-PD24.1.1
+
+
+

或者查看帮助命令以获取更多信息

+
host:~$ ./phyLinux  init --help
+
+usage: phyLinux init [-h] [--verbose] [--no-init] [-o REPOREPO] [-b REPOREPO_BRANCH] [-x XML] [-u URL] [-p PLATFORM] [-r RELEASE]
+
+options:
+  -h, --help          show this help message and exit
+  --verbose
+  --no-init           dont execute init after fetch
+  -o REPOREPO         Use repo tool from another url
+  -b REPOREPO_BRANCH  Checkout different branch of repo tool
+  -x XML              Use a local XML manifest
+  -u URL              Manifest git url
+  -p PLATFORM         Processor platform
+  -r RELEASE          Release version
+
+
+

执行 init 命令后，phyLinux 将打印一些重要说明以及后续构建步骤的信息。

+
+
+

6.4. 高级用法

+

phyLinux 可用于通过多种媒介传输软件状态。软件状态在 manifest.xml 有特定标识。您可以创建一个清单文件，将其发送到另一个地方，然后使用以下方式来恢复软件状态，得到目标软件版本

+
host:~$ ./phyLinux init -x manifest.xml
+
+
+

您还可以创建一个包含软件状态的 Git 仓库。该 Git 仓库需要有除了master以外的分支，因为我们保留了master分支用于其他用途。使用 phyLinux 检查软件状态

+
host:~$ ./phyLinux -u <url-of-your-git-repo>
+
+
+
+
+
+

7. 使用编译容器

+
+

警告

+

目前，无法在容器内运行 phyLinux 脚本。在主机上使用 phyLinux 脚本完成初始化后，您可以使用容器进行编译。如果您的机器上没有 phyLinux 脚本，请参阅 phyLinux 文档。

+
+

运行编译容器有多种实现方式。常用的是 docker 和 podman，但我们更喜欢 podman，因为它不需要 root 权限即可运行。

+
+

7.1. 安装

+

如何安装 podman：https://podman.io 如何安装 docker：https://docs.docker.com/engine/install/

+
+
+

7.2. 可用容器

+

目前我们基于 Ubuntu LTS 版本提供了4个不同版本的容器：https://hub.docker.com/u/phybuilder

+
    +

  • yocto-ubuntu-16.04

    • +

  • yocto-ubuntu-18.04

    • +

  • yocto-ubuntu-20.04

    • +

  • yocto-ubuntu-22.04

    • +
+

这些容器可以使用 podman 或 docker 运行。对于 Yocto Mickledore 版本，容器“yocto-ubuntu-20.04”是首选。

+
+
+

7.3. 下载/拉取容器

+
host:~$ podman pull docker.io/phybuilder/yocto-ubuntu-20.04
+
+OR
+
+host:~$ docker pull docker.io/phybuilder/yocto-ubuntu-20.04
+
+
+

在末尾添加以冒号分隔的容器标签，您还可以拉取或运行带有特殊标签的容器。

+
+

podman pull docker.io/phybuilder/yocto-ubuntu-20.04:phy2

+
+

您可以在我们的 duckerhub 空间中找到所有可用的标签：

+ +

如果您尝试运行尚未拉取/下载的容器，它将被自动拉取/下载。

+

您可以使用以下命令查看所有已下载/拉取的容器：

+
$USERNAME@$HOSTNAME:~$ podman images
+REPOSITORY                               TAG         IMAGE ID      CREATED       SIZE
+docker.io/phybuilder/yocto-ubuntu-22.04  latest      d626178e448d  4 months ago  935 MB
+docker.io/phybuilder/yocto-ubuntu-22.04  phy2        d626178e448d  4 months ago  935 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  phy2        e29a88b7172a  4 months ago  900 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  latest      e29a88b7172a  4 months ago  900 MB
+docker.io/phybuilder/yocto-ubuntu-18.04  phy1        14c9c3e477d4  7 months ago  567 MB
+docker.io/phybuilder/yocto-ubuntu-18.04  latest      14c9c3e477d4  7 months ago  567 MB
+docker.io/phybuilder/yocto-ubuntu-16.04  phy1        28c73e13ab4f  7 months ago  599 MB
+docker.io/phybuilder/yocto-ubuntu-16.04  latest      28c73e13ab4f  7 months ago  599 MB
+docker.io/phybuilder/yocto-ubuntu-22.04  phy1        5a0ef4b41935  8 months ago  627 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  phy1        b5a26a86c39f  8 months ago  680 MB
+
+
+
+
+

7.4. 运行容器

+

要运行并使用容器进行 Yocto 构建，首先进入您之前运行 phyLinux init 的文件夹。然后启动容器

+
host:~$ podman run --rm=true -v /home:/home --userns=keep-id --workdir=$PWD -it docker.io/phybuilder/yocto-ubuntu-20.04 bash
+
+
+
+

备注

+

要使用 docker 运行和使用容器，并不像使用 podman 那么简单，必须先定义和配置容器用户。此外，默认情况下docker不支持转发信任凭据，所以必须对信任凭据进行配置。

+
+

现在您的命令行看起来应该是这样的（其中 $USERNAME 是调用“podman run”的用户，并且每次启动容器时容器代码都会有所不同）

+
$USERNAME@6593e2c7b8f6:~$
+
+
+
+

警告

+

如果进入容器的用户名是“root”，您将无法运行 bitbake。请确保使用您自己的用户名运行容器。

+
+

现在您可以在容器中开始构建。要停止/关闭容器，只需调用

+
$USERNAME@6593e2c7b8f6:~$ exit
+
+
+
+
+
+

8. 使用 Poky 和 Bitbake

+
+

8.1. 开始构建

+

使用 phyLinux init 下载所有元数据后，您必须设置 shell 环境变量。每次打开新 shell 开始构建时都需要执行此操作。我们使用 Poky 默认提供的 shell 脚本。在项目的根目录输入

+
host:~$ source sources/poky/oe-init-build-env
+
+
+

source命令的缩写是一个 .

+
host:~$ . sources/poky/oe-init-build-env
+
+
+

shell 的当前工作目录会被改为 build/。在第一次构建之前，您应该查看主配置文件

+
host:~$ vim conf/local.conf
+
+
+

您当前构建的所有产物存储在这里。根据您使用的芯片平台，可能需要接受许可协议。例如，对于Freescale/NXP 的芯片平台，您需要接受 GPU 和 VPU 二进制许可协议。通过取消注释相应的行来接受许可协议

+
# Uncomment to accept NXP EULA # EULA can be found under
+../sources/meta-freescale/EULA ACCEPT_FSL_EULA = "1"
+
+
+

现在您可以构建第一个镜像了。我们建议从较小的非图形镜像 phytec-headless-image 开始，看看一切是否正常工作

+
host:~$ bitbake phytec-headless-image
+
+
+

在 Intel Core i7 上，首次编译大约需要 40 分钟。但是所有的后续构建都将复用之前的缓存，编译大约需要 3 分钟。

+
+
+

8.2. Images

+

如果一切顺利，可以在以下位置找到镜像

+
host:~$ cd deploy/images/<MACHINE>
+
+
+

测试镜像最简单的方法是将核心板配置为 SD 卡启动，并将构建所得镜像烧写到 SD 卡中

+
host:~$ sudo dd if=phytec-headless-image-<MACHINE>.wic of=/dev/<your_device> bs=1M conv=fsync
+
+
+

这里<your_device>可以是“sde”，具体取决于您的系统。选择硬盘驱动时要非常小心！选择错误的硬盘驱动可能会擦除您的硬盘！参数 conv=fsync 强制数据缓冲区在 dd 返回之前写入硬盘。

+

启动后，您可以使用串口或通过网口 ssh 登录。root账户没有密码。这是因为 conf/local.conf 中开启了调试模式。如果您取消注释该行

+
#EXTRA_IMAGE_FEATURES = "debug-tweaks"
+
+
+

调试模式（例如设置空的 root 密码）将不会生效。

+
+
+

8.3. 获取BSP长期维护版本之间的中间开发版本

+

您也可以访问 Yocto BSP 最新的开发中版本，这属于特殊版本，并不是正式的长期维护版本，所以它们不会显示在 phyLinux 选择菜单中，需要手动选择。可以使用以下命令行来获取BSP

+
host:~$ ./phyLinux init -p master -r mickledore
+
+
+

这将初始化一个最新的BSP开发版本。运行

+
host:~$ repo sync
+
+
+

该文件夹将从我们的 Git 仓库中提取所有最新更改。

+
+
+

8.4. 检查您的编译配置

+

Poky 包含多个工具来检查您的Yocto工程。您可以查询Layer工具支持的指令

+
host:~$ bitbake-layers
+
+
+

例如，它可以用来查看特定Recipe在哪一个Layer被修改了

+
host:~$ bitbake-layers show-appends
+
+
+

在运行构建之前，您还可以启动 Toaster，以便能够使用 Toaster Web GUI 图形界面检查构建的详细信息

+
host:~$ source toaster start
+
+
+

但是您可能需要先安装一些依赖才能运行toaster

+
host:~$ pip3 install -r
+../sources/poky/bitbake/toaster-requirements.txt
+
+
+

然后，您可以将浏览器指向 http://0.0.0.0:8000/ 并继续使用 Bitbake。可以从此 Web 服务器监控和分析所有构建活动。如果您想了解有关 Toaster 的更多信息，请查看 https://docs.yoctoproject.org/4.2.4/toaster-manual/index.html。要关闭 Toaster Web GUI，请执行

+
host:~$ source toaster stop
+
+
+
+
+

8.5. meta-phytec 和 meta-ampliphy 的特点

+
+

8.5.1. Buildinfo

+

Buildinfo 任务是我们Recipe中的一个函数，可打印从公共仓库获取源代码的过程。因此您不必亲自查看对应的Recipe，用 Buildinfo 即可查看过程说明（例如 barebox 包的说明），请执行

+
host:~$ bitbake barebox -c buildinfo
+
+
+

在您的 shell 中，会打印如下类似信息

+
(mini) HOWTO: Use a local git repository to build barebox:
+
+To get source code for this package and version (barebox-2022.02.0-phy1), execute
+
+$ mkdir -p ~/git
+$ cd ~/git
+$ git clone git://git.phytec.de/barebox barebox
+$ cd ~/git/barebox
+$ git switch --create v2022.02.0-phy1-local-development 7fe12e65d770f7e657e683849681f339a996418b
+
+You now have two possible workflows for your changes:
+
+1. Work inside the git repository:
+Copy and paste the following snippet to your "local.conf":
+
+SRC_URI:pn-barebox = "git://${HOME}/git/barebox;branch=${BRANCH}"
+SRCREV:pn-barebox = "${AUTOREV}"
+BRANCH:pn-barebox = "v2022.02.0-phy1-local-development"
+
+After that you can recompile and deploy the package with
+
+$ bitbake barebox -c compile
+$ bitbake barebox -c deploy
+
+Note: You have to commit all your changes. Otherwise yocto doesn't pick them up!
+
+2. Work and compile from the local working directory
+To work and compile in an external source directory we provide the
+externalsrc.bbclass. To use it, copy and paste the following snippet to your
+"local.conf":
+
+INHERIT += "externalsrc"
+EXTERNALSRC:pn-barebox = "${HOME}/git/barebox"
+EXTERNALSRC_BUILD:pn-barebox = "${HOME}/git/barebox"
+
+Note: All the compiling is done in the EXTERNALSRC directory. Every time
+you build an Image, the package will be recompiled and build.
+
+NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded.
+NOTE: Writing buildhistory
+
+
+

正如您所见，控制台输出了清楚地说明了构建信息。

+
+

警告

+

使用 外部源 会破坏 Yocto 的许多内部依赖机制。在构建过程中，源目录下的更改并不能保证被自动抓取并合并到根文件系统或 SD 卡镜像中。您必须始终使用 --force。例如，在编译 barebox 并将其重新部署到 deploy/images/<machine> 时需要执行

+
host:~$ bitbake barebox -c compile --force
+host:~$ bitbake barebox -c deploy
+
+
+
+

要使用新内核或镜像更新 SD 卡镜像，首先强制编译它，然后强制重建根文件系统。使用

+
host:~$ bitbake phytec-qt6demo-image -c rootfs --force
+
+
+

请注意，Yocto构建系统不会对外部源文件目录进行修改。如果要将 Yocto Recipe携带的所有补丁应用到外部源目录，请运行以下指令

+
SRCTREECOVEREDTASKS="" BB_ENV_PASSTHROUGH_ADDITIONS="$BB_ENV_PASSTHROUGH_ADDITIONS SRCTREECOVEREDTASKS" bitbake <recipe> -c patch
+
+
+
+
+
+

8.6. 自定义BSP

+

为了帮助您开始使用 BSP，我们从 Yocto 官方文档中总结了一些基本任务。它描述了如何向镜像添加其他软件、更改kernel和Bootloader配置，以及应用kernel和Bootloader的补丁。

+

诸如添加软件之类的小修改是在文件 build/conf/local.conf 中完成的。在那里，您可以覆盖全局变量并对recipe进行小修改。

+

有两种方法可以进行重大更改：

+
    +

  1. 创建您自己的Layer并使用 bbappend 文件。

    2. +

  2. 将所有新增内容添加到 PHYTEC 的 Distro Layer meta-ampliphy。

    3. +
+

创建您自己的Layer部分描述了如何创建您自己的Layer。

+
+

8.6.1. 禁用 Qt 示例demo

+

默认情况下，BSP 映像 phytec-qt6demo-image 会在连接的显示器或监视器上启动 Qt6 示例应用程序。如果要停止示例并使用后台得 Linux framebuffer 控制台，请通过串口或网络 ssh 连接到目标并执行 shell 命令

+
target:~$ systemctl stop phytec-qtdemo.service
+
+
+

此命令暂时停止演示app。要重新启动，请重启主板或执行

+
target:~$ systemctl start phytec-qtdemo.service
+
+
+

您可以永久禁用该服务，这样它就不会在开机时自启动

+
target:~$ systemctl disable phytec-qtdemo.service
+
+
+
+

小技巧

+

最后一个命令仅禁用了服务，但是它不会立即停止。要查看当前服务状态，请执行

+
target:~$ systemctl status phytec-qtdemo.service
+
+
+
+

如果要默认禁用该服务，请编辑文件 build/conf/local.conf 并添加以下行

+
# file build/conf/local.conf
+SYSTEMD_AUTO_ENABLE:pn-phytec-qtdemo = "disable"
+
+
+

之后重新编译镜像

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

8.6.2. Framebuffer 控制台

+

在具有显示接口的核心板上，默认启用Framebuffer控制台。您可以连接 USB 键盘并登录。要将键盘布局从默认的英语更改为德语，请键入

+
target:~$ loadkeys /usr/share/keymaps/i386/qwertz/de-latin1.map.gz
+
+
+

如果要退出Framebuffer控制台，请运行

+
target:~$ echo 0 > sys/class/vtconsole/vtcon1/bind
+
+
+

要完全停用Framebuffer控制台，请禁用以下内核配置选项

+
Device Drivers->Graphics Support->Support for framebuffer devices->Framebuffer Console Support
+
+
+

更多信息请访问：https://www.kernel.org/doc/Documentation/fb/fbcon.txt

+
+
+

8.6.3. 预编译镜像中提供的工具

+
+

8.6.3.1. RAM 基准测试

+

RAM 和缓存性能测试的最佳方法是使用 pmbw （并行内存带宽基准测试/测量工具）。 Pmbw 运行多个汇编例程，这些例程都使用不同的访问模式来访问 SoC 的缓存和 RAM。在运行测试之前，请确保设备上有大约 2 MiB 的空间用于存储日志文件。我们还降低了基准测试的级别，以便于更积极地向内核请求资源。基准测试将花费几个小时。

+

要开始测试，请键入

+
target:~$ nice -n -2 pmbw
+
+
+

测试完成后，日志文件可以转换为 gnuplot 脚本，运行

+
target:~$ stats2gnuplot stats.txt > run1.gnuplot
+
+
+

现在您可以将日志文件传输到主机并安装任意版本的 gnuplot

+
host:~$ sudo apt-get install gnuplot host:~$ gnuplot run1.gnuplot
+
+
+

生成的 plots-<machine> .pdf 文件包含所有图表。要将单个图表渲染为 png 文件，您可以使用 Ghostscript

+
host:~$ sudo apt-get install ghostscript
+host:~$ gs -dNOPAUSE -dBATCH -sDEVICE=png16m -r150 -sOutputFile='page-%00d.png' plots-phyboard-wega-am335x-1.pdf
+
+
+
+
+
+

8.6.4. 为 BSP 镜像添加新的软件包

+

要向镜像添加其他软件，请查看 OpenEmbedded Layer索引：https://layers.openembedded.org/layerindex/branch/mickledore/layers/

+

首先，从左上角的下拉列表中选择您拥有的 BSP 的 Yocto 版本，然后单击 Recipes。现在您可以搜索软件项目名称并找到它所在的Layer。在某些情况下，程序位于 meta-openembedded、 openembedded-core 或 Poky 中，这意味着Recipe已在您的Yocto工程中。本节介绍在这种情况下如何添加软件。如果软件包位于另一个Layer，请参阅下一部分。

+

您还可以搜索可用Recipe列表

+
host:~$ bitbake -s | grep <program name> # fill in program name, like in
+host:~$ bitbake -s | grep lsof
+
+
+

当程序的Recipe已在 Yocto 工程中时，您只需将他添加到文件 build/conf/local.conf 即可。向镜像添加其他软件的一般语法是

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " <package1> <package2>"
+
+
+

例如，这一行

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " ldd strace file lsof"
+
+
+

在目标镜像上安装一些辅助程序。

+
+

警告

+

程序包名称前的空格非常重要。

+
+

local.conf 中的配置项均适用于所有镜像。因此，新增的这些软件工具将被同时包含在 phytec-headless-image 和 phytec-qt6demo-image 镜像中。

+
+

8.6.4.1. 关于软件包和Recipe的说明

+

您正在将软件包添加到 IMAGE_INSTALL 变量中。这些不一定等同于Layer的Recipe名称。Recipe默认定义一个具有相同名称的软件包。但Recipe也可以将 PACKAGES 变量设置为其他名称，并能够生成具有任意名称的软件包。当您查找软件时，严格来说，都必须搜索软件包名称，而不是Recipe。在最坏的情况下，您必须查看所有 PACKAGES 变量。这会有点繁琐， Toaster 之类的工具可能对查找有所帮助。

+

如果您在文件夹 sources 提供的Layer中找不到您的软件，请参阅下一部分以将一个新的Layer包含到 Yocto 构建中。

+

参考资料：Yocto 4.2.4 文档 - 自定义 Yocto 构建

+
+
+
+

8.6.5. 添加其他Layer

+

这是关于如何在您的 Yocto 构建中添加另一Layer并从中安装软件的详细上手指南。例如，我们将网络安全扫描器 nmap 包含在Layer meta-security 中。首先，您必须找到包含该软件的Layer。查看 OpenEmbedded MetaData 索引 并稍微思考一下。网络扫描器 nmap 位于 meta-security Layer。请参阅 layer.openembedded.org 上的 meta-security。要将其集成到 Yocto 构建中，您必须拉取git仓库，然后切换到正确的稳定分支。由于 BSP 是基于 Yocto “sumo”版本构建，因此您也应该尝试在Layer中使用“sumo”分支。

+
host:~$ cd sources
+host:~$ git clone git://git.yoctoproject.org/meta-security
+host:~$ cd meta-security
+host:~$ git branch -r
+
+
+

所有可用的远程分支都会显示出来。通常应该有“fido”、“jethro”、“krogoth”、“master”……

+
host:~$ git checkout mickledore
+
+
+

现在我们通过把以下代码添加到 build/conf/bblayers.conf 文件末尾的方式来将Layer包含到构建中

+
# file build/conf/bblayers.conf
+BBLAYERS += "${BSPDIR}/sources/meta-security"
+
+
+

然后，您可以通过执行以下代码来检查该Layer是否在构建配置中可用

+
host:~$ bitbake-layers show-layers
+
+
+

如果出现类似以下错误

+
ERROR: Layer 'security' depends on layer 'perl-layer', but this layer is not enabled in your configuration
+
+
+

如果您要添加的Layer（这里是 meta-security）依赖于另一个Layer，您需要先启用被依赖的Layer。例如，此处所需的依赖项是 meta-openembedded 中的Layer（在 PHYTEC BSP 中，它位于路径 sources/meta-openembedded/meta-perl/ 中）。要启用它，请将以下行添加到 build/conf/bblayers.conf

+
# file build/conf/bblayers.conf
+BBLAYERS += "${BSPDIR}/sources/meta-openembedded/meta-perl"
+
+
+

执行命令 bitbake-layers show-layers 应该会打印所有已启用Layer的列表，包括 meta-security 和 meta-perl。包含该Layer后，您可以按照之前的描述安装Layer中的软件包。最简单的方法是添加以下行（这里是包 nmap）

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " nmap"
+
+
+

到您的 build/conf/local.conf。不要添加后忘记重新构建镜像

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

8.6.6. Create your own layer

+

创建Layer应该是自定义 BSP 的首要任务之一。您有两个选择。您可以复制并重命名 meta-ampliphy，也可以创建一个包含修改的新Layer。哪个选择更好取决于您的使用场景。 meta-ampliphy 是我们自定义 Linux 发行版的示例，该发行版也会在未来持续更新。如果您想从这些更新中受益，并且总体上对它的用户空间配置感到满意，那么在 Ampliphy 基础上创建自己的Layer可能是最佳解决方案。如果您需要重建用户空间架构并且只需要 PHYTEC 的基本硬件支持，最好复制 meta-ampliphy，给Layer重新命名并修改其内容以使其适应您的需求。您还可以查看 OpenEmbedded Layer索引以查找不同的发行版 Layer。如果您只需要将自己的应用程序添加到镜像中，请创建自己的Layer。

+

在下一章中，我们有一个名为“racer”的嵌入式项目，我们将使用我们的 Ampliphy Linux 发行版来集成它。首先，我们需要创建一个新的Layer。

+

Yocto 提供了一个脚本来实现Layer创建。如果您已经配置好 BSP 并且 shell 已准备就绪，请输入

+
host:~$ bitbake-layers create-layer meta-racer
+
+
+

目前来说，默认选项是可行的。将该Layer移动到source目录下

+
host:~$ mv meta-racer ../sources/
+
+
+

在此Layer创建一个 Git 仓库来跟踪您的更改

+
host:~$ cd ../sources/meta-racer
+host:~$ git init && git add . && git commit -s
+
+
+

现在您可以将该Layer直接添加到 build/conf/bblayers.conf

+
BBLAYERS += "${BSPDIR}/sources/meta-racer"
+
+
+

或者使用 Yocto 提供的脚本

+
host:~$ bitbake-layers add-layer meta-racer
+
+
+
+
+

8.6.7. kernel和Bootloader的Recipe和版本

+

首先，您需要知道目标Machine使用哪个kernel和对应的版本。PHYTEC 提供多个kernel recipe linux-mainline、 linux-ti 和 linux-imx。第一个为 PHYTEC 的 i.MX 6 和 AM335x SOM提供支持，他是基于 kernel.org 的 Linux kernel稳定版本。 Git 仓库 URL 为：

+
    +

  • linux-mainline：git://git.phytec.de/linux-mainline

    • +

  • linux-ti: git://git.phytec.de/linux-ti

    • +

  • linux-imx: git://git.phytec.de/linux-imx

    • +

  • barebox：git://git.phytec.de/barebox

    • +

  • u-boot-imx: git://git.phytec.de/u-boot-imx

    • +
+

要找出您最终所使用的kernel recipe，请执行以下命令

+
host:~$ bitbake virtual/kernel -e | grep "PREFERRED_PROVIDER_virtual/kernel"
+
+
+

该命令打印变量 PREFERRED_PROVIDER_virtual/kernel 的值。该变量在 Yocto 构建过程被用来选择要使用的kernel recipe。以下几行是您可能会看到的不同输出值

+
PREFERRED_PROVIDER_virtual/kernel="linux-mainline"
+PREFERRED_PROVIDER_virtual/kernel="linux-ti"
+PREFERRED_PROVIDER_virtual/kernel="linux-imx"
+
+
+

要查看使用的是哪个版本，请执行 bitbake -s。例如

+
host:~$ bitbake -s | egrep -e "linux-mainline|linux-ti|linux-imx|barebox|u-boot-imx"
+
+
+

参数 -s 打印所有相关Recipe和它的版本。输出左侧包含Recipe名称，右侧包含版本

+
barebox                      :2022.02.0-phy1-r7.0
+barebox-hosttools-native     :2022.02.0-phy1-r7.0
+barebox-targettools          :2022.02.0-phy1-r7.0
+linux-mainline               :5.15.102-phy1-r0.0
+
+
+

如您所见，recipe linux-mainline 的版本为 5.15.102-phy1。在 PHYTEC 的 linux-mainline Git 仓库中，您将找到相应的标签 v5.15.102-phy1。 barebox recipe的版本为 2022.02.0-phy1。在 i.MX8M* 模块上，输出将包含 linux-imx 和 u-boot-imx。

+
+
+

8.6.8. Kernel和Bootloader配置

+

PHYTEC 所使用的bootloader barebox 采用与 Linux kernel相同的编译系统。因此，本节中的所有指令均可用于配置kernel以及bootloader。要配置kernel或bootloader，请执行以下命令中的一条。

+
host:~$ bitbake -c menuconfig virtual/kernel  # Using the virtual provider name
+host:~$ bitbake -c menuconfig linux-ti        # Or use the recipe name directly
+host:~$ bitbake -c menuconfig linux-mainline  # Or use the recipe name directly (If you use an i.MX 6 or RK3288 Module)
+host:~$ bitbake -c menuconfig linux-imx       # Or use the recipe name directly (If you use an i.MX 8M*)
+host:~$ bitbake -c menuconfig barebox         # Or change the configuration of the bootloader
+host:~$ bitbake -c menuconfig u-boot-imx      # Or change the configuration of the bootloader (If you use an i.MX 8M*)
+
+
+

之后，您可以重新编译并部署kernel或bootloader

+
host:~$ bitbake virtual/kernel -c compile  # Or 'barebox' for the bootloader
+host:~$ bitbake virtual/kernel -c deploy   # Or 'barebox' for the bootloader
+
+
+

或者，您也可以使用以下命令重新进行完整的构建

+
host:~$ bitbake phytec-headless-image  # To update the kernel/bootloader, modules and the images
+
+
+

在最后一个命令中，您可以将镜像名称替换为您选择的镜像名称。新镜像和二进制文件位于 build/deploy/images/<machine> /.

+
+

警告

+

之前对kernel的配置并不是永久生效的。执行 bitbake virtual/kernel -c clean 可以清除所有内容。

+
+

要使更改在构建系统中永久生效，您需要将配置修改整合到Layer中。您有两种选择：

+
    +

  • 仅包含配置差异片段（新旧配置之间的最小 差异）

    • +

  • 修改后的完整配置（defconfig）。

    • +
+

使用配置片段可以使开发者对不同阶段所做的更改更加清晰。您可以选择启用或禁用这些配置，对不同条件下的配置作管理，这有助于更迅速地将更改的配置迁移到新的kernel版本。您还可以对配置片段进行分组，以在不同的特定场景下使用。生成的完整kernel配置将被放在目录 build/deploy/images/<machine> 中。如果您没有上述这些需求，选择维护完整的 defconfig 文件可能会更加简单。

+
+

8.6.8.1. 将配置片段添加到Recipe

+

以下步骤适用于kernel和bootloader。只需将命令中的recipe名称 linux-mainline 替换为 linux-ti，或者将bootloader替换为 barebox。如果您对这个命令作用还不熟悉，请从一个干净的Yocto工程重新开始。否则，配置的差异可能会导致错误。

+
host:~$ bitbake linux-mainline -c clean
+host:~$ bitbake linux-mainline -c menuconfig
+
+
+

在菜单中更改配置并生成配置片段

+
host:~$ bitbake linux-mainline -c diffconfig
+
+
+

他将会打印生成的配置片段文件路径

+
Config fragment has been dumped into:
+/home/<path>/build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg
+
+
+

所有的配置修改都记录在文件 fragment.cfg 中，该文件仅包含少量配置行。以下示例展示了如何创建 bbappend 文件，以及如何为配置片段添加所需的行。您只需根据特定Recipe调整目录和名称： linux-mainline、 linux-ti、linux-imx、u-boot-imx 或 barebox。

+
sources/<layer>/recipes-kernel/linux/linux-mainline_%.bbappend     # For the recipe linux-mainline
+sources/<layer>/recipes-kernel/linux/linux-ti_%.bbappend           # For the recipe linux-ti
+sources/<layer>/recipes-kernel/linux/linux-imx_%.bbappend          # For the recipe linux-imx
+sources/<layer>/recipes-bsp/barebox/barebox_%.bbappend             # For the recipe barebox
+sources/<layer>/recipes-bsp/u-boot/u-boot-imx_%.bbappend           # For the recipe u-boot-imx
+
+
+

将字符串 layer 替换为您自己创建的layer（如上所示）（例如 meta-racer），或者直接使用 meta-ampliphy。要使用 meta-ampliphy，首先，需要为配置片段创建目录并为其指定一个新名称（此处为 enable-r8169.cfg），然后将片段放到这个Layer中。

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features
+# copy the path from the output of *diffconfig*
+host:~$ cp /home/<path>/build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg \
+    sources/meta-ampliphy/recipes-kernel/linux/features/enable-r8169.cfg
+
+
+

之后使用您喜欢的编辑器打开 bbappend 文件（在本例中为 sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend ）并添加以下几行

+
# contents of the file linux-mainline_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://enable-r8169.cfg \
+"
+
+
+
+

警告

+

不要忘记使用正确的 bbappend 文件名： linux-ti_%.bbappend 用于 linux-ti recipe， barebox_%.bbappend 用于文件夹 recipes-bsp/barebox/ 中的bootloader！

+
+

保存 bbappend 文件后，您需要重新编译镜像。 Yocto 会自动识别recipe的更改并生成新的镜像。

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+
+
+

8.6.8.2. 向Recipe添加一个完整配置 (defconfig)

+

这种方法与之前的方法相似，但不是添加一个片段，而是采用 defconfig。首先，在您想要使用的Layer中创建所需的文件夹，这可以是您自己的Layer，或者是 meta-ampliphy。

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features/ # For both linux-mainline and linux-ti
+host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features/ # Or for the bootloader
+
+
+

然后您需要创建一个合适的 defconfig 文件。使用 menuconfig 进行配置更改，然后将 defconfig 文件保存到Layer中。

+
host:~$ bitbake linux-mainline -c menuconfig # Or use recipe name linux-ti or barebox
+host:~$ bitbake linux-mainline -c savedefconfig # Create file 'defconfig.temp' in the work directory
+
+
+

这将打印defconfig的保存路径

+
Saving defconfig to ..../defconfig.temp
+
+
+

然后，按照前面的说明，将生成的完整配置文件复制到您的Layer中，重命名为 defconfig，并在 bbappend 文件中添加以下行（此处为 sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend）。

+
# contents of the file linux-mainline_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://defconfig \
+"
+
+
+
+

小技巧

+

不要忘记使用正确的 bbappend 文件名： linux-ti_%.bbappend 用于 linux-ti recipe ， barebox_%.bbappend 用于文件夹 recipes-bsp/barebox/ 中的bootloader ！

+
+

这样，在重编镜像时，新的镜像将会包含所作的配置修改。

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+
+
+
+

8.6.9. 使用 devtool 修改Kernel或Bootloader

+

除了使用recipes中提供的标准kernel和bootloader外，您可以选择在yocto中用devtool直接修改源代码或单独下载我们的git仓库来构建您的自定义kernel 。 以下是两种修改方式的优劣对比

+ + + + + + + + + + + + +

优势

劣势

Yocto 官方文档的标准工作流程

重复的源文件包，造成了不必要的硬盘空间浪费。

工具链无需重新编译所有内容。

未能有效利用缓存，导致构建成本增加。

+

Devtool 是一套辅助工具，旨在提升 Yocto 用户的工作效率。它与 1.8 版本相兼容。只需配置好 shell 环境，您就可以使用它。 Devtool 的功能包括：

+
    +

  • 修改现有资源文件

    • +

  • 将其他软件项目纳入您的构建配置中

    • +

  • 编译软件并将修改后的软件部署到目标硬件中。

    • +
+

这里我们将利用 devtool 来修改kernel。我们以 linux-mainline 作为 AM335x kernel的实现示例。我们首先使用的命令是 devtool modify - x <recipe><directory>

+
host:~$ devtool modify -x linux-mainline linux-mainline
+
+
+

Devtool 将在 build/workspace 目录下创建一个layer ，您可以在这个Layer下查看 devtool 命令进行的所有更改。它将与recipe 相关的源代码下载到一个指定的文件夹中以及在workspace生成一个 bbappend 文件，其中的 SRC_URI 指向上述下载文件夹。使用 Bitbake 构建镜像时，将会使用此文件夹中的源代码。现在您可以对kernel进行修改。

+
host:~$ vim linux-mainline/arch/arm/boot/dts/am335x-phycore-som.dtsi
+      -> make a change
+host:~$ bitbake phytec-qt6demo-image
+
+
+

您的更改现在将被重新编译并添加到镜像中。如果您希望永久保存这些更改，建议您根据更改创建一个补丁，存储和备份该补丁。您可以进入 linux-mainline 目录并使用 Git 来创建补丁。有关如何创建补丁的详细信息，请参阅 使用“临时方法”修补Kernel 或Bootloader。

+

如果您想了解有关 devtool 的更多信息，请访问：

+

Yocto 4.2.4 - Devtool 或 Devtool 快速指南

+
+
+

8.6.10. 使用“临时方法”修补Kernel 或Bootloader

+ + + + + + + + + + + + +

优势

劣势

无开销，无额外配置

Yocto 非常容易覆盖您所作的修改（所有内容都会丢失！！）。

工具链无需重新编译所有内容。

+

Yocto 允许在 Bitbake 配置和编译recipe之前，更改源代码。使用 Bitbake 的 devshell 命令跳转到recipe的源目录。这是 barebox recipe

+
host:~$ bitbake barebox -c devshell # or linux-mainline, linux-ti, linux-imx, u-boot-imx
+
+
+

执行命令后，将打开一个 shell 窗口。shell 的当前工作目录将更改为 tmp 文件夹中recipe的资源文件目录。在这里，您可以使用您最喜欢的编辑器（例如 vim、 emacs 或任何其他图形编辑器）来更改源代码。完成后，通过键入 exit 或按 CTRL-D 退出 devshell。

+

离开 devshell 后，您可以重新编译软件包

+
host:~$ bitbake barebox -c compile --force # or linux-mainline, linux-ti, linux-imx, u-boot-imx
+
+
+

参数“--force”很重要，因为 Yocto 无法识别源代码是否已被更改。

+
+

小技巧

+

您无法在 devshell 中执行 bitbake 命令。您必须先退出devshell模式。

+
+

如果构建失败，请再次执行 devshell 命令并修复。如果构建成功，则可以部署包并创建新的 SD 卡镜像

+
host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox.bin
+host:~$ bitbake phytec-headless-image # new WIC image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic
+
+
+
+

警告

+

如果您进行clean操作，比如 bitbake barebox -c clean，或者 Yocto 重新下载源码，您所做的所有更改将会丢失！！！

+

为了防止这种情况发生，您可以制作一个补丁并将其添加到 bbappend 文件中。这与配置修改章节中提到的工作流程相似。

+

如果您采用临时方法，让修改永久生效需要在 devshell 中生成补丁；如果您使用 devtool，则必须在 devtool 创建的子目录中生成补丁。

+
+
host:~$ bitbake barebox -c devshell            # Or linux-mainline, linux-ti
+host(devshell):~$ git status                   # Show changes files
+host(devshell):~$ git add <file>               # Add a special file to the staging area
+host(devshell):~$ git commit -m "important modification"   # Creates a commit with a not so useful commit message
+host(devshell):~$ git format-patch -1 -o ~/    # Creates a patch of the last commit and saves it in your home folder
+/home/<user>/0001-important-modification.patch  # Git prints the path of the written patch file
+host(devshell):~$ exit
+
+
+

创建补丁后，必须为其创建一个 bbappend 文件。三个不同recipe文件（linux-mainline、 linux-ti 和 barebox）的位置如下：

+
sources/<layer>/recipes-kernel/linux/linux-mainline_%.bbappend     # For the recipe linux-mainline
+sources/<layer>/recipes-kernel/linux/linux-ti_%.bbappend           # For the recipe linux-ti
+sources/<layer>/recipes-kernel/linux/linux-imx_%.bbappend        # For the recipe linux-imx
+sources/<layer>/recipes-bsp/barebox/barebox_%.bbappend             # For the recipe barebox
+sources/<layer>/recipes-bsp/u-boot/u-boot-imx_%.bbappend           # For the recipe u-boot-imx
+
+
+

以下示例适用于recipe barebox。但是必须根据您的实际情况调整补丁路径。首先，创建文件夹并将补丁移入其中。然后创建 bbappend 文件

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features   # Or use your own layer instead of *meta-ampliphy*
+host:~$ cp ~/0001-important-modification.patch sources/meta-ampliphy/recipes-bsp/barebox/features  # copy patch
+host:~$ touch sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend
+
+
+
+

小技巧

+

注意您当前的工作目录。您必须在BSP根目录中执行命令，而不是在 build 目录中！

+
+

之后，使用您最喜欢的编辑器将以下内容添加到 bbappend 文件中（此处为 sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend）

+
# contents of the file barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://0001-important-modification.patch \
+"
+
+
+

保存文件并使用以下方法重新编译 barebox recipe

+
host:~$ bitbake barebox -c clean # Or linux-ti, linux-mainline, linux-imx, u-boot-imx
+host:~$ bitbake barebox
+
+
+

如果构建成功，您可以通过以下方法重新生成最终镜像。

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+

更多资源：

+

Yocto 项目为软件开发人员提供了一些文档。请参考“Kernel开发手册”以获取有关Kernel配置的详细信息。请注意，并非所有 Yocto 手册中的内容都适用于 PHYTEC BSP，因为我们采用了传统的内核编译方法，而大部分文档会假设使用的是 Yocto 的内核编译方式。

+ +
+
+

8.6.11. 使用 local.conf 文件中的 SRC_URI 来配置Kernel 和Bootloader

+

在这里，我们提供了第三个选项来修改kernel和Bootloader 。您可以从外部拉取 linux-mainline、linux-ti 或 barebox Git 仓库。您将需要重写源代码URL（变量 SRC_URI），以指向您的本地仓库而不是远程仓库。

+ + + + + + + + + + + + + + + +

优势

劣势

所有更改均使用 Git 保存

build/tmp-glibc/work/ 中有许多工作目录<machine>/<package> /

重新编译之前必须提交所有更改

对于每次更改，工具链都会从头开始编译所有内容（可以使用 ccache 避免）

+

首先，您需要一个 Git 仓库 barebox 或kernel的本地副本。如果您还没有，请使用以下命令。

+
host:~$ mkdir ~/git
+host:~$ cd ~/git
+host:~$ git clone git://git.phytec.de/barebox
+host:~$ cd barebox
+host:~$ git switch --create v2022.02.0-phy remotes/origin/v2022.02.0-phy
+
+
+

将以下代码片段添加到 build/conf/local.conf

+
# Use your own path to the git repository
+# NOTE: Branch name in variable "BRANCH_pn-barebox" should be the same as the
+# branch which is used in the repository folder. Otherwise your commits won't be recognized later.
+BRANCH:pn-barebox = "v2022.02.0-phy"
+SRC_URI:pn-barebox = "git:///${HOME}/git/barebox;branch=${BRANCH}"
+SRCREV:pn-barebox = "${AUTOREV}"
+
+
+

您需要在文件中正确设置git仓库分支名称。无论您是选择在 Git 仓库中创建自己的分支，还是使用默认的分支（这里是“v2015.02.0-phy”）。现在，您都可以用自己的源代码重新编译 barebox。

+
host:~$ bitbake barebox -c clean
+host:~$ bitbake barebox -c compile
+
+
+

由于源代码尚未被修改，因此构建应该能够成功。

+

您可以在 ~/git/barebox 或默认的 defconfig 中修改源代码（例如 ~/git/barebox/arch/arm/configs/imx_v7_defconfig）。一旦您完成了代码更改，您需要对 Yocto 进行本地提交。如果您不这样做， Yocto 将无法检测到您在git仓库中的源代码已被更改（例如 ~/git/barebox/）。

+
host:~$ git status  # show modified files
+host:~$ git diff    # show changed lines
+host:~$ git commit -a -m "dummy commit for yocto"   # This command is important!
+
+
+

本地提交后尝试编译。 Yocto 将自动注意到源代码已更改，并从头开始进行源代码获取和工程配置工作。

+
host:~$ bitbake barebox -c compile
+
+
+

如果构建失败，请返回源目录，修复问题并重新提交更改。如果构建成功，您可以获取 barebox，甚至创建一个新的 SD 卡镜像。.

+
host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox-phyflex-imx6-2.bin
+host:~$ bitbake phytec-headless-image # new sd-card image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic
+
+
+

如果您想进行其他更改，只需在git仓库中进行另一次提交并再次重新编译 barebox。

+
+
+

8.6.12. 使用“可持续方法”添加软件

+

现在您已经创建了自己的Layer，您有第二个方式可以将现有软件添加到目标镜像中。我们的标准镜像在 meta-ampliphy 中定义

+
meta-ampliphy/recipes-images/images/phytec-headless-image.bb
+
+
+

在您的layer中，可以使用 bbappend 修改recipe，无需改动源recipe文件

+
meta-racer/recipes-images/images/phytec-headless-image.bbappend
+
+
+

bbappend文件内容将与源recipe一起解析。因此，您可以轻松覆盖源recipe中设置的所有变量。如果我们想要包含一些其他软件，需要在bbapend中将其追加到 IMAGE_INSTALL 变量中

+
IMAGE_INSTALL:append = " rsync"
+
+
+
+
+

8.6.13. 将 Linux 固件添加到根文件系统

+

将额外的固件放入根文件系统的 /lib/firmware/ 目录是一项常见的需求。例如，WiFi适配器或PCIe网卡可能需要专有的固件。为了解决这个问题，我们可以在Layer中使用 bbappend 。首先要创建所需的文件夹，在文件夹中创建bbapend文件并拷贝固件到对应的文件夹中。

+
host:~$ cd meta-racer   # go into your layer
+host:~$ mkdir -p recipes-kernel/linux-firmware/linux-firmware/
+host:~$ touch recipes-kernel/linux-firmware/linux-firmware_%.bbappend
+host:~$ cp ~/example-firmware.bin recipes-kernel/linux-firmware/linux-firmware/    # adapt filename
+
+
+

然后将以下内容添加到 bbappend 文件中，用您的固件名替换每个出现的 example-firmware.bin。

+
# file recipes-kernel/linux-firmware/linux-firmware_%.bbappend
+
+FILESEXTRAPATHS:prepend := "${THISDIR}/linux-firmware:"
+SRC_URI += "file://example-firmware.bin"
+
+do_install:append () {
+        install -m 0644 ${WORKDIR}/example-firmware.bin ${D}/lib/firmware/example-firmware.bin
+}
+
+# NOTE: Use "=+" instead of "+=". Otherwise file is placed into the linux-firmware package.
+PACKAGES =+ "${PN}-example"
+FILES:${PN}-example = "/lib/firmware/example-firmware.bin"
+
+
+

现在尝试构建 linux-firmware recipe

+
host:~$ . sources/poky/oe-init-build-env
+host:~$ bitbake linux-firmware
+
+
+

这会生成一个新的软件包 deploy/ipk/all/linux-firmware-example。

+

最后一步，您必须将固件包安装到您的镜像中。您可以通过在 local.conf 或镜像recipe中添加对应的代码行来实现

+
# file local.conf or image recipe
+IMAGE_INSTALL += "linux-firmware-example"
+
+
+
+

警告

+

确保您已将包名 linux-firmware-example 调整为您在 linux-firmware_%.bbappend 中指定的名称。

+
+
+
+

8.6.14. 使用 bbappend 文件更改 u-boot 环境变量

+

所有 i.MX8M* 产品均使用 u-boot 作为bootloader。可以使用临时方法修改 u-boot 环境变量。对 u-boot-imx 来说，环境变量定义位于 include/configs/phycore_imx8m* 中与处理器名称对应的头文件。新的环境变量应添加在 CONFIG_EXTRA_ENV_SETTINGS 的末尾

+
#define CONFIG_EXTRA_ENV_SETTINGS \
+[...]
+PHYCORE_FITIMAGE_ENV_BOOTLOGIC \
+"newvariable=1\0"
+
+
+

提交修改并在您的layer中创建文件 u-boot-imx_%.bbappend <layer> /recipes-bsp/u-boot/u-boot-imx_%.bbappend

+
# contents of the file u-boot-imx_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://0001-environment-addition.patch \
+"
+
+
+
+
+

8.6.15. 通过 bbappend 文件更改 barebox 环境变量

+

从 BSP-Yocto-AM335x-16.2.0 和 BSP-Yocto-i.MX6-PD16.1.0 开始， meta-phytec 中的 barebox 环境变量已经采用新的机制。现在可以通过 Python bitbake 任务 do_env 在 barebox 环境中添加、更改和删除文件。有两个 Python 函数可以更改环境。它们是：

+
    +

  • env_add(d, ***filename as string*, ***file content as string*): 添加新文件或覆盖现有文件

    • +

  • env_rm(d, ***filename as string*): 删除文件

    • +
+

自定义layer meta-racer 的第一个示例中用 bbappend 文件中展示了如何在 barebox 环境文件夹 /env/nv/ 中加入新的非易失性变量 linux.bootargs.fb。

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_add(d, "nv/linux.bootargs.fb", "imxdrm.legacyfb_depth=32\n")
+}
+
+
+

第二个示例显示如何替换网络配置文件 /env/network/eth0

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_add(d, "network/eth0",
+"""#!/bin/sh
+
+# ip setting (static/dhcp)
+ip=static
+global.dhcp.vendor_id=barebox-${global.hostname}
+
+# static setup used if ip=static
+ipaddr=192.168.178.5
+netmask=255.255.255.0
+gateway=192.168.178.1
+serverip=192.168.178.1
+""")
+}
+
+
+

在上述示例中， Python 的多行字符串语法 """ text """ 可以避免在 Python 代码中插入多个换行符 \n。 Python 函数 env_add 可以用于添加和替换环境文件。

+

下一个示例显示如何删除已添加的环境文件，例如 , /env/boot/mmc

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_rm(d, "boot/mmc")
+}
+
+
+
+

8.6.15.1. 调试

+

如果您想查看在构建过程中添加的所有环境文件，您可以在 local.conf 中启用调试标志

+
# file local.conf
+ENV_VERBOSE = "1"
+
+
+

之后，您必须重新构建 barebox recipe才能看到调试输出

+
host:~$ bitbake barebox -c clean
+host:~$ bitbake barebox -c configure
+
+
+

最后一个命令的输出如下所示

+
[...]
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/allow_color' content "false"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.base' content "consoleblank=0"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.fb' content "imxdrm.legacyfb_depth=32"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.rootfs' content "rootwait ro fsck.repair=yes"
+
+
+
+
+

8.6.15.2. 修改环境（依赖所使用的machine）

+

如果您只需将一些 barebox 环境设置应用于一台或多台设备，您可以利用 Bitbake 的machine覆盖语法。这个语法是，将machine名称或 SoC 名称（例如 mx6、 ti33x 或 rk3288）通过下划线附加到变量或任务上。

+
DEPENDS:remove:mx6 = "virtual/libgl" or
+python do_env_append_phyboard-mira-imx6-4().
+
+
+

下一个示例仅当 MACHINE 设置为 phyboard-mira-imx6-4 时才添加环境变量

+
# file meta-phytec/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append:phyboard-mira-imx6-4() {
+    env_add(d, "nv/linux.bootargs.cma", "cma=64M\n")
+}
+
+
+

Bitbake 变量覆盖语法的更详细解释如下：https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-metadata.html#conditional-metadata

+
+
+

8.6.15.3. 在旧的 BSP 版本升级 barebox 环境

+

在 BSP 版本 BSP-Yocto-AM335x-16.2.0 和 BSP-Yocto-i.MX6-PD16.1.0 之前，通过 bbappend 文件进行的 barebox 环境更改的机制和现在有所不同。例如，meta-layer（此处为 meta-skeleton ）中的目录结构可能如下所示

+
host:~$ tree -a sources/meta-skeleton/recipes-bsp/barebox/
+sources/meta-skeleton/recipes-bsp/barebox
+├── barebox
+│   └── phyboard-wega-am335x-3
+│       ├── boardenv
+│       │   └── .gitignore
+│       └── machineenv
+│           └── nv
+│               └── linux.bootargs.cma
+└── barebox_%.bbappend
+
+
+

并且文件 barebox_%.bbappend 包含

+
# file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:"
+
+
+

在这个示例中，将会忽略Layer meta-phytec 中目录 boardenv 下的所有环境变量更改，并添加文件 nv/linux.bootargs.cma 。而在 barebox 环境最新的处理机制下，您可以在 Python 任务 do_env 中使用 Python 函数 env_add 和 env_rm 来添加和删除环境。现在，上述示例被转换为文件 barebox_%.bbappend 中的一个单独的 Python 函数，如下所示。

+
# file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:"
+python do_env:append() {
+    # Removing files (previously boardenv)
+    env_rm(d, "config-expansions")
+    # Adding new files (previously machineenv)
+    env_add(d, "nv/linux.bootargs.cma", "cma=64M\n")
+}
+
+
+
+
+
+

8.6.16. 更改网络配置

+

要在系统运行时调整 IP 地址、路由和网关，可以使用工具 ifconfig 和 ip 。以下是一些示例

+
target:~$ ip addr                                         # Show all network interfaces
+target:~$ ip route                                        # Show all routes
+target:~$ ip addr add 192.168.178.11/24 dev eth0          # Add static ip and route to interface eth0
+target:~$ ip route add default via 192.168.178.1 dev eth0 # Add default gateway 192.168.178.1
+target:~$ ip addr del 192.168.178.11/24 dev eth0          # Remove static ip address from interface eth0
+
+
+

网络配置由 systemd-networkd 管理。要查询当前状态，请使用

+
target:~$ networkctl status
+target:~$ networkctl list
+
+
+

网络守护进程从目录 /etc/systemd/network/ 、 /run/systemd/network/ 和 /lib/systemd/network/ 读取配置（从高到低优先级）。 /lib/systemd/network/10-eth0.network 中的示例配置如下所示

+
# file /lib/systemd/network/10-eth0.network
+[Match]
+Name=eth0
+
+[Network]
+Address=192.168.3.11/24
+Gateway=192.168.3.10
+
+
+

这些文件 *.network 取代了其他发行版中的 /etc/network/interfaces。您可以直接编辑文件 10-eth0.network，或者将其复制到 /etc/systemd/network/ 并进行修改。修改文件后，您需要重启守护进程以使更改生效。

+
target:~$ systemctl restart systemd-networkd
+
+
+

要查看网络守护进程的系统日志消息，请使用

+
target:~$ journalctl --unit=systemd-networkd.service
+
+
+

要在编译时修改网络配置，请查看recipe sources/meta-ampliphy/recipes-core/systemd/systemd-machine-units.bb 和文件夹 meta-ampliphy/recipes-core/systemd/systemd-machine-units/ 中的接口文件，其中定义了 eth0 （以及可选的 eth1 ）的静态 IP 地址配置。

+

有关更多信息，请参阅https://wiki.archlinux.org/title/Systemd-networkd 和 https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html。

+
+
+

8.6.17. 更改无线网络配置

+
+

8.6.17.1. 连接至 WLAN 网络

+
    +

  • 请首先为您的国家或地区选择合适的网络地域。

    • +
+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

您会看到

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+
    +

  • 设置无线接口

    • +
+
target:~$ ip link    # list all interfaces. Search for wlan*
+target:~$ ip link set up dev wlan0
+
+
+
    +

  • 现在您可以扫描可用网络

    • +
+
target:~$ iw wlan0 scan | grep SSID
+
+
+

您可以使用支持 WEP、 WPA 和 WPA2 的跨平台身份认证客户端（称为 wpa_supplicant）来建立加密连接。

+
    +

  • 为此，请将网络凭据添加到文件 /etc/wpa_supplicant.conf

    • +
+
Confluence country=DE network={ ssid="<SSID>" proto=WPA2 psk="<KEY>" }
+
+
+
    +

  • 现在可以建立连接

    • +
+
target:~$ wpa_supplicant -Dnl80211 -c/etc/wpa_supplicant.conf -iwlan0 -B
+
+
+

这会有以下结果

+
ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

最后，您可以配置 DHCP 以获取 IP 地址（大多数 WLAN 接入点都支持此功能）。有关其他可能的 IP 配置，请参考 更改网络配置 部分。

+
    +

  • 首先，创建目录

    • +
+
target:~$ mkdir -p /etc/systemd/network/
+
+
+
    +

  • 然后在 /etc/systemd/network/10-wlan0.network 中添加以下配置片段

    • +
+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+
    +

  • 现在，重新启动网络守护程序以使配置生效

    • +
+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+

8.6.17.2. 创建 WLAN 接入点

+

本节提供基本的 WPA2 网络接入点 (AP) 的配置。

+

使用以下命令查找 WLAN 接口名称

+
target:~$ ip link
+
+
+

编辑 /etc/hostapd.conf 文件中的设置。这在很大程度上依赖于具体的应用场景。以下是一些示例。

+
# file /etc/hostapd.conf
+interface=wlan0
+driver=nl80211
+ieee80211d=1
+country_code=DE
+hw_mode=g
+ieee80211n=1
+ssid=Test-Wifi
+channel=2
+wpa=2
+wpa_passphrase=12345678
+wpa_key_mgmt=WPA-PSK
+wpa_pairwise=CCMP
+
+
+

通过 systemd-networkd 配置并启用网络接口 wlan0 的 DHCP 服务

+
target:~$ mkdir -p /etc/systemd/network/
+target:~$ vi /etc/systemd/network/10-wlan0.network
+
+
+

将以下文本插入到文件中

+
[Match]
+Name=wlan0
+
+[Network]
+Address=192.168.0.1/24
+DHCPServer=yes
+
+[DHCPServer]
+EmitDNS=yes
+target:~$ systemctl restart systemd-networkd
+target:~$ systemctl status  systemd-networkd -l   # check status and see errors
+
+
+

启动用户空间后台进程 hostapd

+
target:~$ systemctl start hostapd
+target:~$ systemctl status hostapd -l # check for errors
+
+
+

现在，您应该可以在终端设备（笔记本电脑、智能手机等）上看到 WLAN 网络 Test-Wifi。

+

如果接入点出现问题，您可以使用

+
target:~$ journalctl --unit=hostapd
+
+
+

或者从命令行以调试模式启动守护进程

+
target:~$ systemctl stop hostapd
+target:~$ hostapd -d /etc/hostapd.conf -P /var/run/hostapd.pid
+
+
+

您会看到

+
...
+wlan0: interface state UNINITIALIZED->ENABLED
+wlan0: AP-ENABLED
+
+
+

有关 AP 设置和用户空间守护进程 hostapd 的更多信息，请访问

+
https://wireless.wiki.kernel.org/en/users/documentation/hostapd
+https://w1.fi/hostapd/
+
+
+
+
+

8.6.17.3. phyCORE-i.MX 6UL/ULL 蓝牙

+

在使用 phyCORE-i.MX 6UL/ULL 的蓝牙功能时，需要特别谨慎。了解更多详情，请参考 L-844e.A5 i.MX 6UL/ULL BSP手册 - 蓝牙。

+
+
+
+

8.6.18. 添加 OpenCV 库和示例

+

OpenCV （开源计算机视觉 https://opencv.org/）是一个计算机视觉应用的开源库。

+

要安装库和示例，请编辑 Yocto 工程中的文件 conf/local.conf 并添加

+
# file conf/local.conf
+# Installing OpenCV libraries and examples
+LICENSE_FLAGS_ACCEPTED += "commercial_libav"
+LICENSE_FLAGS_ACCEPTED += "commercial_x264"
+IMAGE_INSTALL:append = " \
+    opencv \
+    opencv-samples \
+    libopencv-calib3d2.4 \
+    libopencv-contrib2.4 \
+    libopencv-core2.4 \
+    libopencv-flann2.4 \
+    libopencv-gpu2.4 \
+    libopencv-highgui2.4 \
+    libopencv-imgproc2.4 \
+    libopencv-legacy2.4 \
+    libopencv-ml2.4 \
+    libopencv-nonfree2.4 \
+    libopencv-objdetect2.4 \
+    libopencv-ocl2.4 \
+    libopencv-photo2.4 \
+    libopencv-stitching2.4 \
+    libopencv-superres2.4 \
+    libopencv-video2.4 \
+    libopencv-videostab2.4 \
+"
+
+
+

然后重编译镜像

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+

小技巧

+

大多数示例无法开箱即用，因为它们依赖于 GTK 图形库。此BSP 仅支持 Qt6 。

+
+
+
+

8.6.19. 使用 lightpd 安装最小的 PHP Web 运行环境

+

这个示例说明如何在目标镜像上添加 PHP 应用程序和 Web 服务。Lighttpd 可以通过 cgi 与 PHP 命令行工具一起使用。此解决方案仅占用 5.5 MiB 的磁盘空间。它已在 meta-ampliphy 中预先配置。只需调整yocto工程构建配置即可将其安装到镜像中。

+
# file conf/local.conf
+# install lighttpd with php cgi module
+IMAGE_INSTALL:append = " lighttpd"
+
+
+

启动镜像后，您会在 /www/pages 目录下找到示例网页内容。为了测试 php，您可以删除 index.html 并将其替换为 index.php 文件。

+
<html>
+  <head>
+    <title>PHP-Test</title>
+  </head>
+  <body>
+    <?php phpinfo(); ?>
+  </body>
+</html>
+
+
+

在您的主机上，您可以将浏览器指向主板的 IP（例如 192.168.3.11），然后 phpinfo 就会显示出来。

+
+
+
+

8.7. 常见任务

+
+

8.7.1. 调试用户空间应用程序

+

phytec-qt6demo-image 无需任何调整就可以进行交叉调试。您只需确保主机的 sysroot 与所使用的镜像相匹配。因此，您需要为该镜像创建一个编译工具链。

+
host:~$ bitbake -c populate_sdk phytec-qt6demo-image
+
+
+

此外，如果您希望对镜像中的所有程序和库具有完整的调试和回溯功能，您可以添加

+
DEBUG_BUILD = "1"
+
+
+

到 conf/local.conf。这在某些情况下并不是必需的。这样配置之后，编译器选项将从 FULL_OPTIMIZATION 切换到 DEBUG_OPTIMIZATION。查看 Poky 源代码以了解 DEBUG_OPTIMIZATION 的默认设置。

+

要开始交叉调试，请按照之前的说明安装 SDK，设置 SDK 环境，然后在同一个 shell 中启动 Qt Creator。如果您不使用 Qt Creator，可以在souce SDK环境脚本后直接运行 arm-<..>-gdb 调试器，该gdb调试器在source后会默认配置到您的PATH中。

+

如果您使用 Qt Creator，请查看随产品提供的相应文档（快速入门或应用程序指南），以获取有关如何设置工具链的信息。

+

使用调试器启动用户空间的应用程序时，您可能会遇到 SIGILL，这是来自 libcrypto 的非法指令。 Openssl 通过捕获这些非法指令来检测系统功能，这将导致 GDB 中断被触发。您可以选择忽略此操作并点击 继续 （命令c）。如果希望永久忽略此信号，可以添加

+
handle SIGILL nostop
+
+
+

到您的 GDB 启动脚本或 Qt Creator GDB 配置面板中。其次，您可以禁用安全功能，这通过添加

+
set auto-load safe-path /
+
+
+

到同一个启动脚本，它允许从任何位置自动加载库。

+

如果您想要进行本地调试，需要在目标设备上安装调试符号表。您可以通过在 conf/local.conf 中添加以下行来实现这一点。

+
EXTRA_IMAGE_FEATURES += "dbg-pkgs"
+
+
+

对于交叉调试，这并不是必需的，因为调试符号表会从PC侧加载，并且 dbg-pkgs 也会包含在镜像的 SDK 中。

+
+
+

8.7.2. 生成镜像源，开启离线构建

+

参照如下方式，修改您的 site.conf (如果您不使用 site.conf,请修改 local.conf )

+
#DL_DIR ?= "" don't set it! It will default to a directory inside /build
+SOURCE_MIRROR_URL = "file:///home/share/yocto_downloads/"
+INHERIT += "own-mirrors"
+BB_GENERATE_MIRROR_TARBALLS = "1"
+
+
+

现在运行

+
host:~$ bitbake --runall=fetch <image>
+
+
+

这适用于所有镜像及您希望提供镜像源的所有MACHINE。它将生成所需的所有 tar 文件。我们可以移除所有 SCM 子文件夹，因为它们是和 tar 文件重复的。

+
host:~$ rm -rf build/download/git2/
+etc...
+
+
+

请注意，我们使用本地镜像源来生成 dl_dir。这样，有一些文件是本地链接文件。

+

首先，我们需要将所有文件包括符号链接的源文件拷贝到新的镜像源目录中。

+
host:~$ rsync -vaL <dl_dir> ${TOPDIR}/../src_mirror/
+
+
+

Now we clean the /build directory by deleting everything except /build/conf/ +but including /build/conf/sanity. We change site.conf as follows

+
SOURCE_MIRROR_URL = "file://${TOPDIR}/../src_mirror"
+INHERIT += "own-mirrors"
+BB_NO_NETWORK = "1"
+SCONF_VERSION = "1"
+
+
+

BSP 目录现在可以使用以下方式压缩

+
host:~$ tar cfJ <filename>.tar.xz <folder>
+
+
+

其中文件名和文件夹应该以完整的 BSP 版本命名。

+
+
+

8.7.3. 在目标主机上进行编译

+

在您的 local.conf 中添加

+
IMAGE_FEATURES:append = " tools-sdk dev-pkgs"
+
+
+
+
+

8.7.4. 不同的工具链

+

在 Poky 中有多种方法可以创建工具链安装程序。一种方法是运行

+
host:~$ bitbake meta-toolchain
+
+
+

这将在 build/deploy/sdk 中生成一个工具链安装程序，可用于交叉编译目标应用。但是，这个安装程序不包含添加到您自定义镜像中的库，因此它只是一个单纯的 GCC 编译器。这适用于bootloader和kernel开发。

+

另一种方法是运行

+
host:~$ bitbake -c populate_sdk <your_image>
+
+
+

这将创建一个工具链安装程序，包含所有安装在目标根文件系统上的软件开发包。该安装程序涵盖开发应用程序所需的所有组件，可以被用户空间应用程序开发团队所使用。如果镜像中包含 QT 库，那么所有相关依赖库也将随安装程序提供。

+

第三个选项是创建 ADT（应用程序开发工具包）安装程序。它将包含交叉工具链和一些帮助软件开发人员的工具，例如 Eclipse 插件和 QEMU 系统模拟器。

+
host:~$ bitbake adt-installer
+
+
+

目前，我们的 BSP 尚未使用 ADT 进行测试。

+
+

8.7.4.1. 使用 SDK

+

使用以下方式生成 SDK 后

+
host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
+
+

使用以下方式运行生成的二进制文件

+
host:~$ deploy/sdk/ampliphy-glibc-x86_64-phytec-qt6demo-image-cortexa9hf-vfp-neon-toolchain-i.MX6-PD15.3-rc.sh
+Enter target directory for SDK (default: /opt/ampliphy/i.MX6-PD15.3-rc):
+You are about to install the SDK to "/opt/ampliphy/i.MX6-PD15.3-rc". Proceed[Y/n]?
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
+
+

您可以通过source 工具链目录中的 environment-setup 脚本来激活当前shell的工具链环境

+
host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+
+
+

然后，交叉编译器和链接器等必要工具就在您的 PATH 中了。要编译一个简单的 C 程序，请使用

+
host:~$ $CC main.c -o main
+
+
+

环境变量 $CC 包含 ARM 交叉编译器的路径和其他所需的编译器参数，如 -march、-sysroot 和 --mfloat-abi。

+
+

小技巧

+

您不能仅使用编译器名称来编译程序，例如

+
host:~$ arm-phytec-linux-gnueabi-gcc main.c -o main
+
+
+

在许多情况下它会导致编译失败。请使用 CC、CFLAGS、LDFLAGS 等。

+
+

为了方便起见， environment-setup 脚本会导出其他环境变量，如 CXX、LD、SDKTARGETSYSROOT。

+

编译 C 和 C++ 程序的一个简单的 makefile 可能如下所示

+
# Makefile
+TARGETS=c-program cpp-program
+
+all: $(TARGETS)
+
+c-program: c-program.c
+    $(CC) $(CFLAGS) $(LDFLAGS) $< -o $@
+
+cpp-program: cpp-program.cpp
+    $(CXX) $(CXXFLAGS) $(LDFLAGS) $< -o $@
+
+.PHONY: clean
+clean:
+    rm -f $(TARGETS)
+
+
+

要对目标进行编译，只需在执行 make 之前在当前 shell 中 source 工具链即可

+
host:~$ make     # Compiling with host CC, CXX for host architecture
+host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+host:~$ make     # Compiling with target CC, CXX for target architecture
+
+
+

如果您需要在工具链的 sysroot 中指定额外包含的目录，则可以在 -I 参数中使用“=”符号，例如

+
-I=/usr/include/SDL
+
+
+

GCC 会用工具链中的 sysroot 路径替换它（此处为 /opt/ampliphy/i.MX6-PD15.3-rc/sysroots/cortexa9hf-vfp-neon-phytec-linux-gnueabi/）。有关更多信息，请参阅 GCC 主页。

+
+

小技巧

+

变量 $CFLAGS 和 $CXXFLAGS 默认会包含编译器的调试标志“-g”。这会在二进制文件中加入调试信息，从而使文件变得更大。应该从正式生产的镜像中去除这个标志。如果您编写 Bitbake recipe，默认情况下也会启用“-g”。调试符号在 SDK 根文件系统 中是有用的，以便在主机调用 GDB 时获取调试信息。但是在将软件包安装到目标 根文件系统 之前， Bitbake 会在程序上执行 strip 命令，以去除调试符号。因为默认情况下，这些符号在目标根文件系统中是不需要的。

+
+
+
+

8.7.4.2. 将 SDK 与 GNU Autotools 结合使用

+

Yocto SDK 是 GNU Autotools 项目会用到的一个工具。传统的主机编译过程通常是

+
host:~$ ./autogen.sh # maybe not needed
+host:~$ ./configure
+host:~$ make
+host:~$ make install DESTDIR=$PWD/build/
+
+
+

用 Yocto SDK 对目标machine进行构建的命令也是非常相似的。以下命令假设 SDK 已解压到目录 /opt/phytec-ampliphy/i.MX6-PD15.3.0/ （可根据实际情况修改路径）

+
host:~$ source /opt/phytec-ampliphy/i.MX6-PD15.3.0/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+host:~$ ./autogen.sh  # maybe not needed
+host:~$ ./configure ${CONFIGURE_FLAGS}
+host:~$ make
+host:~$ make install DESTDIR=$PWD/build/
+
+
+

请参考官方 Yocto 文档以获取更多信息：https://docs.yoctoproject.org/4.2.4/singleindex.html#autotools-based-projects

+
+
+
+

8.7.5. 使用Kernel模块

+

如果您需要为内核模块配置一些选项，或者将一个模块加入黑名单。您可以通过 udev 进行，并写入 *.conf 文件中。

+
/etc/modprobe.d/\*.conf.
+
+
+

如果您希望在构建过程中指定kernel模块的一些选项，则有三个相关的变量。如果您仅想自动加载那些没有自动加载功能的模块，请将其添加到

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+
+
+

无论是在kernel recipe中还是涉及到全局变量。如果您需要为模块指定选项，您可以这样做

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+KERNEL_MODULE_PROBECONF += "your-module"
+module_conf_your-module = "options your-module parametername=parametervalue"
+
+
+

如果您想将某个模块列入自动加载黑名单，您可以直接使用

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+KERNEL_MODULE_PROBECONF += "your-module"
+module_conf_your-module = "blacklist your-module"
+
+
+
+
+

8.7.6. 使用 udev

+

Udev（Linux 动态设备管理）是一个系统守护进程，用于处理 /dev 中的动态设备管理。它由位于 /etc/udev/rules.d （系统管理员配置空间）和 /lib/udev/rules.d/ （供应商提供）中的 udev 规则控制。以下是 udev 规则文件的示例

+
# file /etc/udev/rules.d/touchscreen.rules
+# Create a symlink to any touchscreen input device
+SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="input:*-e0*,3,*a0,1,*18,*", SYMLINK+="input/touchscreen0"
+SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="ads7846", SYMLINK+="input/touchscreen0"
+
+
+

有关语法和用法的更详细信息，请访问 https://www.freedesktop.org/software/systemd/man/latest/udev.html。要获取可以在 udev 规则中使用的设备属性列表，您可以利用 udevadm info 工具。该工具将打印出设备节点及其父节点的所有现有属性。输出中的键值对可以直接复制并粘贴到规则文件中。以下是一些示例。

+
target:~$ udevadm info -a /dev/mmcblk0
+target:~$ udevadm info -a /dev/v4l-subdev25
+target:~$ udevadm info -a -p /sys/class/net/eth0
+
+
+

更改 udev 规则后，您必须通知udev守护进程。否则，您的更改不会生效。使用以下命令

+
target:~$ udevadm control --reload-rules
+
+
+

在制定 udev 规则时，您应该监视事件，以便查看设备何时连接到系统或从系统断开连接。使用

+
target:~$ udevadm monitor
+
+
+

在另一个 shell 中监控系统日志也是非常有帮助的，尤其是在udev规则中执行了外部脚本的情况下。执行

+
target:~$ journalctl -f
+
+
+
+

小技巧

+

您无法在 RUN 属性中启动守护进程或大型脚本。请参阅 https://www.freedesktop.org/software/systemd/man/latest/udev.html#RUN%7Btype%7D 。

+

这仅适用于执行时间非常短的前台任务。长时间运行的事件进程可能会阻碍此设备或从设备的后续所有事件。启动守护进程或其他长时间运行的进程并不适合 udev；派生进程（无论是否和母进程分离）都将在母进程事件处理完成后无条件被终止。如果需要执行其他任务，您可以考虑使用特殊属性 ENV {SYSTEMD_WANTS} ="service-name.service" 和 systemd 服务。

+

请参阅https://unix.stackexchange.com/questions/63232/what-is-the-correct-way-to-write-a-udev-rule-to-stop-a-service-under-systemd。

+
+
+
+
+
+

9. 故障排除

+
+

9.1. setscene任务告警

+

当 Yocto 缓存处于dirty状态时会出现此告警。

+
WARNING: Setscene task X ([...]) failed with exit code '1' - real task
+
+
+

但是请避免强制取消构建，或者如果必须取消，请按一次 Ctrl-C 并等待构建过程停止。要删除所有这些告警，请清除 sstate 缓存并删除build文件夹。

+
host:~$ bitbake phytec-headless-image -c cleansstate && rm -rf tmp deploy/ipk
+
+
+
+
+
+

10. Yocto 文档

+

对于 BSP 用户来说，最重要的文档可能是开发人员手册。https://docs.yoctoproject.org/4.2.4/dev-manual/index.html

+

关于常见任务的部分是一个很好的起始点。https://docs.yoctoproject.org/4.2.4/dev-manual/common-tasks.html#common-tasks

+

完整的文档可以在一个单独的 HTML 页面上找到，适合用户搜索功能或变量名称。https://docs.yoctoproject.org/4.2.4/singleindex.html

+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file diff --git a/previews/271/zh_CN/yocto/scarthgap.html b/previews/271/zh_CN/yocto/scarthgap.html new file mode 100644 index 000000000..65f8730ab --- /dev/null +++ b/previews/271/zh_CN/yocto/scarthgap.html @@ -0,0 +1,2327 @@ + + + + + + + + + 1. Yocto 项目 — PHYTEC BSP Documentation + + + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +

Documentation in pdf format: Download

+ + + + + + + + + + + + + + + + + + + +

Yocto Reference Manual

文档标题

Yocto Reference Manual Scarthgap

文档类型

Yocto手册

发布日期

XXXX/XX/XX

母文档

Yocto Reference Manual

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

适用BSP

BSP发布类型

BSP发布日期

BSP 状态

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.0

大版本

2024-04-02

已发布

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1

小更新

2024-04-09

已发布

BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2

小更新

2024-06-26

已发布

BSP-Yocto-NXP-i.MX8MP-PD24.1.0

大版本

2024-11-07

已发布

BSP-Yocto-NXP-i.MX93-PD24.2.0

大版本

2024-10-08

已发布

BSP-Yocto-Ampliphy-i.MX6UL-PD24.1.0

大版本

2024-07-19

已发布

BSP-Yocto-Ampliphy-AM62Ax-PD24.1.0

大版本

2024-06-27

已发布

BSP-Yocto-Ampliphy-AM62x-PD24.1.0

大版本

2024-06-27

已发布

BSP-Yocto-Ampliphy-AM64x-PD24.1.0

大版本

2024-06-27

已发布

+

本手册适用于所有基于 Scarthgap 的 PHYTEC BSP版本。

+
+

1. Yocto 项目

+
+

1.1. PHYTEC 文档

+

PHYTEC 将为旗下所有产品提供各种硬件和软件文档。包括以下任一以及全部内容：

+
    +

  • 快速上手指南：简单指导我们如何配置和启动 phyCORE 核心板，以及对构建 BSP、设备树和外设访问进行简要说明。

    • +

  • 硬件手册：核心板和配套底板的详细硬件描述。

    • +

  • Yocto 手册：phyCORE 使用的 Yocto 版本的综合指南。本指南包含: Yocto 概述；PHYTEC BSP 介绍、编译和定制化修改；如何使用 Poky 和 Bitbake 等编译框架。

    • +

  • BSP 手册：phyCORE 的 BSP 版本专用手册。可在此处找到如何编译BSP、启动、更新软件、设备树和外设等信息。

    • +

  • 开发环境指南：本指南介绍了如何使用 PHYTEC 虚拟机来搭建多样的开发环境。VM 中包含了 Eclipse 和 Qt Creator 的详细上手指导，还说明了如何将所编译出的demo程序放到phyCORE 核心板上运行。本指南同时也介绍了如何在本地Linux ubuntu上搭建完整的应用开发环境。

    • +

  • 引脚复用表：phyCORE 核心板附带一个引脚复用表（Excel 格式）。此表将显示从处理器到底板的信号连接以及默认的设备树复用选项。这为开发人员进行引脚复用和设计提供了必要的信息。

    • +
+

除了这些标准手册和指南之外，PHYTEC 还将提供产品变更通知、应用说明和技术说明。这些文档将根据具体案例进行针对性提供。大多数文档都可以在我们产品的下载页面中找到。

+
+
+

1.2. Yocto 介绍

+

Yocto 是最小的国际单位制前缀。就像milli是描述 10^-3 一样，yocto 是描述 10^-24 。Yocto 也是 Linux 基金会 支持的项目，因此得到了该领域几家主流公司的支持。在 Yocto 项目网站 上您可以阅读官方的介绍：

+
+

Yocto 项目是一个开源协作项目，它提供模板、工具和方法，为您的嵌入式产品创建基于 Linux 的自定义系统，同时不用过多的关注底层硬件架构。该项目由众多硬件制造商、开源操作系统供应商和电子公司合作开发，成立于2010年，旨在引导嵌入式 Linux系统开发走向标准化。

+
+

如前所述，该项目希望为嵌入式开发人员提供工具集。它建立在长期维护的 OpenEmbedded 项目之上。它不是一个Linux 发行版，但它包含创建定制化的Linux 发行版的所有工具。维护工具集的最重要步骤是定义一个通用的版本控制方案和一个参考系统。然后，所有子项目都必须兼容参考系统，并且遵守他的版本控制方案。

+

发布过程类似于 Linux kernel 的发布机制。Yocto 每六个月增加一次版本号，并为发布版本指定版本代号。发布列表可在此处找到：https://wiki.yoctoproject.org/wiki/Releases

+
+
+

1.3. 核心组件

+

Yocto 项目最重要的工具或子项目是：

+
    +

  • Bitbake：构建引擎，是一个类似 make 的任务调度程序，解析元数据

    • +

  • OpenEmbedded-Core，Yocto 核心Layer，包含软件元数据

    • +

  • Yocto kernel

    +
      +

    • 针对嵌入式设备进行了优化

      • +

    • 包括许多子项目：rt-kernel、供应商补丁

      • +

    • Wind River 提供的基础框架

      • +

    • Yocto kernel的替代方案：经典的内核编译方式→Phytec使用这种方式将我们的kernel集成到 Yocto

      • +
    +
    • +

  • Yocto 参考 BSP： beagleboneblack、 minnow max

    • +

  • Poky：Yocto参考系统，是项目和工具的集合，是创建基于 Yocto 的Linux发行版的基石

    • +
+
+
+

1.4. 词汇

+
+

1.4.1. Recipes

+

Recipe包含有关软件项目的信息（作者、主页和许可证）。Recipe 有版本控制，它定义了依赖项，包含源代码的 URL，并描述如何获取、配置和编译源代码。它也描述了如何打包软件，例如打包成不同的 .deb 包，安装到目标系统不同的路径。Recipe是用 Bitbake 自己的编程语言编写的，语法很简单。但是，Recipe 可以包含 Python 以及 bash 代码

+
+
+

1.4.2. 类

+

类将Recipe中的各个方法组合成可重复使用的代码块。

+
+
+

1.4.3. Layers

+

layer是Recipe、类和配置元数据的集合。Layer可以依赖于其他Layer, 它封装了特定的功能。每个Layer都属于一个特别的category：

+
    +

  • Base

    • +

  • Machine（BSP）

    • +

  • Software

    • +

  • Distribution

    • +

  • Miscellaneous

    • +
+

Yocto 的版本控制方案在每一个Layer中以版本分支的形式体现。对于每个 Yocto 版本，每个Layer在其 Git 仓库中都有一个对应分支。您可以在Yocto工程中添加一个或多个Layer。

+

可以在这里https://layers.openembedded.org/layerindex/branch/scarthgap/layers/找到 OpenEmbedded Layer的集合。搜索功能非常有用，可以轻松检索和集成软件包。

+
+
+

1.4.4. Machine

+

Machine是用来描述所使用的目标硬件(核心板/开发套件)的变量。

+
+
+

1.4.5. 发行版 (Distro)

+

发行版描述了软件配置以及一系列的软件特性。

+
+
+
+

1.5. Poky

+

Poky 是定义 Yocto 项目的参考系统。它将几个子项目组合成发行版：

+
    +

  • Bitbake

    • +

  • Toaster

    • +

  • OpenEmbedded Core

    • +

  • Yocto 文档

    • +

  • Yocto 参考 BSP

    • +
+
+

1.5.1. Bitbake

+

Bitbake 是任务调度器。它是一个Python脚本，解释用 Bitbake 自己的编程语言、 Python 或者 bash 代码编写的recipe。官方文档可在此处找到：https://docs.yoctoproject.org/bitbake/2.8/index.html

+
+
+

1.5.2. Toaster

+

Toaster 是 Bitbake 的用于启动和分析工程构建的Web 前端。它提供有关编译历史和所生成镜像的统计信息。在多个案例中，安装和维护 Toaster 实例是有益的。PHYTEC 未对 Poky 提供的 Toaster 作任何功能添加或删除。如果想了解更多，请参考官方文档：https://docs.yoctoproject.org/dev/toaster-manual/index.html

+
+
+
+

1.6. 官方文档

+

有关 Bitbake 和 Poky 的更多常见问题，请参阅手册：https://docs.yoctoproject.org/dev/singleindex.html

+
+
+
+

2. Linux主机开发环境

+

要编译 Yocto，您需要一台合适的 Linux 主机开发环境。支持的Linux发行版列表可在参考手册中找到：https://docs.yoctoproject.org/dev/ref-manual/system-requirements.html#supported-linux-distributions

+
+
+

3. PHYTEC BSP 介绍

+
+

3.1. BSP 框架

+

BSP 大致由三部分组成。BSP 包管理、BSP 元数据和 BSP 代码源。包管理包括 Repo 和 phyLinux，而元数据取决于 SOC，它描述了如何构建软件。BSP 内容源来自 PHYTEC 的 Git 仓库和外部源。

+
+

3.1.1. BSP 包管理

+

Yocto 是一个综合项目。通常情况下，这意味着会强制用户将他们的Yocto项目建立在几个外部仓库上。这些库需要以特定的方式进行管理。我们使用包含 XML 数据结构的清单文件来描述不同版本的 git 仓库。 Repo 工具和我们的 phyLinux 脚本用于管理清单文件并配置 BSP工程。

+
+

3.1.1.1. phyLinux

+

phyLinux 是 Repo 的包装器，用于下载和配置 BSP，提供“开箱即用”的体验。

+
+
+

3.1.1.2. Repo

+

Repo 是 Repo 工具集的包装器。phyLinux 脚本将把Repo安装在全局PATH中。当您首次运行 repo init -u <url>，它会从 Googles Git 服务器下载特定版本的 Repo 工具集到 .repo/repo 目录。下次运行 Repo 时， Repo 工具集相关的指令就可以直接被使用了。请注意，如果您不运行 Repo sync，不同构建目录中的 Repo 工具集版本可能会随着时间的推移而有所不同。此外，如果您要保存您的完整BSP工程信息，也需要保存完整的 .repo 文件夹。

+

Repo 需要一个 Git 仓库，该仓库信息是从Repo命令中解析得来。在 PHYTEC BSP 中，该仓库被称为 phy²octo。在此仓库中，有关软件 BSP 版本的所有信息都以XML形式的 Repo 清单存储。清单文件定义了 Git 服务器（称为“Remote”）的URL、 Git 仓库及其状态（称为“projects”）。 Git 仓库可以呈现不同的状态。这其中的状态变化涉及仓库的分支、标签或commit ID。这意味着仓库的状态不一定是唯一的，可以随时间而变化。这就是我们仅使用标签或commit ID 进行发布的原因。这样的话git工作目录的状态就是唯一的，不会改变。

+

BSP的清单文件与BSP版本号同名。它是 BSP 的唯一标识符。发布的BSP会按 SoC 平台排序。所选 SoC 将定义 phy²octo Git 仓库的分支，该分支将用于选择对应的清单文件。

+
+
+
+

3.1.2. BSP 元数据

+

我们在 BSP 中包含了几个第三方Layer，无需集成其他外部项目即可运行完整的 Linux 发行版。以下描述了所有使用的git仓库。

+
+

3.1.2.1. Poky

+

PHYTEC BSP 建立在 Poky 之上。每个Poky有对应的版本，在 Repo 清单中定义。Poky 包含对应版本的 Bitbake。OpenEmbedded Core 的Layer-“meta”是我们自定义 Linux 系统的基石。

+
+
+

3.1.2.2. meta-openembedded

+

OpenEmbedded 是一组Layer，包含有许多开源软件项目的元数据。我们的 BSP 提供了所有的 OpenEmbedded Layer，但并非所有Layer都已使能。我们的示例镜像包含了几个 OpenEmbedded Layer中的Recipe所生成的软件包。

+
+
+

3.1.2.3. meta-qt6

+

该Layer在 Poky 根文件系统的基础上集成了 Qt6 ，我们的BSP已经包含了该Layer。

+
+
+

3.1.2.4. meta-nodejs

+

这是用于添加最新版本 Node.js 的Layer。

+
+
+

3.1.2.5. meta-gstreamer1.0

+

这是用于添加最新版本 GStreamer 的Layer。

+
+
+

3.1.2.6. meta-rauc

+

这一Layer包含搭建 RAUC 系统更新服务所需的工具. 与其他系统更新机制的对比可以在这里找到：Yocto 系统更新工具.

+
+
+

3.1.2.7. meta-phytec

+

这一Layer包含我们所有 BSP 的所有machine和通用特性。它是 PHYTEC 的 Yocto BSP 适用于所有受支持的硬件（从 fido 开始），并且设计为与 Poky Layer相互独立。如果您想将 PHYTEC 的硬件集成到现有的 Yocto 项目中，只需要这两个Layer即可。其特点是：

+
    +

  • recipes-bsp/barebox/ 和 recipes-bsp/u-boot/ 中的Bootloader

    • +

  • recipes-kernel/linux/ 和 dynamic-layers/fsl-bsp-release/recipes-kernel/linux/ 中的kernel

    • +

  • conf/machine/ 中有许多machine

    • +

  • 适配 AM335x 和 i.MX 6 平台的 OpenGL ES/EGL 上层库

    • +

  • 适配 i.MX 6 平台的 OpenCL 库

    • +
+
+
+

3.1.2.8. meta-ampliphy

+

这是我们的发行版示例 layer。它扩展了 Poky 的基础配置，为您的特定开发场景提供了基础。当前功能包括：

+
    +

  • systemd 初始化系统

    • +

  • 镜像：用于非图形应用的 phytec-headless-image

    • +

  • 基于i.MX 6 平台 的相机、OpenCV 和 GStreamer 集成示例，包含在 phytec-vision-image 中

    • +

  • 集成RAUC：我们为 A/B 系统镜像更新提供了基础支持，该更新可在本地和远程进行

    • +
+
+
+

3.1.2.9. meta-qt6-phytec

+

这是我们用于集成 Qt6 和展示Qt6 demo的Layer。其特点是：

+
    +

  • 针对 PHYTEC AM335x、i.MX 6 和 RK3288 平台的 带有 eglfs 后台的 Qt6

    • +

  • 镜像：带有 Qt6 以及视频应用的 phytec-qt6demo-image

    • +

  • Qt6 示例程序演示如何使用 QML widgets 和 一个 Bitbake recipe在 Yocto 搭建 Qt6 项目并集成到 systemd 中。该示例程序可以在 sources/meta-qt6-phytec/recipes-qt/examples/phytec-qtdemo_git.bb 中找到

    • +
+
+
+

3.1.2.10. meta-virtualization

+
    +

  • 该Layer为构建Xen、KVM、Libvirt以及其他基于OpenEmbedded的虚拟化解决方案提供必要的支持。

    • +
+
+
+

3.1.2.11. meta-security

+
    +

  • 该Layer提供安全工具、Linux内核的强化工具以及实现安全机制的库。

    • +
+
+
+

3.1.2.12. meta-selinux

+
    +

  • 此Layer的目的是启用 SE Linux 支持。此Layer的大部分工作是在 bbappend 文件中完成的，用于在现有Recipe中启用 SE Linux 支持。

    • +
+
+
+

3.1.2.13. meta-browser

+
    +

  • 这是用于添加常用 Web 浏览器（Chromium、Firefox 等）的Layer。

    • +
+
+
+

3.1.2.14. meta-rust

+
    +

  • 包括 Rust 编译器和 Rust 的 Cargo 包管理器。

    • +
+
+
+

3.1.2.15. meta-timesys

+
    +

  • Timesys Layer用于 Vigiles Yocto CVE 监控、安全提醒和镜像清单的生成。

    • +
+
+
+

3.1.2.16. meta-freescale

+
    +

  • 该Layer为i.MX、Layerscape和QorIQ产品线提供支持。

    • +
+
+
+

3.1.2.17. meta-freescale-3rdparty

+
    +

  • 为来自不同供应商的主板提供支持。

    • +
+
+
+

3.1.2.18. meta-freescale-distro

+
    +

  • 该Layer为freescale的演示镜像提供支持，以便与 OpenEmbedded 和/或 Yocto Freescale 的 BSP Layer一起使用。

    • +
+
+
+

3.1.2.19. base layer（fsl-community-bsp-base）

+
    +

  • 该layer提供NXP的基础BSP文件。

    • +
+
+
+

3.1.2.20. meta-fsl-bsp-release

+
    +

  • 这是 i.MX Yocto 项目发行版的Layer。

    • +
+
+
+
+

3.1.3. BSP 代码源

+

当您首次开始使用 Bitbake 时，BSP Content会从不同的线上源提取。所有文件都将下载并拷贝到在 Yocto 中配置为``DL_DIR``的本地目录中。如果您想备份包含完整内容的 BSP，则也必须备份这些源文件。在 生成镜像源，开启离线构建 一章中会作出进一步解释

+
+
+
+

3.2. 编译配置

+

BSP 初始化一个编译文件夹，该文件夹将包含运行 Bitbake 命令所生成的所有文件。它也包含一个用于处理用户输入的 conf 文件夹。

+
    +

  • bblayers.conf 定义使能的元 layers，

    • +

  • local.conf 可以自定义Yocto工程的用户输入变量

    • +

  • site.conf 自定义与编译主机相关的输入变量

    • +
+

两个最顶层的用户输入变量是 DISTRO 和 MACHINE 。当您使用 phyLinux 的方式获取 BSP 时，它们会体现在BSP预先配置的 local.conf 文件中。

+

我们在 BSP 中使用“Ampliphy”作为软件发行版 DISTRO 。此DISTRO将被预先选定，并为您提供实现自定义软件发行版的起点。

+

MACHINE 定义支持特定核心板和底板的二进制镜像。请查看 machine.conf 文件或我们的网页以了解硬件的描述。

+
+
+
+

4. 预编译镜像

+

对于每个 BSP，我们都提供了预编译的目标镜像，可以从 PHYTEC FTP 服务器下载：https://download.phytec.de/Software/Linux/

+

这些镜像也可用于 BSP 测试，他们会在生产时烧写到产品中。您可以使用提供的 .wic 镜像创建 SD 卡启动盘。识别您的硬件Machine并使用 dd 将下载的镜像文件烧写到格式化的 SD 卡中。有关该命令的正确用法的信息，请参阅镜像部分。

+
+
+

5. BSP Workspace安装

+
+

5.1. 设置主机

+

您可以设置主机或使用我们的编译容器来进行 Yocto 工程构建。您需要有一个运行中的 Linux 发行版系统，它应该在一台性能和存储空间强大的机器上运行，因为Yocto需要进行大量编译。

+

如果您想使用编译容器，您只需要在主机上安装以下软件包

+
host:~$ sudo apt install wget git
+
+
+

之后继续下一步 Git 配置。关于如何使用 编译-container ，您可以在 本文档phyLinux 的 高级用法 之后章节找到。

+

如果您不想使用编译container， Yocto 需要在您主机上安装一些其他的软件包。对于 Ubuntu，您需要

+
host:~$ sudo apt install gawk wget git diffstat unzip texinfo \
+      gcc build-essential chrpath socat cpio python3 python3-pip \
+      python3-pexpect xz-utils debianutils iputils-ping python3-git \
+      python3-jinja2 libegl1-mesa libsdl1.2-dev \
+      python3-subunit mesa-common-dev zstd liblz4-tool file locales
+
+
+

对于其他发行版，您可以在 Yocto Quick Build 中找到信息：https://docs.yoctoproject.org/dev/brief-yoctoprojectqs/index.html

+
+
+

5.2. Git 配置

+

BSP 大量使用 Git。 Git 需要您提供一些信息来识别谁对文件进行了更改。如果您没有 ~/.gitconfig 这个文件，请创建一个包含以下内容的文件

+
[user]
+    name = <Your Name>
+    email = <Your Mail>
+[core]
+    editor = vim
+[merge]
+    tool = vimdiff
+[alias]
+    co = checkout
+    br = branch
+    ci = commit
+    st = status
+    unstage = reset HEAD --
+    last = log -1 HEAD
+[push]
+    default = current
+[color]
+    ui = auto
+
+
+

您应该在 Git 配置中设置 name 和 email，否则， Bitbake 会在第一次构建时报错。您可以使用这两个命令直接设置它们，而无需手动编辑 ~/.gitconfig

+
host:~$ git config --global user.email "your_email@example.com"
+host:~$ git config --global user.name "name surname"
+
+
+
+
+

5.3. site.conf 设置

+

在开始编译 Yocto 之前，建议进行初步配置。有两个配置最为重要：下载目录和缓存目录的配置。PHYTEC 强烈建议对这两个配置项进行配置，因为它将减少您后续编译的时间。

+

下载目录是 Yocto 存储从互联网获取的所有源文件/源代码的地方。它可以包含 tar.gz、 Git 镜像源等。建议将下载目录设置为编译主机上用户可以共享的目录。我们首先要给这个目录赋予777访问权限，因为如果要让不同用户共享此目录，则所有文件都需要具有组写入访问权限。这很可能与默认 umask 设置冲突。一种可能的解决方案是对此目录使用 ACL

+
host:~$ sudo apt-get install acl
+host:~$ sudo setfacl -R -d -m g::rwx <dl_dir>
+
+
+

如果您已经创建了下载目录，但是后续想要更改权限，可以使用

+
host:~$ sudo find /home/share/ -perm /u=r ! -perm /g=r -exec chmod g+r \{\} \;
+host:~$ sudo find /home/share/ -perm /u=w ! -perm /g=w -exec chmod g+w \{\} \;
+host:~$ sudo find /home/share/ -perm /u=x ! -perm /g=x -exec chmod g+x \{\} \;
+
+
+

缓存目录存储编译过程的所有阶段产物。 Poky 具有相当复杂的缓存架构。建议创建一个共享目录，这样所有构建都可以访问此缓存目录，这被称为共享状态缓存。

+

在大约有 50 GB 空闲空间的硬盘上创建这两个目录，并在``build/conf/local.conf``中分配两个变量

+
DL_DIR ?= "<your_directory>/yocto_downloads"
+SSTATE_DIR ?= "<your_directory>/yocto_sstate"
+
+
+

如果您想了解更多有关如何配置Yocto工程的信息，请参阅Yocto工程中的文档示例设置

+
sources/poky/meta-yocto/conf/local.conf.sample
+sources/poky/meta-yocto/conf/local.conf.sample.extended
+
+
+
+
+
+

6. phyLinux 文档

+

phyLinux 脚本是使用 Python 编写，用来管理 PHYTEC Yocto BSP 版本。它主要是帮助用户快速上手PHYTEC BSP。您无需与 Repo 或 Git 交互，只使用phyLinux可以获取所有 BSP 源文件

+

phyLinux 脚本只有一个依赖项，那就是它需要您在主机上安装 wget 工具。执行后它会将 Repo 工具 安装到您主机上的全局PATH (/usr/local/bin) 中。您也可以手动安装到其他位置。如果已经在 PATH 中找到 Repo，phyLinux 将自动检测到并使用它。 Repo 工具被用来管理 Yocto BSP 的众多 Git 仓库。

+
+

6.1. 获取 phyLinux

+

phyLinux 脚本可以在 PHYTEC 下载服务器上找到：https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux

+
+
+

6.2. 基本用法

+

对于 phyLinux 的基本用法，请输入

+
host:~$ ./phyLinux --help
+
+
+

这将导致

+
usage: phyLinux [-h] [-v] [--verbose] {init,info,clean} ...
+
+This Programs sets up an environment to work with The Yocto Project on Phytecs
+Development Kits. Use phyLinx <command> -h to display the help text for the
+available commands.
+
+positional arguments:
+  {init,info,clean}  commands
+    init             init the phytec bsp in the current directory
+    info             print info about the phytec bsp in the current directory
+    clean            Clean up the current working directory
+
+optional arguments:
+  -h, --help         show this help message and exit
+  -v, --version      show program's version number and exit
+  --verbose
+
+
+
+
+

6.3. 初始化

+

创建一个新的项目文件夹

+
host:~$ mkdir ~/yocto
+
+
+

调用 phyLinux 将使用系统上安装的默认Python版本。从 Ubuntu 20.04 开始，默认是 Python3。如果您想启动与 Python3 不兼容的 BSP，您需要在运行 phyLinux 之前将 Python2 设置为默认值（临时）

+
host:~$ ln -s \`which python2\` python && export PATH=`pwd`:$PATH
+
+
+

现在在新文件夹下运行 phyLinux

+
host:~$ ./phyLinux init
+
+
+

空的文件夹很重要，因为 phyLinux 将会清空该目录。在非空目录运行 phyLinux 会有以下 告警:

+
This current directory is not empty. It could lead to errors in the BSP configuration
+process if you continue from here. At the very least, you have to check your build directory
+for settings in bblayers.conf and local.conf, which will not be handled correctly in
+all cases. It is advisable to start from an empty directory of call:
+$ ./phyLinux clean
+Do you really want to continue from here?
+[yes/no]:
+
+
+

在第一次初始化时，phyLinux 脚本会要求您在 /usr/local/bin 目录中安装 Repo 工具。在执行 init 命令期间，您需要选择处理器平台 (SoC)、PHYTEC 的 BSP 版本号以及您正在使用的Machine

+
***************************************************
+* Please choose one of the available SoC Platforms:
+*
+*   1: am335x
+*   2: am57x
+*   3: am62ax
+*   4: am62x
+*   5: am64x
+*   6: am68x
+*   7: imx6
+*   8: imx6ul
+*   9: imx7
+*   10: imx8
+*   11: imx8m
+*   12: imx8mm
+*   13: imx8mp
+*   14: imx8x
+*   15: imx93
+*   16: nightly
+*   17: rk3288
+*   18: stm32mp13x
+*   19: stm32mp15x
+*   20: topic
+
+# Exemplary output for chosen imx8mp
+***************************************************
+* Please choose one of the available Releases:
+*
+*   1: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1-rc1
+*   2: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1-rc2
+*   3: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.0
+*   4: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.1
+*   5: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2-rc1
+*   6: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2
+*   7: BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.y
+*   8: BSP-Yocto-Ampliphy-i.MX8MP-master
+*   9: BSP-Yocto-FSL-i.MX8MP-ALPHA1
+*   10: BSP-Yocto-FSL-i.MX8MP-ALPHA2
+*   11: BSP-Yocto-FSL-i.MX8MP-PD21.1-rc1
+*   12: BSP-Yocto-FSL-i.MX8MP-PD21.1-rc2
+*   13: BSP-Yocto-FSL-i.MX8MP-PD21.1.0
+*   14: BSP-Yocto-FSL-i.MX8MP-PD21.1.1-rc1
+*   15: BSP-Yocto-FSL-i.MX8MP-PD21.1.1-rc2
+*   16: BSP-Yocto-FSL-i.MX8MP-PD21.1.1
+*   17: BSP-Yocto-FSL-i.MX8MP-PD21.1.2-rc1
+*   18: BSP-Yocto-FSL-i.MX8MP-PD21.1.2-rc2
+*   19: BSP-Yocto-FSL-i.MX8MP-PD21.1.2
+*   20: BSP-Yocto-FSL-i.MX8MP-PD21.1.3-rc1
+*   21: BSP-Yocto-FSL-i.MX8MP-PD21.1.3
+*   22: BSP-Yocto-NXP-i.MX8MP-PD22.1-rc1
+*   23: BSP-Yocto-NXP-i.MX8MP-PD22.1-rc2
+*   24: BSP-Yocto-NXP-i.MX8MP-PD22.1-rc3
+*   25: BSP-Yocto-NXP-i.MX8MP-PD22.1-rc4
+*   26: BSP-Yocto-NXP-i.MX8MP-PD22.1.0
+*   27: BSP-Yocto-NXP-i.MX8MP-PD22.1.1-rc1
+*   28: BSP-Yocto-NXP-i.MX8MP-PD22.1.1-rc2
+*   29: BSP-Yocto-NXP-i.MX8MP-PD22.1.1-rc3
+*   30: BSP-Yocto-NXP-i.MX8MP-PD22.1.1-rc4
+*   31: BSP-Yocto-NXP-i.MX8MP-PD22.1.1
+*   32: BSP-Yocto-NXP-i.MX8MP-PD22.1.2-rc1
+*   33: BSP-Yocto-NXP-i.MX8MP-PD22.1.2-rc2
+*   34: BSP-Yocto-NXP-i.MX8MP-PD22.1.2
+*   35: BSP-Yocto-NXP-i.MX8MP-PD22.1.y
+*   36: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc1
+*   37: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc2
+*   38: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc3
+*   39: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc4
+*   40: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc5
+*   41: BSP-Yocto-NXP-i.MX8MP-PD23.1-rc6
+*   42: BSP-Yocto-NXP-i.MX8MP-PD23.1.0
+*   43: BSP-Yocto-NXP-i.MX8MP-PD23.1.y
+*   44: BSP-Yocto-NXP-i.MX8MP-PD24.1-rc1
+*   45: BSP-Yocto-NXP-i.MX8MP-PD24.1-rc2
+*   46: BSP-Yocto-NXP-i.MX8MP-PD24.1-rc3
+*   47: BSP-Yocto-NXP-i.MX8MP-PD24.1.0
+*   48: BSP-Yocto-NXP-i.MX8MP-PD24.1.y
+
+# Exemplary output for chosen BSP-Yocto-NXP-i.MX8MP-PD24.1.0
+*********************************************************************
+* Please choose one of the available builds:
+*
+no:                 machine: description and article number
+                             distro: supported yocto distribution
+                             target: supported build target
+
+1: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM
+                             Pollux PL1552.2
+                             PB-03123-001.A3
+                             distro: ampliphy-vendor
+                             target: phytec-headless-image
+2: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM
+                             Pollux PL1552.2
+                             PB-03123-001.A3
+                             distro: ampliphy-vendor-rauc
+                             target: phytec-headless-bundle
+                             target: phytec-headless-image
+3: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM
+                             Pollux PL1552.2
+                             PB-03123-001.A3
+                             distro: ampliphy-vendor-xwayland
+                             target: -c populate_sdk phytec-qt6demo-image
+                             target: phytec-qt6demo-image
+                             target: phytec-vision-image
+4: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM
+                             Pollux PL1552.2
+                             PB-03123-001.A3
+                             distro: securiphy-vendor
+                             target: phytec-securiphy-bundle
+                             target: phytec-securiphy-image
+5: phyboard-pollux-imx8mp-3: PHYTEC phyBOARD-Pollux i.MX8M Plus 1-4GB RAM
+                             Pollux PL1552.2
+                             PB-03123-001.A3
+                             distro: securiphy-vendor-provisioning
+                             target: phytec-provisioning-image
+
+
+

如果您无法通过以上phyLinux选择器提供的信息识别您的所使用的硬件，请查看PHYTEC产品发票。配置完成后，您可以运行

+
host:~$ ./phyLinux info
+
+# Exemplary output
+**********************************************
+* The current BSP configuration is:
+*
+* SoC:  refs/heads/imx8mp
+* Release:  BSP-Yocto-NXP-i.MX8MP-PD24.1.0
+*
+**********************************************
+
+
+

查看当前BSP选择了哪款 SoC 和 BSP版本。如果您不想使用phyLinux提供的选择器，phyLinux 还支持多种命令行参数去设置Soc和BSP版本

+
host:~$ MACHINE=phyboard-pollux-imx8mp-3 ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.0
+
+
+

或者查看帮助命令以获取更多信息

+
host:~$ ./phyLinux  init --help
+
+usage: phyLinux init [-h] [--verbose] [--no-init] [-o REPOREPO] [-b REPOREPO_BRANCH] [-x XML] [-u URL] [-p PLATFORM] [-r RELEASE]
+
+options:
+  -h, --help          show this help message and exit
+  --verbose
+  --no-init           dont execute init after fetch
+  -o REPOREPO         Use repo tool from another url
+  -b REPOREPO_BRANCH  Checkout different branch of repo tool
+  -x XML              Use a local XML manifest
+  -u URL              Manifest git url
+  -p PLATFORM         Processor platform
+  -r RELEASE          Release version
+
+
+

执行 init 命令后，phyLinux 将打印一些重要说明以及后续构建步骤的信息。

+
+
+

6.4. 高级用法

+

phyLinux 可用于通过多种媒介传输软件状态。软件状态在 manifest.xml 有特定标识。您可以创建一个清单文件，将其发送到另一个地方，然后使用以下方式来恢复软件状态，得到目标软件版本

+
host:~$ ./phyLinux init -x manifest.xml
+
+
+

您还可以创建一个包含软件状态的 Git 仓库。该 Git 仓库需要有除了master以外的分支，因为我们保留了master分支用于其他用途。使用 phyLinux 检查软件状态

+
host:~$ ./phyLinux -u <url-of-your-git-repo>
+
+
+
+
+
+

7. 使用编译容器

+
+

警告

+

目前，无法在容器内运行 phyLinux 脚本。在主机上使用 phyLinux 脚本完成初始化后，您可以使用容器进行编译。如果您的机器上没有 phyLinux 脚本，请参阅 phyLinux 文档。

+
+

运行编译容器有多种实现方式。常用的是 docker 和 podman，但我们更喜欢 podman，因为它不需要 root 权限即可运行。

+
+

7.1. 安装

+

如何安装 podman：https://podman.io 如何安装 docker：https://docs.docker.com/engine/install/

+
+
+

7.2. 可用容器

+

目前我们基于 Ubuntu LTS 版本提供了4个不同版本的容器：https://hub.docker.com/u/phybuilder

+
    +

  • yocto-ubuntu-16.04

    • +

  • yocto-ubuntu-18.04

    • +

  • yocto-ubuntu-20.04

    • +

  • yocto-ubuntu-22.04

    • +
+

这些容器可以使用 podman 或 docker 运行。对于 Yocto Scarthgap 版本，容器“yocto-ubuntu-20.04”是首选。

+
+
+

7.3. 下载/拉取容器

+
host:~$ podman pull docker.io/phybuilder/yocto-ubuntu-20.04
+
+OR
+
+host:~$ docker pull docker.io/phybuilder/yocto-ubuntu-20.04
+
+
+

在末尾添加以冒号分隔的容器标签，您还可以拉取或运行带有特殊标签的容器。

+
+

podman pull docker.io/phybuilder/yocto-ubuntu-20.04:phy2

+
+

您可以在我们的 duckerhub 空间中找到所有可用的标签：

+ +

如果您尝试运行尚未拉取/下载的容器，它将被自动拉取/下载。

+

您可以使用以下命令查看所有已下载/拉取的容器：

+
$USERNAME@$HOSTNAME:~$ podman images
+REPOSITORY                               TAG         IMAGE ID      CREATED       SIZE
+docker.io/phybuilder/yocto-ubuntu-22.04  latest      d626178e448d  4 months ago  935 MB
+docker.io/phybuilder/yocto-ubuntu-22.04  phy2        d626178e448d  4 months ago  935 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  phy2        e29a88b7172a  4 months ago  900 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  latest      e29a88b7172a  4 months ago  900 MB
+docker.io/phybuilder/yocto-ubuntu-18.04  phy1        14c9c3e477d4  7 months ago  567 MB
+docker.io/phybuilder/yocto-ubuntu-18.04  latest      14c9c3e477d4  7 months ago  567 MB
+docker.io/phybuilder/yocto-ubuntu-16.04  phy1        28c73e13ab4f  7 months ago  599 MB
+docker.io/phybuilder/yocto-ubuntu-16.04  latest      28c73e13ab4f  7 months ago  599 MB
+docker.io/phybuilder/yocto-ubuntu-22.04  phy1        5a0ef4b41935  8 months ago  627 MB
+docker.io/phybuilder/yocto-ubuntu-20.04  phy1        b5a26a86c39f  8 months ago  680 MB
+
+
+
+
+

7.4. 运行容器

+

要运行并使用容器进行 Yocto 构建，首先进入您之前运行 phyLinux init 的文件夹。然后启动容器

+
host:~$ podman run --rm=true -v /home:/home --userns=keep-id --workdir=$PWD -it docker.io/phybuilder/yocto-ubuntu-20.04 bash
+
+
+
+

备注

+

要使用 docker 运行和使用容器，并不像使用 podman 那么简单，必须先定义和配置容器用户。此外，默认情况下docker不支持转发信任凭据，所以必须对信任凭据进行配置。

+
+

现在您的命令行看起来应该是这样的（其中 $USERNAME 是调用“podman run”的用户，并且每次启动容器时容器代码都会有所不同）

+
$USERNAME@6593e2c7b8f6:~$
+
+
+
+

警告

+

如果进入容器的用户名是“root”，您将无法运行 bitbake。请确保使用您自己的用户名运行容器。

+
+

现在您可以在容器中开始构建。要停止/关闭容器，只需调用

+
$USERNAME@6593e2c7b8f6:~$ exit
+
+
+
+
+
+

8. 使用 Poky 和 Bitbake

+
+

8.1. 开始构建

+

使用 phyLinux init 下载所有元数据后，您必须设置 shell 环境变量。每次打开新 shell 开始构建时都需要执行此操作。我们使用 Poky 默认提供的 shell 脚本。在项目的根目录输入

+
host:~$ source sources/poky/oe-init-build-env
+
+
+

source命令的缩写是一个 .

+
host:~$ . sources/poky/oe-init-build-env
+
+
+

shell 的当前工作目录会被改为 build/。在第一次构建之前，您应该查看主配置文件

+
host:~$ vim conf/local.conf
+
+
+

您当前构建的所有产物存储在这里。根据您使用的芯片平台，可能需要接受许可协议。例如，对于Freescale/NXP 的芯片平台，您需要接受 GPU 和 VPU 二进制许可协议。通过取消注释相应的行来接受许可协议

+
# Uncomment to accept NXP EULA # EULA can be found under
+../sources/meta-freescale/EULA ACCEPT_FSL_EULA = "1"
+
+
+

现在您可以构建第一个镜像了。我们建议从较小的非图形镜像 phytec-headless-image 开始，看看一切是否正常工作

+
host:~$ bitbake phytec-headless-image
+
+
+

在 Intel Core i7 上，首次编译大约需要 40 分钟。但是所有的后续构建都将复用之前的缓存，编译大约需要 3 分钟。

+
+
+

8.2. Images

+

如果一切顺利，可以在以下位置找到镜像

+
host:~$ cd deploy/images/<MACHINE>
+
+
+

测试镜像最简单的方法是将核心板配置为 SD 卡启动，并将构建所得镜像烧写到 SD 卡中

+
host:~$ sudo dd if=phytec-headless-image-<MACHINE>.wic of=/dev/<your_device> bs=1M conv=fsync
+
+
+

这里<your_device>可以是“sde”，具体取决于您的系统。选择硬盘驱动时要非常小心！选择错误的硬盘驱动可能会擦除您的硬盘！参数 conv=fsync 强制数据缓冲区在 dd 返回之前写入硬盘。

+

启动后，您可以使用串口或通过网口 ssh 登录。root账户没有密码。这是因为 conf/local.conf 中开启了调试模式。如果您取消注释该行

+
#EXTRA_IMAGE_FEATURES = "debug-tweaks"
+
+
+

调试模式（例如设置空的 root 密码）将不会生效。

+
+
+

8.3. 获取BSP长期维护版本之间的中间开发版本

+

您也可以访问 Yocto BSP 最新的开发中版本，这属于特殊版本，并不是正式的长期维护的版本。他们会在phyLinux的版本选项中以 PDXX.X.y 结尾

+
host:~$ ./phyLinux init -p imx8mp -r BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.y
+
+
+

这将初始化一个最新的BSP开发版本。

+
+
+

8.4. 检查您的编译配置

+

Poky 包含多个工具来检查您的Yocto工程。您可以查询Layer工具支持的指令

+
host:~$ bitbake-layers
+
+
+

例如，它可以用来查看特定Recipe在哪一个Layer被修改了

+
host:~$ bitbake-layers show-appends
+
+
+

在运行构建之前，您还可以启动 Toaster，以便能够使用 Toaster Web GUI 图形界面检查构建的详细信息

+
host:~$ source toaster start
+
+
+

但是您可能需要先安装一些依赖才能运行toaster

+
host:~$ pip3 install -r
+../sources/poky/bitbake/toaster-requirements.txt
+
+
+

然后，您可以将浏览器指向 http://0.0.0.0:8000/ 并继续使用 Bitbake。可以从此 Web 服务器监控和分析所有构建活动。如果您想了解有关 Toaster 的更多信息，请查看 https://docs.yoctoproject.org/dev/toaster-manual/index.html。要关闭 Toaster Web GUI，请执行

+
host:~$ source toaster stop
+
+
+
+
+

8.5. meta-phytec 和 meta-ampliphy 的特点

+
+

8.5.1. Buildinfo

+

Buildinfo 任务是我们Recipe中的一个函数，可打印从公共仓库获取源代码的过程。因此您不必亲自查看对应的Recipe，用 Buildinfo 即可查看过程说明（例如 barebox 包的说明），请执行

+
host:~$ bitbake barebox -c buildinfo
+
+
+

在您的 shell 中，会打印如下类似信息

+
(mini) HOWTO: Use a local git repository to build barebox:
+
+To get source code for this package and version (barebox-2022.02.0-phy1), execute
+
+$ mkdir -p ~/git
+$ cd ~/git
+$ git clone git://git.phytec.de/barebox barebox
+$ cd ~/git/barebox
+$ git checkout -b v2022.02.0-phy1-local-development 7fe12e65d770f7e657e683849681f339a996418b
+
+You now have two possible workflows for your changes:
+
+1. Work inside the git repository:
+Copy and paste the following snippet to your "local.conf":
+
+SRC_URI:pn-barebox = "git://${HOME}/git/barebox;branch=${BRANCH}"
+SRCREV:pn-barebox = "${AUTOREV}"
+BRANCH:pn-barebox = "v2022.02.0-phy1-local-development"
+
+After that you can recompile and deploy the package with
+
+$ bitbake barebox -c compile
+$ bitbake barebox -c deploy
+
+Note: You have to commit all your changes. Otherwise yocto doesn't pick them up!
+
+2. Work and compile from the local working directory
+To work and compile in an external source directory we provide the
+externalsrc.bbclass. To use it, copy and paste the following snippet to your
+"local.conf":
+
+INHERIT += "externalsrc"
+EXTERNALSRC:pn-barebox = "${HOME}/git/barebox"
+EXTERNALSRC_BUILD:pn-barebox = "${HOME}/git/barebox"
+
+Note: All the compiling is done in the EXTERNALSRC directory. Every time
+you build an Image, the package will be recompiled and build.
+
+NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded.
+NOTE: Writing buildhistory
+
+
+

正如您所见，控制台输出了清楚地说明了构建信息。

+
+

警告

+

使用 外部源 会破坏 Yocto 的许多内部依赖机制。在构建过程中，源目录下的更改并不能保证被自动抓取并合并到根文件系统或 SD 卡镜像中。您必须始终使用 --force。例如，在编译 barebox 并将其重新部署到 deploy/images/<machine> 时需要执行

+
host:~$ bitbake barebox -c compile --force
+host:~$ bitbake barebox -c deploy
+
+
+
+

要使用新内核或镜像更新 SD 卡镜像，首先强制编译它，然后强制重建根文件系统。使用

+
host:~$ bitbake phytec-qt6demo-image -c rootfs --force
+
+
+

请注意，Yocto构建系统不会对外部源文件目录进行修改。如果要将 Yocto Recipe携带的所有补丁应用到外部源目录，请运行以下指令

+
SRCTREECOVEREDTASKS="" BB_ENV_PASSTHROUGH_ADDITIONS="$BB_ENV_PASSTHROUGH_ADDITIONS SRCTREECOVEREDTASKS" bitbake <recipe> -c patch
+
+
+
+
+
+

8.6. 自定义BSP

+

为了帮助您开始使用 BSP，我们从 Yocto 官方文档中总结了一些基本任务。它描述了如何向镜像添加其他软件、更改kernel和Bootloader配置，以及应用kernel和Bootloader的补丁。

+

诸如添加软件之类的小修改是在文件 build/conf/local.conf 中完成的。在那里，您可以覆盖全局变量并对recipe进行小修改。

+

有两种方法可以进行重大更改：

+
    +

  1. 创建您自己的Layer并使用 bbappend 文件。

    2. +

  2. 将所有新增内容添加到 PHYTEC 的 Distro Layer meta-ampliphy。

    3. +
+

创建您自己的Layer部分描述了如何创建您自己的Layer。

+
+

8.6.1. 禁用 Qt 示例demo

+

默认情况下，BSP 映像 phytec-qt6demo-image 会在连接的显示器或监视器上启动 Qt6 示例应用程序。如果要停止示例并使用后台得 Linux framebuffer 控制台，请通过串口或网络 ssh 连接到目标并执行 shell 命令

+
target:~$ systemctl stop phytec-qtdemo.service
+
+
+

此命令暂时停止演示app。要重新启动，请重启主板或执行

+
target:~$ systemctl start phytec-qtdemo.service
+
+
+

您可以永久禁用该服务，这样它就不会在开机时自启动

+
target:~$ systemctl disable phytec-qtdemo.service
+
+
+
+

小技巧

+

最后一个命令仅禁用了服务，但是它不会立即停止。要查看当前服务状态，请执行

+
target:~$ systemctl status phytec-qtdemo.service
+
+
+
+

如果要默认禁用该服务，请编辑文件 build/conf/local.conf 并添加以下行

+
# file build/conf/local.conf
+SYSTEMD_AUTO_ENABLE:pn-phytec-qtdemo = "disable"
+
+
+

之后重新编译镜像

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

8.6.2. Framebuffer 控制台

+

在具有显示接口的核心板上，默认启用Framebuffer控制台。您可以连接 USB 键盘并登录。要将键盘布局从默认的英语更改为德语，请键入

+
target:~$ loadkeys /usr/share/keymaps/i386/qwertz/de-latin1.map.gz
+
+
+

如果要退出Framebuffer控制台，请运行

+
target:~$ echo 0 > sys/class/vtconsole/vtcon1/bind
+
+
+

要完全停用Framebuffer控制台，请禁用以下内核配置选项

+
Device Drivers->Graphics Support->Support for framebuffer devices->Framebuffer Console Support
+
+
+

更多信息请访问：https://www.kernel.org/doc/Documentation/fb/fbcon.txt

+
+
+

8.6.3. 预编译镜像中提供的工具

+
+

8.6.3.1. RAM 基准测试

+

RAM 和缓存性能测试的最佳方法是使用 pmbw （并行内存带宽基准测试/测量工具）。 Pmbw 运行多个汇编例程，这些例程都使用不同的访问模式来访问 SoC 的缓存和 RAM。在运行测试之前，请确保设备上有大约 2 MiB 的空间用于存储日志文件。我们还降低了基准测试的级别，以便于更积极地向内核请求资源。基准测试将花费几个小时。

+

要开始测试，请键入

+
target:~$ nice -n -2 pmbw
+
+
+

测试完成后，日志文件可以转换为 gnuplot 脚本，运行

+
target:~$ stats2gnuplot stats.txt > run1.gnuplot
+
+
+

现在您可以将日志文件传输到主机并安装任意版本的 gnuplot

+
host:~$ sudo apt-get install gnuplot host:~$ gnuplot run1.gnuplot
+
+
+

生成的 plots-<machine> .pdf 文件包含所有图表。要将单个图表渲染为 png 文件，您可以使用 Ghostscript

+
host:~$ sudo apt-get install ghostscript
+host:~$ gs -dNOPAUSE -dBATCH -sDEVICE=png16m -r150 -sOutputFile='page-%00d.png' plots-phyboard-wega-am335x-1.pdf
+
+
+
+
+
+

8.6.4. 为 BSP 镜像添加新的软件包

+

要向镜像添加其他软件，请查看 OpenEmbedded Layer索引：https://layers.openembedded.org/layerindex/branch/scarthgap/layers/

+

首先，从左上角的下拉列表中选择您拥有的 BSP 的 Yocto 版本，然后单击 Recipes。现在您可以搜索软件项目名称并找到它所在的Layer。在某些情况下，程序位于 meta-openembedded、 openembedded-core 或 Poky 中，这意味着Recipe已在您的Yocto工程中。本节介绍在这种情况下如何添加软件。如果软件包位于另一个Layer，请参阅下一部分。

+

您还可以搜索可用Recipe列表

+
host:~$ bitbake -s | grep <program name> # fill in program name, like in
+host:~$ bitbake -s | grep lsof
+
+
+

当程序的Recipe已在 Yocto 工程中时，您只需将他添加到文件 build/conf/local.conf 即可。向镜像添加其他软件的一般语法是

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " <package1> <package2>"
+
+
+

例如，这一行

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " ldd strace file lsof"
+
+
+

在目标镜像上安装一些辅助程序。

+
+

警告

+

程序包名称前的空格非常重要。

+
+

local.conf 中的配置项均适用于所有镜像。因此，新增的这些软件工具将被同时包含在 phytec-headless-image 和 phytec-qt6demo-image 镜像中。

+
+

8.6.4.1. 关于软件包和Recipe的说明

+

您正在将软件包添加到 IMAGE_INSTALL 变量中。这些不一定等同于Layer的Recipe名称。Recipe默认定义一个具有相同名称的软件包。但Recipe也可以将 PACKAGES 变量设置为其他名称，并能够生成具有任意名称的软件包。当您查找软件时，严格来说，都必须搜索软件包名称，而不是Recipe。在最坏的情况下，您必须查看所有 PACKAGES 变量。这会有点繁琐， Toaster 之类的工具可能对查找有所帮助。

+

如果您在文件夹 sources 提供的Layer中找不到您的软件，请参阅下一部分以将一个新的Layer包含到 Yocto 构建中。

+

参考资料：Yocto 开发 文档 - 自定义 Yocto 构建

+
+
+
+

8.6.5. 添加其他Layer

+

这是关于如何在您的 Yocto 构建中添加另一Layer并从中安装软件的详细上手指南。例如，我们将网络安全扫描器 nmap 包含在Layer meta-security 中。首先，您必须找到包含该软件的Layer。查看 OpenEmbedded MetaData 索引 并稍微思考一下。网络扫描器 nmap 位于 meta-security Layer。请参阅 layer.openembedded.org 上的 meta-security。要将其集成到 Yocto 构建中，您必须拉取git仓库，然后切换到正确的稳定分支。由于 BSP 是基于 Yocto Scarthgap 版本构建，因此您也应该尝试在Layer中使用 Scarthgap 分支。

+
host:~$ cd sources
+host:~$ git clone git://git.yoctoproject.org/meta-security
+host:~$ cd meta-security
+host:~$ git branch -r
+
+
+

所有可用的远程分支会被展示出来。通常应该有'sumo'、'warrior'、'zeus'、'dunfell'、'hardnkott'、'kirkstone'、'mickledore'、'master'...

+
host:~$ git checkout scarthgap
+
+
+

现在我们通过把以下代码添加到 build/conf/bblayers.conf 文件末尾的方式来将Layer包含到构建中

+
# file build/conf/bblayers.conf
+BBLAYERS += "${BSPDIR}/sources/meta-security"
+
+
+

然后，您可以通过执行以下代码来检查该Layer是否在构建配置中可用

+
host:~$ bitbake-layers show-layers
+
+
+

如果出现类似以下错误

+
ERROR: Layer 'security' depends on layer 'perl-layer', but this layer is not enabled in your configuration
+
+
+

如果您要添加的Layer（这里是 meta-security）依赖于另一个Layer，您需要先启用被依赖的Layer。例如，此处所需的依赖项是 meta-openembedded 中的Layer（在 PHYTEC BSP 中，它位于路径 sources/meta-openembedded/meta-perl/ 中）。要启用它，请将以下行添加到 build/conf/bblayers.conf

+
# file build/conf/bblayers.conf
+BBLAYERS += "${BSPDIR}/sources/meta-openembedded/meta-perl"
+
+
+

执行命令 bitbake-layers show-layers 应该会打印所有已启用Layer的列表，包括 meta-security 和 meta-perl。包含该Layer后，您可以按照之前的描述安装Layer中的软件包。最简单的方法是添加以下行（这里是包 nmap）

+
# file build/conf/local.conf
+IMAGE_INSTALL:append = " nmap"
+
+
+

到您的 build/conf/local.conf。不要添加后忘记重新构建镜像

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+
+

8.6.6. Create your own layer

+

创建Layer应该是自定义 BSP 的首要任务之一。您有两个选择。您可以复制并重命名 meta-ampliphy，也可以创建一个包含修改的新Layer。哪个选择更好取决于您的使用场景。 meta-ampliphy 是我们自定义 Linux 发行版的示例，该发行版也会在未来持续更新。如果您想从这些更新中受益，并且总体上对它的用户空间配置感到满意，那么在 Ampliphy 基础上创建自己的Layer可能是最佳解决方案。如果您需要重建用户空间架构并且只需要 PHYTEC 的基本硬件支持，最好复制 meta-ampliphy，给Layer重新命名并修改其内容以使其适应您的需求。您还可以查看 OpenEmbedded Layer索引以查找不同的发行版 Layer。如果您只需要将自己的应用程序添加到镜像中，请创建自己的Layer。

+

在下一章中，我们有一个名为“racer”的嵌入式项目，我们将使用我们的 Ampliphy Linux 发行版来集成它。首先，我们需要创建一个新的Layer。

+

Yocto 提供了一个脚本来实现Layer创建。如果您已经配置好 BSP 并且 shell 已准备就绪，请输入

+
host:~$ bitbake-layers create-layer meta-racer
+
+
+

目前来说，默认选项是可行的。将该Layer移动到source目录下

+
host:~$ mv meta-racer ../sources/
+
+
+

在此Layer创建一个 Git 仓库来跟踪您的更改

+
host:~$ cd ../sources/meta-racer
+host:~$ git init && git add . && git commit -s
+
+
+

现在您可以将该Layer直接添加到 build/conf/bblayers.conf

+
BBLAYERS += "${BSPDIR}/sources/meta-racer"
+
+
+

或者使用 Yocto 提供的脚本

+
host:~$ bitbake-layers add-layer meta-racer
+
+
+
+
+

8.6.7. kernel和Bootloader的Recipe和版本

+

首先，您需要知道目标Machine使用哪个kernel和对应的版本。PHYTEC 提供多个kernel recipe linux-mainline、 linux-ti 和 linux-imx。第一个为 PHYTEC 的 i.MX 6 和 AM335x SOM提供支持，他是基于 kernel.org 的 Linux kernel稳定版本。 Git 仓库 URL 为：

+
    +

  • linux-mainline：git://git.phytec.de/linux-mainline

    • +

  • linux-ti: git://git.phytec.de/linux-ti

    • +

  • linux-imx: git://git.phytec.de/linux-imx

    • +

  • barebox：git://git.phytec.de/barebox

    • +

  • u-boot-imx: git://git.phytec.de/u-boot-imx

    • +
+

要找出您最终所使用的kernel recipe，请执行以下命令

+
host:~$ bitbake virtual/kernel -e | grep "PREFERRED_PROVIDER_virtual/kernel"
+
+
+

该命令打印变量 PREFERRED_PROVIDER_virtual/kernel 的值。该变量在 Yocto 构建过程被用来选择要使用的kernel recipe。以下几行是您可能会看到的不同输出值

+
PREFERRED_PROVIDER_virtual/kernel="linux-mainline"
+PREFERRED_PROVIDER_virtual/kernel="linux-ti"
+PREFERRED_PROVIDER_virtual/kernel="linux-imx"
+
+
+

要查看使用的是哪个版本，请执行 bitbake -s。例如

+
host:~$ bitbake -s | egrep -e "linux-mainline|linux-ti|linux-imx|barebox|u-boot-imx"
+
+
+

参数 -s 打印所有相关Recipe和它的版本。输出左侧包含Recipe名称，右侧包含版本

+
barebox                      :2022.02.0-phy1-r7.0
+barebox-hosttools-native     :2022.02.0-phy1-r7.0
+barebox-targettools          :2022.02.0-phy1-r7.0
+linux-mainline               :5.15.102-phy1-r0.0
+
+
+

如您所见，recipe linux-mainline 的版本为 5.15.102-phy1。在 PHYTEC 的 linux-mainline Git 仓库中，您将找到相应的标签 v5.15.102-phy1。 barebox recipe的版本为 2022.02.0-phy1。在 i.MX8M* 模块上，输出将包含 linux-imx 和 u-boot-imx。

+
+
+

8.6.8. Kernel和Bootloader配置

+

PHYTEC 所使用的bootloader barebox 采用与 Linux kernel相同的编译系统。因此，本节中的所有指令均可用于配置kernel以及bootloader。要配置kernel或bootloader，请执行以下命令中的一条。

+
host:~$ bitbake -c menuconfig virtual/kernel  # Using the virtual provider name
+host:~$ bitbake -c menuconfig linux-ti        # Or use the recipe name directly
+host:~$ bitbake -c menuconfig linux-mainline  # Or use the recipe name directly (If you use an i.MX 6 or RK3288 Module)
+host:~$ bitbake -c menuconfig linux-imx       # Or use the recipe name directly (If you use an i.MX 8M*)
+host:~$ bitbake -c menuconfig barebox         # Or change the configuration of the bootloader
+host:~$ bitbake -c menuconfig u-boot-imx      # Or change the configuration of the bootloader (If you use an i.MX 8M*)
+
+
+

之后，您可以重新编译并部署kernel或bootloader

+
host:~$ bitbake virtual/kernel -c compile  # Or 'barebox' for the bootloader
+host:~$ bitbake virtual/kernel -c deploy   # Or 'barebox' for the bootloader
+
+
+

或者，您也可以使用以下命令重新进行完整的构建

+
host:~$ bitbake phytec-headless-image  # To update the kernel/bootloader, modules and the images
+
+
+

在最后一个命令中，您可以将镜像名称替换为您选择的镜像名称。新镜像和二进制文件位于 build/deploy/images/<machine> /.

+
+

警告

+

之前对kernel的配置并不是永久生效的。执行 bitbake virtual/kernel -c clean 可以清除所有内容。

+
+

要使更改在构建系统中永久生效，您需要将配置修改整合到Layer中。您有两种选择：

+
    +

  • 仅包含配置差异片段（新旧配置之间的最小 差异）

    • +

  • 修改后的完整配置（defconfig）。

    • +
+

使用配置片段可以使开发者对不同阶段所做的更改更加清晰。您可以选择启用或禁用这些配置，对不同条件下的配置作管理，这有助于更迅速地将更改的配置迁移到新的kernel版本。您还可以对配置片段进行分组，以在不同的特定场景下使用。生成的完整kernel配置将被放在目录 build/deploy/images/<machine> 中。如果您没有上述这些需求，选择维护完整的 defconfig 文件可能会更加简单。

+
+

8.6.8.1. 将配置片段添加到Recipe

+

以下步骤适用于kernel和bootloader。只需将命令中的recipe名称 linux-mainline 替换为 linux-ti，或者将bootloader替换为 barebox。如果您对这个命令作用还不熟悉，请从一个干净的Yocto工程重新开始。否则，配置的差异可能会导致错误。

+
host:~$ bitbake linux-mainline -c clean
+host:~$ bitbake linux-mainline -c menuconfig
+
+
+

在菜单中更改配置并生成配置片段

+
host:~$ bitbake linux-mainline -c diffconfig
+
+
+

他将会打印生成的配置片段文件路径

+
Config fragment has been dumped into:
+/home/<path>/build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg
+
+
+

所有的配置修改都记录在文件 fragment.cfg 中，该文件仅包含少量配置行。以下示例展示了如何创建 bbappend 文件，以及如何为配置片段添加所需的行。您只需根据特定Recipe调整目录和名称： linux-mainline、 linux-ti、linux-imx、u-boot-imx 或 barebox。

+
sources/<layer>/recipes-kernel/linux/linux-mainline_%.bbappend     # For the recipe linux-mainline
+sources/<layer>/recipes-kernel/linux/linux-ti_%.bbappend           # For the recipe linux-ti
+sources/<layer>/recipes-kernel/linux/linux-imx_%.bbappend          # For the recipe linux-imx
+sources/<layer>/recipes-bsp/barebox/barebox_%.bbappend             # For the recipe barebox
+sources/<layer>/recipes-bsp/u-boot/u-boot-imx_%.bbappend           # For the recipe u-boot-imx
+
+
+

将字符串 layer 替换为您自己创建的layer（如上所示）（例如 meta-racer），或者直接使用 meta-ampliphy。要使用 meta-ampliphy，首先，需要为配置片段创建目录并为其指定一个新名称（此处为 enable-r8169.cfg），然后将片段放到这个Layer中。

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features
+# copy the path from the output of *diffconfig*
+host:~$ cp /home/<path>/build/tmp/work/phyboard_mira_imx6_11-phytec-linux-gnueabi/linux-mainline/4.19.100-phy1-r0.0/fragment.cfg \
+    sources/meta-ampliphy/recipes-kernel/linux/features/enable-r8169.cfg
+
+
+

之后使用您喜欢的编辑器打开 bbappend 文件（在本例中为 sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend ）并添加以下几行

+
# contents of the file linux-mainline_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://enable-r8169.cfg \
+"
+
+
+
+

警告

+

不要忘记使用正确的 bbappend 文件名： linux-ti_%.bbappend 用于 linux-ti recipe， barebox_%.bbappend 用于文件夹 recipes-bsp/barebox/ 中的bootloader！

+
+

保存 bbappend 文件后，您需要重新编译镜像。 Yocto 会自动识别recipe的更改并生成新的镜像。

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+
+
+

8.6.8.2. 向Recipe添加一个完整配置 (defconfig)

+

这种方法与之前的方法相似，但不是添加一个片段，而是采用 defconfig。首先，在您想要使用的Layer中创建所需的文件夹，这可以是您自己的Layer，或者是 meta-ampliphy。

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-kernel/linux/features/ # For both linux-mainline and linux-ti
+host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features/ # Or for the bootloader
+
+
+

然后您需要创建一个合适的 defconfig 文件。使用 menuconfig 进行配置更改，然后将 defconfig 文件保存到Layer中。

+
host:~$ bitbake linux-mainline -c menuconfig # Or use recipe name linux-ti or barebox
+host:~$ bitbake linux-mainline -c savedefconfig # Create file 'defconfig.temp' in the work directory
+
+
+

这将打印defconfig的保存路径

+
Saving defconfig to ..../defconfig.temp
+
+
+

然后，按照前面的说明，将生成的完整配置文件复制到您的Layer中，重命名为 defconfig，并在 bbappend 文件中添加以下行（此处为 sources/meta-ampliphy/recipes-kernel/linux/linux-mainline_%.bbappend）。

+
# contents of the file linux-mainline_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://defconfig \
+"
+
+
+
+

小技巧

+

不要忘记使用正确的 bbappend 文件名： linux-ti_%.bbappend 用于 linux-ti recipe ， barebox_%.bbappend 用于文件夹 recipes-bsp/barebox/ 中的bootloader ！

+
+

这样，在重编镜像时，新的镜像将会包含所作的配置修改。

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+
+
+
+

8.6.9. 使用 devtool 修改Kernel或Bootloader

+

除了使用recipes中提供的标准kernel和bootloader外，您可以选择在yocto中用devtool直接修改源代码或单独下载我们的git仓库来构建您的自定义kernel 。 以下是两种修改方式的优劣对比

+ + + + + + + + + + + + +

优势

劣势

Yocto 官方文档的标准工作流程

重复的源文件包，造成了不必要的硬盘空间浪费。

工具链无需重新编译所有内容。

未能有效利用缓存，导致构建成本增加。

+

Devtool 是一套辅助工具，旨在提升 Yocto 用户的工作效率。它与 1.8 版本相兼容。只需配置好 shell 环境，您就可以使用它。 Devtool 的功能包括：

+
    +

  • 修改现有资源文件

    • +

  • 将其他软件项目纳入您的构建配置中

    • +

  • 编译软件并将修改后的软件部署到目标硬件中。

    • +
+

这里我们将利用 devtool 来修改kernel。我们以 linux-mainline 作为 AM335x kernel的实现示例。我们首先使用的命令是 devtool modify - x <recipe><directory>

+
host:~$ devtool modify -x linux-mainline linux-mainline
+
+
+

Devtool 将在 build/workspace 目录下创建一个layer ，您可以在这个Layer下查看 devtool 命令进行的所有更改。它将与recipe 相关的源代码下载到一个指定的文件夹中以及在workspace生成一个 bbappend 文件，其中的 SRC_URI 指向上述下载文件夹。使用 Bitbake 构建镜像时，将会使用此文件夹中的源代码。现在您可以对kernel进行修改。

+
host:~$ vim linux-mainline/arch/arm/boot/dts/am335x-phycore-som.dtsi
+      -> make a change
+host:~$ bitbake phytec-qt6demo-image
+
+
+

您的更改现在将被重新编译并添加到镜像中。如果您希望永久保存这些更改，建议您根据更改创建一个补丁，存储和备份该补丁。您可以进入 linux-mainline 目录并使用 Git 来创建补丁。有关如何创建补丁的详细信息，请参阅 使用“临时方法”修补Kernel 或Bootloader。

+

如果您想了解有关 devtool 的更多信息，请访问：

+

Yocto 开发 - Devtool 或 Devtool 快速指南

+
+
+

8.6.10. 使用“临时方法”修补Kernel 或Bootloader

+ + + + + + + + + + + + +

优势

劣势

无开销，无额外配置

Yocto 非常容易覆盖您所作的修改（所有内容都会丢失！！）。

工具链无需重新编译所有内容。

+

Yocto 允许在 Bitbake 配置和编译recipe之前，更改源代码。使用 Bitbake 的 devshell 命令跳转到recipe的源目录。这是 barebox recipe

+
host:~$ bitbake barebox -c devshell # or linux-mainline, linux-ti, linux-imx, u-boot-imx
+
+
+

执行命令后，将打开一个 shell 窗口。shell 的当前工作目录将更改为 tmp 文件夹中recipe的资源文件目录。在这里，您可以使用您最喜欢的编辑器（例如 vim、 emacs 或任何其他图形编辑器）来更改源代码。完成后，通过键入 exit 或按 CTRL-D 退出 devshell。

+

离开 devshell 后，您可以重新编译软件包

+
host:~$ bitbake barebox -c compile --force # or linux-mainline, linux-ti, linux-imx, u-boot-imx
+
+
+

参数“--force”很重要，因为 Yocto 无法识别源代码是否已被更改。

+
+

小技巧

+

您无法在 devshell 中执行 bitbake 命令。您必须先退出devshell模式。

+
+

如果构建失败，请再次执行 devshell 命令并修复。如果构建成功，则可以部署包并创建新的 SD 卡镜像

+
host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox.bin
+host:~$ bitbake phytec-headless-image # new WIC image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic
+
+
+
+

警告

+

如果您进行clean操作，比如 bitbake barebox -c clean，或者 Yocto 重新下载源码，您所做的所有更改将会丢失！！！

+

为了防止这种情况发生，您可以制作一个补丁并将其添加到 bbappend 文件中。这与配置修改章节中提到的工作流程相似。

+

如果您采用临时方法，让修改永久生效需要在 devshell 中生成补丁；如果您使用 devtool，则必须在 devtool 创建的子目录中生成补丁。

+
+
host:~$ bitbake barebox -c devshell            # Or linux-mainline, linux-ti
+host(devshell):~$ git status                   # Show changes files
+host(devshell):~$ git add <file>               # Add a special file to the staging area
+host(devshell):~$ git commit -m "important modification"   # Creates a commit with a not so useful commit message
+host(devshell):~$ git format-patch -1 -o ~/    # Creates a patch of the last commit and saves it in your home folder
+/home/<user>/0001-important-modification.patch  # Git prints the path of the written patch file
+host(devshell):~$ exit
+
+
+

创建补丁后，必须为其创建一个 bbappend 文件。三个不同recipe文件（linux-mainline、 linux-ti 和 barebox）的位置如下：

+
sources/<layer>/recipes-kernel/linux/linux-mainline_%.bbappend     # For the recipe linux-mainline
+sources/<layer>/recipes-kernel/linux/linux-ti_%.bbappend           # For the recipe linux-ti
+sources/<layer>/recipes-kernel/linux/linux-imx_%.bbappend        # For the recipe linux-imx
+sources/<layer>/recipes-bsp/barebox/barebox_%.bbappend             # For the recipe barebox
+sources/<layer>/recipes-bsp/u-boot/u-boot-imx_%.bbappend           # For the recipe u-boot-imx
+
+
+

以下示例适用于recipe barebox。但是必须根据您的实际情况调整补丁路径。首先，创建文件夹并将补丁移入其中。然后创建 bbappend 文件

+
host:~$ mkdir -p sources/meta-ampliphy/recipes-bsp/barebox/features   # Or use your own layer instead of *meta-ampliphy*
+host:~$ cp ~/0001-important-modification.patch sources/meta-ampliphy/recipes-bsp/barebox/features  # copy patch
+host:~$ touch sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend
+
+
+
+

小技巧

+

注意您当前的工作目录。您必须在BSP根目录中执行命令，而不是在 build 目录中！

+
+

之后，使用您最喜欢的编辑器将以下内容添加到 bbappend 文件中（此处为 sources/meta-ampliphy/recipes-bsp/barebox/barebox_%.bbappend）

+
# contents of the file barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://0001-important-modification.patch \
+"
+
+
+

保存文件并使用以下方法重新编译 barebox recipe

+
host:~$ bitbake barebox -c clean # Or linux-ti, linux-mainline, linux-imx, u-boot-imx
+host:~$ bitbake barebox
+
+
+

如果构建成功，您可以通过以下方法重新生成最终镜像。

+
host:~$ bitbake phytec-headless-image # Or another image name
+
+
+

更多资源：

+

Yocto 项目为软件开发人员提供了一些文档。请参考“Kernel开发手册”以获取有关Kernel配置的详细信息。请注意，并非所有 Yocto 手册中的内容都适用于 PHYTEC BSP，因为我们采用了传统的内核编译方法，而大部分文档会假设使用的是 Yocto 的内核编译方式。

+ +
+
+

8.6.11. 使用 local.conf 文件中的 SRC_URI 来配置Kernel 和Bootloader

+

在这里，我们提供了第三个选项来修改kernel和Bootloader 。您可以从外部拉取 linux-mainline、linux-ti 或 barebox Git 仓库。您将需要重写源代码URL（变量 SRC_URI），以指向您的本地仓库而不是远程仓库。

+ + + + + + + + + + + + + + + +

优势

劣势

所有更改均使用 Git 保存

build/tmp-glibc/work/ 中有许多工作目录<machine>/<package> /

重新编译之前必须提交所有更改

对于每次更改，工具链都会从头开始编译所有内容（可以使用 ccache 避免）

+

首先，您需要一个 Git 仓库 barebox 或kernel的本地副本。如果您还没有，请使用以下命令。

+
host:~$ mkdir ~/git
+host:~$ cd ~/git
+host:~$ git clone git://git.phytec.de/barebox
+host:~$ cd barebox
+host:~$ git checkout -b v2022.02.0-phy remotes/origin/v2022.02.0-phy
+
+
+

将以下代码片段添加到 build/conf/local.conf

+
# Use your own path to the git repository
+# NOTE: Branch name in variable "BRANCH_pn-barebox" should be the same as the
+# branch which is used in the repository folder. Otherwise your commits won't be recognized later.
+BRANCH:pn-barebox = "v2022.02.0-phy"
+SRC_URI:pn-barebox = "git:///${HOME}/git/barebox;branch=${BRANCH}"
+SRCREV:pn-barebox = "${AUTOREV}"
+
+
+

您需要在文件中正确设置git仓库分支名称。无论您是选择在 Git 仓库中创建自己的分支，还是使用默认的分支（这里是“v2015.02.0-phy”）。现在，您都可以用自己的源代码重新编译 barebox。

+
host:~$ bitbake barebox -c clean
+host:~$ bitbake barebox -c compile
+
+
+

由于源代码尚未被修改，因此构建应该能够成功。

+

您可以在 ~/git/barebox 或默认的 defconfig 中修改源代码（例如 ~/git/barebox/arch/arm/configs/imx_v7_defconfig）。一旦您完成了代码更改，您需要对 Yocto 进行本地提交。如果您不这样做， Yocto 将无法检测到您在git仓库中的源代码已被更改（例如 ~/git/barebox/）。

+
host:~$ git status  # show modified files
+host:~$ git diff    # show changed lines
+host:~$ git commit -a -m "dummy commit for yocto"   # This command is important!
+
+
+

本地提交后尝试编译。 Yocto 将自动注意到源代码已更改，并从头开始进行源代码获取和工程配置工作。

+
host:~$ bitbake barebox -c compile
+
+
+

如果构建失败，请返回源目录，修复问题并重新提交更改。如果构建成功，您可以获取 barebox，甚至创建一个新的 SD 卡镜像。.

+
host:~$ bitbake barebox -c deploy # new barebox in e.g. deploy/images/phyflex-imx6-2/barebox-phyflex-imx6-2.bin
+host:~$ bitbake phytec-headless-image # new sd-card image in e.g. deploy/images/phyflex-imx6-2/phytec-headless-image-phyflex-imx6-2.wic
+
+
+

如果您想进行其他更改，只需在git仓库中进行另一次提交并再次重新编译 barebox。

+
+
+

8.6.12. 使用“可持续方法”添加软件

+

现在您已经创建了自己的Layer，您有第二个方式可以将现有软件添加到目标镜像中。我们的标准镜像在 meta-ampliphy 中定义

+
meta-ampliphy/recipes-images/images/phytec-headless-image.bb
+
+
+

在您的layer中，可以使用 bbappend 修改recipe，无需改动源recipe文件

+
meta-racer/recipes-images/images/phytec-headless-image.bbappend
+
+
+

bbappend文件内容将与源recipe一起解析。因此，您可以轻松覆盖源recipe中设置的所有变量。如果我们想要包含一些其他软件，需要在bbapend中将其追加到 IMAGE_INSTALL 变量中

+
IMAGE_INSTALL:append = " rsync"
+
+
+
+
+

8.6.13. 将 Linux 固件添加到根文件系统

+

将额外的固件放入根文件系统的 /lib/firmware/ 目录是一项常见的需求。例如，WiFi适配器或PCIe网卡可能需要专有的固件。为了解决这个问题，我们可以在Layer中使用 bbappend 。首先要创建所需的文件夹，在文件夹中创建bbapend文件并拷贝固件到对应的文件夹中。

+
host:~$ cd meta-racer   # go into your layer
+host:~$ mkdir -p recipes-kernel/linux-firmware/linux-firmware/
+host:~$ touch recipes-kernel/linux-firmware/linux-firmware_%.bbappend
+host:~$ cp ~/example-firmware.bin recipes-kernel/linux-firmware/linux-firmware/    # adapt filename
+
+
+

然后将以下内容添加到 bbappend 文件中，用您的固件名替换每个出现的 example-firmware.bin。

+
# file recipes-kernel/linux-firmware/linux-firmware_%.bbappend
+
+FILESEXTRAPATHS:prepend := "${THISDIR}/linux-firmware:"
+SRC_URI += "file://example-firmware.bin"
+
+do_install:append () {
+        install -m 0644 ${WORKDIR}/example-firmware.bin ${D}/lib/firmware/example-firmware.bin
+}
+
+# NOTE: Use "=+" instead of "+=". Otherwise file is placed into the linux-firmware package.
+PACKAGES =+ "${PN}-example"
+FILES:${PN}-example = "/lib/firmware/example-firmware.bin"
+
+
+

现在尝试构建 linux-firmware recipe

+
host:~$ . sources/poky/oe-init-build-env
+host:~$ bitbake linux-firmware
+
+
+

这会生成一个新的软件包 deploy/ipk/all/linux-firmware-example。

+

最后一步，您必须将固件包安装到您的镜像中。您可以通过在 local.conf 或镜像recipe中添加对应的代码行来实现

+
# file local.conf or image recipe
+IMAGE_INSTALL += "linux-firmware-example"
+
+
+
+

警告

+

确保您已将包名 linux-firmware-example 调整为您在 linux-firmware_%.bbappend 中指定的名称。

+
+
+
+

8.6.14. 使用 bbappend 文件更改 u-boot 环境变量

+

所有 i.MX8M* 产品均使用 u-boot 作为bootloader。可以使用临时方法修改 u-boot 环境变量。对 u-boot-imx 来说，环境变量定义位于 include/configs/phycore_imx8m* 中与处理器名称对应的头文件。新的环境变量应添加在 CONFIG_EXTRA_ENV_SETTINGS 的末尾

+
#define CONFIG_EXTRA_ENV_SETTINGS \
+[...]
+PHYCORE_FITIMAGE_ENV_BOOTLOGIC \
+"newvariable=1\0"
+
+
+

提交修改并在您的layer中创建文件 u-boot-imx_%.bbappend <layer> /recipes-bsp/u-boot/u-boot-imx_%.bbappend

+
# contents of the file u-boot-imx_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/features:"
+SRC_URI:append = " \
+    file://0001-environment-addition.patch \
+"
+
+
+
+
+

8.6.15. 通过 bbappend 文件更改 barebox 环境变量

+

从 BSP-Yocto-AM335x-16.2.0 和 BSP-Yocto-i.MX6-PD16.1.0 开始， meta-phytec 中的 barebox 环境变量已经采用新的机制。现在可以通过 Python bitbake 任务 do_env 在 barebox 环境中添加、更改和删除文件。有两个 Python 函数可以更改环境。它们是：

+
    +

  • env_add(d, ***filename as string*, ***file content as string*): 添加新文件或覆盖现有文件

    • +

  • env_rm(d, ***filename as string*): 删除文件

    • +
+

自定义layer meta-racer 的第一个示例中用 bbappend 文件中展示了如何在 barebox 环境文件夹 /env/nv/ 中加入新的非易失性变量 linux.bootargs.fb。

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_add(d, "nv/linux.bootargs.fb", "imxdrm.legacyfb_depth=32\n")
+}
+
+
+

第二个示例显示如何替换网络配置文件 /env/network/eth0

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_add(d, "network/eth0",
+"""#!/bin/sh
+
+# ip setting (static/dhcp)
+ip=static
+global.dhcp.vendor_id=barebox-${global.hostname}
+
+# static setup used if ip=static
+ipaddr=192.168.178.5
+netmask=255.255.255.0
+gateway=192.168.178.1
+serverip=192.168.178.1
+""")
+}
+
+
+

在上述示例中， Python 的多行字符串语法 """ text """ 可以避免在 Python 代码中插入多个换行符 \n。 Python 函数 env_add 可以用于添加和替换环境文件。

+

下一个示例显示如何删除已添加的环境文件，例如 , /env/boot/mmc

+
# file meta-racer/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append() {
+    env_rm(d, "boot/mmc")
+}
+
+
+
+

8.6.15.1. 调试

+

如果您想查看在构建过程中添加的所有环境文件，您可以在 local.conf 中启用调试标志

+
# file local.conf
+ENV_VERBOSE = "1"
+
+
+

之后，您必须重新构建 barebox recipe才能看到调试输出

+
host:~$ bitbake barebox -c clean
+host:~$ bitbake barebox -c configure
+
+
+

最后一个命令的输出如下所示

+
[...]
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/allow_color' content "false"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.base' content "consoleblank=0"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.fb' content "imxdrm.legacyfb_depth=32"
+WARNING: barebox-2022.02.0-phy1-r7.0 do_env_write: File 'nv/linux.bootargs.rootfs' content "rootwait ro fsck.repair=yes"
+
+
+
+
+

8.6.15.2. 修改环境（依赖所使用的machine）

+

如果您只需将一些 barebox 环境设置应用于一台或多台设备，您可以利用 Bitbake 的machine覆盖语法。这个语法是，将machine名称或 SoC 名称（例如 mx6、 ti33x 或 rk3288）通过下划线附加到变量或任务上。

+
DEPENDS:remove:mx6 = "virtual/libgl" or
+python do_env_append_phyboard-mira-imx6-4().
+
+
+

下一个示例仅当 MACHINE 设置为 phyboard-mira-imx6-4 时才添加环境变量

+
# file meta-phytec/recipes-bsp/barebox/barebox_2022.02.0-phy1.bbappend
+python do_env:append:phyboard-mira-imx6-4() {
+    env_add(d, "nv/linux.bootargs.cma", "cma=64M\n")
+}
+
+
+

Bitbake 变量覆盖语法的更详细解释如下：https://docs.yoctoproject.org/bitbake/2.4/bitbake-user-manual/bitbake-user-manual-metadata.html#conditional-metadata

+
+
+

8.6.15.3. 在旧的 BSP 版本升级 barebox 环境

+

在 BSP 版本 BSP-Yocto-AM335x-16.2.0 和 BSP-Yocto-i.MX6-PD16.1.0 之前，通过 bbappend 文件进行的 barebox 环境更改的机制和现在有所不同。例如，meta-layer（此处为 meta-skeleton ）中的目录结构可能如下所示

+
host:~$ tree -a sources/meta-skeleton/recipes-bsp/barebox/
+sources/meta-skeleton/recipes-bsp/barebox
+├── barebox
+│   └── phyboard-wega-am335x-3
+│       ├── boardenv
+│       │   └── .gitignore
+│       └── machineenv
+│           └── nv
+│               └── linux.bootargs.cma
+└── barebox_%.bbappend
+
+
+

并且文件 barebox_%.bbappend 包含

+
# file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:"
+
+
+

在这个示例中，将会忽略Layer meta-phytec 中目录 boardenv 下的所有环境变量更改，并添加文件 nv/linux.bootargs.cma 。而在 barebox 环境最新的处理机制下，您可以在 Python 任务 do_env 中使用 Python 函数 env_add 和 env_rm 来添加和删除环境。现在，上述示例被转换为文件 barebox_%.bbappend 中的一个单独的 Python 函数，如下所示。

+
# file sources/meta-skeleton/recipes-bsp/barebox/barebox_%.bbappend
+FILESEXTRAPATHS:prepend := "${THISDIR}/barebox:"
+python do_env:append() {
+    # Removing files (previously boardenv)
+    env_rm(d, "config-expansions")
+    # Adding new files (previously machineenv)
+    env_add(d, "nv/linux.bootargs.cma", "cma=64M\n")
+}
+
+
+
+
+
+

8.6.16. 更改网络配置

+

要在系统运行时调整 IP 地址、路由和网关，可以使用工具 ifconfig 和 ip 。以下是一些示例

+
target:~$ ip addr                                         # Show all network interfaces
+target:~$ ip route                                        # Show all routes
+target:~$ ip addr add 192.168.178.11/24 dev eth0          # Add static ip and route to interface eth0
+target:~$ ip route add default via 192.168.178.1 dev eth0 # Add default gateway 192.168.178.1
+target:~$ ip addr del 192.168.178.11/24 dev eth0          # Remove static ip address from interface eth0
+
+
+

网络配置由 systemd-networkd 管理。要查询当前状态，请使用

+
target:~$ networkctl status
+target:~$ networkctl list
+
+
+

网络守护进程从目录 /etc/systemd/network/ 、 /run/systemd/network/ 和 /lib/systemd/network/ 读取配置（从高到低优先级）。 /lib/systemd/network/10-eth0.network 中的示例配置如下所示

+
# file /lib/systemd/network/10-eth0.network
+[Match]
+Name=eth0
+
+[Network]
+Address=192.168.3.11/24
+Gateway=192.168.3.10
+
+
+

这些文件 *.network 取代了其他发行版中的 /etc/network/interfaces。您可以直接编辑文件 10-eth0.network，或者将其复制到 /etc/systemd/network/ 并进行修改。修改文件后，您需要重启守护进程以使更改生效。

+
target:~$ systemctl restart systemd-networkd
+
+
+

要查看网络守护进程的系统日志消息，请使用

+
target:~$ journalctl --unit=systemd-networkd.service
+
+
+

要在编译时修改网络配置，请查看recipe sources/meta-ampliphy/recipes-core/systemd/systemd-machine-units.bb 和文件夹 meta-ampliphy/recipes-core/systemd/systemd-machine-units/ 中的接口文件，其中定义了 eth0 （以及可选的 eth1 ）的静态 IP 地址配置。

+

有关更多信息，请参阅https://wiki.archlinux.org/title/Systemd-networkd 和 https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html。

+
+
+

8.6.17. 更改无线网络配置

+
+

8.6.17.1. 连接至 WLAN 网络

+
    +

  • 请首先为您的国家或地区选择合适的网络地域。

    • +
+
target:~$ iw reg set DE
+target:~$ iw reg get
+
+
+

您会看到

+
country DE: DFS-ETSI
+   (2400 - 2483 @ 40), (N/A, 20), (N/A)
+   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
+   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
+   (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
+   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
+
+
+
    +

  • 设置无线接口

    • +
+
target:~$ ip link    # list all interfaces. Search for wlan*
+target:~$ ip link set up dev wlan0
+
+
+
    +

  • 现在您可以扫描可用网络

    • +
+
target:~$ iw wlan0 scan | grep SSID
+
+
+

您可以使用支持 WEP、 WPA 和 WPA2 的跨平台身份认证客户端（称为 wpa_supplicant）来建立加密连接。

+
    +

  • 为此，请将网络凭据添加到文件 /etc/wpa_supplicant.conf

    • +
+
Confluence country=DE network={ ssid="<SSID>" proto=WPA2 psk="<KEY>" }
+
+
+
    +

  • 现在可以建立连接

    • +
+
target:~$ wpa_supplicant -Dnl80211 -c/etc/wpa_supplicant.conf -iwlan0 -B
+
+
+

这会有以下结果

+
ENT-CONNECTED - Connection to 88:33:14:5d:db:b1 completed [id=0 id_str=]
+
+
+

最后，您可以配置 DHCP 以获取 IP 地址（大多数 WLAN 接入点都支持此功能）。有关其他可能的 IP 配置，请参考 更改网络配置 部分。

+
    +

  • 首先，创建目录

    • +
+
target:~$ mkdir -p /etc/systemd/network/
+
+
+
    +

  • 然后在 /etc/systemd/network/10-wlan0.network 中添加以下配置片段

    • +
+
# file /etc/systemd/network/10-wlan0.network
+[Match]
+Name=wlan0
+
+[Network]
+DHCP=yes
+
+
+
    +

  • 现在，重新启动网络守护程序以使配置生效

    • +
+
target:~$ systemctl restart systemd-networkd
+
+
+
+
+

8.6.17.2. 创建 WLAN 接入点

+

本节提供基本的 WPA2 网络接入点 (AP) 的配置。

+

使用以下命令查找 WLAN 接口名称

+
target:~$ ip link
+
+
+

编辑 /etc/hostapd.conf 文件中的设置。这在很大程度上依赖于具体的应用场景。以下是一些示例。

+
# file /etc/hostapd.conf
+interface=wlan0
+driver=nl80211
+ieee80211d=1
+country_code=DE
+hw_mode=g
+ieee80211n=1
+ssid=Test-Wifi
+channel=2
+wpa=2
+wpa_passphrase=12345678
+wpa_key_mgmt=WPA-PSK
+wpa_pairwise=CCMP
+
+
+

通过 systemd-networkd 配置并启用网络接口 wlan0 的 DHCP 服务

+
target:~$ mkdir -p /etc/systemd/network/
+target:~$ vi /etc/systemd/network/10-wlan0.network
+
+
+

将以下文本插入到文件中

+
[Match]
+Name=wlan0
+
+[Network]
+Address=192.168.0.1/24
+DHCPServer=yes
+
+[DHCPServer]
+EmitDNS=yes
+target:~$ systemctl restart systemd-networkd
+target:~$ systemctl status  systemd-networkd -l   # check status and see errors
+
+
+

启动用户空间后台进程 hostapd

+
target:~$ systemctl start hostapd
+target:~$ systemctl status hostapd -l # check for errors
+
+
+

现在，您应该可以在终端设备（笔记本电脑、智能手机等）上看到 WLAN 网络 Test-Wifi。

+

如果接入点出现问题，您可以使用

+
target:~$ journalctl --unit=hostapd
+
+
+

或者从命令行以调试模式启动守护进程

+
target:~$ systemctl stop hostapd
+target:~$ hostapd -d /etc/hostapd.conf -P /var/run/hostapd.pid
+
+
+

您会看到

+
...
+wlan0: interface state UNINITIALIZED->ENABLED
+wlan0: AP-ENABLED
+
+
+

有关 AP 设置和用户空间守护进程 hostapd 的更多信息，请访问

+
https://wireless.wiki.kernel.org/en/users/documentation/hostapd
+https://w1.fi/hostapd/
+
+
+
+
+

8.6.17.3. phyCORE-i.MX 6UL/ULL 蓝牙

+

在使用 phyCORE-i.MX 6UL/ULL 的蓝牙功能时，需要特别谨慎。了解更多详情，请参考 L-844e.A5 i.MX 6UL/ULL BSP手册 - 蓝牙。

+
+
+
+

8.6.18. 添加 OpenCV 库和示例

+

OpenCV （开源计算机视觉 https://opencv.org/）是一个计算机视觉应用的开源库。

+

要安装库和示例，请编辑 Yocto 工程中的文件 conf/local.conf 并添加

+
# file conf/local.conf
+# Installing OpenCV libraries and examples
+LICENSE_FLAGS_ACCEPTED += "commercial_libav"
+LICENSE_FLAGS_ACCEPTED += "commercial_x264"
+IMAGE_INSTALL:append = " \
+    opencv \
+    opencv-samples \
+    libopencv-calib3d2.4 \
+    libopencv-contrib2.4 \
+    libopencv-core2.4 \
+    libopencv-flann2.4 \
+    libopencv-gpu2.4 \
+    libopencv-highgui2.4 \
+    libopencv-imgproc2.4 \
+    libopencv-legacy2.4 \
+    libopencv-ml2.4 \
+    libopencv-nonfree2.4 \
+    libopencv-objdetect2.4 \
+    libopencv-ocl2.4 \
+    libopencv-photo2.4 \
+    libopencv-stitching2.4 \
+    libopencv-superres2.4 \
+    libopencv-video2.4 \
+    libopencv-videostab2.4 \
+"
+
+
+

然后重编译镜像

+
host:~$ bitbake phytec-qt6demo-image
+
+
+
+

小技巧

+

大多数示例无法开箱即用，因为它们依赖于 GTK 图形库。此BSP 仅支持 Qt6 。

+
+
+
+

8.6.19. 使用 lightpd 安装最小的 PHP Web 运行环境

+

这个示例说明如何在目标镜像上添加 PHP 应用程序和 Web 服务。Lighttpd 可以通过 cgi 与 PHP 命令行工具一起使用。此解决方案仅占用 5.5 MiB 的磁盘空间。它已在 meta-ampliphy 中预先配置。只需调整yocto工程构建配置即可将其安装到镜像中。

+
# file conf/local.conf
+# install lighttpd with php cgi module
+IMAGE_INSTALL:append = " lighttpd"
+
+
+

启动镜像后，您会在 /www/pages 目录下找到示例网页内容。为了测试 php，您可以删除 index.html 并将其替换为 index.php 文件。

+
<html>
+  <head>
+    <title>PHP-Test</title>
+  </head>
+  <body>
+    <?php phpinfo(); ?>
+  </body>
+</html>
+
+
+

在您的主机上，您可以将浏览器指向主板的 IP（例如 192.168.3.11），然后 phpinfo 就会显示出来。

+
+
+
+

8.7. 常见任务

+
+

8.7.1. 调试用户空间应用程序

+

phytec-qt6demo-image 无需任何调整就可以进行交叉调试。您只需确保主机的 sysroot 与所使用的镜像相匹配。因此，您需要为该镜像创建一个编译工具链。

+
host:~$ bitbake -c populate_sdk phytec-qt6demo-image
+
+
+

此外，如果您希望对镜像中的所有程序和库具有完整的调试和回溯功能，您可以添加

+
DEBUG_BUILD = "1"
+
+
+

到 conf/local.conf。这在某些情况下并不是必需的。这样配置之后，编译器选项将从 FULL_OPTIMIZATION 切换到 DEBUG_OPTIMIZATION。查看 Poky 源代码以了解 DEBUG_OPTIMIZATION 的默认设置。

+

要开始交叉调试，请按照之前的说明安装 SDK，设置 SDK 环境，然后在同一个 shell 中启动 Qt Creator。如果您不使用 Qt Creator，可以在souce SDK环境脚本后直接运行 arm-<..>-gdb 调试器，该gdb调试器在source后会默认配置到您的PATH中。

+

如果您使用 Qt Creator，请查看随产品提供的相应文档（快速入门或应用程序指南），以获取有关如何设置工具链的信息。

+

使用调试器启动用户空间的应用程序时，您可能会遇到 SIGILL，这是来自 libcrypto 的非法指令。 Openssl 通过捕获这些非法指令来检测系统功能，这将导致 GDB 中断被触发。您可以选择忽略此操作并点击 继续 （命令c）。如果希望永久忽略此信号，可以添加

+
handle SIGILL nostop
+
+
+

到您的 GDB 启动脚本或 Qt Creator GDB 配置面板中。其次，您可以禁用安全功能，这通过添加

+
set auto-load safe-path /
+
+
+

到同一个启动脚本，它允许从任何位置自动加载库。

+

如果您想要进行本地调试，需要在目标设备上安装调试符号表。您可以通过在 conf/local.conf 中添加以下行来实现这一点。

+
EXTRA_IMAGE_FEATURES += "dbg-pkgs"
+
+
+

对于交叉调试，这并不是必需的，因为调试符号表会从PC侧加载，并且 dbg-pkgs 也会包含在镜像的 SDK 中。

+
+
+

8.7.2. 生成镜像源，开启离线构建

+

参照如下方式，修改您的 site.conf (如果您不使用 site.conf,请修改 local.conf )

+
#DL_DIR ?= "" don't set it! It will default to a directory inside /build
+SOURCE_MIRROR_URL = "file:///home/share/yocto_downloads/"
+INHERIT += "own-mirrors"
+BB_GENERATE_MIRROR_TARBALLS = "1"
+
+
+

现在运行

+
host:~$ bitbake --runall=fetch <image>
+
+
+

这适用于所有镜像及您希望提供镜像源的所有MACHINE。它将生成所需的所有 tar 文件。我们可以移除所有 SCM 子文件夹，因为它们是和 tar 文件重复的。

+
host:~$ rm -rf build/download/git2/
+etc...
+
+
+

请注意，我们使用本地镜像源来生成 dl_dir。这样，有一些文件是本地链接文件。

+

首先，我们需要将所有文件包括符号链接的源文件拷贝到新的镜像源目录中。

+
host:~$ rsync -vaL <dl_dir> ${TOPDIR}/../src_mirror/
+
+
+

Now we clean the /build directory by deleting everything except /build/conf/ +but including /build/conf/sanity. We change site.conf as follows

+
SOURCE_MIRROR_URL = "file://${TOPDIR}/../src_mirror"
+INHERIT += "own-mirrors"
+BB_NO_NETWORK = "1"
+SCONF_VERSION = "1"
+
+
+

BSP 目录现在可以使用以下方式压缩

+
host:~$ tar cfJ <filename>.tar.xz <folder>
+
+
+

其中文件名和文件夹应该以完整的 BSP 版本命名。

+
+
+

8.7.3. 在目标主机上进行编译

+

在您的 local.conf 中添加

+
IMAGE_FEATURES:append = " tools-sdk dev-pkgs"
+
+
+
+
+

8.7.4. 不同的工具链

+

在 Poky 中有多种方法可以创建工具链安装程序。一种方法是运行

+
host:~$ bitbake meta-toolchain
+
+
+

这将在 build/deploy/sdk 中生成一个工具链安装程序，可用于交叉编译目标应用。但是，这个安装程序不包含添加到您自定义镜像中的库，因此它只是一个单纯的 GCC 编译器。这适用于bootloader和kernel开发。

+

另一种方法是运行

+
host:~$ bitbake -c populate_sdk <your_image>
+
+
+

这将创建一个工具链安装程序，包含所有安装在目标根文件系统上的软件开发包。该安装程序涵盖开发应用程序所需的所有组件，可以被用户空间应用程序开发团队所使用。如果镜像中包含 QT 库，那么所有相关依赖库也将随安装程序提供。

+

第三个选项是创建 ADT（应用程序开发工具包）安装程序。它将包含交叉工具链和一些帮助软件开发人员的工具，例如 Eclipse 插件和 QEMU 系统模拟器。

+
host:~$ bitbake adt-installer
+
+
+

目前，我们的 BSP 尚未使用 ADT 进行测试。

+
+

8.7.4.1. 使用 SDK

+

使用以下方式生成 SDK 后

+
host:~$ source sources/poky/oe-init-build-env
+host:~$ bitbake -c populate_sdk phytec-qt6demo-image # or another image
+
+
+

使用以下方式运行生成的二进制文件

+
host:~$ deploy/sdk/ampliphy-glibc-x86_64-phytec-qt6demo-image-cortexa9hf-vfp-neon-toolchain-i.MX6-PD15.3-rc.sh
+Enter target directory for SDK (default: /opt/ampliphy/i.MX6-PD15.3-rc):
+You are about to install the SDK to "/opt/ampliphy/i.MX6-PD15.3-rc". Proceed[Y/n]?
+Extracting SDK...done
+Setting it up...done
+SDK has been successfully set up and is ready to be used.
+
+
+

您可以通过source 工具链目录中的 environment-setup 脚本来激活当前shell的工具链环境

+
host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+
+
+
+

备注

+

在可以用SDK和Meson编译系统编译Qt6应用之前，需要在source SDK 后做以下步骤：

+
host:~$ export PATH=$OECORE_NATIVE_SYSROOT/usr/libexec:$PATH
+
+
+
+

然后，交叉编译器和链接器等必要工具就在您的 PATH 中了。要编译一个简单的 C 程序，请使用

+
host:~$ $CC main.c -o main
+
+
+

环境变量 $CC 包含 ARM 交叉编译器的路径和其他所需的编译器参数，如 -march、-sysroot 和 --mfloat-abi。

+
+

小技巧

+

您不能仅使用编译器名称来编译程序，例如

+
host:~$ arm-phytec-linux-gnueabi-gcc main.c -o main
+
+
+

在许多情况下它会导致编译失败。请使用 CC、CFLAGS、LDFLAGS 等。

+
+

为了方便起见， environment-setup 脚本会导出其他环境变量，如 CXX、LD、SDKTARGETSYSROOT。

+

编译 C 和 C++ 程序的一个简单的 makefile 可能如下所示

+
# Makefile
+TARGETS=c-program cpp-program
+
+all: $(TARGETS)
+
+c-program: c-program.c
+    $(CC) $(CFLAGS) $(LDFLAGS) $< -o $@
+
+cpp-program: cpp-program.cpp
+    $(CXX) $(CXXFLAGS) $(LDFLAGS) $< -o $@
+
+.PHONY: clean
+clean:
+    rm -f $(TARGETS)
+
+
+

要对目标进行编译，只需在执行 make 之前在当前 shell 中 source 工具链即可

+
host:~$ make     # Compiling with host CC, CXX for host architecture
+host:~$ source /opt/ampliphy/i.MX6-PD15.3-rc/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+host:~$ make     # Compiling with target CC, CXX for target architecture
+
+
+

如果您需要在工具链的 sysroot 中指定额外包含的目录，则可以在 -I 参数中使用“=”符号，例如

+
-I=/usr/include/SDL
+
+
+

GCC 会用工具链中的 sysroot 路径替换它（此处为 /opt/ampliphy/i.MX6-PD15.3-rc/sysroots/cortexa9hf-vfp-neon-phytec-linux-gnueabi/）。有关更多信息，请参阅 GCC 主页。

+
+

小技巧

+

变量 $CFLAGS 和 $CXXFLAGS 默认会包含编译器的调试标志“-g”。这会在二进制文件中加入调试信息，从而使文件变得更大。应该从正式生产的镜像中去除这个标志。如果您编写 Bitbake recipe，默认情况下也会启用“-g”。调试符号在 SDK 根文件系统 中是有用的，以便在主机调用 GDB 时获取调试信息。但是在将软件包安装到目标 根文件系统 之前， Bitbake 会在程序上执行 strip 命令，以去除调试符号。因为默认情况下，这些符号在目标根文件系统中是不需要的。

+
+
+
+

8.7.4.2. 将 SDK 与 GNU Autotools 结合使用

+

Yocto SDK 是 GNU Autotools 项目会用到的一个工具。传统的主机编译过程通常是

+
host:~$ ./autogen.sh # maybe not needed
+host:~$ ./configure
+host:~$ make
+host:~$ make install DESTDIR=$PWD/build/
+
+
+

用 Yocto SDK 对目标machine进行构建的命令也是非常相似的。以下命令假设 SDK 已解压到目录 /opt/phytec-ampliphy/i.MX6-PD15.3.0/ （可根据实际情况修改路径）

+
host:~$ source /opt/phytec-ampliphy/i.MX6-PD15.3.0/environment-setup-cortexa9hf-vfp-neon-phytec-linux-gnueabi
+host:~$ ./autogen.sh  # maybe not needed
+host:~$ ./configure ${CONFIGURE_FLAGS}
+host:~$ make
+host:~$ make install DESTDIR=$PWD/build/
+
+
+

请参考官方 Yocto 文档以获取更多信息：https://docs.yoctoproject.org/dev/singleindex.html#autotools-based-projects

+
+
+
+

8.7.5. 使用Kernel模块

+

如果您需要为内核模块配置一些选项，或者将一个模块加入黑名单。您可以通过 udev 进行，并写入 *.conf 文件中。

+
/etc/modprobe.d/\*.conf.
+
+
+

如果您希望在构建过程中指定kernel模块的一些选项，则有三个相关的变量。如果您仅想自动加载那些没有自动加载功能的模块，请将其添加到

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+
+
+

无论是在kernel recipe中还是涉及到全局变量。如果您需要为模块指定选项，您可以这样做

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+KERNEL_MODULE_PROBECONF += "your-module"
+module_conf_your-module = "options your-module parametername=parametervalue"
+
+
+

如果您想将某个模块列入自动加载黑名单，您可以直接使用

+
KERNEL_MODULE_AUTOLOAD += "your-module"
+KERNEL_MODULE_PROBECONF += "your-module"
+module_conf_your-module = "blacklist your-module"
+
+
+
+
+

8.7.6. 使用 udev

+

Udev（Linux 动态设备管理）是一个系统守护进程，用于处理 /dev 中的动态设备管理。它由位于 /etc/udev/rules.d （系统管理员配置空间）和 /lib/udev/rules.d/ （供应商提供）中的 udev 规则控制。以下是 udev 规则文件的示例

+
# file /etc/udev/rules.d/touchscreen.rules
+# Create a symlink to any touchscreen input device
+SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="input:*-e0*,3,*a0,1,*18,*", SYMLINK+="input/touchscreen0"
+SUBSYSTEM=="input", KERNEL=="event[0-9]*", ATTRS{modalias}=="ads7846", SYMLINK+="input/touchscreen0"
+
+
+

有关语法和用法的更详细信息，请访问 https://www.freedesktop.org/software/systemd/man/latest/udev.html。要获取可以在 udev 规则中使用的设备属性列表，您可以利用 udevadm info 工具。该工具将打印出设备节点及其父节点的所有现有属性。输出中的键值对可以直接复制并粘贴到规则文件中。以下是一些示例。

+
target:~$ udevadm info -a /dev/mmcblk0
+target:~$ udevadm info -a /dev/v4l-subdev25
+target:~$ udevadm info -a -p /sys/class/net/eth0
+
+
+

更改 udev 规则后，您必须通知udev守护进程。否则，您的更改不会生效。使用以下命令

+
target:~$ udevadm control --reload-rules
+
+
+

在制定 udev 规则时，您应该监视事件，以便查看设备何时连接到系统或从系统断开连接。使用

+
target:~$ udevadm monitor
+
+
+

在另一个 shell 中监控系统日志也是非常有帮助的，尤其是在udev规则中执行了外部脚本的情况下。执行

+
target:~$ journalctl -f
+
+
+
+

小技巧

+

您无法在 RUN 属性中启动守护进程或大型脚本。请参阅 https://www.freedesktop.org/software/systemd/man/latest/udev.html#RUN%7Btype%7D 。

+

这仅适用于执行时间非常短的前台任务。长时间运行的事件进程可能会阻碍此设备或从设备的后续所有事件。启动守护进程或其他长时间运行的进程并不适合 udev；派生进程（无论是否和母进程分离）都将在母进程事件处理完成后无条件被终止。如果需要执行其他任务，您可以考虑使用特殊属性 ENV {SYSTEMD_WANTS} ="service-name.service" 和 systemd 服务。

+

请参阅https://unix.stackexchange.com/questions/63232/what-is-the-correct-way-to-write-a-udev-rule-to-stop-a-service-under-systemd。

+
+
+
+
+
+

9. 故障排除

+
+

9.1. setscene任务告警

+

当 Yocto 缓存处于dirty状态时会出现此告警。

+
WARNING: Setscene task X ([...]) failed with exit code '1' - real task
+
+
+

但是请避免强制取消构建，或者如果必须取消，请按一次 Ctrl-C 并等待构建过程停止。要删除所有这些告警，请清除 sstate 缓存并删除build文件夹。

+
host:~$ bitbake phytec-headless-image -c cleansstate && rm -rf tmp deploy/ipk
+
+
+
+
+
+

10. Yocto 文档

+

对于 BSP 用户来说，最重要的文档可能是开发人员手册。https://docs.yoctoproject.org/dev/dev-manual/index.html

+

关于常见任务的部分是一个很好的起始点。https://docs.yoctoproject.org/dev/dev-manual/common-tasks.html#common-tasks

+

完整的文档可以在一个单独的 HTML 页面上找到，适合用户搜索功能或变量名称。https://docs.yoctoproject.org/dev/singleindex.html

+
+ + +
+
+ +
+
+
+
+
+ + Languages + + +
+ +
+
语言
+ +
en
+ +
zh_CN
+ +
+ + +
+
+
Version
+
imx8mp-pd24.1.0-nxp-39-g585f711
+
+
+
+ + + \ No newline at end of file